
Gemini ADK High-Level Design: Interfaces and Core Classes
Delve into the architectural blueprint of the Gemini ADK. Understand the core classes, interfaces, and the philosophy of 'Separation of Concerns' that makes ADK the most robust framework for enterprise AI agents.
Gemini ADK High-Level Design: Interfaces and Core Classes
When you first start building with the Gemini ADK, it can feel like you're just calling a few functions. However, beneath the surface is a sophisticated, modular architecture designed for Separation of Concerns. The ADK is built so that you can swap out pieces of the puzzle—like your memory store or your tool definitions—without rewriting the entire agent logic.
In this lesson, we will explore the high-level design of the ADK. We will deconstruct the four primary interfaces: the Agent, the Tool, the Memory Manager, and the Runtime Orchestrator.
1. The Design Philosophy: Configuration over Chaos
Many AI frameworks grow "organically," leading to spaghetti code where the prompt, the retry logic, and the API calls are all mixed together. The Gemini ADK enforces a declarative philosophy. You define what the agent is, what it knows, and what it can do, and the ADK manages the "how."
The Core Architectural Loop
The ADK treats an agent as a State Machine.
- State: Current context, history, and available tools.
- Transition: The LLM's decision to act or speak.
- Observation: The result of that action, which updates the state.
2. Pillar 1: The Agent Interface
The Agent is the top-level object. It is the representation of the "Mind" of your system.
Responsibilities:
- System Identity: Storing the "Persona" (e.g., "You are a helpful researcher").
- Model Selection: Binding to a specific version of Gemini (Flash, Pro).
- Safety Policy: Defining the guardrails (e.g., "Never expose user passwords").
Separation of Concerns:
The Agent class does not know how a tool works. It only knows that a tool exists and how to describe it to Gemini. This allows the same agent to be deployed with different sets of tools depending on the environment.
3. Pillar 2: The Tool and Toolkit
Tools are the "hands" of the agent. In the ADK, tools are highly standardized.
The Anatomy of a Tool:
- Description (Docstring): This is arguably the most important part. Gemini uses this text to decide if it should call the tool.
- Input Schema (JSON/Pydantic): Defines the exact structure of the arguments Gemini must provide.
- Execution Logic: The actual Python or API code that runs.
Toolkits:
Multiple related tools are grouped into a Toolkit. For example, a "Cloud Storage Toolkit" might include list_buckets, upload_file, and get_permissions.
classDiagram
class Agent {
+String name
+SystemInstruction instructions
+bind_tools(Toolkit)
+run(user_prompt)
}
class Tool {
+String name
+String description
+Schema arguments
+execute()
}
class Toolkit {
+List[Tool] tools
}
Agent "1" *-- "many" Tool : has
Toolkit "1" *-- "many" Tool : groups
4. Pillar 3: Memory and State Manager
The MemoryManager is responsible for persistence. It ensures that Turn 10 of a conversation remains coherent with Turn 1.
Layers of Memory:
- Context (In-Session): Fast, non-persistent memory held in the current memory buffer.
- Episodic Memory: Storing previous "sessions" for future reference.
- Semantic Memory: Storing facts and knowledge (often via a Vector Database).
Interface Design:
The MemoryManager usually exposes two methods: save(fact/turn) and retrieve(query). The ADK calls these automatically behind the scenes to keep Gemini's context window optimized.
5. Pillar 4: The Runtime Orchestrator
The Runtime is the engine that actually starts the loop. It acts as the mediator between the Model, the Tools, and the Memory.
The Execution Workflow:
- Start: Runtime receives a user request.
- Fetch Context: Runtime asks MemoryManager for relevant history.
- Model Turn: Runtime sends (Instructions + Context + Request) to Gemini.
- Handling Tool Calls: If Gemini emits a
ToolCall, the Runtime pauses, executes the tool, and feeds the result back to Gemini. - Termination: Once Gemini provides a final answer, the Runtime saves the turn to Memory and returns the response to the user.
6. Implementation: Defining a Custom Tool
Let's look at how we build a custom tool and bind it to our agent using the ADK's interface patterns.
Step 1: Define the Tool Logic
We use standard Python typing and docstrings. The ADK uses these to generate the JSON schema for Gemini.
from typing import List, Optional
def fetch_top_news(category: str, limit: int = 5) -> List[str]:
"""
Fetches the latest news headlines for a specific category.
Args:
category: The topic of the news (e.g., 'tech', 'science', 'business').
limit: The maximum number of headlines to return.
"""
# In a real app, this would call an external News API
headlines = [
f"[Tech] New Gemini 1.5 update released!",
f"[Tech] AI Agents are taking over DevOps."
]
return headlines[:limit]
# Step 2: Bind the Tool to the Agent
import google.generativeai as genai
# Gemini ADK automatically converts 'fetch_top_news' into a Tool object
model = genai.GenerativeModel(
model_name='gemini-1.5-flash',
tools=[fetch_top_news]
)
# Step 3: Run the Agentic Session
# The 'chat' object here acts as the 'Runtime' and 'Memory' manager
chat = model.start_chat(enable_automatic_function_calling=True)
response = chat.send_message("What's the latest in tech news?")
print(response.text)
7. Comparison with LangChain and MCP
| Feature | Gemini ADK | LangChain | MCP (Model Context Protocol) |
|---|---|---|---|
| Philosophy | Gemini-Native / Simple. | Abstract / "Chain" focused. | Standardized Protocol. |
| Complexity | Low - standard Python. | High - complex class hierarchies. | Moderate - requires server/client setup. |
| Optimization | Pixel-perfect for Gemini features. | General purpose - often lags on new features. | Focuses on tool interoperability. |
| Best For | Production Gemini Agents. | Prototyping multi-model apps. | Connecting heterogenous tools to any LLM. |
8. Extensibility: Building Middleware
Advanced ADK users often implement Middleware—code that sits between the Runtime and the Model.
- Logging Middleware: Automatically sends every turn to a tool like LangSmith or Google Cloud Logging.
- Cost Middleware: Stops the agent if the current session costs more than $0.10.
- Guardrail Middleware: Checks the model's response for specific banned words before it reaches the user.
9. Summary and Exercises
The Gemini ADK high-level design is about Standardization.
- The Agent defines the identity.
- The Tool defines the capability.
- The Memory defines the history.
- The Runtime orchestrates the loop.
Exercises
- Interface Design: You want to add a "Web Search" capability to your agent. Write the
Tooldefinition (including the docstring and arguments) that would give Gemini the best chance of using it correctly. - Architecture Review: Why is it better to have the
MemoryManageras a separate class rather than built into theAgentclass? (Hint: Think about swapping a local text file for a cloud database). - State Machine Mapping: Map a "Customer Support Ticket" workflow to the Agentic State Machine. What is the "Initial State"? What are the "Transitions"? What is the "Termination State"?
In the next lesson, we will follow the Agent Lifecycle, tracking a request from the moment the user hits "Send" to the final result.