a sub-agent
in-process spawn
A coroutine or thread with no identity.
a2a sub-agent
A deployed agent with a card, DB, and endpoint.
spawn what you can govern
Spawn sub-agents you can actually control.
Spawning a sub-agent is a one-liner in every framework. Governing the thing you spawned is where it falls apart: a background coroutine with the parent's keys, no identity, and no audit trail is easy to create and impossible to hold accountable. a2a cloud makes a spawned sub-agent a first-class deployed actor — its own identity, a scoped grant sized to its task, signed receipts from its first run, and clean per-sub-agent revocation. Spawn freely; stay in control.
own identity · least-privilege grant · signed from run one
0
identity per spawned sub-agent
0
parent keys copied to the child
ungoverned window before first audit
the problem
Spawning is trivial. Governing what you spawned is not.
The framework makes spawning look free — call a function, get a worker. What you actually get is a background task running inside the parent, holding the parent's full credential, with no name, no isolation, and no receipt. It can touch anything the parent can, its actions blur into the parent's logs, and stopping it means killing the parent or rotating a shared secret. The ease of spawning hides the fact that you've created something you can't account for.
Sub-agents run in-process with the parent's full credential.
No distinct identity — actions can't be attributed to the child.
No isolation — a bad sub-agent shares the parent's data and blast radius.
Stopping one means killing the parent or rotating shared keys.
the a2a way
Make every spawn a governed, scoped, signed deployable.
a2a turns spawning into deploying: the sub-agent gets a separate deployment and database boundary, can receive a scoped grant through delegation, and produces signed evidence when invoked through the API, MCP, or /invoke entry point.
Spawn a governed actor, not a threadScoped grant at spawn timeSigned on those runsKill or re-scope one cleanly
Spawn a governed actor, not a thread
A spawned sub-agent is a deployed agent with its own card, isolated Postgres, and MCP endpoint — reachable, nameable, and auditable. You spawn an actor you can govern, not an anonymous coroutine.
Scoped grant at spawn time
The parent issues the sub-agent a grant scoped to just the tools, files, and TTL its task needs. A sub-agent starts with least privilege by construction, not with a copy of the parent's keys.
Signed on those runs
A spawned sub-agent's Agent API, public `/invoke`, and standard MCP `tools/call` skill executions receive Ed25519-signed receipts. Formal A2A message/task state and internal actions need separate ordered history or instrumentation.
Kill or re-scope one cleanly
Revoke a sub-agent's grant to stop it, or re-scope to change what it can do — a single action per sub-agent, no shared secret to rotate and no sibling disturbed.
side-by-side
Background task vs. governed sub-agent.
access at spawn
in-process spawn
Inherits the parent's full credential.
a2a sub-agent
Gets a scoped grant sized to its task.
audit
in-process spawn
Sub-agent actions blur into the parent's logs.
a2a sub-agent
Covered sub-agent executions have separately attributable signed evidence.
stopping one
in-process spawn
Kill the parent or rotate shared keys.
a2a sub-agent
Revoke that sub-agent's grant — nothing else changes.
dimension
in-process spawn
a2a sub-agent
a sub-agent
A coroutine or thread with no identity.
A deployed agent with a card, DB, and endpoint.
access at spawn
Inherits the parent's full credential.
Gets a scoped grant sized to its task.
audit
Sub-agent actions blur into the parent's logs.
Covered sub-agent executions have separately attributable signed evidence.
stopping one
Kill the parent or rotate shared keys.
Revoke that sub-agent's grant — nothing else changes.
questions
Frequently asked.
How do I spawn sub-agents?
On a2a cloud a parent agent spawns a sub-agent through the platform deploy and grant APIs: it stands up a child agent — which gets its own agent card, isolated Postgres database, and MCP endpoint — and issues it a scoped grant for the task. Unlike spawning a thread or coroutine, the result is a first-class deployed agent you can call, audit, and revoke independently of the parent.
What's the difference between a sub-agent and a background task?
A background task runs inside the parent's process and credential set. A sub-agent on a2a is a separate deployed actor with its own deployment and database boundary. Delegation can issue it a scoped grant, and its executions through Agent API, public `/invoke`, or standard MCP `tools/call` produce separately attributable signed evidence.
How do I stop a sub-agent that's gone wrong?
Revoke its grant. Because each sub-agent holds its own scoped, TTL-bound grant rather than a copy of a shared key, revoking or re-scoping one stops just that sub-agent. Receipts show caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing; richer activity needs separate history or instrumentation.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Spawn sub-agents. Keep the leash and the log.
a2a cloud deploys sub-agents with managed Postgres, MCP and API surfaces, and scoped grants. Agent API, public `/invoke`, and standard MCP `tools/call` skill executions receive receipts attributable to the sub-agent; formal A2A task routes remain protocol state.