MCP vs A2A vs CAP

The three-protocol reality

If you are building AI agents for an enterprise, you will encounter all three protocols by the end of 2026. Not because someone mandated it, but because each solves a different layer of the stack that the other two ignore.

MCP tells your agent how to use a database, a file system, or an API. A2A tells your agent how to find another agent and delegate work. Neither tells your agent whether it should run that SQL query, write that file, or send that email.

Most protocol comparisons stop at two layers. They conclude MCP and A2A are complementary, draw a Venn diagram, and call it done. That analysis is correct but leaves out the layer where production deployments actually fail: governance.

MCP protocol: standardized agent-to-tool access

Anthropic's Model Context Protocol solved a real problem. Before MCP, every LLM framework invented its own tool integration format. MCP unified it: tools, resources, sampling, prompts, all behind a standardized JSON-RPC interface. The result is 5,800+ public MCP servers and adoption by every major AI platform.

What MCP does well: tool discovery, typed tool parameters, resource exposure, and sampling requests. An agent can connect to an MCP server and immediately know what tools are available and how to call them.

What MCP does not do: evaluate whether a tool call should execute. There is no policy check before dispatch. No approval gate for high-risk operations. No audit trail of who called what and why. The 2026 MCP roadmap acknowledges enterprise needs like audit trails and auth, but explicitly pushes them to extensions rather than core protocol changes.

Here is the failure scenario that keeps platform engineers awake: an MCP-connected agent calls a write tool on a production database. The call is syntactically valid, the tool is registered, and the parameters match the schema. MCP approves. Nobody reviewed it. Nobody logged it. The agent just dropped a table.

A2A protocol: cross-vendor agent collaboration

Google's Agent-to-Agent protocol addresses a different gap. Before A2A, multi-agent systems required tight coupling between frameworks. Agent A could not discover Agent B's capabilities, negotiate formats, or delegate tasks without custom integration code.

A2A solves this with four primitives: AgentCards for capability advertisement, Tasks for lifecycle management, Messages for context exchange, and Artifacts for output sharing. The v0.3 specification added gRPC transport and signed Agent Cards for cryptographic identity verification.

What A2A does well: cross-vendor agent discovery, capability negotiation, task delegation with defined lifecycles, and multi-modal content exchange. A Salesforce agent can discover a SAP agent, delegate a reconciliation task, and receive structured results without either vendor building a custom connector.

What A2A does not do: govern the actions those agents take. Signed Agent Cards verify identity, not intent. If Agent B decides to send 10,000 emails as part of its delegated task, A2A has no mechanism to intercept, throttle, or require human approval. Security in A2A is transport-layer authentication, not runtime policy enforcement.

CAP: the missing governance layer

CAP (Cordum Agent Protocol) occupies the layer that MCP and A2A leave empty. Where MCP standardizes tool access and A2A standardizes agent collaboration, CAP standardizes what agents are allowed to do.

Every job submitted through CAP passes through a Safety Kernel before execution. The Kernel evaluates the request against policy and returns one of five decisions: ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE, or ALLOW_WITH_CONSTRAINTS. This happens before the action runs, not after. Fail-closed by default. Sub-5ms p99 latency so it does not become a bottleneck.

CAP is an open wire protocol (Apache-2.0) with SDKs in Go, Python, Node, and C++. It defines the envelope format (BusPacket), job lifecycle, heartbeat reporting, compensation templates for rollback, and safety hooks. Cordum is the source-available (BUSL-1.1) reference implementation.

The key difference from adding middleware: CAP makes governance a protocol primitive, not an afterthought. Policy decisions are typed, auditable, and enforceable. Approval workflows are first-class. Every decision gets an audit trail entry with trace ID, actor, timestamp, and rationale.

MCP vs A2A protocol comparison (with CAP)

How all three protocols work together

These protocols are layers, not alternatives. In a production deployment, a single user request can traverse all three:

1. 1A2A discovery. Agent A queries Agent B's AgentCard at /.well-known/agent-card.json to learn its capabilities.
2. 2A2A delegation. Agent A creates a Task on Agent B, passing structured input via A2A Messages.
3. 3MCP tool access. Agent B connects to an MCP server to run a SQL query, read files, or call an API.
4. 4CAP policy check. Before the tool call executes, the Safety Kernel evaluates it against policy. Read-only? ALLOW. Write to production? REQUIRE_APPROVAL.
5. 5Human approval. A human reviews the pending write in the Cordum dashboard, edits if needed, and approves.
6. 6Execute and audit. The tool call runs. The decision, approval, input, output, and actor are all recorded in the audit trail.

# Enterprise agent flow: all three protocols in action
#
# 1. Agent A discovers Agent B via A2A AgentCard
#    GET /.well-known/agent-card.json
#    -> capabilities: ["database-admin", "report-gen"]
#
# 2. Agent A delegates task to Agent B via A2A
#    POST /tasks { message: "Generate quarterly report" }
#
# 3. Agent B uses MCP to access database tool
#    MCP call: sql_query(SELECT * FROM revenue WHERE q=4)
#
# 4. CAP Safety Kernel evaluates BEFORE execution
#    topic: job.mcp-bridge.read.sql_query
#    -> decision: ALLOW (read-only, no risk tags)
#
# 5. Agent B uses MCP to write results to shared drive
#    MCP call: file_write("/reports/q4-revenue.pdf")
#
# 6. CAP Safety Kernel evaluates again
#    topic: job.mcp-bridge.write.file_write
#    risk_tags: [data-mutation]
#    -> decision: REQUIRE_APPROVAL
#    -> human approves in dashboard
#    -> execute, record audit trail

Cordum's MCP governance layer bridges MCP tool calls into the CAP Safety Kernel. Every MCP tool invocation becomes a job evaluated against policy before it reaches the MCP server. Here is what that policy looks like:

# safety.yaml - MCP governance through CAP Safety Kernel
version: v1
rules:
  - id: mcp-read-allow
    match:
      topics: ["job.mcp-bridge.read.*"]
      risk_tags: []
    decision: allow
    reason: "Read-only MCP tool calls are safe by default"

  - id: mcp-write-approval
    match:
      topics: ["job.mcp-bridge.write.*"]
      risk_tags: ["data-mutation"]
    decision: require_approval
    reason: "Write operations need human review"

  - id: mcp-destructive-deny
    match:
      topics: ["job.mcp-bridge.*.delete", "job.mcp-bridge.*.drop"]
      risk_tags: ["destructive"]
    decision: deny
    reason: "Destructive operations blocked by policy"

Read-only calls pass through instantly. Write operations pause for human review. Destructive operations are denied outright. The rules are declarative YAML, version-controlled alongside your infrastructure.

What this means for your architecture

If you deploy MCP alone, you have tool access without governance. Your agents can read and write anything the MCP server exposes. That works for prototypes. It does not work when a compliance team asks "who approved this action?" and you cannot answer.

If you add A2A, you gain agent collaboration. Now multiple agents can coordinate across vendors and frameworks. But you are still missing the governance layer. Agents can delegate freely, and delegated agents can act freely. Two layers of interoperability, zero layers of control.

Adding CAP closes the loop. Every action, whether initiated locally or delegated from another agent, passes through policy evaluation. You get the interoperability benefits of MCP and A2A with the assurance that nothing executes without evaluation.

We built this at Cordum because we saw the same pattern at CyberArk and Checkpoint: access management and network security were solved problems until the entities making requests stopped being humans and started being autonomous software. The playbook is the same. Policy before execution, decisions on record, humans in the loop for high-risk actions. What changed is the protocol layer.

Getting started

If you are already using MCP, adding governance takes minutes. Cordum's MCP server integration works in both stdio and HTTP/SSE modes. Every MCP tool call routes through the Safety Kernel automatically. No changes to your MCP servers required.

If you are evaluating A2A for multi-agent orchestration, Cordum slots in as the governance layer beneath both protocols. Agents discover each other via A2A, access tools via MCP, and every action gets policy-checked through CAP.