handoffs
in-process group chat
Agents pass work as in-process calls — no identity, no authorization, no record.
a2a cloud
Scoped A2A handoffs carry identity and authority context; worker runs receive signed receipts.
autogen, in production
Deploy an AutoGen multi-agent system to production.
AutoGen lets a group of agents converse and hand work to each other. a2a cloud hosts the multi-agent system, adds scoped grants to A2A exchanges, and supplies MCP, an auth gateway, and managed Postgres. Skill executions through the Agent API, public `/invoke`, and standard MCP `tools/call` receive receipts; formal A2A messages remain protocol state.
scoped handoffs · explicit authority · verifiable execution
0
signed execution entry points
0
ambient trust
idle cost
the problem
Multi-agent conversations don't survive contact with production.
An AutoGen system is a set of agents talking in a single process. It works on your machine, but production exposes what the group chat never had: no authenticated entry point, no identity or authorization on the handoffs between agents, no durable transcript, and no verifiable record of which agent did what under whose authority. When agents act on each other's behalf, in-process calls give you none of the proof an incident review needs.
Handoffs are in-process calls — untraceable, unauthorized, ambiently trusted.
There's no authenticated entry point to the system for other services to call.
The conversation transcript lives in memory and dies with the process.
You can't prove which agent took which action, or under what authority.
the a2a way
One deploy makes the whole system callable, auditable, and signed.
a2a is framework-agnostic: it deploys the whole agent app around your AutoGen code, carries scoped grants across A2A exchanges, and signs executions on the Agent API, public `/invoke`, and standard MCP `tools/call` paths. Formal A2A messages and tasks remain protocol state.
Your agents, as writtenScoped A2A handoffsMCP server for shared toolsOpenAPI gateway + authManaged Postgres for the transcriptPer-agent receipts
Your agents, as written
Keep your AutoGen AssistantAgents, UserProxyAgent, GroupChat, and orchestration. a2a hosts the process your system runs in — it doesn't rebuild your conversation graph in another framework.
Scoped A2A handoffs
An Agent2Agent exchange can carry caller identity and a scoped grant. Formal A2A messages remain protocol history; when the worker skill executes through Agent API, public `/invoke`, or standard MCP `tools/call`, that execution receives its own signed evidence.
MCP server for shared tools
The tools your agents use become a hosted MCP server, so agents inside and outside the system invoke them over a real protocol instead of sharing Python function references.
OpenAPI gateway + auth
The multi-agent system gets one authenticated HTTP entry point through an OpenAPI gateway, with Keycloak identity, TLS, and scoped grants — so the whole system is callable, not just runnable.
Managed Postgres for the transcript
Conversation state, message history, and results land in a managed Postgres provisioned in the same deploy — durable across restarts and scale-to-zero, no DB to run yourself.
Per-agent receipts
Agent API, public `/invoke`, and standard MCP `tools/call` executions receive Ed25519-signed receipts with caller, skill, input evidence, verified grants, outcome, and timing. The ordered signed session history is separate; formal A2A messages are protocol state.
side-by-side
Raw AutoGen deploy vs. a2a.
entry point
in-process group chat
You run the group chat from a script; there's no authenticated way in.
a2a cloud
One OpenAPI gateway with Keycloak identity and TLS fronts the whole system.
tools
in-process group chat
Tools are shared Python references only agents in the same process can use.
a2a cloud
Hosted MCP server — agents inside and outside the system call tools over a protocol.
transcript
in-process group chat
Message history lives in memory and is gone when the process exits.
a2a cloud
Managed Postgres keeps the transcript and results durable across restarts.
proof
in-process group chat
A verbose console log of the conversation — mutable and unverifiable.
a2a cloud
Per-agent Ed25519-signed receipts plus an ordered signed session history.
dimension
in-process group chat
a2a cloud
handoffs
Agents pass work as in-process calls — no identity, no authorization, no record.
Scoped A2A handoffs carry identity and authority context; worker runs receive signed receipts.
entry point
You run the group chat from a script; there's no authenticated way in.
One OpenAPI gateway with Keycloak identity and TLS fronts the whole system.
tools
Tools are shared Python references only agents in the same process can use.
Hosted MCP server — agents inside and outside the system call tools over a protocol.
transcript
Message history lives in memory and is gone when the process exits.
Managed Postgres keeps the transcript and results durable across restarts.
proof
A verbose console log of the conversation — mutable and unverifiable.
Per-agent Ed25519-signed receipts plus an ordered signed session history.
questions
Frequently asked.
How do I deploy an AutoGen multi-agent system to production?
Point a2a cloud at your AutoGen project and run one deploy. It hosts the system as a Knative or Kubernetes container service, fronts it with an authenticated OpenAPI gateway and TLS, exposes shared tools through MCP, and provisions managed Postgres for the transcript. Authenticated Agent API calls and public `/invoke` or standard MCP `tools/call` executions receive signed receipts; explicit `ctx.sandbox` code uses a separate microsandbox.
How are A2A handoffs governed between agents?
An AutoGen handoff can become an Agent2Agent call carrying caller identity and a scoped grant. That formal A2A exchange remains protocol history. If the worker then executes through Agent API, public `/invoke`, or standard MCP `tools/call`, the gateway or control plane signs a separate execution receipt.
Is a2a specific to AutoGen?
No. a2a is framework-agnostic and hosts the process your AutoGen system runs in, the same way it hosts LangGraph, CrewAI, the OpenAI Agents SDK, or a custom loop. You keep AutoGen; a2a adds scoped handoffs, MCP, a gateway, a database, and signed evidence on the API, MCP, and /invoke paths.
Where does the conversation state live?
In a managed Postgres provisioned in the same deploy. Message history, group-chat transcript, and results are durable across restarts and scale-to-zero, so a long-running multi-agent conversation doesn't evaporate when the process cycles.
Can I audit what each agent in the system did?
Yes. Runs on the API, MCP, and /invoke entry points receive receipts with caller identity/classification, skill, input, verified grants, outcome, and timing. Ordered history can supply a timeline. Formal A2A routes are protocol state; only Agent API paid calls have linked economics.
keep reading
Related guides.
All guides live in the guides index.
no ambient trust
Scope handoffs. Sign those runs.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — with managed Postgres, MCP and API surfaces, and a frontend. The control plane signs authenticated Agent API calls; trusted ingress signs public /invoke and standard MCP tools/call executions. Connector MCP and formal A2A task routes are outside that coverage.