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 — reportedly around 88% never make it. 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
'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.
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-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: conversation history, task state, embeddings. Every a2a agent gets its own managed Postgres, provisioned on deploy, reached through scoped grants — no connection string to leak, no database to stand up.
3 · Auth that isn't a hardcoded key
The demo pattern — an API key in an env var, one secret that can do everything — is the first thing to fail an audit. a2a replaces ambient keys with scoped grants: each call to a tool, database, or downstream service carries a short-lived, audience-bound authority for exactly that action. No standing production access sitting in a config file.
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 did the agent do?' a2a writes an Ed25519-signed receipt for every run — the inputs, the tool calls, the grants that were in force, the outputs. Not a log line you hope wasn't rotated away, but a tamper-evident record you can hand to a customer, a regulator, or yourself.
Laptop prototype vs. production-grade agent.
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 — you point it at any agent (or describe and build one), and it provisions the runtime, a managed Postgres, scoped grants, an MCP server plus REST/A2A API, scale-to-zero, and a signed receipt per run.
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?
Runtime (survives long tool-loops, not a serverless timeout), database (durable state, not an in-memory dict), auth (scoped grants, not a hardcoded key), interface (an MCP server, API, or frontend so it can actually be called), cost control (scale-to-zero so idle agents don't bill you), and audit (a tamper-evident record of what ran). Reportedly the vast majority of agents — often cited as around 88% — never make it past the prototype because these six are treated as afterthoughts. a2a ships them as platform primitives.
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?
Instead of a hardcoded API key that grants everything, a2a issues scoped grants: each call to the database, a tool, or a downstream service carries a short-lived, audience-bound authority for exactly that action. There's no single standing secret sitting in a config file for an attacker or a leaked repo to find, and every grant that was in force during a run is recorded in that run's signed receipt.
Related guides.
All guides live in the guides index.
Get past the prototype.
a2a cloud deploys any agent — LangGraph, CrewAI, AutoGen, or custom — and ships it with a runtime built for long tool-loops, a managed Postgres database, scoped grants instead of hardcoded keys, an automatic MCP server plus REST/A2A API, an optional hosted frontend, scale-to-zero cost control, and an Ed25519-signed receipt for every run. The whole production checklist, from one deploy. Working with a specific framework? See the guides for deploying a LangGraph, CrewAI, or custom a2a agent.