-
Notifications
You must be signed in to change notification settings - Fork 4
MCP A2A and CHAP ‐ the open agent stack
MCP connects agents to tools, A2A connects independent agents, and CHAP connects accountable work among humans, agents and services.
MCP, A2A and CHAP are not competing names for one protocol problem.
- MCP standardises how AI applications connect to external context and tools.
- A2A standardises communication and task exchange between independent agent systems.
- CHAP standardises the shared collaboration room where humans, agents and services assign, review, modify, approve, hand off and escalate work with verifiable evidence.
A production agent system can use all three. Each protocol should remain visible at its own trust boundary.
| Layer | Primary question | Typical endpoints | Example |
|---|---|---|---|
| User interaction, often AG-UI or an application protocol | How does the person see and control the live agent experience? | Frontend and agent backend | Stream a draft and show review controls |
| CHAP | Who is responsible for this work, what did they decide, and what evidence remains? | Human, agent and service participants | Record an override with a diff and rationale |
| A2A | How does one independent agent delegate to another? | Agent system and agent system | Ask a specialist agent to analyse a document |
| MCP | How does an AI application call a tool or obtain context? | MCP client and server | Query a database or create a ticket |
These are conceptual layers, not a required network order. A CHAP Coordinator can itself be exposed through MCP or A2A, and an A2A agent can call MCP tools while performing a task.
Imagine a procurement agent preparing a supplier recommendation.
- The agent uses MCP to retrieve approved supplier records and current prices.
- It delegates a sanctions-screening task to an external specialist agent over A2A.
- The external agent returns an artefact to the local A2A bridge.
- The procurement agent produces a recommendation in a CHAP workspace and cites the relevant MCP and A2A evidence boundaries.
- A buyer reviews the recommendation.
- The buyer replaces the proposed supplier because the delivery risk outweighs the price advantage.
- CHAP records the human action as
decide.override, with the structured change, rationale and policy tags. - The approved result triggers an MCP tool call that creates the purchase request.
MCP explains the tool interactions. A2A explains the delegated agent work. CHAP explains the accountable human-agent decision that joined them.
An agent can cite an MCP invocation in a CHAP artefact with hashes of the input and output. The evidence chain records the boundary and provenance without duplicating the complete MCP transcript.
An external A2A peer can appear in a CHAP workspace through a service:bridge... participant. A2A traffic stays on the A2A wire. The bridge maps relevant progress and results into local CHAP tasks and artefacts.
CHAP methods can be presented as MCP tools. An MCP-aware client can then create tasks, request reviews and read audit evidence through a transport it already supports.
The same Coordinator can publish an A2A Agent Card and expose CHAP methods as skills. An A2A orchestrator can delegate accountable collaboration to it without implementing a separate CHAP client.
Transport does not change semantics. A decide.override invoked through an MCP tool or A2A skill should produce the same CHAP envelope and evidence as a direct CHAP call.
Separation creates clearer trust boundaries and lets each ecosystem evolve independently.
Tool invocation has different security and lifecycle concerns from cross-organisation agent delegation. A live frontend event has different latency and rendering needs from a long-lived evidence record. Human authority and override semantics should not be buried in a generic tool result.
A small set of composable protocols also reduces lock-in. A team can change its UI framework without rewriting its accountability record, or change an MCP tool server without changing the meaning of a human decision.
An agent completing a remote task means the agent produced its result. It does not mean an authorised human approved the business action.
An elicitation response or tool confirmation can collect the user's action. It does not automatically retain the proposal, authority, modification and evidence lifecycle that CHAP represents.
This increases privacy, retention and data ownership risk. Use citations, hashes and opaque references where a boundary is sufficient.
Keep explicit mappings among the CHAP task, A2A task, MCP request and application session. A single global identifier is not always practical, but an evidence record should let an operator trace the relationship.
Conformance shows that messages follow expected protocol behaviour. It does not establish that the agent is accurate, the human is competent or the policy is appropriate.
- Choose one consequential human review flow.
- Model its participants, task, artefact and decision in CHAP.
- Keep existing MCP and A2A traffic in place.
- Add citations for the tool calls and external agent results that materially support the decision.
- Verify the CHAP evidence chain from a separate process.
- Add transport adapters only when another client or orchestrator needs them.
This sequence tests CHAP's value without redesigning the complete agent stack.
- MCP specification
- A2A Protocol specification
- CHAP relationship to other standards
- CHAP implementation registry
- CHAP with MCP
- CHAP with A2A
If this stack matches what you are building, star CHAP and share your combination of protocols and frameworks in Discussions.
Last reviewed: 25 August 2026.