Deploy an OpenAI Agents SDK Agent in 60 Seconds (With Postgres, MCP, and Signed Receipts)

Deploy an OpenAI Agents SDK Agent in 60 Seconds (With Postgres, MCP, and Signed Receipts)

The OpenAI Agents SDK makes the agent part easy. You define an Agent with instructions, hand it a few function_tools, and Runner.run() executes the loop on your laptop in minutes. Then production asks the questions the SDK doesn't answer for you:

• Where does state and memory persist between runs?
• How do the agents reach tools that other systems — or other agents — can also use?
• How does anything else call the agent — an API, a frontend, another agent?
• When it does something costly or irreversible, where's the proof of what ran?

On most stacks each of those is a separate ticket. On a2a cloud they're provisioned *with* the agent the first time you deploy it. This post walks the whole path: an Agents SDK agent → live URL with a managed Postgres database, an MCP server, an HTTP/OpenAPI surface, and an Ed25519-signed receipt for every run.

The agent you already have

Nothing about your Agents SDK code changes. A minimal agent with a tool:

from agents import Agent, Runner, function_tool

@function_tool
def word_count(text: str) -> int:
    """Count the words in a passage."""
    return len(text.split())

researcher = Agent(
    name="Researcher",
    instructions="Answer the question with a concise, sourced summary. Use tools when they help.",
    tools=[word_count],
)

async def answer(question: str) -> str:
    result = await Runner.run(researcher, question)
    return result.final_output

That's the artifact. The job now is to give it somewhere to live, something to remember, tools others can reach, and a way to be invoked.

Wrap it in an a2a skill

a2a runs your agent as a class with one or more @skill methods. Drop the SDK agent inside one:

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

class Researcher(A2AAgent[dict, NoAuth]):
    name = "researcher"
    description = "An OpenAI Agents SDK research agent"

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

The ctx is your window into the platform — ctx.llm for model access (routed through LiteLLM, so the SDK's model calls work without you shipping keys), ctx.sandbox for code execution, ctx.workspace for grant-scoped storage. Your agent loop keeps running exactly as written.

The 60-second part

Three commands:

a2a init researcher
cd researcher   # paste your agent + skill into agent.py
a2a deploy

a2a deploy tarballs the source, commits it to a managed repo, builds the image, syncs the deployment, and polls until the agent is actually serving before it hands you a public URL. You get the URL when the agent works — not when the upload finished.

What gets provisioned with it

This is the part other stacks make you assemble yourself.

A managed Postgres database

Every agent gets its own Postgres instance, isolated to that agent. It's where session state, conversation history, and anything your tools write actually lives — durable between runs and across scale events. You don't create it, connect a Neon project, or paste a connection string into a secret; it's there on first deploy, scoped so the agent reaches its data and nothing reaches across to another agent's. (More on why per-agent isolation matters: [How to Give AI Agents Database Access Without Handing Over Production](/blog/give-ai-agents-database-access-without-handing-over-production).)

An MCP server

The agent's skills are exposed as MCP tools automatically. That means other agents — or any MCP client — can call your agent as a tool with zero extra config. The Agents SDK is great at *consuming* tools; a2a also makes your agent *itself* a tool everyone else can reach, without a tool-server to write, host, or keep in sync with your code.

An API and frontend

The deploy emits a FastAPI server speaking the full A2A protocol, an OpenAPI surface, an agent card at /.well-known/agent-card, and SSE streaming for progress and human-in-the-loop. Your agent is callable over HTTP the moment it's live.

A signed receipt for every run

This is the one you can't get by gluing services together. Every run emits an Ed25519-signed receipt — a tamper-evident record of what the agent did, when, and with what inputs and outputs. Not a trace log you have to trust; a cryptographic artifact anyone can verify. When a reviewer, an auditor, or a customer asks "prove this agent only did what it was supposed to," you have the receipt instead of a screenshot of your logs. (Why that beats trace logs: [Signed Receipts vs Trace Logs](/blog/signed-receipts-vs-trace-logs-agent-audit-trail).)

Why this is the right default

The usual Agents-SDK-to-production story is: agent in an afternoon, then two weeks wiring a database, a tool-serving layer, an API gateway, auth, and observability before anyone external can touch it. The infra work dwarfs the agent work.

Provisioning the database, MCP server, API, and receipts *with* the agent collapses that. You spend your time on the agent — the part that's actually your product — and the path to a callable, persistent, provable agent is the same three commands whether it's a hello-world or a production multi-agent handoff.

The same path works from a LangGraph graph or a CrewAI crew — see [Deploy a LangGraph Agent in 60 Seconds](/blog/deploy-langgraph-agent-60-seconds) and [Deploy a CrewAI Agent in 60 Seconds](/blog/deploy-crewai-agent-60-seconds). This post just starts from an OpenAI Agents SDK agent.

Try it

Bring an agent you already have:

a2a init my-agents-sdk-agent
cd my-agents-sdk-agent
a2a deploy

Agent in, live URL out — with the database, tools, API, and signed proof already attached.