A2A vs MCP vs Runtime Authority

A customer-support agent needs help from a billing agent.

The support agent sends the billing agent a task. The billing agent looks up invoices, calls a refund tool, and returns a status update. The support agent writes the final answer back to the customer.

That workflow crosses three different control surfaces:

• Agent-to-agent communication.
• Agent-to-tool access.
• Runtime decisions about whether each action should execute.

It is tempting to collapse those into one category and ask whether A2A or MCP "solves agent governance." That framing creates confusion. A2A, MCP, and runtime authority solve different problems.

A2A helps agents communicate with other agents. MCP helps agents connect to tools, data, and context. Runtime authority decides whether the next action should proceed, given budget, risk, scope, and policy.

Production systems usually need all three.

The short version

Layer	Primary job	It does not automatically decide
A2A	Agent-to-agent interoperability	Whether the delegated task is within budget or authority
MCP	Agent-to-tool and agent-to-context access	Whether this specific tool call should still execute
Runtime authority	Pre-execution budget, risk, and action decisions	How agents serialize messages or expose tool schemas

The official A2A documentation describes A2A as an open protocol for communication and interoperability between opaque agentic applications. It also positions A2A and MCP as complementary: MCP is agent-to-tool, while A2A is agent-to-agent.

The official MCP documentation describes MCP as an open-source standard for connecting AI applications to external systems: data sources, tools, and workflows. That makes MCP a powerful integration surface, but an integration surface is not the same thing as an enforcement plane.

Runtime authority sits next to those protocols. It does not replace message exchange or tool discovery. It asks a different question before execution: is this next action allowed?

Where A2A fits

A2A is useful when agents need to collaborate across boundaries.

For example:

• A support agent delegates invoice analysis to a billing agent.
• A research agent asks a compliance agent to review a draft.
• A planning agent hands a task to an execution agent in another system.

The important detail is that the receiving agent may be opaque. The calling agent may not know the receiver's internal prompts, tools, model choices, or orchestration framework. A2A gives these systems a shared communication protocol.

That is valuable. It lets teams compose agentic systems without forcing every agent into one runtime.

But delegation is not the same as authorization. If the support agent has $2 of remaining budget, it should not be able to delegate a $20 task to the billing agent and bypass the limit. If the support agent is allowed to read invoices but not issue refunds, it should not be able to regain refund authority by handing the task to another agent.

That is the problem covered by authority attenuation. Delegation should narrow authority, not reset it.

Where MCP fits

MCP is useful when agents need tools or context.

For example:

• A coding assistant reads repository files.
• A support agent searches a knowledge base.
• A finance agent invokes an invoice lookup tool.
• A workflow agent calls a system-specific action through an MCP server.

MCP standardizes the connection between AI applications and external systems. That standardization is a major step forward because every tool does not need a bespoke integration for every agent host.

But exposing a tool is not the same as granting permission. If an MCP server exposes send_email, the agent can discover and call it. The remaining question is whether this specific call, for this tenant, in this workflow, after the last 12 calls, should still run.

That is why MCP gateways are not runtime authority. A gateway can centralize traffic and policy hooks, but it must still make or call a pre-execution decision before the tool side effect happens.

The implementation pattern is covered in Add Hard Budgets to MCP Tools Before They Execute: reserve budget before the tool executes, commit actual usage after success, and release the reservation when the tool fails or is canceled.

Where runtime authority fits

Runtime authority is the layer that evaluates the next action before it starts.

It can consider:

• The tenant, workspace, agent, workflow, and toolset scope.
• The remaining monetary, token, credit, or RISK_POINTS budget.
• The parent budget delegated to this agent.
• The risk class of the requested tool.
• The difference between read-only, write, destructive, and external side-effect actions.

That decision should return something operationally useful:

• ALLOW: the action can proceed.
• ALLOW_WITH_CAPS: the action can proceed with smaller limits.
• DENY: the action must not run.

This is the same three-way decision model used throughout Cycles. It is not tied to whether the action arrived through A2A, MCP, a direct SDK call, a queue worker, or a framework hook. The point is to place the decision before execution.

For a broader layer comparison, see Runtime Authority vs Guardrails vs Observability. For the underlying concept, see What Is Runtime Authority for AI Agents?.

How the layers compose

Consider the support-to-billing workflow again.

1. The support agent receives a customer request.
2. It delegates an invoice task to a billing agent over A2A.
3. The billing agent calls an invoice lookup tool over MCP.
4. The billing agent calls a refund tool over MCP.
5. The support agent returns the final answer.

Runtime authority should be checked at several points:

• Before the support agent delegates work to the billing agent.
• Before the billing agent reads invoice data.
• Before the billing agent issues a refund.
• Before any fallback loop repeats the same expensive or risky action.

A2A carries the delegation. MCP exposes the tools. Runtime authority decides whether each action is still inside the allowed budget and scope.

If those roles are confused, the system gets brittle. Treat A2A as runtime authority and you may assume delegated agents inherit limits they never actually received. Treat MCP as runtime authority and you may expose tools without a shared budget ledger. Treat runtime authority as a transport protocol and you may end up rebuilding message exchange badly.

A design checklist

When teams adopt A2A and MCP together, the architecture review should ask five concrete questions.

What authority crosses the A2A boundary? A delegated agent should receive explicit budget, scope, and action authority. The handoff should not imply full trust.

Which MCP tools create side effects? Read-only lookup, write operations, external notifications, payments, deployments, and record deletion should not share the same risk budget.

Where is the pre-execution decision made? The decision can sit in an SDK hook, MCP tool wrapper, gateway, worker, or service boundary. It has to happen before the action.

What gets committed after execution? Estimates are useful before the call. Actual usage should be recorded after success so operators can tune future budgets.

What evidence survives the workflow? Multi-agent systems need a record of who delegated what, which tool ran, what budget was reserved, and why any action was denied.

Those questions are not protocol-specific. They are the operational layer around the protocols.

What this means for adoption

A2A and MCP are adoption accelerators because they reduce integration friction. They make it easier for agents to talk to other agents and use external systems.

That same success increases the need for runtime authority. The more tools and agents a system can reach, the more important it becomes to bound what each run, tenant, and delegated agent is allowed to do.

Start with the surface that has the highest exposure:

• If agents are calling production tools through MCP, add budget checks around those tool handlers first.
• If agents are delegating tasks across systems, add bounded delegation and authority attenuation first.
• If the main risk is runaway model spend, start with run or model-call budgets.

The architecture does not need to be exotic. It needs clear separation:

• A2A for agent-to-agent work.
• MCP for agent-to-tool work.
• Runtime authority for the yes/no/capped decision before work starts.

Resource links

• A2A protocol documentation — official protocol overview and MCP comparison.
• Model Context Protocol documentation — official MCP introduction.
• MCP Gateways Are Not Runtime Authority — why routing traffic is not the same as enforcing action authority.
• Add Hard Budgets to MCP Tools Before They Execute — implementation pattern for MCP tool wrappers.
• Agent Delegation Chains Need Authority Attenuation — how delegated authority should narrow across agent boundaries.
• Runtime Authority vs Guardrails vs Observability — the broader layer model.
• Choosing the Right Integration Pattern — where to place enforcement in real systems.