Decision comparison
Google Agent Development Kit vs LangGraph vs OpenAI Agents SDK
All three are free and permissively licensed, so price will not decide this — which is unusual and makes the decision cleaner than it looks. Two questions settle it instead. The first is platform: the OpenAI Agents SDK and Google ADK are each built around their own vendor's models and deployment, and LangGraph is the option that belongs to neither, so if embedding a platform decision in your agent code is unacceptable, the field narrows to one immediately. The second is the shape of the work: handoffs express delegation, a graph expresses a process. A team routing a request to a specialist wants the first and finds a graph to be machinery; a team running a long approval workflow with checkpoints wants the second and finds handoffs too thin. Language choice is the tiebreaker only for Go, Java and Kotlin shops, where ADK is effectively alone.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 3 are agent frameworks.
Quick Comparison
| Decision factor | Google Agent Development Kit | LangGraph | OpenAI Agents SDK |
|---|---|---|---|
| Best for | Enterprise teams whose agent has to live inside an existing service rather than in a Python notebook. The five-language surface is the clearest statement of who this is for: if the agent must be a Java service because the surrounding system is Java, this is one of very few frameworks that does not force a Python sidecar. | Workflows that are genuinely a state machine — cycles, conditional edges, and state that has to survive a restart. If you find yourself describing the process as a diagram before you describe it as code, this is the framework that lets you write the diagram down. | Teams already standardised on OpenAI who want multi-agent structure without adopting a framework with its own worldview. It is the production successor to Swarm, and the whole design argument is a small primitive set a team can learn in an afternoon and still use in production. |
| How it expresses orchestration | Graph workflows, introduced in ADK 2.0, which weave deterministic code with model reasoning in one structure — explicit execution paths where the process is known, model reasoning where it is not. Hierarchical multi-agent composition sits alongside, so a coordinator contains specialists and the structure is a tree you can read rather than handoff rules you have to trace. | An explicit graph with persisted state. Nodes do work, edges decide what happens next, and the state between steps is durable rather than held in a request. That is a different primitive from delegation: handoffs say who does the next thing, a graph says what the process is. | Four primitives and no graph: agents with instructions and tools, handoffs that delegate to a specialist, guardrails that validate input and output in parallel with execution and fail fast, and sessions that hold working context across turns of one run. You orchestrate with ordinary language constructs and the SDK supplies the loop. |
| Languages | Python, TypeScript, Go, Java and Kotlin, each with a first-party implementation. They do not always move in step, so check that a specific feature has landed in the language you need. | Python and JavaScript, from one team. It is built on LangChain, so its integration ecosystem is inherited rather than rebuilt. | Python and TypeScript, maintained by the same team, so a split frontend and backend team shares a mental model. |
| Provider commitment | Portable in principle, Google-weighted in practice. Most documentation examples use Gemini and the smooth deployment path runs onto Vertex AI Agent Engine, a managed Google Cloud service with its own usage-based charges. Pointing an agent at another provider is a model string change; translating the examples as you read is the friction. | Vendor-neutral. It is the option on this page that belongs to neither large model vendor, which is the reason a team picks it when it does not want a platform decision embedded in its agent code. | Designed around OpenAI's platform. Other providers are reachable but are not the happy path, and the defaults keep pulling back. That is the trade to understand before adopting it, and it is usually the reason teams choose one of the other two. |
| Tracing and evaluation | A first-party evaluation harness ships with the framework, which matters because what usually stops an agent reaching production is the absence of a pass/fail gate rather than the absence of a feature. | Not first-party in the framework. LangSmith is the vendor's own destination, and OpenTelemetry-based tools such as Langfuse and Arize Phoenix integrate — so you choose the tracing backend rather than inheriting it. | Built in rather than bolted on, and it feeds OpenAI's own evaluation and fine-tuning tooling. Convenient on day one, and the tightest coupling in the product: the default destination is OpenAI's platform. |
| When it is the wrong choice | A small Python team shipping one agent. Hierarchical composition, graph workflows and the deployment tooling are all answers to enterprise problems, and they cost learning time even when unused. | When the hard part is getting one correctly shaped object back from a model rather than orchestrating a process. A graph is machinery, and a single typed call does not need it. | When provider independence is a requirement, and when the workflow is a long-running process with checkpoints — handoffs express delegation, not a durable state machine. |
Google Agent Development Kit
- Best for:
- Enterprise teams whose agent has to live inside an existing service rather than in a Python notebook. The five-language surface is the clearest statement of who this is for: if the agent must be a Java service because the surrounding system is Java, this is one of very few frameworks that does not force a Python sidecar.
- How it expresses orchestration:
- Graph workflows, introduced in ADK 2.0, which weave deterministic code with model reasoning in one structure — explicit execution paths where the process is known, model reasoning where it is not. Hierarchical multi-agent composition sits alongside, so a coordinator contains specialists and the structure is a tree you can read rather than handoff rules you have to trace.
- Languages:
- Python, TypeScript, Go, Java and Kotlin, each with a first-party implementation. They do not always move in step, so check that a specific feature has landed in the language you need.
- Provider commitment:
- Portable in principle, Google-weighted in practice. Most documentation examples use Gemini and the smooth deployment path runs onto Vertex AI Agent Engine, a managed Google Cloud service with its own usage-based charges. Pointing an agent at another provider is a model string change; translating the examples as you read is the friction.
- Tracing and evaluation:
- A first-party evaluation harness ships with the framework, which matters because what usually stops an agent reaching production is the absence of a pass/fail gate rather than the absence of a feature.
- When it is the wrong choice:
- A small Python team shipping one agent. Hierarchical composition, graph workflows and the deployment tooling are all answers to enterprise problems, and they cost learning time even when unused.
LangGraph
- Best for:
- Workflows that are genuinely a state machine — cycles, conditional edges, and state that has to survive a restart. If you find yourself describing the process as a diagram before you describe it as code, this is the framework that lets you write the diagram down.
- How it expresses orchestration:
- An explicit graph with persisted state. Nodes do work, edges decide what happens next, and the state between steps is durable rather than held in a request. That is a different primitive from delegation: handoffs say who does the next thing, a graph says what the process is.
- Languages:
- Python and JavaScript, from one team. It is built on LangChain, so its integration ecosystem is inherited rather than rebuilt.
- Provider commitment:
- Vendor-neutral. It is the option on this page that belongs to neither large model vendor, which is the reason a team picks it when it does not want a platform decision embedded in its agent code.
- Tracing and evaluation:
- Not first-party in the framework. LangSmith is the vendor's own destination, and OpenTelemetry-based tools such as Langfuse and Arize Phoenix integrate — so you choose the tracing backend rather than inheriting it.
- When it is the wrong choice:
- When the hard part is getting one correctly shaped object back from a model rather than orchestrating a process. A graph is machinery, and a single typed call does not need it.
OpenAI Agents SDK
- Best for:
- Teams already standardised on OpenAI who want multi-agent structure without adopting a framework with its own worldview. It is the production successor to Swarm, and the whole design argument is a small primitive set a team can learn in an afternoon and still use in production.
- How it expresses orchestration:
- Four primitives and no graph: agents with instructions and tools, handoffs that delegate to a specialist, guardrails that validate input and output in parallel with execution and fail fast, and sessions that hold working context across turns of one run. You orchestrate with ordinary language constructs and the SDK supplies the loop.
- Languages:
- Python and TypeScript, maintained by the same team, so a split frontend and backend team shares a mental model.
- Provider commitment:
- Designed around OpenAI's platform. Other providers are reachable but are not the happy path, and the defaults keep pulling back. That is the trade to understand before adopting it, and it is usually the reason teams choose one of the other two.
- Tracing and evaluation:
- Built in rather than bolted on, and it feeds OpenAI's own evaluation and fine-tuning tooling. Convenient on day one, and the tightest coupling in the product: the default destination is OpenAI's platform.
- When it is the wrong choice:
- When provider independence is a requirement, and when the workflow is a long-running process with checkpoints — handoffs express delegation, not a durable state machine.
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | Google Agent Development Kit | LangGraph | OpenAI Agents SDK |
|---|---|---|---|
| GitHub commits, 90d(Product adoption) | 1.3k | 122 | 703 |
| GitHub stars(Product adoption) | 21,000+ | 42,000+ | 29,000+ |
| Search interest(Market interest) | Not available | 9 | Not available |
| Hacker News mentions, 90d(Community interest) | Not available | 20 | Not available |
| Product Hunt comments(Community interest) | 5 | Not available | 4 |
| Product Hunt rating(Community interest) | 5.0/5 | Not available | 5.0/5 |
| Product Hunt reviews(Community interest) | 2 | Not available | 848 |
| Product Hunt votes(Community interest) | 140 | Not available | 121 |
| PyPI weekly downloads(Product adoption) | 2.4M | 9.9M | 3.0M |
| npm weekly downloads(Developer adoption) | Not available | 2.4M | 1.3M |
| Stack Overflow questions(Community interest) | Not available | 143 | Not available |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
Google Agent Development Kit
September 21, 2026Package vulnerabilities
PyPI · google-adk@2.9.2
0 vulnerabilities
across 1 package
Repository security score
Not available
LangGraph
September 21, 2026Package vulnerabilities
npm · @langchain/langgraph@1.4.16 · PyPI · langgraph@1.2.11
0 vulnerabilities
across 2 packages
Repository security score
Not available
OpenAI Agents SDK
Package vulnerabilities
npm · @openai/agents@0.18.0 · PyPI · openai-agents@0.22.3
0 vulnerabilities
across 2 packages
Repository security score
Not available
Interface Preview
LangGraph
Feature Comparison
| Feature | Google Agent Development Kit | LangGraph | OpenAI Agents SDK |
|---|---|---|---|
| Orchestration model | |||
| Primary abstraction | Graph workflows plus hierarchical agent composition | An explicit graph with nodes, conditional edges and persisted state | Agents, handoffs, guardrails and sessions — four primitives, no graph |
| Cycles and conditional branching | Graph workflows give explicit execution paths, new in ADK 2.0 | The core of the design: cycles and conditional edges are what it is for | Expressed in ordinary Python control flow around the agent loop |
| State that survives a restart | Agent state is managed by the framework and its deployment target | Persisted state between steps is a first-class feature | Sessions hold working context within one agent run |
| Multi-agent delegation | Hierarchical composition: agents contain agents, forming a readable tree | Modelled as nodes and edges in the same graph | Handoffs, also usable as agents-as-tools |
| Input and output validation | Part of the graph and evaluation tooling | Left to the application, commonly with Pydantic | Guardrails run in parallel with execution and fail fast |
| Reach | |||
| Language implementations | Python, TypeScript, Go, Java and Kotlin | Python and JavaScript | Python and TypeScript |
| Model providers on the happy path | Gemini in most examples; other providers are a model string change | Vendor-neutral, inheriting LangChain's provider coverage | OpenAI; other providers work against the grain |
| Managed deployment target | Vertex AI Agent Engine, a managed Google Cloud service with its own usage charges | The vendor offers a hosted platform; the framework runs wherever you run it | Runs wherever you run it; the platform relationship is the model API |
| Voice and realtime | Not a documented first-party feature of the framework | Assembled from the surrounding ecosystem | First-party realtime agents on gpt-realtime-2.1, plus a speech-to-text and text-to-speech pipeline |
| Sandboxed execution | Not a documented first-party feature of the framework | Assembled from the surrounding ecosystem | Sandbox agents with manifest-defined files and resumable sessions |
| Operating it | |||
| Built-in evaluation | A first-party evaluation harness ships with the framework | Provided by LangSmith or another evaluation tool you choose | Tracing feeds OpenAI's own evaluation and fine-tuning tooling |
| Tracing destination | Open, with Google Cloud as the integrated path | Your choice: LangSmith, Langfuse, Arize Phoenix or any OTel backend | OpenAI's platform by default |
| Scaffolding and tooling | An Agents CLI that scaffolds, builds, tests, evaluates and deploys | Graph authoring in code, with a visual studio from the vendor | Function tools generated from Python callables, plus MCP server tool calling |
| Licence | Apache 2.0 across the whole framework | Open source, with the vendor's paid platform sold alongside | MIT with no paid tier |
| Cost of the framework | Free; you pay for models and, if used, Vertex AI Agent Engine | Free; you pay for models and, if used, the vendor's hosted platform | Free; you pay OpenAI for the model calls the agent makes |
Orchestration model
Primary abstraction
Cycles and conditional branching
State that survives a restart
Multi-agent delegation
Input and output validation
Reach
Language implementations
Model providers on the happy path
Managed deployment target
Voice and realtime
Sandboxed execution
Operating it
Built-in evaluation
Tracing destination
Scaffolding and tooling
Licence
Cost of the framework
Which to choose
All three are free and permissively licensed, so price will not decide this — which is unusual and makes the decision cleaner than it looks. Two questions settle it instead. The first is platform: the OpenAI Agents SDK and Google ADK are each built around their own vendor's models and deployment, and LangGraph is the option that belongs to neither, so if embedding a platform decision in your agent code is unacceptable, the field narrows to one immediately. The second is the shape of the work: handoffs express delegation, a graph expresses a process. A team routing a request to a specialist wants the first and finds a graph to be machinery; a team running a long approval workflow with checkpoints wants the second and finds handoffs too thin. Language choice is the tiebreaker only for Go, Java and Kotlin shops, where ADK is effectively alone.
Best-fit scenarios
Choose OpenAI Agents SDK if:
Choose the OpenAI Agents SDK when you are on OpenAI and want structure without adopting a worldview. Four primitives — agents, handoffs, guardrails, sessions — are learnable in an afternoon and still hold up in production, which is a real and underrated property. Two features are genuinely hard to assemble elsewhere: sandbox agents give code-writing agents an isolated workspace with manifest-defined files and resumable sessions, and realtime voice on gpt-realtime-2.1 with interruption detection is first-party rather than a pipeline you build. Tracing needs no configuration. Accept that the defaults assume OpenAI's platform and that the built-in tracing goes there by default, so an existing observability estate is an integration rather than a given. Accept too that the Python package was at v0.22.3 in mid-September 2026, and a sub-1.0 version is a real signal about API stability.
Choose LangGraph if:
Choose LangGraph when the process is the hard part and you do not want a model vendor's decisions embedded in your agent code. Cycles, conditional edges and state that survives a restart are the primitives, and they are the right ones when you are modelling an approval flow, a research loop or anything where a step can send you back to an earlier one. Being vendor-neutral is the other half of the argument: it is the only option on this page that does not pull toward a platform, and its integration ecosystem is inherited from LangChain rather than rebuilt. Accept that you choose your own tracing backend rather than inheriting one — LangSmith, Langfuse or Arize Phoenix over OpenTelemetry — and that a graph is machinery a single typed model call does not need. If your problem is getting one correctly shaped object back, this is heavier than it has to be.
Choose Google Agent Development Kit if:
Choose Google ADK when the agent has to fit an enterprise system that is not Python, or when the workflow is only partly deterministic. Five first-party implementations — Python, TypeScript, Go, Java and Kotlin — make it effectively the only choice for a JVM, Go or Kotlin service, and that is a decision made by the surrounding codebase rather than by preference. Graph workflows let you weave explicit execution paths with model reasoning, which is the right shape when an approval, a policy check or a write to a system of record must happen in a fixed order. The first-party evaluation harness answers 'does this agent work' before deployment rather than after. Accept that the centre of gravity is Google Cloud: the framework is portable, but the deployment story that makes it attractive runs onto Vertex AI Agent Engine, a paid service. Accept too that 2.x is recent, so older tutorials describe a different framework, and that the five implementations do not always move together.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
Do any of these cost money?
Not the frameworks. ADK is Apache 2.0, the OpenAI Agents SDK is MIT, and LangGraph is open source, none with a paid tier holding features back. You pay for the model calls in every case. The paid layers sit beside them: Vertex AI Agent Engine for ADK's managed deployment, the vendor's hosted platform for LangGraph, and OpenAI's API for the Agents SDK — which is the model bill rather than a framework charge.
Which one should a team that has not picked a model vendor use?
LangGraph, on the grounds that it is the only one here that does not pull toward a platform. Both vendor SDKs can call other providers, but their defaults, examples and integrated tooling assume their own, and that friction compounds. If you also want validated typed output rather than graph orchestration, PydanticAI is worth comparing before you settle.
Is a graph better than handoffs?
They answer different questions, and neither is a superset. Handoffs say who handles the next step, which is what you want for routing to a specialist. A graph says what the process is, including the cycles and conditional branches, which is what you want when a step can send you back to an earlier one and the state has to survive a restart. Picking the wrong one shows up as either unnecessary machinery or as control flow smeared across prompt instructions.
What if my codebase is Java, Go or Kotlin?
ADK is effectively the only option on this page. LangGraph ships Python and JavaScript; the OpenAI Agents SDK ships Python and TypeScript. Check that the specific feature you need has landed in your language, because ADK's five implementations do not always move in step.
Where does tracing fit with each of these?
The Agents SDK has it built in and pointed at OpenAI's platform, which is convenient on day one and the tightest coupling in the product. ADK integrates with Google Cloud on its smooth path but does not force it. LangGraph leaves the choice open. For any of them, an OpenTelemetry-based tool such as Langfuse or Arize Phoenix keeps the spans portable, which matters if you may change framework later.