« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 22 — Framework Deep-Dive: Google Agent Development Kit (ADK)

Answers these JD lines: every posting in jd.md that names Google ADK by name — the Citi enterprise-agent-platform roles ("Code and optimize multi-tenant agents using ReAct, ReWOO, and Google ADK-style orchestration"; "Develop multi-tenant intelligent agents using ReAct/ReWOO-style orchestration and Google ADK"), the "Build with Google Gemini, Vertex AI, Google ADK" line, and the Temporal AI-Foundations role that lists ADK among the frameworks its durable-execution plugins target. ADK is one of the few frameworks these JDs name explicitly and repeatedly, so being able to reason about its execution model (not just call it) is a direct interview signal.

Why this phase exists

You already built the primitives from scratch in earlier phases: the ReAct/ReWOO loop (Phase 01), tool-calling with schema validation (Phase 02), context/state/memory (Phase 04), multi-agent orchestration (Phase 07), and guardrails (Phase 10). Google ADK is the production framework that packages all of those into one code-first, model-agnostic SDK, optimized for Gemini and Vertex AI. This phase is where you stop treating ADK as a black box and learn its execution model well enough to own it — because "we use ADK" on a résumé is worth nothing if you can't explain what runner.run(agent) actually does, or why a SequentialAgent is more reliable than an LLM deciding the order.

Four ideas carry the whole framework, and they map onto the three labs:

1. The LlmAgent + FunctionTool + Runner triangle. An LlmAgent is the reasoning unit (instruction, tools, output_key); a FunctionTool wraps a Python function and derives its schema from the signature; a Runner drives the loop and yields Events (the stream of what happened). This is the same trust boundary from Phase 00 — the model proposes tool calls, your code executes them — with ADK's ergonomics on top.

2. Deterministic orchestration vs LLM-driven delegation. ADK's signature distinction. The workflow agents — SequentialAgent, ParallelAgent, LoopAgent — fix the control flow in code; the order is guaranteed, not chosen by a model. Contrast that with sub_agents on an LlmAgent, where the model decides at runtime which child to transfer_to_agent. The ADK philosophy in one line: deterministic structure around LLM reasoning.

3. Scoped session state. State keys carry scope prefixes — unprefixed (this conversation), user: (all of a user's sessions), app: (the whole app), temp: (this turn only) — so ADK separates "what this chat knows" from "what this user always wants" from "global config" without you juggling three dictionaries. This is Phase 04 context-engineering, productized.

4. Callbacks as the interception/guardrail layer. before_*/after_* hooks around agent, model, and tool steps. A before_* that returns a value short-circuits the wrapped step — a cache hit that skips the (paid) model, or a guardrail that blocks a dangerous tool. This is Phase 10 guardrails, wired into the framework's lifecycle.

Concept map

• Reasoning unit: LlmAgent (alias Agent) — name, model, instruction, description (read by other agents for delegation), tools, output_key, sub_agents.
• Tools: FunctionTool (a Python function → auto-derived schema), agent-as-a-tool, built-in tools, MCP tools (Phase 03), OpenAPI tools. The model proposes; the tool executes.
• Execution: Runner drives an agent and yields Events (model response, tool call, tool result, final); an Event carries content and a state delta (e.g. the output_key write).
• Deterministic orchestration: SequentialAgent (order + state flow), ParallelAgent (independent fan-out, merge), LoopAgent (repeat until escalate or max_iterations).
• LLM-driven orchestration: sub_agents + transfer_to_agent — a coordinator model routes.
• State & memory: SessionService (InMemory / Database / VertexAI) holds Sessions with scoped state; MemoryService for long-term recall across sessions.
• Interception: the six callbacks — before/after × agent/model/tool — for logging, metrics, caching, and guardrails, with the before_* short-circuit contract.
• Deployment: local Runner → Vertex AI Agent Engine (managed sessions, scaling, tracing).

The three labs

Integrated scenario (how this shows up at work)

A Google-Cloud shop wants an internal "research assistant" agent: given a topic, gather from three sources in parallel, draft an answer, and refine it until a quality bar is met — with per-user preferences, a global model config, PII redaction on tool outputs, and a hard block on any tool that writes to production. In ADK you compose this deterministically: a ParallelAgent fans out the three gather sub-agents (each writing its own output_key), a SequentialAgent threads gather → draft → a LoopAgent that refines until an exit_loop-style checker escalates. Per-user prefs live in user:-scoped state; the model id in app:-scoped state. A before_tool_callback denies the production-write tool (the guardrail never even calls it), and an after_tool_callback redacts PII before it enters context. The LLM reasons inside each leaf; the structure around it is code you can test, replay, and defend in a design review. That is the Staff-level move: reliable orchestration wrapped around fuzzy reasoning. You then deploy the whole thing to Vertex AI Agent Engine for managed sessions and tracing.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• Lab 02 green — you can state Sequential vs Parallel vs Loop semantics and their guarantees.
• Lab 03 green — you can explain user:/app: scope sharing and the callback short-circuit.
• You can contrast workflow agents (deterministic) with sub_agent transfer (LLM-driven).
• You can explain when ADK is the right choice (Gemini/Vertex/Google-Cloud shops) and how it compares to LangGraph (Phase 18) and the OpenAI Agents SDK.

Key takeaways

• ADK is code-first and model-agnostic but Gemini/Vertex-optimized; the mental model is LlmAgent + tools + a Runner that yields Events, exactly the loop you built in Phase 01.
• The distinction interviewers probe: deterministic workflow agents (Sequential/Parallel/ Loop) put guaranteed structure around LLM reasoning; sub_agents + transfer let the model route. Reach for the deterministic one whenever the flow is known — reliability compounds (Phase 00), and code you can test beats a model you have to trust.
• State scopes (user:/app:/temp:) and callbacks (short-circuit guardrails) are how ADK turns Phase 04 memory and Phase 10 guardrails into framework features.
• Choose ADK when you're on Google Cloud / Gemini and want first-class Vertex AI Agent Engine deployment; the ideas (agents, tools, workflow orchestration, scoped state, callbacks) are portable to LangGraph and the OpenAI Agents SDK — which is why building the miniatures, not memorizing the API, is what makes the knowledge defensible.