Agent Frameworks & ADK Study Guide — AI Advanced

Agent Frameworks & ADK

This domain accounts for 25% of the exam and tests your ability to design, build, and evaluate multi-agent systems using Google ADK, LangGraph, CrewAI, and related orchestration patterns. Questions assess both conceptual understanding (when to use which framework or agent type) and practical knowledge (exact APIs, persistence mechanisms, communication patterns, and evaluation metrics). Expect scenario-based questions requiring you to select the correct agent type, tool, or memory strategy for a given requirement.

Google Agent Development Kit (ADK): Agents, Tools, Sessions, Runners

Google ADK is an open-source Python framework for building, orchestrating, and deploying LLM-powered agents. Its four core abstractions are agents, tools, sessions, and runners.

Core Abstractions

Sessions and SessionService

A Session holds events (the turn history), state (a mutable dict), and metadata (session_id, app_name, user_id). The SessionService is the interface for creating, reading, and updating sessions. ADK provides three implementations:

Runner

The Runner ties an agent to a SessionService and an ArtifactService. You invoke runner.run(session_id, message) or the async runner.run_async(...). The Runner orchestrates the agent loop: call LLM → parse tool calls → execute tools → append events → repeat until no tool calls remain.

Common traps:

• Confusing Session.state (mutable per-session dict) with Session.events (immutable turn log).
• Using InMemorySessionService in production — it loses all state on restart.
• Thinking the Runner is per-request; it is created once and reused across sessions.
• Forgetting that runner.run() is synchronous and blocks; runner.run_async() is required in async applications.

ADK Agent Types: LlmAgent, SequentialAgent, ParallelAgent, LoopAgent

ADK provides four primary agent types. Choosing the correct type is a frequent exam question.

Bold decision rule: Use SequentialAgent when step N requires step N-1's output. Use ParallelAgent when sub-tasks are independent. Use LoopAgent when you need iterative improvement with a stopping criterion.

LoopAgent requires a max_iterations parameter to prevent infinite loops. The loop terminates when either the sub-agent signals completion via a special tool call (exit_loop) or max_iterations is reached.

Common traps:

• Choosing ParallelAgent when tasks have dependencies — it does not sequence execution.
• Forgetting max_iterations on LoopAgent — without it, you risk infinite loops (though ADK enforces a default limit).
• Assuming SequentialAgent has an LLM itself — it is a pure orchestrator with no model.
• Confusing SequentialAgent output passing (state-based) with direct argument injection.

Worked scenario: A pipeline must (1) extract entities from a document, then (2) look up each entity in a database, then (3) generate a summary. The sub-tasks are ordered and dependent. → Correct choice: SequentialAgent with three LlmAgent sub-agents. ParallelAgent is wrong because step 2 depends on step 1's output.

Agent type selection decision tree:

Choose the right ADK agent type based on execution requirements.