Every second architecture call this year has included some version of the same question: should we build on Google’s ADK, the Claude Agent SDK, or LangChain, or should we just run Hermes?
The honest answer starts with a correction. This is not a four-way comparison of interchangeable products. Three of these are developer frameworks: libraries you build an agent with. The fourth, Hermes, is a finished autonomous agent you deploy and steer. They still end up on the same shortlist because they compete for the same line in the plan: make an agent do useful work for us. So here is the comparison as it actually plays out.
Google ADK: multi-agent engineering, Google style
Google’s Agent Development Kit arrived in April 2025 and is now on its 2.0 release. It is open source under Apache 2.0, code-first Python at its core, with companion implementations in Java, Go, Kotlin, and TypeScript.
ADK’s design center is the multi-agent hierarchy:
- Structure. Specialized agents compose into hierarchies. A graph-based workflow runtime handles routing, loops, retry logic, and nested workflows, and a Task API covers agent-to-agent delegation across multi-turn tasks.
- Tools. Plain functions, OpenAPI specs, and MCP servers all register as tools, with a confirmation mechanism for human-in-the-loop steps.
- Models. Happiest with Gemini and the Vertex AI Model Garden, but LiteLLM integration reaches Anthropic, Meta, Mistral, and the rest of the market.
- Operations. Evaluation is built in through
adk eval, and the sanctioned deployment paths are Cloud Run and Vertex AI Agent Engine.
Read between the lines and ADK is Google Cloud’s answer to a specific question: how do we make agent development look like software engineering? If your infrastructure is already GCP and your compliance team already trusts Vertex, ADK removes more decisions for you than anything else here. Outside that gravity well, its advantages thin out.
Claude Agent SDK: the harness, extracted
Anthropic took the loop that runs Claude Code and packaged it. Renamed from the Claude Code SDK in early 2026, the Claude Agent SDK ships in Python and TypeScript and hands you a working agent runtime rather than parts for one.
- Built-in tools for the file system and shell, so the harness code other frameworks make you write does not exist here.
- Subagents: isolated child agents with their own context windows. The parent delegates, the child works, only findings come back. That keeps the main context clean and lets several investigations run in parallel.
- Hooks at lifecycle points, before a tool call or after a response, that gate agent behavior behind your own policy code.
- MCP integration that early-2026 comparison guides consistently rank as the deepest of any framework, including an in-process server model.
The trade is stated in the name. This is a Claude SDK: you buy the loop and the model as one decision, and the quality of the loop is the argument for accepting that. If your agent’s work is fundamentally “read things, run tools, edit things, verify,” this is the shortest path to production of the four.
LangChain: the neutral ground
LangChain reached 1.0 on October 22, 2025, jointly with LangGraph 1.0, and committed to semantic versioning at the same time. The release reshaped the library around agents: create_agent in Python, createAgent in TypeScript, produces a tool-loop agent in a few lines, and it executes on the LangGraph runtime underneath.
Customization moved to middleware, the 1.0 answer to years of asking how to change what an agent does between steps. Standardized content blocks make outputs interoperable across providers, which matters because model neutrality remains the core sell: LangChain has the largest integration catalog of any agent framework and no preferred model vendor. When orchestration outgrows the default loop, LangGraph exposes the full graph: state, branches, checkpoints, and long-running workflows.
The cost is the flip side of neutrality: you own more architecture. Where the Claude SDK hands you one opinionated loop and ADK hands you Google’s operational path, LangChain hands you options. Teams with mixed model estates, existing LangChain code, or genuinely custom orchestration take that deal happily. Teams that need exactly one good agent sometimes drown in it.
Hermes: the agent you do not build
Nous Research released Hermes in February 2026 under the MIT license, and it moved fast enough through the spring that it now shows up on shortlists next to SDKs from Google and Anthropic. It is not a framework. It is an autonomous agent you self-host: it lives on your server, holds persistent memory of your preferences, projects, and environment across sessions, and gets better at your workload the longer it runs.
The architecture is modular and event-driven, and the surface area is unusually wide for a project this young. Execution backends: local terminal, Docker, SSH remote, Modal. Interfaces: CLI plus Telegram, Discord, Slack, WhatsApp, and Signal. Models: the Nous Portal natively, OpenRouter’s catalog, any OpenAI-compatible endpoint, or local vLLM. It ships more than forty built-in skills and an automated skill-creation system on the open SKILL.md standard. Everything stays on your machine; there is no telemetry.
The right question for Hermes is not “should we build on it” but “do we need to build at all.” If what you want is a capable operator for triage, research, ops chores, and glue work, running Hermes may beat building a bespoke agent with any of the other three. If the agent is your product, Hermes is not your dependency; it is your benchmark.
Side by side
| Google ADK | Claude Agent SDK | LangChain | Hermes | |
|---|---|---|---|---|
| Category | Framework | SDK and runtime | Framework | Finished agent |
| Builder | Anthropic | LangChain | Nous Research | |
| License | Apache 2.0 | Free SDK, commercial API behind it | MIT | MIT |
| Languages | Python core; Java, Go, Kotlin, TypeScript | Python, TypeScript | Python, TypeScript | Self-hosted service |
| Models | Gemini first, others via LiteLLM | Claude only | Any major provider | OpenRouter, OpenAI-compatible, local vLLM |
| MCP | Servers register as tools | Deepest of the four | Adapter support | MCP 2.x since mid-2026 |
| Home turf | Google Cloud | Claude-native products | Mixed stacks | Your own server |
How to actually choose
- Already on Google Cloud, need multiple cooperating agents, want evaluation and deployment in the box: ADK.
- All-in on Claude and want the strongest single-agent loop with the least harness code: Claude Agent SDK.
- Mixed model estate, custom orchestration, or an existing LangChain investment: LangChain on LangGraph.
- Need a working operator agent this month, and it is not the product you sell: run Hermes before writing anything.
The switching cost none of the docs mention
Pick any of the four and the loop code is the cheap part. The expensive part is what accumulates around it: system prompts, tool definitions, skills, memory schemas, evaluation sets, approval policies. Each stack encodes that material in its own shape: ADK agent configs, Claude SDK options and hooks, LangGraph graphs and middleware, Hermes skills and memory. Two years in, that material is your actual AI system, and it is written in a dialect only one runtime speaks.
The industry has started standardizing the edges. MCP made tool access portable, and all four stacks speak it. SKILL.md is doing the same for skills. But the system itself, the composition of prompts, skills, memory, connectors, and models that makes your agent yours, still has no portable form inside any of these stacks.
That layer is where Viorant works: AI Deployment Infrastructure. A .vio definition composes those assets as signed, versioned artifacts, independent of the runtime that executes them, so the choice above stays a runtime decision instead of a permanent one. Whichever loop wins the next benchmark cycle, your system definition should survive the migration.
For the definition layer itself, see how .vio composes signed, versioned AI artifacts into one portable system definition, and browse more reporting in AI Infrastructure Field Notes.
