a2a cloud
describe → build → review → improve → deploy

An AI agent builder that ships production agents, not demos.

Most AI agent builders are drag-and-drop canvases. You wire nodes until something demos well, then discover it can't reach production — no database, no real access model, no proof of what it did, and no way out of the visual editor. a2a cloud's Agent Studio works differently. You describe the agent in one prompt, and a crew of specialist agents builds it, reviews it for flaws, fixes them, and deploys it as a real governed service you own.

one prompt · builder + reviewer + editor · real code you own

0
prompt to deploy
0
specialist agents in the crew
0
signed execution entry points
the problem

Drag-and-drop builders demo well and ship nothing.

The typical AI agent builder is a visual editor: drag nodes, connect arrows, and watch a happy-path demo run. The trouble starts after the demo. The flow is trapped inside the editor with no code to own, it talks to a model but has no database or service other systems can call, its access is a long-lived API key with standing reach, and there's no record of what any run actually did. What looked like a finished agent is a screenshot away from production and a long way from it.

The agent lives inside a visual editor — no real code, no git repo, no exit.
It calls a model but isn't a service: no database, no API, nothing to call it.
Access is a standing API key in an env var, not scoped, revocable grants.
Runs leave mutable logs at best — no signed execution record or ordered event history.
the a2a way

Describe it once. A crew builds, reviews, and deploys it.

Agent Studio turns one prompt into a running service. A builder writes the code, a reviewer hunts for flaws, an editor fixes them, and the loop runs until the work passes or the budget stops it. What deploys is a real agent: its own managed Postgres, an MCP server, a REST/A2A API, an optional frontend, scoped grants, and signed receipts on every call.

Describe it onceA crew, not a templateYou own the codeA whole service, deployedGrants, not API keysSigned evidence at governed entry points

Describe it once

You don't wire nodes on a canvas. You write one prompt describing what the agent should do, and Agent Studio turns it into a working service — the scaffolding, the tools, the API surface, the database schema. The starting point is a sentence, not a blank flowchart.

A crew, not a template

A builder agent scaffolds the code, a reviewer agent hunts for flaws and gaps, and an editor agent fixes what the reviewer finds. They loop — build, review, improve — bounded by a budget and a review cap, so you get something inspected and corrected, not the first draft of a generator.

You own the code

The output is real source in a git repo you own — readable, forkable, diffable. It is not trapped inside a visual editor you can only escape by rebuilding. When you outgrow the studio, you keep the code and edit it like any other service.

A whole service, deployed

Every agent ships as a governed service: its own managed Postgres, an MCP server, a REST/A2A API, and an optional frontend. One deploy stands up the whole app — not a chat widget that calls a model, but a service other systems and agents can actually call.

Grants, not API keys

Supported delegation and workspace operations can use audience- and TTL-bound grants. Managed databases and user-configured upstream tools use separately projected credentials, which remain outside that grant boundary and require their own governance.

Signed evidence at governed entry points

Authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions receive Ed25519-signed receipts covering caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Formal A2A message and task routes remain protocol state.

side-by-side

Drag-and-drop toy vs. Agent Studio.

how you build

toy builder

Drag nodes onto a canvas and wire them by hand until a demo works.

Agent Studio

Describe the agent in one prompt; a crew builds, reviews, and improves it.

what you get

toy builder

A flow locked inside a visual editor you can't leave without rebuilding.

Agent Studio

Real code in a git repo you own — readable, forkable, editable.

what ships

toy builder

A chat widget or webhook that calls a model — demo-grade, not a service.

Agent Studio

A governed service: managed Postgres, MCP server, REST/A2A API, frontend.

access

toy builder

A long-lived API key in an env var with standing access to everything.

Agent Studio

Scoped grants — audience-bound, time-limited, revocable — not ambient keys.

trust

toy builder

Mutable logs you hope captured what the agent did.

Agent Studio

Signed receipts for authenticated Agent API, public `/invoke`, and standard MCP `tools/call` executions.

questions

Frequently asked.

What is a2a cloud's AI agent builder?

It's Agent Studio: you describe the agent you want in one prompt, and a crew of specialist agents builds it. A builder agent scaffolds the code, a reviewer agent hunts for flaws, and an editor agent fixes them — looping build → review → improve until the work passes, bounded by a budget and a review cap. The result deploys as a real governed service with its own managed Postgres, an MCP server, a REST/A2A API, and an optional frontend. It's a builder that ships production agents, not drag-and-drop demos.

How is this different from drag-and-drop agent builders?

Most 'AI agent builders' are visual canvases: you wire nodes until a demo works, and the result lives inside the editor. Agent Studio starts from a prompt and produces real code in a git repo you own — nothing is locked in a proprietary flow. And it doesn't stop at a chatbot: it deploys a full service with a database, an MCP server, and an API, so the agent is something other systems can call in production, not a demo you screen-record.

Do I own the code the agent builder produces?

Yes. The build → review → improve loop writes real source into a git repo you own — readable, forkable, and diffable. You are never trapped in a visual editor. When you outgrow the studio, you keep the code and edit it like any other service; the studio was the starting point, not a cage.

How does the build-and-review loop actually work?

Three roles run as a crew. The builder scaffolds the agent from your prompt — code, tools, database schema, API surface. The reviewer reads the result and hunts for flaws, gaps, and risky assumptions. The editor applies fixes for what the reviewer flags. They iterate build → review → improve, bounded by a budget and a maximum number of review passes, so you get inspected and corrected work instead of a generator's untouched first draft.

What does 'deploy as a real service' actually give me?

One deploy stands up the whole agent app. It gets its own managed Postgres database, an MCP server usable directly from Claude Code or Cursor, a REST and A2A API, and an optional frontend. The hosted agent runs as a Knative or Kubernetes container service and scales to zero when idle; code explicitly sent through `ctx.sandbox` uses a separate microsandbox microVM. Authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions receive signed receipts.

keep reading

Related guides.

All guides live in the guides index.

a builder that ships

Describe the agent. Ship the service.

One prompt in, a deployed agent out. It ships with managed Postgres, MCP and API surfaces, an optional frontend, scale-to-zero, a sandbox for `ctx.sandbox` code, scoped grants, and Ed25519-signed receipts. Real code you own in a git repo — not a flow trapped in a visual editor.