John Bulla for Google Developer Experts

Posted on Aug 2 • Originally published at wiki-cloud.co

Google ADK: Architecture and Essential Components

#agents #cloud #googlecloud #ai

Nota: ✋ This post was originally published on my blog wiki-cloud.co

Introduction

The development of artificial intelligence solutions is evolving from traditional conversational assistants to systems capable of reasoning, using tools, querying information, executing processes, and collaborating with other agents.

In this context, Google Agent Development Kit (ADK) provides a framework for designing, developing, testing, and deploying AI-based agent applications. Its modular architecture allows you to build anything from a simple agent to multi-agent systems capable of coordinating complex business workflows.

Based on the official product guide, some research, and the experience of many developers, I present a high-level architecture of Google ADK with different components, which can be explained through the following layers:

User interfaces.
ADK Runtime and Runner.
Agent system.
Foundation components.
Models and knowledge.
Observability and governance.
Deployment options.

Each layer fulfills a specific function and integrates with the others to process user requests in an organized, secure, and scalable manner.

High-level architecture

Below I present the high-level architecture divided into layers and components, where I will explain each one of them:

User interfaces

The top layer of this high-level architecture represents the different channels through which users or applications can interact with the agents.

Google ADK doesn't require the use of a specific interface. Users and developers can interact with the agents through various options, including:

CLI: for running and testing agents from the command line.
Web UI: for interacting with agents through a web interface.
API Endpoints: for integrating agents with other applications or services.
Custom Frontends: such as corporate portals, mobile apps, conversational assistants, or messaging channels.

This separation allows the agent's logic to be independent of the user experience. The same agent system can be used from different channels without needing to modify its internal behavior.

For example, a support agent can handle inquiries from a web application, an internal chatbot, and an API used by other corporate applications.

Source: Google ADK

ADK Runtime & Runner

The ADK Runtime and Runner constitute the environment responsible for executing and coordinating the operation of the agents.

This layer acts as the operational engine of the architecture and is responsible for connecting the user interfaces with the agent system and the services they need.

Its main capabilities are:

Event Loop

The event loop is the central operating pattern that defines the interaction between the Runner and the custom code (agents, tools, callbacks, collectively referred to as “execution logic” or “logical components” in the design document). The event loop manages the sequence of actions that occur during an interaction.

Source: Google ADK

Orchestration

Orchestration controls how agents participate and in what order tasks are performed.

You can determine, for example:

Which agent should handle a request?
Whether multiple agents should execute sequentially?
Whether certain tasks can be processed in parallel?
When should an action be repeated?
When should control be transferred to another agent?
When should the execution flow end?

This capability is especially important in multi-agent architectures.

Service Management

Service management connects the Runner to the infrastructure components used by the application.

This includes services such as:

Sessions.
Memory.
State.
Artifacts.
Tools.
Evaluation services.
Observability systems.

Thanks to this separation, the agent's logic can remain decoupled from the mechanism used to store information or deploy the solution.

Agent System

The functional core of the architecture is the agent system. ADK allows combining different types of agents depending on the level of autonomy, control, and specialization required by the solution.

LLM Agents

LLM Agents use language models to interpret requests, reason about the context, and decide what action to take. Google ADKuse models from the Gemini family through Vertex AI or Google AI Studio to reason and make decisions.

This type of agent can:

Understand natural language.
Analyze information.
Generate responses.
Select tools.
Decide which agent should intervene.
Solve tasks that don't follow a completely deterministic flow.

For example, a customer service agent can analyze a request, check the status of an order, and determine whether to respond directly or transfer the case to a specialized agent.

Agent workflow

Workflows control the execution of other agents using more structured patterns. They are useful when the process requires predictable behavior and a defined execution order.

The main patterns are:

Sequential execution
Parallel execution
Execution using loops

Custom Agents

Custom agents allow you to implement specialized behaviors when agents based solely on language models or predefined flows are insufficient.

A custom agent can include:

Specific business logic.
Custom algorithms.
Deterministic validations.
Complex integrations.
Security rules.
Specialized data processing.
Advanced execution cycle control.

For example, an organization could create a custom agent to validate financial transactions by applying internal rules before allowing another agent to continue the process.

Foundation components

The ADK architecture relies on a set of components that preserve context, coordinate actions, and enable interaction with external systems. These components are essential for the agent to maintain continuity and perform tasks beyond a simple conversation. The basic or fundamental components are as follows:

Session

A session represents a continuous interaction between a user and an agent application. The session allows for the preservation of:

User messages.
Agent responses.
Tool calls.
Intermediate results.
Transfers between agents.
Events that occur during execution.

The session provides the necessary context to maintain a coherent conversation across multiple exchanges.

For example, if a user provides an order number at the beginning of a conversation, the agent can reuse it in subsequent requests within the same session.

State

State stores structured information that can change during execution. Unlike conversational history, state contains concrete values that agents can query or update. Some examples are:

User name.
Selected language.
Incident number.
Selected product.
Approval status.
Validation result.
Current step in a process.

State facilitates the construction of multi-step conversational flows and avoids relying solely on the text in the history.

Memory

Memory allows information to be stored and retrieved beyond a single session. It can be used to remember:

User preferences.
Previous interactions.
Related projects.
Previous decisions.
Relevant information from past conversations.

Memory helps deliver more personalized experiences and maintain continuity across different sessions.

It is important to distinguish between three concepts:

Session: represents a specific conversation.
State: stores structured values during execution.
Memory: stores reusable information long-term.

Events

Events are the fundamental units of information flow within the Agent Development Kit (ADK). They represent every significant occurrence during an agent's interaction lifecycle, from initial user input to final response, including all intermediate steps. Understanding events is crucial, as they are the primary means of communication between components, state management, and control flow direction. An event can correspond to:

A message.
An answer.
A call to a tool.
The result of a tool.
A change of state.
A transfer between agents.
A mistake.

The use of events allows you to reconstruct the path followed by the system and understand how a response was generated. It is also an important basis for traceability, debugging, and evaluation.

Tools

Tools allow agents to interact with external services and perform real-world actions. A tool can be:

A Python function.
An enterprise API.
A database query.
A Google Cloud service.
A ticketing system.
A search tool.
A SaaS application.
Another agent.
An MCP-compatible server.

When an agent needs information or needs to perform an action, they can select a tool, generate its parameters, and process the result. For example, a support agent can query a knowledge base, check the status of a service, and create a ticket on an external platform.

Artifacts

Artifacts represent a crucial mechanism for managing named and versioned binary data, associated with a specific user interaction session or persistently with a user across multiple sessions. They allow agents and tools to manage data beyond simple text strings, enabling more comprehensive interactions that include files, images, audio, and other binary formats.

Models and Knowledge

The models and knowledge layer provides the intelligence, context, and information sources used by the agents. This layer includes four main elements.

Gemini and other models

Google ADK is designed to integrate seamlessly with Gemini, although it can also use other third-party models depending on the solution's needs.

The model can handle:

Understanding user intent.
Reasoning about a problem.
Generate responses.
Select tools.
Classifying requests.
Summarizing information.
Coordinating agents.

An architecture can use different models depending on the task.

For example:

An advanced model for complex reasoning.
A faster model for classification.
A multimodal model for processing images or documents.
A specialized model for a specific task.
This flexibility allows for balancing quality, latency, and cost.

Long-Term Memory

Long-term memory retains relevant information obtained from previous interactions. It can be used to retrieve:

User preferences.
Historical decisions.
Project context.
Previous interactions.
Information associated with long-running processes.

Retrieval should be selective to avoid sending unnecessary information to the model. It is also important to implement data privacy, retention, and deletion policies.

Retrieval Augmented Generation (RAG)

The architecture can integrate Retrieval Augmented Generation mechanisms, known as RAG. This approach allows the agent to search for information in knowledge sources before generating a response. These sources can include:

Enterprise documentation.
Manuals.
Internal policies.
Knowledge bases.
Technical documents.
Repositories.
Vector databases.

RAG reduces reliance on general model knowledge and improves the accuracy of responses.

APIs, services and external systems

Agents can connect to internal and external systems using tools and integrations. Some examples include:

Enterprise APIs.
Databases.
ERP systems.
CRM systems.
Ticketing platforms.
SaaS services.
Storage systems.
Search engines.
Google Cloud services.
Third-party applications.

This capability allows agents not only to answer questions but also to access up-to-date information and perform actions within business processes.

Observability and governance

Observability and governance allow us to understand what happens within an agent as it performs a task. Through telemetry and structured logs, it's possible to analyze aspects such as its reasoning steps, tool calls, and the responses generated by the models. This information is especially useful during development, as it facilitates error identification, diagnosis of unexpected behavior, continuous agent improvement, and monitoring of system performance.

This layer consists of:

Traceability: Allows us to reconstruct the complete path of a request. This information is fundamental for analyzing errors and understanding the behavior of multi-agent systems.
Logs: Logs record important events that occur during execution. Logs facilitate incident investigation and operational monitoring.
Metrics: Metrics allow us to measure system performance and quality. These metrics help identify performance, cost, or design problems.
Evaluation: Evaluation allows us to verify whether the agents meet the expected objectives. In an agent-based system, it's not enough to evaluate the final response. It's also necessary to review whether the agent followed the correct process.
Alerts: Alerts notify you of unexpected behavior or critical conditions. They allow you to respond quickly before the problem affects a larger number of users.
Security: Security should be integrated into the entire architecture, enabling control over user authentication, role-based authorization and permissions, data protection, auditing, and more. For example, an agent can view an invoice but not modify it. Another authorized agent could make changes after human validation or approval.

Deployment Options

Una aplicación desarrollada con Google ADK puede desplegarse en diferentes entornos. La elección depende del nivel de control, escalabilidad, costos, integración, seguridad y operación requerida por la organización. A continuación se mencionan las opciones de despliegue más comunes:

Agent Runtime: This is a fully managed, auto-scaling service on Google Cloud, specifically designed to deploy, manage, and scale AI agents built with frameworks like ADK.
Cloud Run: Cloud Run allows you to deploy agents as serverless containers. Cloud Run can be used to expose the agent via an API or integrate it with events and other Google Cloud services.
Google Kubernetes Engine: Google Kubernetes Engine (GKE) is a managed Kubernetes service from Google Cloud that allows you to run agents in a container environment. GKE is a good option if you need greater control over the deployment and to run Open Models.
Other Environments: As an open-source, code-based framework, ADK can also be deployed in other compatible environments, such as on-premises infrastructure, private data centers, other container platforms, other cloud environments, and virtual machines. This flexibility allows you to tailor the deployment to sovereignty, regulatory, integration, or multicloud strategy requirements.

Conclusion

The Google ADK architecture provides a modular framework for building AI-based applications.

User interfaces allow access to the system from various channels. The Runtime and Runner coordinate execution. The agent system provides reasoning, orchestration, and specialized behaviors. Core components manage sessions, state, memory, events, tools, and artifacts.

The model and knowledge layer connects the agents to Gemini, other models, RAG systems, and external sources. Observability and governance enable control over performance, quality, and security. Finally, the various deployment options allow the solution to run in managed environments, serverless environments, Kubernetes, or on-premises infrastructure.

The main strength of ADK lies not only in connecting an application to a language model, but also in providing the necessary components to transform that model into an organized, extensible, observable agentic system ready to integrate with real-world business processes.

The appropriate design will depend on each use case, but should always maintain a balance between autonomy, control, security, and simplicity.

In future articles, we will delve deeper into this topic.