Agent-Builder: The Meta-Agent That Writes, Tests, and Ships Other Agents

Agent-Builder: The Meta-Agent That Writes, Tests, and Ships Other Agents

The most ambitious agent on A2A Cloud is the one that builds other agents.

Agent-Builder takes a natural-language description and returns a live, deployed, callable agent. Not a code snippet. Not a draft. A running service at a public URL. And it does that by being an A2A agent itself — written in the same A2A Pack contract, deployed through the same pipeline, running in the same Knative runtime as everything else on the platform.

This is agents-all-the-way-down done right.

The One Skill That Does Everything

Agent-Builder is an A2AAgent with exactly one public skill: build. Pass it a name and a prompt. Stand back.

build(name="weather-bot", prompt="Tell me the weather for any city")

What happens next is a real DeepAgents loop. Not a script. Not a template renderer. An agent that thinks, writes code, runs that code, fixes it, and ships it.

The outer A2AAgent surface wraps an inner DeepAgents graph created with create_deep_agent(). The graph gets the user prompt, plus access to a curated set of tools and skill bundles. Then it runs.

Skills That Make It Smart

Five skill bundles teach the builder how to build:

• deepagent-agent-design — architecture patterns for the agents it will write
• a2apack-agent-authoring — the A2A class shape, card shape, manifest shape
• deepagents-implementation-patterns — tool/subagent/skill wiring
• workspace-artifact-safety — don't write past the grant, don't ship secrets
• agent-quality-review — pre-deploy validation

These live at BUILDER_SKILL_SOURCE = "/.agent-builder/skills/" and get mounted into the workspace at runtime. The builder consults them as it works. The skills are the playbook.

This is the DeepAgents pattern: don't bake knowledge into prompts. Put it in a directory the agent can read, file-by-file, as needed.

The Build Loop

The LLM doesn't get to YOLO files. It works through tools. Here's the order:

1. `init_agent_template(name, ...)` — scaffold a clean A2A Pack project in the workspace.
2. `write_agent_file(...)` — write agent.py, a2a.yaml, requirements.txt, optional frontend, optional skill bundles. The builder reads back what it wrote, reviews the file tree, patches as needed.
3. `test_agent_in_sandbox(name)` — bundle the workspace into a gzip tarball, POST to the sandbox runtime, install a2a-pack, install requirements, run a2a card. If it fails, the builder reads the error and fixes the code.
4. `cp_deploy_tarball(name, version, public)` — tarball the verified source, POST to the control plane's /v1/agents/from-tarball with the user's cp_jwt.
5. `_wait_for_live_card(...)` — poll /.well-known/agent-card every 2s with exponential backoff (capped 10s, 900s timeout) until the deployed version matches.

When step 5 returns, the agent is actually live and callable. Not "upload accepted." Not "build queued." Live.

Testing In The Same Sandbox Everyone Else Uses

This is the elegant part. The builder doesn't have a special test rig. It uses the same microsandbox layer every other agent uses.

test_agent_in_sandbox() POSTs the project tarball to the sandbox runtime, which boots a libkrun microVM, mounts a workspace, runs pip install, runs a2a card. The output — exit code, stdout, stderr — streams back. The builder reads it. If a2a card fails because of a syntax error or missing import or bad type hint, the builder patches the file and tries again.

The builder eats its own dogfood. Every generated agent passes the same gate every developer-written agent passes.

Upload, GitOps, Done

When the sandbox test succeeds, cp_deploy_tarball() ships the source up. The control plane:

1. Creates or updates the managed Gitea repo for this agent.
2. Commits the source as the user.
3. Wires the ArgoCD application.
4. Records deployment events.
5. Lets the normal build-and-rollout pipeline take over.

The builder then polls the live card. It doesn't claim success until the runtime confirms the new version is serving. Honest delivery.

What Knative Sees

The agent-builder itself is a Knative service. Its deploy manifest:

• Image: registry.a2acloud.io/agents/agent-builder:<sha>
• Port: 8000
• Max concurrency: 1 (one build at a time per pod)
• Timeout: 1200s
• Resources: 200m CPU request / 1 CPU limit, 512Mi / 1Gi memory
• Env: SANDBOX_URL, SANDBOX_TIMEOUT_S=1200, DEPLOY_WAIT_TIMEOUT_S=900, A2A_CP_URL

It scales to zero when idle. Boots cold when called. Builds an agent. Hands back a URL. Goes back to sleep.

A meta-agent that costs nothing while it isn't working.

Why The Architecture Is Beautiful

Look at what this composition gives you:

• The builder is an agent. It uses ctx.workspace to write source files, ctx.sandbox to test them, ctx.cp_jwt to deploy them, and ctx.llm to think.
• The agents it builds use the same exact contract.
• The runtime is the same for both — microVM-isolated, grant-scoped, GitOps-tracked.
• The deployment path is the same. The builder doesn't have a privileged shortcut. It uploads tarballs to the same endpoint every other agent uses.

That's not luck. That's an architecture where the platform's primitives are powerful enough that the platform's own tools can be built from them. Composability all the way through.

Most agent platforms ship code generators that bypass their own infrastructure. A2A Cloud's code generator uses its own infrastructure. That's the test.

What This Means For The Future

Agent-builder is the proof point. Once you can describe an agent and get a real one back, the marketplace becomes generative.

• Builders ship agent ideas in minutes, not days.
• Operators can fork, customize, and re-deploy agents.
• Buyers can request agents for specific tasks.
• The platform learns from every build — which patterns work, which fail, which need new skills.

This is the loop that makes the agent economy *scale*. Not "hire ten engineers to build ten agents." Describe ten agents. Get ten agents. Iterate.

The Direction

Agent-builder is the *current* meta-agent. The architecture invites more:

• A reviewer agent that audits other agents before deploy.
• A patcher agent that diagnoses failing live agents and ships fixes.
• A composer agent that wires existing agents into multi-agent workflows.
• A migrator agent that ports agents between SDK versions.

All of them: agents calling the same platform primitives, deploying through the same GitOps path, isolated in the same microVMs, governed by the same grants.

This is what a platform built for agents looks like. Not a chatbot wrapper. Not a function-calling library. An operating system where agents build agents that build agents — safely, repeatably, and at scale.

A2A Cloud isn't talking about that future. It's the live runtime.