The Agent Web Looks a Lot Like 1995
You have probably seen it already. Someone asks an AI assistant to do something small, renew a prescription, change a reservation, check a bank balance and move money from one account to another. The assistant can read the page. It can tell you what the form does. It can't act. The session belongs to the browser. The checkout belongs to a payment network that expects a human. The speciality the task really needs is locked inside a different vendor's agent, with no shared handshake between them. The user is sitting in front of a machine that knows exactly what it should do and can't do it.
The web itself isn't broken. The agent web is. It's hostile to the machines users are now sending into it, and the worst part is that the reason is familiar. We have been here before. The last time we were here, it took about a decade to get out.
A pattern from thirty years ago
In 1995, if you wanted a web page to look right, you wrote one version for Netscape and another for Internet Explorer. There were tags that worked in one and crashed the other. Ambitious sites shipped two codebases. Less ambitious sites told their users which browser to install. The problem wasn't that browser vendors shipped features. The problem was that each vendor's early lead became the next decade's lock-in, and nobody outside the vendors had enough of a voice to pull them towards a shared standard. When the pull eventually arrived, it came from communities, standards bodies, working groups, developers who refused to keep doing the work twice, users who refused to install a second browser. That work was slow and unglamorous. It's also the only reason a web page written once can, today, run everywhere.
The agent web is at that same point right now. The pieces we're already seeing shipped look like this.
Four protocols, two discovery surfaces
MCP, the Model Context Protocol, came from Anthropic. It gives a running model a standard way to ask "what tools do you have for me, and how do I call them?" It's the tool layer. A site that wants a specific capability to be machine-callable, a search, a booking, a status lookup, declares it through an MCP server and the model picks it up. Adoption has been broad; most of the major AI vendors now speak MCP in one form or another.
A2A, Agent2Agent, came from Google and now sits with the Linux Foundation. It answers a different question: how does one agent hand a task to a counterpart, when the two were built on different frameworks by different companies? An agent publishes an "Agent Card", a small public manifest saying what it can do and how to reach it, and other agents read the card and negotiate. It's the agent-to-agent layer. Useful exactly when the task crosses a boundary between teams.
UCP, the Universal Commerce Protocol, also came from Google, in partnership with a set of retailers. It's the commerce layer: a standardised envelope for machine-initiated purchases, so an agent can complete a transaction without pretending to be a human clicking through a checkout form designed for humans. A parallel proposal from OpenAI and Stripe, ACP, is tackling the same problem with slightly different assumptions about credentials and liability. Retailers are mostly picking one, hedging, or waiting.
WebMCP is the newest and the one closest to the user's browser. It's a proposal, incubated at W3C with Microsoft's Edge team in the lead, to let a web page itself be an MCP server, exposing tools that run inside it, with the user's already-authenticated session, under the browser's existing security model. It's the browser-session layer. It's how the assistant finally acts on the prescription the user is already signed in to renew.
Then there are the discovery surfaces. llms.txt is the small plain-text file a site publishes to describe itself to an AI reader - what it covers, what parts are worth indexing, what rules apply. Agent cards are the equivalent at the agent layer, a public manifest that says "this agent exists, this is what it can do, this is how to talk to it." Together they're the signposts. They say "here's what this thing is, and who is allowed to act on it." Neither is settled, neither is universal, both are live proposals moving through their own venues.
Four protocols, two signposts. None of them addresses the whole.
The gap that matters
Here's the part that might be less obvious. The gap in this field isn't another protocol. We don't need a fifth acronym.
The gap is that none of the existing venues convene the stack as a whole. MCP has its governance. A2A has the Linux Foundation. UCP has its retail partners. WebMCP has a W3C Community Group. llms.txt and agent cards are each maintained in their own repositories by their own people. Every piece has a venue. The stack has none. There's no single place where a developer, a site owner, an accessibility advocate, a user-rights group or a standards-minded engineer can turn up and argue, in public, about how these pieces fit together, what breaks when they don't, who's responsible when they disagree, what the user actually needs from them as a whole.
That's a standards-community gap, not a technical one. Standards-community gaps don't get filled by vendors. They get filled by communities that decide to fill them.
Why we built The Gathering
The Gathering is a vendor-neutral forum built for exactly this gap: a venue for the dialogue between the existing venues rather than another protocol or a consortium selling seats at the table - the conversation that went missing in the 1990s and got retrofitted at enormous cost a decade later.
Our posture is the one community standards bodies have always taken when they have worked. Drafts are written in public. Reviews happen through Stream, a public review process that anyone can read, comment on, and no single vendor can override. The drafts are proposals, not decrees, they're expected to change in response to what the community finds. There's no membership fee, no gating, no editorial capture.
Be honest about the scale: we're early. A community-led body earns its legitimacy from the number and diversity of people who turn up. Nothing in our approach can substitute for that. The drafts we have today are a beginning, not an ending. They will be better in six months because of the people reading them now. They will be unrecognisable in three years if the community we're convening actually convenes.
The technical details - which fields go in the core, which extensions are vendor-neutral, which protocols fit where in the stack, which discovery surfaces a site should publish first - belong on tg.community and in Stream. This post is the invitation, not the brief.
How to show up
If you are a practitioner
We need you. You're a developer, a site owner, an accessibility advocate, an agent builder, a platform engineer, a standards-minded person with opinions about how machines should read pages. You have watched the 1995 pattern happen before and you know how it ends if nobody pulls on the other rope.
Turn up to Stream. Read the current drafts. Push back on the parts that are wrong. Add the parts that are missing. Bring the perspectives the current drafters don't yet have, particularly if you work in a region, a vertical, or a user community whose needs aren't being heard in the existing vendor-led venues. The review process is public and the comment surface is low-ceremony. The only thing it costs is time, and what gets built without it is the version of this stack that serves whoever was in the room when the drafters wrote it first.
Start at tg.community. The Stream review process is linked from there.
If you run a company in this space
We welcome sponsors. Community-led standards work needs sustainable infrastructure, review venues, editorial capacity, legal support, convening cost. A vendor-neutral body can't stay that way if it depends on any single vendor to keep the lights on, and it can't do the work the community needs if it depends on unpaid time alone. Sponsorship is how companies that care about the outcome help fund the work without buying a seat at a table that, by design, doesn't have seats for sale.
If your company builds products or serves users in this space - agent platforms, browsers, CMS vendors, retail infrastructure, accessibility tooling, payments, identity - reach out. The same tg.community page has the sponsor enquiry route.
Further reading
If you want to see what the "written in public" approach looks like applied to the metadata layer rather than the protocol stack, A Standard That Knows What It Isn't walks through how MX, the machine-readable standard being drafted under The Gathering, stays deliberately small and defers to Dublin Core, Schema.org, DCAT, and IETF rather than duplicating them. The broader body of MX work, including the ongoing book series, is at mx.allabout.network. Both are good places to see the approach in motion before deciding whether the posture is one you want to help shape.
One last thing
The agent web doesn't have to repeat the browser wars. The escape hatch from vendor fragmentation has always been the same: a community that refused to wait for vendors to agree, that wrote its standards in public, that insisted on the seams being documented, and that earned the right to be taken seriously by showing up week after week until the work was done. That's the invitation. The rest is timing.
The next decade is still available. Help us build it.