Skip to content

How CHAP works with A2A

Jump to bottom
Arsalan Shahid edited this page Aug 25, 2026 · 5 revisions

A2A lets independent agents communicate across systems. CHAP adds the shared human-agent workspace and evidence needed to make that delegated work accountable.

Short answer

A2A and CHAP are complementary.

The Agent2Agent Protocol defines how independent and potentially opaque agent systems discover capabilities, exchange messages, manage tasks and deliver artefacts. CHAP defines how humans, agents and services collaborate around work, including review, approval, override, abstention, escalation and an append-only evidence chain.

When a CHAP participant delegates to an external A2A agent, a bridge participant represents that peer inside the CHAP workspace. The A2A exchange remains on the A2A wire. The bridge signs the relevant CHAP envelopes and links the external result to the local task.

The division of responsibility

Concern A2A CHAP
Main relationship Agent to agent Human, agent and service participants in shared work
Capability discovery Agent Cards and skills Participant capabilities and workspace membership
Work unit A2A task, message and artefact CHAP task, artefact and decision lifecycle
Long-running status A2A task states and updates Task state plus accountable review and intervention methods
Human input Can be represented by application flows and task states First-class review, approve, reject, override, abstain and escalate semantics
Cross-system delegation Core purpose Represented locally through a bridge participant
Audit evidence Implementation and deployment dependent Signed, hash-linked envelopes and audit operations
Replacement relationship Does not replace CHAP Does not replace A2A

Pattern 1: cite an external A2A exchange

This is the outward pattern. An agent is already doing work in a CHAP workspace and needs help from an external A2A peer.

  1. Create a CHAP participant such as service:bridge:research-partner.
  2. The local agent delegates the subtask over A2A.
  3. A2A manages the remote message, task state and returned artefacts.
  4. The bridge maps the result back into the CHAP task.
  5. The CHAP artefact cites the A2A exchange, including hashes or stable references that define the evidence boundary.
  6. Any later human review happens through normal CHAP decision methods.

The A2A payload does not need to be duplicated into the CHAP log. This matters when the remote system has separate retention, confidentiality or ownership requirements.

CHAP's reference libraries include helpers for wrapping an A2A message exchange into the local task and evidence model. The bridge remains responsible for authenticating the external peer and applying local policy.

Pattern 2: expose a CHAP Coordinator as an A2A agent

This is the inward pattern. An A2A-aware orchestrator needs to drive accountable work without implementing the CHAP wire directly.

A CHAP Coordinator can publish an A2A Agent Card and expose CHAP methods as skills. The orchestrator can then create or update a workspace, assign work, request review and retrieve evidence through its existing A2A integration.

The A2A adapter is a transport boundary. CHAP semantics still come from the Coordinator. The adapter should not silently reinterpret decide.override as a generic task completion, because the structured modification and rationale are part of the accountable record.

Pattern 3: use both directions in one system

The two patterns stack.

An enterprise orchestrator can call a CHAP Coordinator as an A2A agent. Inside the resulting workspace, one participant can delegate a specialist subtask to another A2A peer. The bridge returns the remote artefact, a human reviewer modifies it, and the final decision is recorded on the same CHAP evidence chain.

This lets each protocol retain its own job:

  • A2A moves work between agent systems.
  • CHAP records who proposed, reviewed, changed and accepted the work.
  • MCP can still be used by either agent to call tools, with those calls cited in the CHAP artefact.

Example: cross-organisation claims review

Consider an insurer whose internal agent prepares a claim recommendation. It asks an external fraud-analysis agent for a risk assessment over A2A.

The external system returns an A2A artefact and completes its task. A local bridge participant records the result reference in CHAP. The internal agent incorporates it into the claim recommendation and sends review.request to a claims specialist.

The specialist decides that the recommendation is broadly correct but changes the proposed reserve amount. CHAP records this as decide.override with the diff, rationale and relevant tags. The final claim action can cite both the external A2A analysis and any MCP tool calls used to update internal systems.

A2A alone can move the task and artefact across the organisational boundary. CHAP supplies the local, accountable history of how that result influenced a human decision.

Identity and trust boundaries

A bridge is not proof that the remote agent is trustworthy. It is a declared boundary where one system translates external activity into local evidence.

A production design should define:

  • How the bridge authenticates the A2A peer.
  • Which Agent Card and skill versions are permitted.
  • Which remote artefacts may enter the workspace.
  • Whether raw content, hashes or opaque references are retained.
  • Which local participant is authorised to accept the result.
  • How timeouts, rejection and partial results are represented.
  • Which organisation operates and signs for the bridge.

These choices belong in workspace policy and deployment documentation. They should not be hidden inside adapter code.

Mapping A2A state into CHAP

Avoid a one-to-one mapping based only on similar words. An A2A task marked completed means the remote agent finished its unit of work. It does not necessarily mean a human approved the business consequence.

A useful mapping separates three facts:

  1. The external A2A task reached a state.
  2. Its artefact was incorporated into a CHAP task.
  3. An authorised participant made a CHAP decision about that task.

Keeping these facts distinct prevents an agent's technical completion from being mistaken for human authorisation.

When to use both

Use A2A alone when independent agents only need interoperable delegation and your application already has sufficient decision controls. Add CHAP when people share responsibility with those agents, when an external result needs review or override, or when cross-system evidence must retain standard meaning.

Use CHAP without A2A when all participants already communicate through the same Coordinator and no independent agent-to-agent boundary is involved.

Related pages

Primary sources

If you are building an A2A bridge, star CHAP and share the architecture or missing interoperability case in Discussions.

Last reviewed: 25 August 2026.

Clone this wiki locally