Signal Snapshot
MCP, A2A, and AG-UI are starting to split the agent connection stack into three layers
Reading the MCP, A2A, and AG-UI specifications next to public materials from OpenAI, Anthropic, Google, Microsoft, and AWS through late March 2026 makes one pattern visible: the connection surface for AI agents is no longer appearing as one monolithic product surface. MCP is increasingly used for tool and data access, A2A for agent-to-agent delegation, and AG-UI for human-facing progress, interruption, and approval flows. What changed this week is not merely that more protocol names appeared. The separation is now visible in runtime products, frameworks, apps, and enterprise documentation.
3 layers
Split responsibilities
Tool access, agent delegation, and human supervision are starting to sit on different protocol surfaces.
5 families
Implementation surfaces
OpenAI, Anthropic, Google, Microsoft, and AWS each expose different parts of the stack.
27
Published sources
Specifications, official docs, and official announcements are enough to compare the emerging stack.
1 implication
No need to trap everything in one product
Access, delegation, and oversight can now be designed as separate concerns.
Why This Week
By late March 2026, the idea that one framework should own everything is starting to break down
Earlier agent tooling often bundled tool access, sub-agent coordination, and user-facing interaction inside one product surface. But the public material visible by late March 2026 shows at least three responsibilities splitting apart. MCP now covers tool and server access together with discoverable authentication requirements. A2A defines agent cards, tasks, asynchronous execution, and status updates. AG-UI defines event streams, state synchronization, and human-in-the-loop interaction on the front-end side. AWS has added stateful MCP and AG-UI support to AgentCore Runtime, Google has documented MCP and A2A in parallel, Microsoft has published A2A and AG-UI integrations in Agent Framework, and OpenAI plus Anthropic have pulled MCP into product-facing surfaces. The story this week is therefore not that protocols exist, but that the division of labor is becoming visible in implementation.
MCP handles tool access and discoverable auth requirements
The direction is to describe tools, resources, and auth expectations through a protocol rather than through one-off integration code.
A2A handles delegation to specialist agents
Agent cards, tasks, messages, and async completion make it easier to move orchestrator-specialist coordination outside a single closed product.
AG-UI handles state visibility and approval paths
Long-running agents need progress, artifacts, interrupts, and approvals. AG-UI starts to frame those as UI contracts rather than as improvised chat behavior.
Three Layers
Each protocol is filling a different gap
1. MCP: the agent-to-tool and agent-to-data layer
- What it standardizes: tools, resources, prompts, transport, and auth requirements
- Best-fit use case: enterprise documents, SaaS systems, data warehouses, and internal APIs
- Operational benefit: teams can swap back-end systems without rewriting the agent around each integration
- What remains uneven: support still varies by platform, especially around stateful behavior and auth
2. A2A: the orchestrator-to-specialist layer
- What it standardizes: agent discovery, skill declaration, task transfer, progress, and completion
- Best-fit use case: splitting work across legal, procurement, support, finance, or domain specialists
- Operational benefit: one agent no longer has to own every capability directly
- What remains uneven: production deployments still need separate answers for auth, evaluation, and tracing
3. AG-UI: the agent-to-user layer
- What it standardizes: event streams, state sync, artifact display, user interruption, and approvals
- Best-fit use case: long-running work, review-heavy automation, artifact editing, and approval-heavy processes
- Operational benefit: teams can expose state that would otherwise stay hidden behind a chat transcript
- What remains uneven: the ecosystem is still thinner and younger than MCP
Read together
The important point is that these protocols are not simply rivals. MCP alone does not express specialist delegation well. A2A alone does not define human oversight UX. AG-UI alone does not solve secure tool access.
For enterprise deployments, separating connection, delegation, and supervision may be more practical than trying to collapse them into one surface.
Vendor Convergence
Vendors are strongest in different layers, but the public structure is becoming similar
OpenAI and Anthropic are pushing MCP toward the product surface
OpenAI apps plus developer mode, and Anthropic's MCP connector plus Claude Code MCP, move tool access out of hidden framework plumbing and into user- and developer-facing surfaces.
At this layer, discovery and permissions begin to shape the app experience itself.
Google is documenting MCP and A2A side by side
Google Cloud documents enterprise authentication for MCP servers, while Google ADK places MCP tooling and A2A support in the same development surface.
The signal is that system access and specialist delegation should be designed together, but not treated as the same thing.
Microsoft is making A2A and AG-UI first-class Agent Framework integrations
Microsoft publishes dedicated A2A and AG-UI integrations next to the broader Agent Framework overview.
That makes multi-agent coordination and human-in-the-loop UX look less like sample code and more like expected framework-level connection surfaces.
AWS is absorbing protocols at the runtime layer
AWS has added stateful MCP and AG-UI support to AgentCore Runtime and positions the runtime as a host for different agent frameworks.
In that view, protocols are not only app-level abstractions. They are becoming deployment contracts for long-running agents.
What changed
No vendor has fully standardized the whole stack, but several now expose the stack as separate surfaces for tool access, agent delegation, and user interaction.
That widens the comparison axis from raw model quality to how much of the connection stack each platform opens.
Concrete Scenarios
Once the three layers are present, approval-heavy long-running work becomes more realistic
An internal research agent calling specialists
A lead agent uses MCP to access documents, data, and internal APIs, then delegates tasks to legal or procurement specialists over A2A. The user watches progress, evidence, and pending actions through AG-UI and approves only high-risk external actions.
Support workflows that cross billing and policy checks
A front-line agent structures the request, delegates billing and policy checks through A2A, and lets each specialist touch only the required systems through MCP. Refund approval or policy exceptions can then be held for human review through AG-UI.
Code and operations work with write approvals
An execution agent touches build, log, ticket, and repository systems over MCP, splits work across analysis and verification agents through A2A, and stops before writes, deploys, or permission changes so the human reviewer can inspect the diff and reasoning in AG-UI.
What Is Still Early
Having protocols does not mean interoperability is solved
Auth and policy still need local design
Even when MCP or A2A expose security metadata, enterprises still need their own answers for least privilege, revocation, audit, and approval thresholds.
Cross-layer tracing and evaluation remain hard
When tool calls, agent handoffs, and user approvals sit in different layers, evaluation and audit need correlation IDs and shared trace design.
AG-UI is younger than MCP
AG-UI looks promising as a human-supervision surface, but its ecosystem is still thinner. In the short term it is more realistic to expect mixed deployments with vendor-specific UI.
Trying to force one protocol to solve everything is the wrong frame
The visible direction is not a single winner that absorbs the whole stack. It is a layered split of responsibilities. Teams will make fewer mistakes if they decide first which problem each protocol is supposed to solve.
Takeaway
The comparison axis for AI agents is expanding from model quality to how the connection stack is opened
The public evidence this week does not justify claiming that agents are suddenly fully interoperable. It does justify a narrower and more useful conclusion: connection, delegation, and supervision are becoming separate design layers. For enterprise adoption, the key question is starting to shift from only which model to use, toward which layers should be opened through protocols and which should remain constrained by local policy and product choices.