a2a cloud
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
0
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 an identity, a least-privilege grant, its own database, and receipts from the start — so control comes built in, not bolted on later.

Spawn a governed actor, not a threadScoped grant at spawn timeSigned from its first runKill 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 from its first run

From the moment it's spawned, every action the sub-agent takes emits an Ed25519-signed receipt. There's no ungoverned window between spawn and first audited action.

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.

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.
Each sub-agent has its own signed receipt chain.
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, under the parent's credentials, with no identity of its own — if it misbehaves, the blast radius is the parent's. A sub-agent on a2a is a separate deployed actor with its own identity, its own scoped grant, its own database, and its own signed receipt chain. That makes it independently governable: least-privilege access, per-sub-agent audit, and clean revocation.

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 is a single action that stops just that sub-agent — no need to kill the parent, rotate a shared secret, or disturb its siblings. Its signed receipts also let you see exactly what it did before you cut it off.

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 any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and every sub-agent it spawns gets its own isolated Postgres database, an MCP server, an API, a scoped grant, and an Ed25519-signed receipt for every run. Least privilege at spawn, clean revocation, per-sub-agent proof.