Cloudflare Agents Alternative for Python Agents: Postgres, MCP, and Signed Receipts Included

Cloudflare's Agents SDK is a genuinely good piece of engineering. Each agent is a Durable Object: a stateful, addressable instance with its own embedded SQLite, scheduling, WebSockets, and first-class support for serving an MCP server. If you write TypeScript and your agent fits the Workers runtime, it's a strong default.

A lot of the teams we talk to don't fit that shape. They built on LangGraph, CrewAI, or the OpenAI Agents SDK — in Python — and they need three things on the way to production: a real database the agent owns, tools exposed over MCP, and a way to *prove* what the agent did. This post is an honest comparison for that team, including when Cloudflare is the better pick.

The short version

| | Cloudflare Agents SDK | a2a cloud | |---|---|---| | Primary language | TypeScript on Workers (V8 isolates) | Python agents (LangGraph, CrewAI, OpenAI Agents SDK, custom) in a full Linux container | | Agent state | Per-instance embedded SQLite in a Durable Object | Managed Postgres per agent, injected as DATABASE_URL | | MCP | You build an MCP server with the SDK's MCP classes | Every @skill is exposed as an MCP tool automatically on deploy | | API surface | You write the Worker routes | HTTP/OpenAPI surface generated from your skills | | Proof of actions | Logs and observability | Ed25519-signed receipt for every run | | Best at | Edge-latency, per-user stateful TS agents at massive fan-out | Getting an existing Python agent to production with data, tools, and audit evidence |

Where the difference actually bites

1. Your framework is Python

The Python agent ecosystem — LangGraph, CrewAI, the OpenAI Agents SDK, plus the long tail of libraries they pull in — assumes a normal Python process: native wheels, arbitrary packages, long-running async work, subprocesses. The Workers runtime is an isolate, not a Linux box. That's exactly why it's fast and cheap to start, and it's also why "just run my LangGraph graph there" usually turns into a port.

On a2a cloud, your graph doesn't change. You wrap it in a skill and deploy:

from a2a_pack.agent import A2AAgent, skill
from a2a_pack.context import RunContext, NoAuth

class Researcher(A2AAgent[dict, NoAuth]):
    name = "researcher"
    description = "A LangGraph research agent"

    @skill(description="Answer a research question")
    async def ask(self, ctx: RunContext[NoAuth], question: str) -> dict:
        return await graph.ainvoke({"question": question})

Walkthrough: Deploy a LangGraph agent in 60 seconds (also for CrewAI and the OpenAI Agents SDK).

2. SQLite-per-instance vs Postgres-per-agent

Cloudflare's model gives *each agent instance* its own SQLite. That's elegant for per-user or per-session agents: state lives next to compute, no connection strings.

It's a different fit when the agent's data is shared — one support agent answering for a whole company, a growth agent keeping a pipeline of leads, a RAG agent over a document corpus. There you usually want one relational database with joins, migrations, pgvector, and the Postgres tooling your team already knows (LangGraph's PostgresSaver, SQLAlchemy, psql).

On a2a cloud you declare it and it's provisioned with the agent, scoped to that agent's role:

resources:
  databases:
    - name: app
      engine: postgres
      access_mode: read_write
      env:
        url: DATABASE_URL

More: Give your AI agent a Postgres database and Add memory and RAG with pgvector.

3. MCP you write vs MCP you get

Cloudflare's SDK makes it straightforward to *build* an MCP server — you define the tools and host them on Workers. That's real value, and it's still a server you author and keep in sync with your code.

On a2a cloud there is no separate server to author. The signature and docstring of each @skill *are* the tool definition, regenerated on every deploy, so the schema can't drift from the implementation. Details: Wire an MCP server to your agent (zero config).

4. Logs vs proof

This is the one that doesn't show up in a feature matrix until a customer or auditor asks, "prove the agent did exactly this."

Observability tells you what happened so you can debug it. It doesn't give a third party anything they can verify — an exported log is just text. a2a cloud emits an Ed25519-signed receipt for every agent run: what ran, which agent ran it, inputs and outputs bound together and signed, so anyone can check it wasn't altered after the fact. Why that matters: Signed receipts vs trace logs, and for regulated buyers, SOC 2 evidence for AI agents.

When to choose Cloudflare instead

Be honest with yourself about the workload:

• You're writing the agent in TypeScript from scratch and happy to stay there.
• You need one stateful instance per user/session/room, at very high fan-out, close to the user.
• Your state is naturally small and private to each instance, so embedded SQLite is a feature, not a limit.
• You're already deep in Workers, KV, R2, and Workers AI.

That's a great fit for Cloudflare, and we'd tell you so.

When a2a cloud fits better

• You already have a Python agent on LangGraph, CrewAI, or the OpenAI Agents SDK and don't want to port it.
• The agent needs a shared relational database (plus pgvector) rather than per-instance storage.
• You want MCP tools and an API generated from your code, not a second server to maintain.
• Someone — a customer, your security lead, an auditor — will ask for evidence of what the agent did, not a dashboard.

Try it

Take the agent you already have, wrap it in a skill, and deploy it. You get a live URL, a Postgres database, MCP tools, an OpenAPI surface, and a signed receipt for the first run. Start at a2acloud.io.