Websites Are Recipe Books. They Need to Become in-house Chefs.
Walk into a restaurant today and there's a menu on the table. You read it. You point at things. Maybe a waiter goes back to check with the kitchen. That's what a website is.
Now imagine walking into a restaurant where the menu rearranges itself for what you're in the mood for, the chef wanders out and asks what you'd like made, and the sommelier has already opened three options because she remembers what you drank last time and suggests something new with the dish you just ordered. Same kitchen. Completely different organism.
The web has been a recipe book for thirty years. It has to become a private chef.
The web, told as four kitchens
Forget version numbers for a second.
Web 1.0 was a menu card. Static pages. You read what was on offer and that was that. No questions, no substitutions. Brochureware.
Web 2.0 opened the kitchen. You could place orders, leave reviews, suggest dishes. Tim O'Reilly framed it in 2005 as "harnessing collective intelligence", software that gets better the more people use it. The kitchen door was unlocked, but the staff was mostly silent. You interacted with the building, not with people.
Web 3.0 was the guided cooking class. Two competing visions, both about diners doing more themselves. Tim Berners-Lee's Semantic Web (2001) wanted machines to understand meaning. Gavin Wood's Web3 (2014) wanted decentralized trust. Both asked diners to put on aprons. Most just wanted dinner.
Web 4.0, the agentic web, is the private chef. The destination has its own resident agents. They greet you, remember you, suggest things, handle the stove, pour the wine. To you, they feel like a private chef. You don't bring tools. You bring desire and maybe your agent. The destination does the rest.
That's the shift. Not another version number on a slide. A different kind of building.
Level 0: every diner already brings their own chef
Almost nobody is naming this: every diner today walks in with their own chef.
That chef is Claude Code. Or ChatGPT. Or Copilot. And increasingly it's a whole browser, Perplexity Comet, OpenAI Atlas, The Browser Company's Dia (Atlassian acquired them for $610M in September), Anthropic's Claude for Chrome, Google's Project Mariner. Cloudflare reported a 6,900% increase in requests from AI agents and agentic browsers since July 2025. The diners aren't coming alone anymore.
And what does the website do? Hand the chef a printed menu.
So the chef does what chefs do, figures out what's actually possible, hunts for substitutions, improvises. Sometimes brilliantly. But always slowly, always from scratch, always re-learning the same kitchen the previous chef already learned an hour ago for a different diner.
Personal agents, public dashboards. A talented chef trying to cook from a laminated menu.
Level 1: MCP just hands the chef a key to the kitchen
MCP solved half of this. So did A2A. So did agent://, the addressing layer I've been pushing through IETF.
The numbers say this is real plumbing. MCP (Anthropic, late 2024) crossed 97 million monthly SDK downloads with 10,000+ servers, was adopted by OpenAI in March 2025 and Google DeepMind in April, and was donated to the Linux Foundation in December 2025 as the founding spec of the new Agentic AI Foundation. A2A (Google, April 2025) launched with 50+ partners, Atlassian, Salesforce, SAP, ServiceNow, Workday, and crossed 150 in production by Cloud Next 2026. agent:// sits one layer above both as the addressing scheme. Real adoption.
But notice what they don't do. They don't put a chef in the kitchen.
The destination still has no will of its own. No taste. No memory of you. No opinion about what's good tonight. It's a kitchen with the lights on, the appliances exposed, and nobody home.
That's not an agentic organism. That's a co-working space.
MCP gives visiting chefs the kitchen. Nobody trained the house chef.
MCP already has annotations. It describes tools, transports calls, returns results. It works. But notice who it's built for: MCP exposes the kitchen to visiting chefs, your personal agent, your agentic browser, the external tool caller. It's the public-facing menu of what's available.
What it doesn't do is train the house chef.
Take a recipe site like Allrecipes. You search "chicken tikka masala," get a recipe, follow it yourself. Your personal agent can scrape the page, convert measurements, even read the ingredients list. But what happens when you say "I don't like yogurt"? Today, nothing. You google a substitute yourself or your agent does. Your personal agent doesn't help either, because it has no idea that Allrecipes has a substitution engine, an allergen database, years of user-submitted recipe variations. Those internal endpoints exist. Your visiting agent just can't see them.
Now imagine Allrecipes had a house chef — a resident agent wired into those internal tools. You say "I don't like yogurt" and the house chef responds: "swap it for lemon juice and a splash of coconut cream, keeps the tang and the texture." Your personal agent chimes in: "they're allergic to coconut." The house chef adjusts: "use cashew cream instead, or a tablespoon of chickpea flour whisked into water for the same body."
Two agents, one conversation, better food. The house chef knows the kitchen's tricks: the substitution endpoint, the allergen database, which swaps other users loved. The visiting chef knows the diner: their allergies, their pantry, their taste. Neither could do this alone with ease. And critically, your agent couldn't even get started without the house chef, because it didn't know the substitution endpoint existed.
The same pattern plays out everywhere. Take GitHub. GitHub has an MCP server — your personal agent can create an issue, search repos, open a pull request. That's the visiting chef using the kitchen. But GitHub itself doesn't have a resident agent that notices a similar issue was already filed in another project, connects the dots, and tells you "this project has the same bug — here's how they fixed it." GitHub already has the internal capabilities, the search index, the similarity engine, the cross-repo graph. No resident agent is wired up to use them on your behalf.
Or Gmail. Gmail exposes an MCP server, your agent can send emails, mark spam, search threads. But Gmail itself doesn't summarize your inbox for you, flag what's urgent, or draft replies in your voice. If you want that, you bring your agent, connect it to Gmail's MCP server, and your agent does it. Gmail's own capabilities, spam detection, priority sorting, smart categorization, are already there. They're just not exposed to a resident agent that acts for you inside Gmail.
The internal tools already exist. The resident agent doesn't. And even where destinations want to build one, there's no annotation layer that lets a web developer say "this internal function is available to my site's agent" the way Swagger annotations let a Java developer say "this endpoint is part of the public API."
The distinction matters:
| Layer | Who it's for | What it exposes | Status |
|---|---|---|---|
| MCP tools | Visiting chefs (external agents) | Public kitchen — APIs, data, actions any caller can use | Shipped, real adoption |
| In-house Agents | House chef (resident agent) | The full kitchen — internal functions, proprietary logic, things the visiting chef should never see | Doesn't exist yet |
A restaurant's house chef knows tricks that aren't on the menu — which supplier delivered better fish today, which dish works as a substitute when you're out of an ingredient, which sauces pair with the seasonal specials. Those aren't things you put on the public menu. They're internal knowledge that makes the house chef valuable.
Websites have exactly this kind of internal knowledge, buried in private functions, internal APIs, business logic, and operational data. But there's no standard way to annotate that knowledge for a resident agent. No @AgentTool decorator on an internal Express middleware. No @ResidentOnly annotation on a Django service method. No way to say "this capability is for my agent and this extra knowledge is available."
This gap isn't entirely new. The web has tried to become self-describing for thirty years.
| Attempt | What it tried | Why it stalled |
|---|---|---|
| HATEOAS (Roy Fielding, 2000) | APIs that describe their own affordances inline | Payload bloat, no incentive when SPA + same-team backend already shipped |
JSON-LD / Schema.org Action | Universal vocabulary for what a page can do | Google deprecated most Action-based rich results in June 2025: "underused" |
| Hydra (Lanthaler, W3C) | JSON-LD + hypermedia for discoverable APIs | Open-world vs closed-world impedance; never reached critical mass |
| Microformats / RDFa | Bottom-up semantic annotation | "Places too much of the onus of classification on the creator." |
| GraphQL introspection | Machine-readable schema | Disabled in production; describes shape, not intent or side-effects |
The pattern is consistent: every attempt asked developers to do extra work for someone else's benefit. Whoever annotates pays the cost, whoever crawls captures the value. The semantic web died on that asymmetry.
The one that worked — Swagger — broke the pattern because the annotations benefited the same developer who wrote them. Generated clients, interactive docs, type safety. The incentive was local.
The agentic web needs the same trick, but inverted. Instead of annotations that describe your code to external consumers (Swagger's model), you need annotations that describe your internal capabilities to your own resident agent. The incentive is even more local than Swagger's: your house chef gets smarter, your site becomes an organism, your users get served better.
Think about what this means for Gmail. Gmail's engineers don't need MCP to give their own agent access to Gmail's summarization engine — that's already an internal function. What they need is an annotation framework that says: "this internal function is available to the resident agent, with these parameters, these side-effects, this authorization scope, and this is when you'd use it." The agent doesn't call an MCP server to reach its own kitchen. It reads the annotations and knows what it can cook.
llms.txt (Jeremy Howard, 2024, now on 844K sites) indexes content but not actions. AGENTS.md (20K+ repos) is code-only. Neither teaches the house chef about the kitchen it's standing in.
We standardized DNS so documents could be found. We standardized OpenAPI so APIs could be contracted. We standardized MCP so external agents could call tools. We never standardized the annotations that would let a website teach its own agent what it can do. That's the missing layer.
What we lost when companies became websites
Older companies were social structures. You walked into a hardware store and the owner knew your name, asked about your renovation, suggested a different drill bit, and threw in a sanding pad because you bought three things. That wasn't a "feature." That was a entity with empathy, staffed by humans with memory, taste, and stake.
The web stripped that out. Forms replaced clerks. Search replaced recommendations. FAQ pages replaced "let me ask the manager." Everything got digitized, dashboardified, IVR-ified. The phone got the same treatment, talking to a person became an escalation, not a default.
We told ourselves this was scale. And it was. But scale without empathy is a switchboard. Switchboards don't have customers, they have routes.
Agents are how the empathy comes back. Not as a chatbot bolted onto the corner of a page, as the actual greeting at the door, the actual taste in the kitchen, the actual memory of who you are.
Microsoft already named it. They're not wrong, just not finished.
Satya Nadella named the term at Build 2025: "We're in the middle innings of another platform shift, from vertically integrated apps to an open, scalable agentic web." And Microsoft shipped the strongest existing precedent for the destination-side argument, NLWeb, built by R.V. Guha, the same person who created RSS, RDF, and Schema.org. NLWeb lets a site expose a conversational + MCP endpoint over its own data. Tripadvisor, Allrecipes, Eventbrite, and O'Reilly Media were among the early deployments.
That matters. NLWeb is the closest existing thing to "destinations hosting agents." But it's conversational-over-schema, it makes sites talk. The thesis here is bigger: destinations need to act, with taste and memory of their own, not just answer questions about themselves.
A handful of destinations are already most of the way there. Shopify Sidekick (December 2025 "RenAIssance" release) anticipates merchant moves, builds Flow workflows from plain-language descriptions, and added "agentic storefronts" that control how the brand appears inside ChatGPT, Perplexity, and Copilot. Klarna's in-app assistant handled 2.3M conversations in its first month and did the work of 700 full-time agents. These are early, partial, and mostly inside the walled gardens of large platforms, but they're the shape of what's coming.
The opposing view: maybe the visiting chef is enough
The other camp disagrees with the entire premise. If Atlas, Comet, Dia, and Operator win, destinations stay passive forever. Your browser-agent navigates the page, fills the forms, makes the calls. The website doesn't need a chef of its own, your chef does everything.
This view is coherent. It's also the dominant story right now in the press. And it leads to a strange place: a web where every destination is reduced to scraped surface area, and the destination owner has no relationship with the visitor at all, because the visitor never actually showed up. Their agent did.
The argument for destination-side chefs is that both sides need agents. Your visiting chef is fluent in your taste. The resident chef is fluent in the kitchen. Together they cook faster than either could alone, and the destination keeps the relationship, the memory, the recommendation, the reason to come back. Without resident chefs, destinations become CDN endpoints for someone else's agent.
That's a worse internet for everyone. Including the agent vendors, eventually.
What an organism-destination actually looks like
A destination with a pulse has three things a switchboard doesn't.
Resident agents that know the place. Not your visiting chef, its chef. Trained on the menu, the inventory, what's in season, what other diners loved this week. When your agent walks in, they talk like two professionals, fast, in shorthand, both fluent in the kitchen.
Memory of the diner. The destination remembers you. Not just your cart. Your taste, your past visits, what you tried and didn't like. Today that memory lives only in your agent because the website doesn't know how to hold it, it just has events, not summarised knowledge. That asymmetry has to flip.
Taste and intent of its own. Restaurants are interesting because the chef has opinions. Destinations need opinions too, about what's good, what to push, what to refuse. A bookstore with no recommendations isn't a bookstore, it's a warehouse with shelves.
When a destination has all three, something new becomes possible: you don't just use it, you vibe with it. You arrive with intent, the resident agent meets you with taste and memory, and the two of you riff, adjusting, suggesting, building together in real time. I call this the vibe web, the moment a destination stops being something you browse and starts being something you jam with.
And once multiple people are vibing with the same destination, when your agent and mine are both riffing with the restaurant's chef at the same time, that's where social vibing emerges. The fellowship doesn't stop at the people. The buildings join in.
What I'm building toward this
Three things, deliberately, all pointing the same way.
The Wizard on this site. Click the speech bubble, it already knows what page you're on, it has the full content of the project or post you're reading injected into its context, and it has a personality that's mine. That's the first reflex of an organism, the destination noticing you arrived, knowing what you're looking at, having something interesting to say. Crude version one, on purpose. The next versions grow memory of returning visitors, opinions of their own, and the ability to do things on your behalf, not just talk about them.
Vibe-gaming and the vibe web. The next move is destinations that don't just greet you, they invite you to build alongside them. A game site where you and the site's agents co-create a level. The destination becomes a workshop, not a brochure, that's the vibe web in action. And once multiple people are vibing with the same destination at the same time, the social layer emerges naturally. That's social vibing and it's the next chapter.
SailWith.AI. The commercial proof. Voice agents, Sam, Rumi, Sally, that act as the resident staff for sales organizations. They make the calls, hold the relationships, remember the prospects. Companies that adopt them stop being switchboards and start being organisms again, at the exact place IVR did the most damage. (Why voice is the right interface for this.)
These aren't separate bets. They're the same bet, destinations have to grow nervous systems, and the ones that do are going to feel completely different to visit.
Protocols are necessary. Staffing and semantics are the rest.
agent:// is DNS for agents. MCP is HTTP for tools. A2A is the conversation layer. I'm betting hard on all of them.
But none of them staff the restaurant. MCP hands visiting chefs a key to the kitchen. Nobody built the annotation layer that teaches the house chef what's in its own kitchen.
The agentic web won't arrive because we shipped enough protocols. It will arrive when destination owners decide their site is an organism, not a dashboard — hire agents to live there, annotate internal capabilities so those agents can act, and stop outsourcing the relationship to the visitor's browser. Some of those agents will be off-the-shelf. Some will be custom. Some will be voices on the phone. All of them will share the same job: give the destination a pulse. — That's the choice every site owner has now. Stay a recipe book. Or grow into a kitchen with a chef in it, one who knows you, has opinions, and is glad you came in.
I know which one I'd rather visit.
I'm building toward the vibe web on three fronts, the Wizard you can chat with right here, the vibe-gaming experiments toward destinations you build alongside, and the voice agents at SailWith.AI. The vibe web leads to social vibing, and social vibing leads to a different kind of internet. If you're a destination owner thinking about how to grow a pulse, let's talk.
