invocation
kickoff() + diy
You run crew.kickoff() from a script, notebook, or cron. There's no real endpoint.
a2a cloud
Authenticated OpenAPI gateway — other services call the crew like any API.
crewai, in production
Deploy a CrewAI crew to production.
CrewAI gives you a crew that runs when you call kickoff(). Production wants something else: an endpoint other services can call, tools other agents can reach, somewhere durable to keep results, and verifiable execution evidence. a2a cloud wraps your crew in MCP, authenticated HTTP, managed Postgres, and signed control-plane execution paths — without rebuilding it.
your crew · mcp + gateway · signed proof · scale-to-zero
0%
crew rewrite required
0
signed entry points
idle cost
the problem
A crew that runs isn't a service yet.
A CrewAI project gets you agents, tasks, and a kickoff() that orchestrates them. That's a program, not a production service. There's no authenticated endpoint for other systems to call, no way for other agents to reach the crew's tools, no durable place for results, and no verifiable record of what each agent did on a given run — just verbose console output you have to trust.
Invocation is a script call — no real API, identity, or access control.
Crew tools are Python objects nothing outside the process can invoke.
Results and memory live in RAM or a file until you wire up a database yourself.
Proof of a multi-agent run is console logs — mutable, unsigned, and unverifiable.
the a2a way
One deploy turns the crew into a real service.
a2a is framework-agnostic: it deploys the whole agent app around your CrewAI code — MCP, gateway, database, frontend, receipts — so a crew becomes a callable, auditable production capability without leaving CrewAI.
Your crew, as writtenMCP server for crew toolsOpenAPI gatewayManaged PostgresSigned execution evidenceScale-to-zero isolation
Your crew, as written
Keep your agents, tasks, tools, and Process (sequential or hierarchical). a2a hosts the process your crew runs in — it doesn't ask you to rebuild the crew in a different framework.
MCP server for crew tools
Your crew's tools become a hosted MCP server, so other agents and MCP clients invoke them over a real protocol. Your crew can be a callable capability, not just a script you run.
OpenAPI gateway
The crew gets an authenticated HTTP endpoint through an OpenAPI gateway — a real API other services can call — instead of a kickoff() you trigger from a cron job.
Managed Postgres
Crews that remember runs, queue work, or store outputs get a managed Postgres provisioned in the same deploy — no database to stand up or secure yourself.
Signed execution evidence
Crew executions through Agent API, public /invoke, or standard MCP tools/call receive signed receipts for observed inputs and outcomes. Only authenticated Agent API paid calls have separate economics; direct gateway receipts record zero platform economics.
Scale-to-zero isolation
The crew runs as a scale-to-zero Knative container service. Code explicitly sent through ctx.sandbox executes in a separate microsandbox microVM.
side-by-side
Raw CrewAI deploy vs. a2a.
tool exposure
kickoff() + diy
Crew tools are Python objects; nothing outside your process can reach them.
a2a cloud
Hosted MCP server — other agents and MCP clients invoke the crew's tools.
state
kickoff() + diy
Outputs land in memory or a file; a database is on your to-do list.
a2a cloud
Managed Postgres provisioned in the same deploy for memory, queues, and results.
proof
kickoff() + diy
You have console output and maybe a verbose log of what each agent said.
a2a cloud
Signed execution evidence per kickoff, with economics in a separate receipt-linked ledger row.
cost & isolation
kickoff() + diy
A warm container runs the crew and bills whether or not a kickoff happens.
a2a cloud
Scale-to-zero Knative service, with separate microsandbox code execution when requested.
dimension
kickoff() + diy
a2a cloud
invocation
You run crew.kickoff() from a script, notebook, or cron. There's no real endpoint.
Authenticated OpenAPI gateway — other services call the crew like any API.
tool exposure
Crew tools are Python objects; nothing outside your process can reach them.
Hosted MCP server — other agents and MCP clients invoke the crew's tools.
state
Outputs land in memory or a file; a database is on your to-do list.
Managed Postgres provisioned in the same deploy for memory, queues, and results.
proof
You have console output and maybe a verbose log of what each agent said.
Signed execution evidence per kickoff, with economics in a separate receipt-linked ledger row.
cost & isolation
A warm container runs the crew and bills whether or not a kickoff happens.
Scale-to-zero Knative service, with separate microsandbox code execution when requested.
questions
Frequently asked.
How do I deploy a CrewAI crew to production?
Point a2a cloud at your CrewAI project and run one deploy. It hosts the crew in a Knative container service, exposes tools over MCP, and provisions managed Postgres. Agent API, public /invoke, and standard MCP tools/call executions are signed by trusted control-plane paths.
Is a2a tied to CrewAI, or framework-agnostic?
Framework-agnostic. a2a hosts the process your crew runs in, the same way it hosts LangGraph, AutoGen, the OpenAI Agents SDK, or a custom loop. You keep CrewAI; a2a adds the production layer — MCP, gateway, database, and signed proof — around it.
How do other services call my CrewAI crew?
Through the authenticated OpenAPI gateway a2a puts in front of the crew, and through the hosted MCP server that exposes the crew's tools. Instead of running crew.kickoff() from a script, other services and agents invoke the crew over a real, authenticated protocol.
Can I prove what a multi-agent crew did?
Yes. Kickoffs through Agent API or public /invoke, and standard MCP tools/call executions, receive receipts for observed execution fields. Only authenticated Agent API paid calls have control-plane billing economics; direct gateway receipts record zero.
Does my crew stay isolated in production?
The hosted crew runs in a Knative container service and scales to zero when idle. A separate microsandbox microVM is used only when crew code explicitly invokes ctx.sandbox for code execution.
keep reading
Related guides.
All guides live in the guides index.
don't trust the crew
Trust the receipt.
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.