The Orchestrator

There is an agent-to-agent protocol, and it is useful to know its actual shape, because its gaps are the point. A2A, originally from Google and now governed by the Linux Foundation, lets one agent discover another through an advertised capability card and delegate tasks to it over ordinary web standards — JSON-RPC over HTTPS — even when the two agents share no memory, no tools, and no vendor. As of this writing it has reached version 1.0 and defines transport authentication, signed Agent Cards, and in-task authorization states. Deployments can apply authorization policies around those exchanges, including skill-specific rules. What the core protocol does not standardize is a portable delegation object that says which principal authorized this task, which subset of authority may flow downstream, what budget and duration apply, how that authority can be revoked, and which evidence must return with the result — the specification explicitly leaves the scope, validity, and revocation semantics of authorization decisions to implementations and extensions, and task-bound delegated authorization sits in the project’s issue tracker as an open question.⁷ Two independent systems do not inherit the same task-bound authority semantics merely because they both speak A2A.

Read that open issue rather than only citing it, because it shows the missing object being worked out in public. It was filed in June 2026 by a contributor, not a maintainer, and it asks a narrow question: should A2A define an optional profile that binds a delegation to a specific acting agent, task, target, scope, and validity window, so that a grant issued for one task cannot be replayed into another? The commenters — practitioners, not the project’s owners — converged on a minimum tuple: caller, delegate, task or session scope, allowed skills or tools, validity window, and the state the delegation was based on, with the rule that the delegate can accept or refuse the tuple and can never widen it. As of this writing the issue is open, has five comments, and has no response from the maintainers; an older issue asking A2A to account for the confused-deputy problem has been open since April 2025, assigned and unresolved.⁸

The identity standards bodies are further along. Chapter 7 pointed at RFC 8693, OAuth 2.0 Token Exchange, whose act claim already lets a token carry a nested chain of who acted on whose behalf. In June 2026 the IETF’s OAuth working group approved a charter with a work item it calls complex delegation: “authorization of automated agents working on behalf of users, including addressing scenarios where automated agents act across multiple administrative domains.” That last clause is the cross-system case exactly. The individual drafts arriving under it are not yet working-group documents, and Internet-Drafts expire after six months, so nothing here should be built to; but they agree on a property worth designing for now. An attenuated-delegation profile submitted in September 2026 carries a chain of delegation links in which every link may only narrow the scope, tighten the conditions, or shorten the expiry of its parent, and a verifier must check every link rather than trusting the last hop; other drafts — one already expired, one revised in August — propose claims for task context, delegation chain, and human oversight, or a grant profile that attenuates authority through token exchange and pushes budgets, audit stores, and policy engines outside the interoperable core.⁹ Monotonic narrowing, whole-chain verification, an expiry on every link: the same tuple the A2A commenters reached independently, which is some evidence that the shape is real and not one community’s taste.

Governance has consolidated, and an orchestrator should know where. In December 2025 the Linux Foundation formed the Agentic AI Foundation, with Anthropic donating the Model Context Protocol, Block donating goose, and OpenAI donating AGENTS.md; A2A already lived under the Linux Foundation.¹⁰ A separate Linux Foundation project, AGNTCY, is building the discovery, identity, and messaging layer that lets agents from different vendors find and verify each other.¹¹ None of this solves the problem. It names the fora — the AAIF for agent protocols, the IETF for delegation tokens, FIDO for payment mandates — so that when the delegation object arrives it will arrive from one of them, in a shape you can already see. A system that records the tuple today will have something to hand the protocol. A system that records a task ID and a bearer token will not.