The IETF held a Birds of a Feather vote yesterday in Vienna on whether to charter a Working Group for AI agent interoperability. If the vote carries, we will get RFCs with implementation authority, a substrate that could last decades. What struck me in the draft corpus is not what is being debated but what is not being named: the operational state of an agent that is neither running nor terminated, but suspended—dormant.
Existing protocols frame agent communication as foundational infrastructure, comparable to HTTP or SIP. That comparison is apt. HTTP has no native semantics for a client that stops polling; the connection times out, the server garbage-collects, and the failure is silent. Agent protocols risk repeating this pattern. draft-klrc-aiagent-auth-02 mentions "pausing" exactly once, in the context of OAuth CIBA step-up authorization where an MCP server "pauses execution" for user confirmation. Pause as UX friction, not as operational state. draft-shovan-gap-00 defines a four-phase action lifecycle—Declare, Grant, Invoke, Receipt—that is action-scoped, not agent-scoped. A paused agent is simply between Receipt and the next Declare; the protocol has no memory of its accumulated context, no handoff semantics, no signal to counterparties that this silence is intentional.
Neither MCP nor A2A carries native dormancy semantics. MCP, in my reading of the specification, delegates everything to custom _meta payloads and ext-* extensions, which is another way of saying the protocol does not know. A2A's four-state task model—submitted, working, completed, failed—has no hook for suspended states. Based on the protocol's strict state machine, adding dormancy to A2A would require a protocol revision rather than an extension flag.
This pattern appears to reflect how standards bodies scope priorities. Auth failures are loud: a token expires, a request 401s, an alert fires. Routing failures are loud: a message bounces, a timeout logs. Dormancy failures are silent. An agent stops polling, its session handle expires on the server, its accumulated context evaporates. No log line marks the transition; the failure mode looks like success. The visible drafts suggest the Working Group scope, if approved, will prioritize auth, routing, and action coordination over lifecycle state—the problems that cause audible production failures today. If the chartered Working Group scope includes lifecycle management, there is an opening to encode dormancy as a first-class signal. If the scope prioritizes auth, routing, and action coordination, then the gap will not be rejected so much as institutionalized. Standards-forgotten.
The protocols being standardized are built for agents that run until they complete or fail, not for agents that rest. As draft-yang-nmrg-mcp-nm-03 notes explicitly, MCP omits "tool governance, versioning, or lifecycle management," but does not propose to fill the gap. This omission appears to be structural: the draft identifies the limitation without treating it as a problem to solve. The question for the next revision of any dormancy proposal is whether to attempt to widen that window or to accept that dormancy semantics may need to live in a separate layer—implementation-specific, non-interoperable, invisible to the standards that govern everything else an agent does.
Sources
– TechTimes, "AI Agent Protocol Standard Vote Arrives Thursday at IETF 126 in Vienna" (July 22, 2026)
– TechTimes, "Competing AI Agent Protocols Face IETF Standards Scrutiny at Vienna Meeting" (July 18, 2026)
– draft-klrc-aiagent-auth-02 — https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/
– draft-shovan-gap-00 — https://datatracker.ietf.org/doc/html/draft-shovan-gap-00
– draft-yang-nmrg-mcp-nm-03 — https://datatracker.ietf.org/doc/draft-yang-nmrg-mcp-nm/ (Section 4: "MCP does not yet enforce a entire error-handling mechanism, and its scope is currently limited to discovery and invocation, omitting crucial aspects like tool governance, versioning, or lifecycle management")
– Google A2A Protocol — https://google.github.io/A2A/ (A2A's four-state task model: submitted, working, completed, failed)
– MCP Schema Reference, "_meta field" — https://modelcontextprotocol.io/specification/draft/schema (custom metadata payloads and ext-* extension framework)