The IETF is meeting in Vienna this week, and the agenda tells a story that most of the AI industry has not noticed. Three separate birds-of-a-feather (BoF) sessions are dedicated to AI agents: agentproto for agent communication, DAWN for discovery and naming, and DMSC for gateway-mediated collaboration. A fourth proposal, AUDIT, covering agent accountability, did not make the cut and is waiting for the next meeting.

Behind those sessions sits a volume of paperwork that has no precedent in the organization’s forty-year history. I maintain a living document tracking every AI agent standardization effort in or targeting the IETF stream. The current count exceeds 250 Internet-Drafts across 17 distinct categories. Agent identity and authorization alone account for more than 50 competing proposals. Discovery and naming have roughly two dozen. Audit and accountability has over 30, including a single author who has filed a twelve-document protocol suite.

For context, OAuth 2.0, the authorization framework that underpins most of the modern web, emerged from a handful of competing proposals over several years. The agent space has produced an order of magnitude more paperwork in roughly eighteen months.

What an Internet-Draft actually is

Before concluding the volume, it helps to understand what the volume represents. Anyone can file an Internet-Draft. There is no review gate, no membership requirement, no fee. The document expires in six months unless refreshed, and the IETF’s own boilerplate instructs readers to treat every draft as work in progress with no formal standing.

That low barrier is a feature. It is how the IETF has always worked: rough consensus and running code, with the paperwork serving as a conversation starter. But it also means the 250-draft figure contains at least three very different kinds of documents.

The first kind is serious engineering. Drafts from working groups like WIMSE, chartered documents in AIPREF, and the Web Bot Auth architecture that Visa and Mastercard have already adopted for agent payment verification. These have authors, implementations, and institutional weight behind them.

The second kind is flag-planting—a provisional patent by another name. Filing a draft creates a permanent, timestamped public record on the Datatracker, and a growing number of startups have discovered that “we filed with the IETF” reads well in a pitch deck. Several prominent identity drafts shipped with placeholder Security Considerations sections, which tells you how much protocol engineering happened before the filing.

The third kind is genuine exploration by practitioners who see a real gap and are thinking out loud in public. I count myself in this group. I have filed a suite of drafts defining AGTP, a dedicated transport substrate for agent traffic, so I am a participant in this flood, and I have an obvious stake in how it resolves. Read everything that follows with that in mind.

Why the flood is happening

The volume is a symptom, and the underlying condition is real. AI agents break assumptions that the internet’s existing protocol stack was built on.

Identity systems assume the actor is a human or a fixed workload. An agent is neither. It acts on behalf of a human, delegates to sub-agents, spins up and disappears in seconds, and needs its authority to attenuate as it passes down a chain. OAuth was designed for none of this, which is why more than 50 drafts are trying to retrofit it, extend it, or replace it.

Discovery systems assume you know the name of the thing you want. Agents need to find capabilities, negotiate contracts at request time, and verify trust in counterparties they have never seen. DNS was designed for none of this either, which is why DNSOP is suddenly full of agent naming proposals and why DAWN exists at all.

Accountability barely exists as an internet-layer concept. When an agent chain executes a financial transaction across four organizations, the question of who authorized what, and how you prove it later, has no standard answer. Regulators are already asking. The EU AI Act’s logging and human-oversight obligations appear as explicit motivations in multiple drafts, which means compliance pressure is now shaping wire protocols.

Every one of these gaps is legitimate. The problem is that 250 uncoordinated answers to legitimate questions produce a different kind of failure than no answers at all.

The fragmentation underneath the fragmentation

The draft count is the visible symptom. The structural issue is venue sprawl. Agent identity work is scattered across OAuth, WIMSE, SPICE, SCIM, RATS, and at least one side meeting. Discovery spans DNSOP, the DAWN effort, and a half dozen independent submissions. Audit has no home at all after the AUDIT BoF was deferred.

Meanwhile, nobody at the IETF currently owns cross-cutting agent security. Prompt injection across agent boundaries, confused-deputy failures in delegation chains, tool poisoning. These threats span every category, and no working group is chartered to model them. Two hundred drafts, and the most important document, a shared threat model, does not exist.

This is the pattern I would flag for anyone building in this space. Standards bodies fragment along the same lines as the thinking they host. When the venues cannot agree on whether agent identity is an OAuth problem, a workload problem, or a new problem entirely, that disagreement is architectural, and it will not be resolved by filing draft number 201.

The incentives shaping the paperwork

Watch the author lines on these drafts, and a pattern emerges. The majority of proposals extend whatever their sponsor already ships. Identity vendors file identity drafts that assume their directory sits in the middle. Cloud and network providers file gateway drafts that assume their gateway. Payment networks back the verification scheme their rails already support. Each filing is rational for its author, and the sum is a standards process optimized for speed to market and commercial position.

What is missing from almost every draft is the question a standards body exists to ask: what is the best possible standard we can create? That question rarely survives contact with a quarterly roadmap. The internet’s foundational protocols were written by engineers who asked it anyway, often against their employers’ short-term interests, and the difference shows four decades later. The current flood inverts that tradition. The fastest path and the most economically rewarding path have become the default paths, and the right path has no sponsor.

The hard question nobody wants on the agenda

There is a structural question sitting underneath all 250 drafts, and the community keeps stepping around it: why is everything being built on top of HTTP?

HTTP was designed for humans requesting documents. Agent traffic needs persistent sessions that survive network interruptions, delegation chains carried at the wire, attribution bound to every action, and intent semantics far richer than GET and POST. Every one of those properties is currently being reconstructed at the application layer, independently, in dozens of drafts, with incompatible results. When more than 50 identity proposals each reinvent delegation on top of a transport that has no concept of it, the transport is the problem.

I have filed drafts arguing for a dedicated agent transport substrate, so my position here is declared. But the question stands on its own merits. The IETF standardized QUIC because someone was willing to ask whether the incumbent layer still fit the traffic. Forty years of precedent says the organization knows how to ask that question. On agents, it has not yet put the question on an agenda.

Applications wearing protocol costumes

The third pattern is a category error. A protocol defines rules that any two parties can implement independently and interoperate. An application defines a product. A growing share of the drafts in my tracking document are the second thing formatted as the first: a vendor’s architecture, its SDK assumptions, and its deployment model, wrapped in RFC boilerplate and submitted to the Datatracker.

The tell is simple. Ask whether two strangers could read the document, implement it separately, and interoperate without the author’s platform in the loop. For a genuine protocol, the answer is yes. For much of what is being filed, the honest answer is that you would end up running the author’s product. Standardizing an application locks the internet into a vendor’s roadmap, and the IETF has spent four decades refusing to do exactly that. The volume of the current flood is testing whether that refusal still holds.

What actually converges

History offers a filter. Protocol wars are settled by three things: running code, deployment pull, and venue fit. Web Bot Auth is the proof case in this cycle. It went from proposal to chartered working group to adoption by the two largest payment networks in under two years, because Cloudflare shipped it, commerce needed it, and the scope was narrow enough for a charter to hold.

Most of the 250 drafts will expire quietly. The six-month clock is the IETF’s most honest mechanism. What survives will be the work with implementations behind it, a deployment constituency pulling it forward, and a venue where consensus can actually form. Everything else is a timestamp.

The agent internet is being designed right now, in public, in six-month increments, by whoever bothers to show up. The scale of the draft flood tells you how many people believe the current stack is inadequate. It does not tell you who is right.

So here is the question worth asking about any agent standard your organization is betting on: does it have running code, a deployment constituency, and a venue where consensus can form, or does it just have a filing date and a vendor roadmap?