child agent
in-process spawn
A sub-process or in-memory thread with no identity of its own.
a2a self-building
A deployed agent with its own card, DB, grant, and receipts.
agents that ship agents
Self-building agents you can actually govern.
An agent that writes and deploys new agents is exercising real authority. a2a cloud makes a self-built child a separate deployable with its own database boundary. Delegation can issue scoped grants, and a build skill executed through the API, MCP, or /invoke entry point produces signed evidence; child deployment metadata and history remain separate.
every child a governable actor · authority can narrow · build runs signed
0
identity per generated child
0
extra scopes a child can grab
signed build execution entry points
the problem
Self-building is easy. Governing what gets built is the hard part.
Wiring an agent to generate more agents takes an afternoon. The trouble starts after: the children run inside the parent with the parent's keys, no distinct identity, no isolation, and no record of who built what. When one of them takes a consequential action, you can't say which generation produced it, what authority it held, or how to revert. A self-modifying system with no boundary is a self-modifying liability.
Generated agents share the parent's process, keys, and blast radius.
There's no record of which parent built which child, or from what prompt.
A buggy generation can quietly widen access instead of narrowing it.
Rolling back means guessing which version broke and hand-editing state.
the a2a way
Make the child a first-class, signed, scoped deployable.
a2a treats a generated agent like another deployment: separate identity and database boundaries, optional scoped delegation, and signed evidence on the API, MCP, and /invoke paths.
Every child gets an identityThe build run is signedAuthority flows down, never upInspect and compare generations
Every child gets an identity
When a parent agent generates a new agent, `a2a deploy` mints it a first-class identity — its own agent card, MCP endpoint, and isolated Postgres. The child isn't a thread in the parent; it's a governable actor you can name, scope, and audit.
The build run is signed
When generation executes through the API, MCP, or /invoke entry point, its receipt signs caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Artifacts, handoffs, deployment metadata, and economics remain separate records.
Authority flows down, never up
A parent can only grant a child a subset of what it holds. Scoped, TTL-bound grants pass down the build chain, so a self-built agent can never quietly acquire more access than the agent that made it.
Inspect and compare generations
Generated agents are versioned, and the signed ordered event history lets you inspect the build run. If a generation regresses, compare its artifacts and deployment metadata before reverting to a known version.
side-by-side
In-process spawning vs. governed self-building.
authority
in-process spawn
The child inherits the parent's keys — often all of them.
a2a self-building
The child gets a scoped grant strictly narrower than the parent's.
the build event
in-process spawn
An untracked side effect buried in logs, if recorded at all.
a2a self-building
A signed build-run record plus separate child deployment metadata.
regression
in-process spawn
You diff logs and guess which generation broke.
a2a self-building
Inspect the signed history, compare versioned artifacts, and revert deliberately.
dimension
in-process spawn
a2a self-building
child agent
A sub-process or in-memory thread with no identity of its own.
A deployed agent with its own card, DB, grant, and receipts.
authority
The child inherits the parent's keys — often all of them.
The child gets a scoped grant strictly narrower than the parent's.
the build event
An untracked side effect buried in logs, if recorded at all.
A signed build-run record plus separate child deployment metadata.
regression
You diff logs and guess which generation broke.
Inspect the signed history, compare versioned artifacts, and revert deliberately.
questions
Frequently asked.
What is a self-building agent?
A self-building agent is one that generates, configures, and deploys other agents at runtime instead of being hand-written and shipped by a human. On a2a cloud the generated agent is a real deployable — it gets its own agent card, an isolated Postgres database, an MCP endpoint, and a scoped grant — so a self-built agent is a governable actor rather than an untracked sub-process.
How do you keep a self-building agent from escalating its own access?
Authority only narrows down the build chain. A parent agent can grant a child a subset of the scopes it holds and no more, and every grant is audience-bound and TTL-limited. Because the child runs under its own signed grant rather than the parent's raw keys, it can never widen its own access — the platform rejects any request outside the grant.
Can I prove what a self-building agent created and why?
When building executes through the API, MCP, or /invoke entry point, its receipt records caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Child-agent metadata, artifacts, handoffs, and evaluations remain separate records. Only authenticated Agent API paid calls can receive linked economics.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Let agents build agents — with proof.
a2a cloud deploys generated agents with managed Postgres, MCP and API surfaces, and scoped grants. Their Agent API, public `/invoke`, and standard MCP `tools/call` executions receive signed receipts; build artifacts and deployment metadata remain separate records.