A different boundary
MCP commonly connects an AI application to a capability provider. Agent-to-Agent protocols address another situation: a system delegates a task to another system that has its own skills, state, tools and control loop.
An A2A-style exchange needs more than a request. The caller needs to understand the receiving agent’s advertised capabilities, send a bounded task, receive status or artifacts, and decide what to do with the result.
delegating system → task with scope and identity → receiving system
delegating system ← status, result, artifact, evidence ← receiving system
Delegation does not remove responsibility
The delegating system is still accountable for selecting a trustworthy peer and for what it does with the result. The receiving system must enforce its own authorization and policies. A received artifact is evidence to review, not a command that automatically runs.
This is why identity, tenant boundaries, task expiry, trace correlation and a clear failure contract matter. “Ask another agent” is an integration, not a shortcut around controls.
When to use it
Use delegation when the other system owns a genuinely separate capability or context: a security-review service, a specialist data system, or an external organization. If all workers share one application and one set of tools, ordinary internal functions or a queue may be clearer.
Try it
Open two terminals in the cloned Workbench folder. In the first, start the bounded peer:
workbench a2a-server
In the second, send one request through the SDK client:
workbench a2a-review
The client discovers the Agent Card, sends a named synthetic scenario plus two permitted evidence sources, and receives a task and Synthetic evidence review artifact. The peer rejects unknown evidence and cannot deploy, notify, read secrets or reach another system. Stop the server with Ctrl+C when you are done.
Keep this with you
Delegation transfers work, never accountability.