runtime
laptop prototype
Serverless function or a script — seconds-long timeout kills the tool loop.
a2a production
Runtime built for long agent loops; multi-step runs finish, no function timeout.
the production checklist
How to deploy an AI agent to production.
Getting an agent to 'it runs on my laptop' takes an afternoon. Getting it to production is where most agents die. The gap isn't your prompt; it's six things tutorials skip: a runtime that survives long tool-loops, a durable database, auth that isn't a hardcoded key, an interface other systems can call, cost control, and an audit trail. Here's the honest checklist — and how a2a cloud ships all six in one deploy.
runtime · database · auth · interface · scale-to-zero · receipts
0%
of agents never reach prod
0
checklist items, one deploy
signed execution entry points
the gap nobody warns you about
'It runs on my laptop' is not production.
Most agent tutorials end at the demo: a script that loops, calls a model, prints a result. That version has no durable memory, one hardcoded key that can do everything, no way for another system to call it, and no record of what it did. Deploy it as-is to a serverless function and the first long tool-loop times out mid-run. The reason so many agents never ship isn't the model — it's that the production concerns are treated as a someday problem, and someday never comes.
Serverless timeouts kill agent loops mid-run — functions expect seconds, agents take minutes.
State lives in an in-memory dict that dies with the process; there's no real database.
One hardcoded API key grants everything and fails the first security review.
Nothing else can call the agent, and no record survives to show what it did.
the a2a way
Six production concerns, one deploy.
a2a cloud takes any agent — LangGraph, CrewAI, AutoGen, or custom — from one command or a describe-and-build prompt straight to a production surface. Runtime, database, auth, interface, cost control, and audit aren't a checklist you assemble yourself; they're what the platform provisions around your agent. Work through the six below.
1 · A runtime that survives long tool-loops2 · A real database, not a global dict3 · Auth that isn't a hardcoded key4 · An interface: MCP server, REST/A2A API, frontend5 · Scale-to-zero cost control6 · An audit trail you can actually produce
1 · A runtime that survives long tool-loops
An agent isn't a request/response function — it's a loop that plans, calls tools, waits on APIs, and reasons again, sometimes for minutes. Serverless functions cap out at seconds and kill the loop mid-thought. a2a runs each agent on a runtime built for long-running invocations, so a multi-step tool loop finishes instead of timing out.
2 · A real database, not a global dict
'It works on my laptop' usually means state lives in a Python dict that dies with the process. Production needs durable memory. An a2a deploy can provision per-agent managed Postgres and project its connection credential into that agent; database access is not universally mediated by scoped grants.
3 · Auth that isn't a hardcoded key
The demo pattern—one shared API key that can do everything—is the first thing to fail an audit. a2a supports short-lived, audience-bound grants for managed delegation and workspace access. Agent-owned database and upstream credentials remain separately configured secrets and must be governed as such.
4 · An interface: MCP server, REST/A2A API, frontend
A deployed agent nobody can reach isn't in production. a2a exposes every agent automatically — an MCP server so other agents and IDEs can call it as a tool, a REST and A2A API for your own services, and an optional hosted frontend so humans can use it. You write the agent; the surface area comes with the deploy.
5 · Scale-to-zero cost control
A production agent that idles on a warm instance bleeds money between requests. a2a scales each agent to zero when it's not being called and wakes it on the next request, so you pay for invocations, not for a box waiting for traffic. Cost control is a property of the platform, not a cron job you write later.
6 · An audit trail you can actually produce
The question you can't answer at 2am is 'what exactly ran?' Covered execution paths receive an Ed25519-signed receipt with caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. Optional activity fields require separate instrumentation.
side-by-side
Laptop prototype vs. production-grade agent.
state
laptop prototype
In-memory dict or SQLite on the laptop; gone when the process restarts.
a2a production
Managed Postgres per agent, provisioned on deploy with a per-agent connection credential.
auth
laptop prototype
One hardcoded API key in an env var — everything or nothing, forever.
a2a production
Scoped grants for supported operations, with separately governed agent-owned secrets.
interface
laptop prototype
A local script you run by hand; nothing else can call it.
a2a production
Automatic MCP server, REST/A2A API, and an optional hosted frontend.
cost & isolation
laptop prototype
A box left warm 24/7, running beside everything else on the host.
a2a production
Knative container service that scales to zero; explicit `ctx.sandbox` code uses a separate microVM.
dimension
laptop prototype
a2a production
runtime
Serverless function or a script — seconds-long timeout kills the tool loop.
Runtime built for long agent loops; multi-step runs finish, no function timeout.
state
In-memory dict or SQLite on the laptop; gone when the process restarts.
Managed Postgres per agent, provisioned on deploy with a per-agent connection credential.
auth
One hardcoded API key in an env var — everything or nothing, forever.
Scoped grants for supported operations, with separately governed agent-owned secrets.
interface
A local script you run by hand; nothing else can call it.
Automatic MCP server, REST/A2A API, and an optional hosted frontend.
cost & isolation
A box left warm 24/7, running beside everything else on the host.
Knative container service that scales to zero; explicit `ctx.sandbox` code uses a separate microVM.
questions
Frequently asked.
How do I deploy an AI agent to production?
At minimum you need six things a laptop demo doesn't have: a runtime that survives long-running tool loops, a durable database, auth that isn't a hardcoded key, an interface other systems can call, cost control so it doesn't bill you while idle, and an audit trail. With a2a cloud you get all six from one deploy — including signed receipts for authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions. Formal A2A message and task routes remain protocol state, not skill executions.
Why can't I just deploy my agent to a serverless function?
Serverless functions are built for short request/response work and cap execution at seconds. An agent is a loop — it plans, calls a tool, waits on an external API, reasons again — and a real task can run for minutes. A function timeout kills that loop mid-run, and you get truncated or failed outputs that worked fine on your laptop. Production agents need a runtime that expects long-running invocations, which is what a2a provides.
What's on the AI agent production checklist?
Six things. A runtime that survives long tool-loops instead of a serverless timeout. A database for durable state, not an in-memory dict. Auth with scoped grants, not a hardcoded key. An interface — MCP server, API, or frontend — so the thing can actually be called. Scale-to-zero, so idle agents stop billing you. And an audit record of what ran. Prototypes die when these are treated as afterthoughts. a2a ships all six with the deploy.
Do I have to rewrite my agent to productionize it on a2a?
No. a2a deploys agents built with LangGraph, CrewAI, AutoGen, or your own custom Python/TypeScript unchanged. The framework code stays as it is; the production concerns — runtime, Postgres, grants, MCP/API surface, scale-to-zero, receipts — are provided by the platform around your agent rather than wired into it. Framework-specific guides (deploy a LangGraph agent, deploy a CrewAI agent) walk through the exact steps.
How does a2a handle secrets and production access?
For delegation and workspace operations, a2a uses short-lived, audience-bound grants instead of passing one broad credential between callers. Receipts on the API, MCP, and /invoke paths record the grants that authorized it. Agent-owned upstream credentials remain separately configured secrets in the agent container; grants do not mediate every local file, database, tool, or network operation.
keep reading
Related guides.
All guides live in the guides index.
ship it, don't stall it
Get past the prototype.
a2a cloud deploys any agent — LangGraph, CrewAI, AutoGen, or custom — as a Knative or Kubernetes container service with managed Postgres, scoped grants, MCP plus REST/A2A surfaces, an optional frontend, and scale-to-zero cost control. Authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions receive Ed25519-signed receipts; explicit `ctx.sandbox` code execution uses a separate microsandbox microVM.