Agents that build agents, on the platform API.
A meta-agent is only useful if what it builds actually runs. On most stacks a builder agent emits code or config and a human still has to deploy it — the automation stops at the interesting part. a2a cloud gives builders the deploy API directly: your meta-agent packages, provisions, and exposes a live child agent, finds capabilities by discovery instead of hard-coding, and leaves a signed record of everything the factory produced.
deploy by API · discover, don't hard-code · every child an audit boundary
A meta-agent that only emits config isn't building anything.
The point of an agent that builds agents is to close the loop — go from intent to a working agent with no human in the middle. But most frameworks let a builder produce a spec, a graph, or a snippet, then hand it back to you to deploy, isolate, and secure by hand. The children have no identity, share whatever the parent holds, and leave no record. You've automated the easy half and kept the hard half manual.
Give the builder a real deploy API and real isolation.
a2a exposes the same deploy, discovery, and grant primitives to a meta-agent that a human developer uses — so building an agent produces a governed, isolated, callable actor, not homework.
A deploy API for meta-agents
Your builder agent calls the same `a2a deploy` path a human would — package, provision, expose. The output isn't a config blob; it's a live agent with an endpoint, so a meta-agent can stand up working children on demand.
Discovery instead of hard-coding
A builder finds capabilities with `ctx.discover.find_agents(skill=...)` rather than hard-wiring child references. It can compose existing agents or generate new ones, and the wiring is queryable, not buried in code.
Each child is an audit boundary
Every built agent gets its own isolated Postgres and its own receipt chain. One misbehaving child can't read another's data or muddy its ledger — the factory produces isolated units, not shared state.
The factory is auditable too
The meta-agent's own runs are signed like any other. You get a provable record of the factory: what it built, when, for whom, and at what cost — the supply chain of your agent fleet.
Config-emitting builder vs. platform-native factory.
Frequently asked.
What is an agent that builds agents?
It's a meta-agent, or agent factory — an agent whose job is to generate, configure, and deploy other agents rather than to do the end task itself. On a2a cloud the builder uses the platform deploy API, so each agent it produces is a first-class deployable with its own agent card, isolated Postgres, and MCP endpoint, not a template or a code snippet a human still has to ship.
How does a builder agent find or compose the agents it needs?
Through discovery. A builder calls `ctx.discover.find_agents(tags=..., skill=..., capability=...)` to locate existing agents by what they can do, then composes them or generates new ones to fill gaps. Because wiring happens at runtime by capability instead of hard-coded references, the resulting fleet stays queryable and doesn't rot when individual agents change.
How do you keep one built agent from interfering with another?
Every agent the factory builds gets its own isolated Postgres database and its own hash-chained receipt ledger, and runs under its own scoped grant. That makes each child a hard audit and data boundary — one child can't read another's data or write to another's ledger, so a fault in one built agent is contained rather than fleet-wide.
Related guides.
All guides live in the guides index.
Ship a factory, not a template engine.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and hands your builder agents the same API: deploy a live child, give it an isolated Postgres and an MCP endpoint, scope its grant, and sign every run. The whole agent app, produced by another agent, with proof.