Compete in OpenAI's WebMCP Challenge with Netlify. August 25, 2026 The WebMCP Challenge opens today. Netlify is partnering with OpenAI to support WebMCP and backing builders with 3 million credits and a $5,000 prize pool. To win, build a new agent-native web app, or add WebMCP support to one you already run. Join the challenge. For a lot of people, the web started as a directory, a hand-curated list of links on a site like Yahoo. Then came Google and search. That worked because the web was already open and able to be read. Crawlers could follow links and index pages without asking permission, with a handful of light conventions like sitemaps to guide them. WebMCP could be the next version of that, but reading isn't the same problem as acting. A crawler indexing a page is one thing; an agent booking a table or completing a checkout is another. It needs to know exactly what's safe to do and when to check back with you first. A casual operating agreement isn't enough for that. That's where WebMCP comes in. What is WebMCP? WebMCP is an experimental open web standard (currently a draft under the W3C's Web Machine Learning Community Group) that adds navigator.modelContext to the browser, letting a site expose structured tools an AI agent can call directly instead of clicking and typing through a normal interface. Instead of describing what you want to a search box, you'd describe it to an agent, and the agent would act on it directly, booking the table, checking the order, filling the form, using tools the site has explicitly defined instead of guessing its way through an interface built for a person with a mouse. Making the agents navigation a ton more efficient. How to add WebMCP to your site. ChatGPT's in-app browser supports WebMCP out of the box today, with permissioning and safety checks built in - the agent has to have access to a site before it can use its tools, and sensitive actions like purchases or messages still require confirmation. You can also test WebMCP in Chrome paste chrome://flags/#enable-webmcp-testing in your browser and enable it. In practice, adding WebMCP to a site is a small amount of code that lets you register a tool with a name, a description, and a schema, and tells the agent to use a function your site already has. It looks like this: For the full API, security model, and schema details, see the WebMCP spec. What can help you for the challenge. Netlify wanted builders to have working code to start from fast, so Netlify published five demo apps you can read and prompt or fork: * WebMCP starter: a prompt-first starting point. Copy the prompt, hand it to your agent, and it builds and deploys the site on Netlify using Agent Runners. * Kurio: a fictional marketplace where an agent can search products, add items to a cart, and complete a simulated checkout. Its /learn page shows exactly what the agent sees. * Tagboard: a public guestbook where agents can read and post notes, with every write moderated through Netlify's AI Gateway. * Mabel's Table: a fictional restaurant where agents work against live reservation state. They can hit a fully booked slot, negotiate alternatives, place holds, confirm or cancel bookings. * The Archive: a detective mystery built for a person and their agent to solve together, where some clues are visual and others are only reachable through tools. Each one is live, forkable, and meant to show a different pattern for putting WebMCP to work. Start building with Netlify. As an open standard, WebMCP is a positive step toward that future and why Netlify is excited to support OpenAI's WebMCP Challenge. * Aug 25, 2026 11 a.m. PT: the challenge opens. * Aug 25, 2026 3 p.m. PT: kickoff livestream with example apps and implementation ideas. * Aug 31, 2026 11 a.m. PT: community office hours with its team. * Sep 3, 2026 5 p.m. PT: submissions close. * Sep 23, 2026: winners announced. Netlify think the agent-native web should be built in the open, by a lot of people at once. Come build something, and come talk about it with Netlify on Discord.

The two-person team: the domain expert prompts, the engineer connects. At RenderATL I had the same conversation twice, from two different sides. The first was at the Commit Awards with Mat Biilmann, Netlify's CEO. The second was the next day, in the expo hall, with Danny Thompson, developer advocate and one of the most grounded voices on what AI actually changes about the job. Mat is watching a new kind of builder show up: the domain expert who no longer needs an engineer to translate their idea into an app. Danny is watching engineers panic that this makes them obsolete. Both of them are right, and the interesting thing is that they're describing the same team from opposite ends. Here's the team I think is forming. The new two-person team. Picture an HR business partner who is tired of the sentiment survey tool her company pays for. She knows exactly what she wants: the questions, the cadence, how the results should roll up. What she's never had is a way to build it without filing a ticket and waiting two quarters for it to climb the engineering backlog. Now she prompts a coding agent and gets a working app. Mat tells a version of this story about a real HR partner who replaced Culture Amp with her own app, built alongside a single developer, "cutting out the product-manager-to-engineer translation loop entirely." She decides what to build. The agent handles most of how. That split is the whole story. Anthropic's Economic Index put it plainly earlier this year: "people decide what to build, and the agent decides how to build it," and the more understanding a person brings to the agent, the better the work that comes back. Non-engineers in that study landed within a few points of professional software engineers on task success. The domain expertise turns out to be the scarce part. The code was never the point. The temptation is to read this as "agents replace engineers," which is wrong. This isn't about replacing engineers. It's about the enormous queue of software that domain experts need and can't get, because it sits too far down engineering's backlog to ever ship. The internal tool that would save one team ten hours a week but doesn't clear the bar against revenue work. The one-off app for a single department, all the software that matters to somebody but never matters enough to fund, that's the queue that's about to drain. And it drains by empowering the people who feel the pain, not by firing the people who build. Where the agent stops. The agent gets you a long way, fast, and then hits a wall. Addy Osmani named this the "70% problem": non-engineers "get 70% of the way there surprisingly quickly, but that final 30% becomes an exercise in diminishing returns." The last stretch, the requirements you didn't know to state, the edge cases, the security, the performance, still needs human judgment. And notice where the wall is. The app itself, the thing the agent generates, is usually the easy part now. The wall is everything the app has to touch. Real authentication, the existing database that already holds the company's data, the internal API that speaks a format nobody documented, the third-party system with a rate limit and a login flow. Mat is blunt about this: agents "excel at generating code," but "the path from prompt to production is still filled with obstacles," and the hardest of those is working "with existing legacy code bases and data sources." This is not a cosmetic gap. The Cloud Security Alliance surveyed 5,600 vibe-coded apps and found that zero of them had CSRF protection, security headers, or properly scoped access policies. The demo runs, the wiring to the real world is missing, and when it's there, it's often wrong in ways the person who prompted it can't see. That gap has a name in a dozen different write-ups: the "70% problem," Vercel's "90% problem," the "last mile." They're all pointing at the same seam: the code generates, the connections don't. Connectivity is the job now. So what does the engineer do on the two-person team? They own the seam. Not the app, the domain expert can conjure the app. The engineer builds the connective tissue: the API that exposes the legacy system cleanly, the auth that actually holds, the integration that lets the shiny new tool read from the warehouse of record. Yoko Li at a16z put it well: "agents can generate a lot of code, but they still need something solid to plug into." The engineer builds the "something solid." Danny frames the human half of this as well as anyone. His line is that "the prompt-and-pray era is over - and that's a good thing," and that your value now is "caring, context, judgment, and composing solutions." Not typing the app into existence, but composing the systems it depends on, and having the judgment to know where it will break. He talks about the real production work as state orchestration, constraint generation, infrastructure reliability, and regression testing - none of which the agent volunteers, and all of which decide whether the thing survives contact with real users. That's a promotion, not a demotion. The engineer stops being the translator between a PM's intent and a codebase, the slow, expensive step in the middle, and becomes the person who makes the domain expert's app real. Higher leverage, less busywork, more of the work that was interesting in the first place. So how do you trust what got shipped? There's a harder question hiding under all of this, and it's the one an engineering leader should actually lose sleep over. When the person building the app can't read the code, "does it work?" stops meaning "does it compile" and starts meaning "does it do the right thing against real systems, safely, every time." Correctness moves up a level. And the place it's most likely to fail silently is exactly the seam the engineer owns: the API call that succeeds with the wrong scope, the integration that returns stale data, the auth path that lets the wrong person through. Which means the engineer's contribution isn't just building the connectivity. It's proving the connectivity behaves. Tests, evals, observability into what the app actually does in production: these stop being hygiene you get to later and become the deliverable. On a team where one person can ship something they can't fully inspect, the person who can inspect it is what keeps it trustworthy. That's not overhead. On this kind of team, it's the point. The team didn't shrink. It re-specialized. Go back to the two conversations at RenderATL. Mat is right that the translation loop is collapsing and a new cohort of builders is showing up. Danny is right that the engineer's value didn't evaporate. It moved. Put them together and you don't get a smaller team. You get a differently-shaped one: the domain expert who knows what to build and can now prompt it into being, paired with an engineer who gives that creation a nervous system, the connections to real systems, and the proof that those connections hold. For anyone staffing or leading engineering, that reframes the whole question. The goal was never to protect engineers from agents, or to replace engineers with them. It's to finally ship the mountain of software that real people needed and never got, because it lived forever at the bottom of a backlog. The domain experts can start it now. The engineers are what make it real.

Summer Summit: what I learned by getting stuck on its own product. * Home * / * Blog * / * Article August 8, 2026 Last week at its Summer Summit Buildathon, the entire Netlify company came together to build on Netlify Agent Runners. Like everyone else, I set out to build a site that would publish blogs to multiple websites. I didn't get very far. Instead, I got stuck. And that turned out to be the most valuable part of the day. I wasn't reading customer feedback. I was the customer. I experienced exactly what a new builder experiences. I wasn't reading customer feedback or watching a demo. I was the customer. I hit a step that asked me to configure a build hook and connect it to a repo. Then I got an error: "Build hook could not configure." My immediate reaction was, "What is a build hook?" One error message changed how I think about its product. That one moment changed how I think about its product. It reminded me that every confusing workflow, every unclear error message, and every assumption Richardterrylloyd make creates friction for someone trying to build. Watching its engineers, true professionals, work through these challenges also gave me a deeper appreciation for the craft that goes into building great developer tools. The lesson came from getting stuck. The biggest lesson, though, came from getting stuck myself. The executive who experiences their own product the way a first-time customer does isn't wasting time. They're getting the most honest product feedback possible. If you lead a platform company, spend time building on your own platform. You'll learn things no dashboard, customer interview, or product review can teach you. If you've had a moment like this on your own platform, I'd love to hear about it. Find me on LinkedIn.