Google ADK

Workflow patterns as classes

What are AI agents argues that five workflow patterns are usually the answer and a model deciding its own steps is a step past most problems. Google's Agent Development Kit encodes that argument in its type system.

Alongside LlmAgent, where the model decides, it gives you SequentialAgent, ParallelAgent, LoopAgent and CustomAgent. Those are deterministic control flow. A sequential pipeline is a class rather than an agent you hope behaves sequentially.

That is the distinguishing feature against Claude Agent SDK and OpenAI AgentKit, which both centre the model-driven loop. ADK treats "the model decides" as one option among several, and for a team whose real problem is a four-step pipeline with one judgement call in the middle, that framing is the right one.

Model-agnostic, and it means it

It connects to Gemini, Claude, OpenAI, Ollama, vLLM, LiteLLM and locally-running models.

Two consequences. The framework is usable without adopting Google's models, which is unusual for a vendor-published SDK. And it covers local runtimes, so an agent developed against a hosted model can be evaluated against something you run yourself, which matters for the case self-hosted models describes.

Five language bindings exist: Python (google-adk), TypeScript (@google/adk), Go, Java and Kotlin. The JVM entries are the notable ones, since most agent frameworks are Python-first and a Java shop has had few options.

Tools come from three places

Function tools are your own code. MCP tools reach anything speaking the protocol, which is the whole ecosystem MCP in one sitting describes. OpenAPI tools generate from a spec, so an existing REST API becomes callable without writing wrappers.

The OpenAPI route is the one that shortens a real project. Most internal capability already has a spec, and turning that into tools is a generation step rather than a writing step.

The caution from building an MCP client applies: every tool definition is input tokens on every request, and one study had an 8b model fail with 46 tools and succeed with 19 inside its window. Generating tools from a large spec is easy, and passing all of them is the wrong default.

Evaluation is built in

ADK ships an evaluation framework with criteria, user simulation, environment simulation and custom metrics.

That is a real differentiator rather than a checkbox, because LLM evaluations argues the set should exist before the feature and agents are the hardest case to evaluate: the output is a trajectory rather than an answer. User and environment simulation are how you get a repeatable trajectory at all.

Use it early. An agent framework without evaluation produces a demo that works and a system nobody can change safely.

Deploying it

Google Cloud targets are Agent Runtime, Cloud Run and GKE. Containerisation covers custom infrastructure, and there is a command line and web interface for running locally.

So ADK does not tie you to Google Cloud, though the managed path is where the friction is lowest. Vertex AI Agent Builder is the fully managed alternative, and the choice between them is the same one every section here keeps raising: how much of the operation you want to own.

Where it fits

Reach for ADK when your work is mostly deterministic with some model judgement, when you are not on Python, when you want one framework across several providers, or when evaluation matters enough to want it in the box.

Reach elsewhere when the agent is one model-driven loop, where the provider's own SDK is less to learn, or when agent use cases says you do not need a loop at all.

Further reading

• Google, Agent Development Kit: the agent types, workflow agents, tool sources, evaluation and deployment targets.
• What are AI agents: the workflow patterns these classes implement.
• Vertex AI Agent Builder: the managed alternative.
• Claude Agent SDK and OpenAI AgentKit: the loop-centred SDKs.