Agent Development Kit (ADK) Crash Course

This repository provides practical implementations of various Agent Development Kit (ADK) patterns. Use these examples to learn specific agent capabilities:

• Basic Agent: Simple query-response agents.
• Tool Agent: Agents equipped with tools to perform external actions.
• LiteLLM Agent: Using LiteLLM to abstract LLM providers and switch models easily.
• Structured Outputs: Using Pydantic models with output_schema for consistent responses.
• Sessions and State: Maintaining memory across multiple interactions.
• Persistent Storage: Storing agent data across restarts.
• Multi-Agent Systems: Orchestrating specialized agents, including Stateful Multi-Agent workflows.
• Agent Control Flow: Implementing Callbacks (real-time monitoring), Sequential Agents (pipelines), Parallel Agents (concurrency), and Loop Agents (iterative refinement via feedback loops).

A Tool Agent in ADK extends a basic agent by incorporating tools that allow it to interact with external systems, retrieve information, or perform specific functions.

There are two main types of tools:

1. Built-in Tools: Pre-configured tools provided by ADK, such as google_search, code_execution, and vertex_ai_search.
2. Custom Function Tools: Python functions defined by the user to extend capabilities.

Tool Compatibility Rules

Crucial Limitation: You cannot mix built-in tools and custom tools in a single agent. Additionally, a single agent can only support one built-in tool at a time. To combine these types, you must use a multi-agent architecture (the Agent Tool approach).

Unsupported Patterns:

• Multiple built-in tools: tools=[built_in_code_execution, google_search]
• Mixing built-in and custom: tools=[google_search, get_current_time]

# Example of what is NOT supported
root_agent = Agent(
    name="RootAgent",
    model="gemini-2.0-flash",
    description="Root Agent",
    tools=[google_search, get_current_time],  # NOT SUPPORTED
)

The LinkedIn Post Generator demonstrates how to combine SequentialAgent and LoopAgent to create complex workflows.

In this pattern:

1. A Sequential Pipeline (e.g., LinkedInPostGenerationPipeline) orchestrates the high-level stages (e.g., Stage 1: Initial Generation $\rightarrow$ Stage 2: Refinement Loop).
2. A Loop Agent (e.g., PostRefinementLoop) handles iterative tasks within one of those stages, such as reviewing and refining content.
3. Sub-Agents operate inside the loop to perform specific roles (e.g., a PostReviewer to evaluate and a PostRefiner to improve).

This architecture allows for a clear separation between the initial creation of an asset and the iterative process of polishing it based on feedback.

# Example Architecture Flow
# 1. SequentialAgent (Root)
#    |--> InitialPostGenerator (LlmAgent)
#    |--> PostRefinementLoop (LoopAgent)
#               |--> PostReviewer (Sub-Agent)
#               |--> PostRefiner (Sub-Agent)

A Multi-Agent System in ADK allows multiple specialized agents to collaborate on complex tasks. There are two primary architectural patterns for implementing this:

1. Sub-Agent Delegation Model: The root agent uses the sub_agents parameter in the Agent constructor. In this model, the root agent acts as a router. When a task is delegated, the sub-agent takes full control of the conversation and its decision is final.

2. Agent-as-a-Tool Model: Agents are wrapped using AgentTool and passed into the tools list of a root agent. In this model, the sub-agent returns results to the root agent, which maintains control and can incorporate the response into its own output or call multiple agent tools in a single turn.

Use Delegation when you want a specialist to take over the entire interaction. Use Agent-as-a-Tool when you want the root agent to orchestrate multiple specialists and synthesize their findings.

# Sub-Agent Delegation Model
root_agent = Agent(
    name="manager",
    sub_agents=[stock_analyst, funny_nerd],
)

# Agent-as-a-Tool Model
from google.adk.tools.agent_tool import AgentTool
root_agent = Agent(
    name="manager",
    tools=[AgentTool(news_analyst)],
)

The LlmRequest object is provided to before_model_callback. It allows you to inspect the request before it reaches the LLM, which is useful for content filtering or bypassing the model call entirely.

Properties:

• contents: List of Content objects representing the conversation history.
• generation_config: Configuration for the model generation.
• safety_settings: Safety settings for the model.
• tools: Tools provided to the model.

def before_model_callback(callback_context: CallbackContext, llm_request: LlmRequest):
    # Get the last user message for analysis
    last_message = None
    for content in reversed(llm_request.contents):
        if content.role == "user" and content.parts:
            last_message = content.parts[0].text
            break
            
    # Analyze the user's message
    if last_message and contains_sensitive_info(last_message):
        # Return a response that bypasses the model call
        return LlmResponse(...)