MCP vs A2A in Fall 2026: What Each Protocol Standardizes and the Execution Gap Between Them

What MCP standardizes in the 2026-07-28 spec

MCP is an open protocol that connects LLM applications to external tools and data. It uses JSON-RPC 2.0 messages between three roles: hosts (the LLM application), clients (connectors inside the host) and servers (services that provide context and capabilities), per the current MCP specification, version 2026-07-28.

The core surface is small and concrete:

• Server features: resources (context and data), prompts (templated messages and workflows) and tools (functions the model can execute).
• Client features: elicitation, which lets a server request more information from the user.
• Utilities: configuration, progress tracking, cancellation and error reporting.
• Opt-in extensions: Tasks for long-running operations with polling, mid-flight input and durable handles; Skills over MCP; MCP Apps for inline UI.

The 2026-07-28 release made a remote MCP server a normal HTTP workload. The roadmap updated on August 22, 2026 lists five priorities for the next six to twelve months: agentic messaging primitives (Tasks, triggers and events), HTTP-native transport, agent identity and enterprise-ready security, improved primitives such as a redesigned tools/call result, and SDK developer experience (MCP roadmap). Adoption is large: monthly downloads across MCP's Tier 1 SDKs are approaching half a billion (AAIF, Sep 14, 2026).

What A2A standardizes: the agent to agent protocol

A2A is an open protocol for communication between opaque agentic applications: an agent publishes an Agent Card, other agents discover it, send it messages and receive task updates and artifacts back. Agents collaborate without sharing internal memory, tools or proprietary logic (a2a-protocol.org).

The building blocks in the A2A specification:

• Agent Card: a JSON document with the agent's identity, capabilities, skills, endpoint and authentication requirements.
• Task: the fundamental unit of work, with an ID generated by the server and a defined lifecycle: submitted, working, input required, auth required, completed, failed, canceled, rejected.
• Message and Part: conversation turns made of text, file references or structured data.
• Artifact: an output of a task, such as a document, image or structured data.
• Delivery: streaming updates and push notifications to a client webhook; bindings for JSON-RPC, gRPC and HTTP+JSON/REST.

A2A was originally developed by Google and donated to the Linux Foundation. On August 27, 2026 it was accepted as a Growth Stage project at the Agentic AI Foundation, after reaching a stable v1.0 specification; the project reports backing from over 150 organizations (A2A joins AAIF).

MCP vs A2A: where they overlap and where they split

MCP is the vertical link from an agent down to its tools and data; A2A is the horizontal link between peer agents. A2A's announcement of joining AAIF uses this framing, and the A2A home page states that A2A does not specify how an agent invokes tools, which it leaves to MCP or framework primitives.

The overlap is growing at the edges. Both protocols now have a notion of asynchronous work and a pause for human input. The MCP roadmap names the risk plainly: three answers to "the server isn't done yet" that don't share a lifecycle, a cancellation model or an error surface. Each answer, though, is scoped to one connection. An MCP task belongs to one server. An A2A task belongs to one remote agent and the client that called it.

The missing layer: state, approval, artifacts and memory across the chain

The execution gap is the lifecycle of one business request that crosses several MCP servers, one or more A2A agents, a workflow engine and at least one human. Each protocol tracks its own hop well. The whole request sits outside both specs.

Take a typical lead generation request. An agent researches companies through MCP tools, delegates contact enrichment to a partner's agent over A2A, an n8n workflow prepares the CRM update, and a person approves before anything is written. Four questions come up on every such run:

1. Identity: what is the ID of the whole request, across the MCP calls, the A2A task and the workflow execution?
2. Review: why is it paused right now, who has to decide, and what exactly are they looking at?
3. Artifacts: where are the outputs of every step, and which request produced each one?
4. Memory: what does the next run of the same process know about this one?

Teams usually answer these with logs, chat threads and spreadsheets, rebuilt by hand at every boundary. We covered the cost of that in what an AI agent bus is.

How an envelope and run contract close the gap

An envelope is a versioned object that wraps one unit of requested work and keeps its identity while tools, agents and executors change underneath it. The run contract defines which lifecycle states that work can be in and which transitions are valid. This is the Agintent protocol: a protocol concept with a working reference orchestrator, published as a v0.1 draft.

In the Agintent Envelope v0.1 draft, the fields map directly onto the four questions above:

• Identity: envelopeId plus source.actorType (human, agent, workflow or system), and refs.parentEnvelopeId to link a delegated sub-request to its parent.
• Review: intent status moves through draft, queued, planning, running, waiting_input, completed, failed or cancelled. The reference orchestrator exposes patch, resume, approve and reject transitions for a waiting envelope and records the human decision as a protocol event.
• Routing: work goes to a declared executor capability such as research, workflow_webhook_dispatch, manual_review, browser_automation or crm_mutation, so an n8n webhook, an LLM step and a person are interchangeable executors of the same object.
• Outputs and context: artifacts and memoryRefs stay on the envelope, whichever step produced them.

Agintent's design direction for MCP and A2A follows from that model, as a protocol mapping that a pilot validates on real work: an MCP tool call becomes a step inside a run, an A2A task becomes a delegated child envelope, and an A2A input required state surfaces as waiting_input with a reason on the parent. The full object model is in the intent envelope, explained and on the protocol page; for how this differs from graph-based frameworks, see Agintent vs LangGraph.

Governance: why Security & Governance is 24% of the MCPA exam

Agent interoperability raises governance questions faster than protocols can answer them, and the new MCP certification reflects that. In the MCPA exam launched by AAIF on September 14, 2026, Security & Governance weighs 24% and Interactions & Execution 26%, half of the 120-minute exam together (our news brief on the MCPA).

The MCP specification is explicit about where responsibility sits. Hosts must obtain explicit user consent before invoking any tool, tool descriptions and annotations count as untrusted unless they come from a trusted server, and MCP cannot enforce these principles at the protocol level. The roadmap adds agent identity, delegation with narrower authority for sub-agents, and DPoP as open work. A practical governance baseline for a mixed MCP and A2A stack:

• A map of every tool and remote agent that can write, send, pay or delete.
• An approval rule and a reason code for each of those actions, visible on the paused run.
• The approver, the decision and the reviewed artifact stored on the same record as the request.
• Delegated agents given the smallest authority the step needs.
• Outputs kept for audit after the run completes.

Treating review as a lifecycle state makes this baseline enforceable in daily operations. We explain the pattern in human-in-the-loop agent execution.

Who we work with, and what we can show today

Agintent fits teams that already run agents and need one inspectable object around them. Good fits right now:

• Early design partners with AI-heavy internal workflows.
• Operator-led teams coordinating agents, n8n and human review.
• Tools that want to emit or consume Agintent envelopes.

The envelope vocabulary, the v0.1 envelope spec and protocol-native API routes exist, and the reference orchestrator runs the full emit → normalize → route → run → attach → review loop. See the use cases for concrete scenarios.