delegation
shared-key manager
The manager shares its API keys with every worker.
a2a manager
The manager issues each worker a scoped, TTL-bound grant.
the manager pattern, governed
An agent of agents that delegates safely.
The supervisor pattern—one agent directing workers—is where authority can sprawl. a2a cloud supports scoped delegation and discoverable workers. Agent API, public `/invoke`, and standard MCP `tools/call` worker executions produce signed evidence; formal handoffs and ordered history remain separate records.
grants not keys · discoverable workers · signed run evidence
0
worker keys the manager shares
0
signed worker execution entry points
grant scope per worker task
the problem
To delegate, the manager usually hands over the keys.
A manager agent has to give its workers enough access to do their jobs. On most stacks that means sharing credentials — the same broad API key flows to every worker, and the moment of delegation leaves no trace of intent or authority. The result is a hierarchy on paper and a flat, fully-trusted blast radius in practice: any worker can do anything the manager can, and no receipt shows who authorized what. That's not a chain of command; it's shared root.
Delegation is done by copying the manager's keys to every worker.
Workers are hard-coded sub-routines, not swappable deployed agents.
The chain of command isn't recorded — logs show calls, not authority.
Removing one worker means rotating shared keys and redeploying.
the a2a way
Delegate scoped authority and preserve the evidence.
a2a lets a supervisor mint narrow, revocable grants for each worker. Individually signed run receipts and a signed ordered session let you read the resulting hierarchy without claiming more than the signature covers.
The manager delegates authority, not keysWorkers are real, discoverable agentsYou can read the delegation timelineRevoke a worker without touching the rest
The manager delegates authority, not keys
Delegation can issue each worker a child grant no broader than its parent, bound to an audience and TTL. Credentials you configure yourself sit outside the grant.
Workers are real, discoverable agents
Each worker under the manager is a deployed agent with its own card and skills. The manager finds them by capability through discovery and calls them like services, so you can add, swap, or retire workers without rewiring the boss.
You can read the delegation timeline
Each worker's Agent API, public `/invoke`, or standard MCP `tools/call` execution receives its own receipt with caller identity/classification, skill, input evidence, verified grants, outcome, and timing. A separately signed ordered session can preserve cross-worker events.
Revoke a worker without touching the rest
A platform-issued worker grant can be revoked or re-scoped without rotating a shared credential. This affects grant-backed operations, not unrelated secrets configured directly on the worker.
side-by-side
Shared-key hierarchy vs. governed delegation.
workers
shared-key manager
Sub-routines hard-wired into the manager's code.
a2a manager
Discoverable deployed agents the manager calls by capability.
chain of command
shared-key manager
Untraceable — logs don't show who authorized what.
a2a manager
Per-run signatures plus an ordered session show caller, handoff, action, and grant references.
removing a worker
shared-key manager
Rotate shared keys and redeploy everything.
a2a manager
Revoke one grant; the manager keeps running.
dimension
shared-key manager
a2a manager
delegation
The manager shares its API keys with every worker.
The manager issues each worker a scoped, TTL-bound grant.
workers
Sub-routines hard-wired into the manager's code.
Discoverable deployed agents the manager calls by capability.
chain of command
Untraceable — logs don't show who authorized what.
Per-run signatures plus an ordered session show caller, handoff, action, and grant references.
removing a worker
Rotate shared keys and redeploy everything.
Revoke one grant; the manager keeps running.
questions
Frequently asked.
What is an agent of agents?
An agent of agents directs workers and combines results. On a2a cloud, delegation can use scoped grants instead of shared keys. Worker skills executed through the API, MCP, and /invoke entry points produce signed evidence; ordered session history only exists if you record it.
How does a manager agent give workers access without sharing its keys?
Through delegation, a manager can request a child grant no broader than its parent, bound to an audience, declared scope, and short TTL. That avoids copying the manager's raw credential for grant-backed operations; worker credentials you configure yourself stay separate.
Can I prove the chain of command in a supervisor-worker system?
Each worker execution on the API, MCP, or /invoke entry point receives an Ed25519-signed receipt recording caller, skill, input evidence, verified grant IDs, outcome, result preview, and timing. Cross-worker handoffs belong to separate ordered session history. Deterministic reruns still require replay doubles and seeded randomness.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Put an agent in charge — with a paper trail.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, AutoGen, or custom — so supervisors and workers get managed Postgres, MCP and API surfaces, and scoped grants. Agent API, public `/invoke`, and standard MCP `tools/call` executions receive signed receipts; formal A2A task routes remain protocol state.