Google ADK vs OpenAI Agents SDK

Google’s Agent Development Kit (ADK) and the OpenAI Agents SDK both run the agent loop for you: call the model, run the tools it asks for, feed the results back. The differences are in everything around that loop. ADK is the larger framework: five languages, workflow agents and graphs for the parts you want fixed, session and long-term memory services, an evaluation command, and a one-line deploy to Google Cloud. The Agents SDK is the smaller one: Python and TypeScript, a handful of primitives, handoffs between agents, and tracing that is on from the first run. Pick ADK if you want a framework that also decides how the agent is tested and hosted, or if you ship in Go, Java or Kotlin. Pick the Agents SDK if you want a thin layer you can read in an afternoon and host yourself.

This page compares the two directly. For the wider field, including LangGraph, CrewAI and the Claude Agent SDK, see AI agent frameworks compared; for the Agents SDK in depth, with guardrails and approvals, see the OpenAI Agents SDK in practice.

The two at a glance

• Languages. ADK: Python, TypeScript, Go, Java and Kotlin. Agents SDK: Python, with a separate TypeScript package.
• Install. ADK: pip install google-adk. Agents SDK: pip install openai-agents. Both need Python 3.10 or later.
• Models. ADK: Gemini natively, plus Gemma, Claude, OpenAI models and local models through Ollama, vLLM or LiteLLM. Agents SDK: OpenAI models by default, other providers through its model provider interface.
• Shape. ADK: model-driven agents, workflow agents (sequential, parallel, loop) and graph workflows. Agents SDK: agents, handoffs, agents as tools and guardrails.
• Several agents. ADK: sub-agents under a coordinator, or an agent wrapped as a tool. Agents SDK: handoffs, or an agent wrapped as a tool.
• State. ADK: session services for one conversation and memory services for knowledge across conversations. Agents SDK: sessions that keep conversation history.
• MCP. Both connect to servers over stdio and Streamable HTTP. ADK can also expose an agent as an MCP server; the Agents SDK can let OpenAI call a public server for you.
• Tracing. ADK: OpenTelemetry, exported wherever OTLP goes. Agents SDK: on by default, sent to OpenAI’s Traces dashboard, with processors for other backends.
• Evaluation. ADK: test files, evalsets and an adk eval command. Agents SDK: trace grading and evals on the OpenAI platform.
• Hosting. ADK: adk deploy to Google Cloud’s Agent Runtime, Cloud Run or GKE, or your own container. Agents SDK: inside your own application.

Languages and models

The ADK documentation↗ (opens in a new tab) lists install commands for Python, TypeScript, Go, Java and Kotlin, and names Gemini, Gemma, Claude, OpenAI, Ollama, vLLM and LiteLLM as model options. If your backend is in Java or Go, that alone may settle it, because the Agents SDK has no package for either.

The Agents SDK is Python-first, with a TypeScript twin that follows the same design. It works with other providers’ models, but its hosted tools, its conversation storage on OpenAI’s side and its default trace export all assume OpenAI. ADK has the mirror-image lean: Gemini and Google Cloud are where its extras, such as Memory Bank and one-command deploys, are most complete.

Several agents: sub-agents or handoffs

This is the biggest design difference. In the Agents SDK a handoff transfers control: the receiving agent takes over the conversation and answers the user, and the model sees the handoff as a tool named transfer_to_<agent>. If you want the calling agent to stay in charge, you use Agent.as_tool() instead and get the specialist’s result back like any function’s.

ADK builds a tree. You give a coordinator a list of sub_agents, and according to its guide to collaborative workflows↗ (opens in a new tab) ADK generates a delegation tool named after each one. Each sub-agent has a mode: chat talks to the user and hands back only when told to, task may ask clarifying questions and returns control automatically when it calls finish_task, and single_turn never talks to the user and returns straight away, which also lets several run in parallel. AgentTool wraps an agent as a plain tool, the same idea as as_tool().

ADK then adds what the Agents SDK leaves to your code: workflow agents that run sub-agents in a fixed order, side by side or in a loop, and, since ADK 2.0, graph workflows that mix agents with deterministic steps and branches. The docs note that task mode is disabled inside graph workflows for now. With the Agents SDK, a fixed sequence is ordinary Python: call Runner.run() twice and pass the first result into the second.

Sessions and memory

Both keep a conversation across runs. The Agents SDK calls this a session and ships many backends: SQLite for development, Redis, SQLAlchemy, MongoDB, Dapr, an encrypted wrapper, and a session stored in OpenAI’s Conversations API. A session is history; long-term memory across conversations is left to you.

ADK splits the idea in two. A session holds one conversation’s events and a scratchpad called state, stored in memory, in a database or on Google Cloud. The ADK memory guide↗ (opens in a new tab) describes a separate memory service for searchable knowledge across past conversations: an in-memory one with keyword matching for prototypes, and Vertex AI Memory Bank or a RAG corpus for production. If your agent should remember a customer from last month, ADK has a named place for that; with the Agents SDK you build it.

MCP

The Agents SDK’s MCP guide↗ (opens in a new tab) offers HostedMCPTool, where OpenAI’s Responses API calls a publicly reachable server for you, and MCPServerStreamableHttp or MCPServerStdio, where your process makes the calls. MCPServerSse still exists but is marked deprecated, because MCP itself deprecated the SSE transport.

ADK uses one class, McpToolset, with connection parameters for stdio, SSE or Streamable HTTP, and it can turn an ADK agent into an MCP server that Claude Code or an IDE can call. There is no hosted-tool option: the process running your agent always holds the connection and its credentials. The difference matters for private servers. A hosted MCP call only works for a server OpenAI can reach over the internet.

Tracing and evaluation

Agents SDK tracing is on by default and goes to the Traces dashboard on the OpenAI platform. You can add a processor to send copies elsewhere, or replace the processors so nothing goes to OpenAI; the docs note that tracing is unavailable to organisations under a Zero Data Retention policy. For evaluation, OpenAI’s guide to evaluating agent workflows↗ (opens in a new tab) starts with grading traces and then moves to datasets and eval runs, all on its platform.

ADK emits OpenTelemetry spans following the GenAI semantic conventions, so traces go to Cloud Trace, to any OTLP backend such as Jaeger or Grafana Tempo, or to the trace view in adk web. Evaluation is part of the kit: .test.json files for single sessions, evalsets for longer multi-turn ones, run from adk web, the adk eval command or pytest, with built-in criteria such as tool trajectory and response match. That makes ADK the easier of the two to put under a CI check without adopting another vendor’s platform.

Where each one runs

The Agents SDK runs inside your application, wherever that is. OpenAI’s separate Agents API is the option where OpenAI runs the agent for you, and it is a different product, not a deploy target for SDK code.

ADK agents run anywhere Python, Node, Go or the JVM runs, and adk deploy has targets for Google Cloud’s managed runtime, Cloud Run, GKE and a local Docker container. Names have moved here. Google describes Gemini Enterprise Agent Platform as the evolution of Vertex AI, and its managed service for agents is now called Agent Runtime↗ (opens in a new tab); the ADK command is still adk deploy agent_engine, and the API resource keeps the old ReasoningEngine name for backwards compatibility.

The same agent in both

A support agent with one tool that looks up an order, and a second agent for refunds. First in ADK, as the agent.py that adk run and adk web expect:

from google.adk.agents import Agent


def get_order_status(order_id: str) -> dict:
    """Returns the status of an order."""
    return {"order_id": order_id, "status": "shipped"}


refunds = Agent(
    name="refunds",
    model="gemini-flash-latest",
    description="Handles refund requests.",
    instruction="Explain the refund policy and collect the order id.",
)

root_agent = Agent(
    name="support",
    model="gemini-flash-latest",
    description="Answers order questions.",
    instruction="Look up orders with the tool. Send refund requests to refunds.",
    tools=[get_order_status],
    sub_agents=[refunds],
)

from agents import Agent, Runner, function_tool


@function_tool
def get_order_status(order_id: str) -> str:
    """Returns the status of an order."""
    return f"Order {order_id} has shipped."


refunds = Agent(
    name="Refunds",
    handoff_description="Handles refund requests.",
    instructions="Explain the refund policy and collect the order id.",
)

support = Agent(
    name="Support",
    instructions="Look up orders with the tool. Hand refund requests to Refunds.",
    tools=[get_order_status],
    handoffs=[refunds],
)

if __name__ == "__main__":
    result = Runner.run_sync(support, "Where is order A1001?")
    print(result.final_output)

Both files were checked against google-adk 2.10.0 and openai-agents 0.22.3: they compile, import cleanly, and build their agents without calling a model. In ADK, refunds reports support as its parent agent; in the Agents SDK, the tool’s schema has one required field, order_id, taken from the type hint. Notice what is missing from the ADK file: no runner. The adk command line supplies one, which is convenient in development and one more thing to replace with Runner and a session service when you embed the agent in your own service.

How to choose

1. Language first. Go, Java or Kotlin means ADK. Python or TypeScript leaves both open.
2. Where it will run. Already on Google Cloud, or wanting a managed runtime with memory built in: ADK. A service you host yourself, on any cloud: either, but the Agents SDK asks less of you.
3. How much structure. If parts of the flow are fixed, ADK’s workflow agents and graphs say so in the framework. If the model should decide and your code stays thin, the Agents SDK’s handoffs are enough.
4. How you will test it. ADK brings evaluation with it. With the Agents SDK you use OpenAI’s trace grading and evals, or bring your own.
5. Private MCP servers. Both call them from your process. Only the Agents SDK offers OpenAI-hosted calls, and only for servers on the public internet.

Recording what the agents did

Traces and sessions last as long as someone keeps them, and they are read by engineers. The people who asked for the work want a different record: which tasks the agent took, what it changed and what it could not finish. fenbs is an MCP server at https://fenbs.ai/api/mcp, so an ADK agent reaches it through McpToolset and an Agents SDK agent through MCPServerStreamableHttp, with a token you issue under Settings with a name, the scopes it needs and an optional expiry. The agent reads its task, comments what it did, sets the test status and notes, and moves the task between To Do, Next Up, In Progress and Completed, and each change is recorded in the board’s history under the assistant’s name. Change framework next year and the record stays where it was.