output
emit-and-hand-off
A meta-agent emits config or code a human must deploy.
a2a factory
A meta-agent deploys a live, callable agent through the platform API.
the factory pattern for agents
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 signed evidence for its executed runs alongside the child's deployment record.
deploy by API · discover, don't hard-code · every child an audit boundary
0
steps from build to live child
0
isolated database per child
0
shared blast radius
the problem
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.
Builders output code or config a human still has to deploy and secure.
Child agents share the parent's database, keys, and failure domain.
References between agents are hard-coded and break as the fleet changes.
There's no ledger of what the factory built or on whose authority.
the a2a way
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-agentsDiscovery instead of hard-codingEach child is an audit boundaryThe factory is auditable too
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
Each built agent can get its own isolated Postgres and its own signed evidence on the API, MCP, and /invoke paths. One child cannot read another's database through the platform's normal scoped interfaces, and their deployment and run records stay separate.
The factory is auditable too
Meta-agent skill executions on the API, MCP, and /invoke entry points receive signed caller, skill, input, verified grant, outcome, and timing evidence. Artifacts, child deployment metadata, and Agent API paid-call economics remain separate records.
side-by-side
Config-emitting builder vs. platform-native factory.
wiring
emit-and-hand-off
Child references are hard-coded and go stale.
a2a factory
Children are discovered by skill and capability at runtime.
isolation
emit-and-hand-off
Built agents share a database and a blast radius.
a2a factory
Each built agent gets its own Postgres and signed run history.
the factory
emit-and-hand-off
No record of what the builder produced or why.
a2a factory
Signed build-run evidence sits beside separate child deployment records.
dimension
emit-and-hand-off
a2a factory
output
A meta-agent emits config or code a human must deploy.
A meta-agent deploys a live, callable agent through the platform API.
wiring
Child references are hard-coded and go stale.
Children are discovered by skill and capability at runtime.
isolation
Built agents share a database and a blast radius.
Each built agent gets its own Postgres and signed run history.
the factory
No record of what the builder produced or why.
Signed build-run evidence sits beside separate child deployment records.
questions
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?
Each child can be deployed with its own isolated Postgres, scoped delegation, and signed evidence on Agent API, public `/invoke`, or standard MCP `tools/call` executions. That keeps normal platform database access and evidence records separate, without claiming absolute isolation from arbitrary externally configured credentials.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Ship a factory, not a template engine.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and hands builders the same API: deploy a live child, give it isolated Postgres and MCP surfaces, scope delegation, and sign executions on the API, MCP, and /invoke entry points.