Hello! Welcome back to our course on agent development.
In our last lesson, we established why Agent Development Kits (ADKs) are so valuable. We saw that they provide powerful abstractions that solve the core engineering challenges of orchestration, state management, and error handling, allowing you to build sophisticated agents without getting lost in low-level boilerplate code.
Today, we're going to look under the hood of those abstractions. This lesson will deconstruct a typical ADK to reveal its core components. By the end of our session, you'll be able to describe the typical components provided by ADKs, specifically executors, memory stores, and tool integrations. Understanding these building blocks is crucial for effectively using an ADK and for making informed decisions about agent architecture.
The Anatomy of an Agent Development Kit
While every ADK has its unique features, most are built around a common set of components that work together to bring an agent to life. To get a clear roadmap of these components, we'll start with an article that outlines the typical architecture of an ADK.
Google's Agent Development Kit: Architecture, Tools, Workflow ...
This article from the Hugging Face blog provides a fantastic, high-level overview of what comes inside a typical ADK, using Google's kit as a primary example. It gives us a great structure for today's lesson.
Please read the section titled 'What Google’s Agent Development Kit Typically Provides'. As you read, focus on the first four items in the list: Agent Definitions, Tooling Layer, Memory + Retrieval, and Workflow Orchestration. These are the fundamental building blocks we'll be dissecting.
As the article highlights, an ADK is much more than a simple LLM wrapper; it's a full runtime environment. Let's explore these components in more detail, starting with the engine that drives the agent.
1. Executors and Workflow Orchestration
The "Workflow Orchestration" component, which we'll also refer to as the Executor, is the agent's engine. It's the part of the framework that takes your agent definition and actually runs it. It manages the agent loop, directs the flow of control, handles state transitions between steps, and executes the tasks you define. This component is the direct solution to the "orchestration boilerplate" challenge we discussed previously.
A powerful and increasingly popular approach to orchestration is modeling the agent's workflow as a graph. LangChain, a popular ADK, has a dedicated library for this called LangGraph.
Don't learn AI Agents without Learning these Fundamentals
LangGraph is an excellent example of a sophisticated Executor. It allows you to define agent workflows as a state graph, where you have explicit control over the sequence, branching, and looping of tasks. This is highly appealing from a software engineering perspective as it makes complex flows traceable and debuggable.
Watch this segment from 41:58 to 45:17. As you watch, focus on understanding these core concepts: Nodes: These are the fundamental units of work, typically represented as functions (e.g., call the LLM, execute a tool). Edges: These are the connectors that define the path of execution from one node to the next. They can be conditional, allowing for branching logic (e.g., if a tool fails, go to an error-handling node). StateGraph: This is a shared object that maintains the state of the workflow. Each node can read from and write to this graph, ensuring information is passed consistently through the process.
By representing the workflow as a graph, the Executor provides a structured and visual way to manage complex, multi-step processes. Instead of a single, monolithic ReAct loop, you can build modular, maintainable flows, much like you would design a system using microservices or a data pipeline using a DAG (Directed Acyclic Graph) tool like Apache Airflow.
2. Memory Stores
The memory component is responsible for giving an agent context and continuity, solving the "state management" challenge. As we've touched on, this isn't just one thing; it's a system for managing different types of memory.
Let's quickly refresh our understanding of the two main types of memory an agent needs.
This article from PromptingGuide.ai offers a concise explanation of the distinction between short-term and long-term agent memory.
Read just the 'Memory' subsection. Take note of how short-term memory is related to the immediate context (like a conversation), while long-term memory involves an external storage and retrieval mechanism, often a vector store.
ADKs provide components to handle both types. They offer pluggable modules that abstract away the implementation details of storing, retrieving, and formatting this information for the LLM.
Don't learn AI Agents without Learning these Fundamentals
Now, let's see how an ADK like LangChain packages these memory concepts into concrete components that you can import and use.
Re-watch the short segment from 07:26 to 09:32. Listen for how the video describes components for 'Memory management' (for short-term conversation history) and 'Vector database integration' (for long-term knowledge retrieval). The key is that the ADK provides standardized interfaces for these, so you can easily swap them out.
So, an ADK's memory component might include:
- Conversation Buffers: Objects that automatically store and retrieve the recent history of a conversation, managing the token limit of the context window.
- Vector Store Integrations: Connectors to databases like Pinecone, ChromaDB, or Google's Vertex AI Vector Search. These components handle the process of embedding text and querying the database for relevant information (the "Retrieval" in RAG).
This diagram from Google's documentation provides a great visual model for how an ADK can abstract the memory process.
3. Tool Integrations
If the executor is the engine and memory is the context, then tools are the agent's hands and eyes, allowing it to interact with the world beyond the LLM's internal knowledge. The Tooling Layer or Tool Integration component of an ADK standardizes how you connect these external functionalities.
This component handles the critical two-way communication:
- Exposing tools to the LLM: It formats the tool's description, parameters, and instructions in a way the LLM can understand, enabling it to decide when and how to use the tool.
- Executing tool calls: When the LLM decides to use a tool, the ADK parses this request, calls your actual code (e.g., a Python function or an API endpoint), and passes the output back to the LLM as an "observation."
A good ADK makes it easy to integrate various kinds of tools, from simple, pre-built functions to complex, custom-coded logic.
How to Build Multi AI Agents with Google Agent Development Kit (ADK) For Beginners
This practical demonstration using Google's ADK is perfect for showing the different levels of tool integration provided by a mature framework.
Please watch these three segments, which showcase a spectrum of tool integration patterns: Pre-built Tools (03:41 - 05:50): See how a ready-made GoogleSearch tool is added to an agent with just one or two lines of code. Agent as a Tool (05:50 - 08:16): This is a powerful concept where an entire agent is 'wrapped' to act as a tool for another agent. This allows you to add a layer of processing or validation to a tool's output. Custom Function Tools (08:16 - 10:08): As a developer, this is a pattern you'll use frequently. Pay close attention to how a simple Python function is turned into a tool. The ADK uses the function's type hints and docstrings to automatically generate the description that the LLM will see.
The "Custom Function Tool" pattern is particularly powerful. By simply writing a standard Python function and adding a decorator, the ADK handles all the complex plumbing of making that function available to the agent's reasoning process.
Test your understanding!
You are tasked with building a customer support agent for an e-commerce site. It must be able to:
- Look up a customer's order status by calling an internal
getOrder(order_id)API. - Remember the customer's name and order ID for the duration of the conversation.
- Follow a strict, non-negotiable workflow: first greet the user, then ask for their order ID, then look it up, and finally report the status. It should never deviate from this sequence.
Map each of these three requirements to the primary ADK component that would handle it: Executor/Orchestrator, Memory Store, or Tool Integration.
Show answer
- Look up order status: This is handled by the Tool Integration component. You would wrap the
getOrder(order_id)API call in a custom function and register it as a tool for the agent. - Remember customer details: This is the job of the Memory Store. You would use a short-term memory component, like a conversation buffer, to retain the customer's name and order ID throughout the session.
- Follow a strict workflow: This is managed by the Executor/Orchestrator. Instead of a flexible
LlmAgentthat might try other things, you would use aSequentialAgentor a similar graph-based structure to force the agent to follow the exact Greet -> Ask -> Look up -> Report sequence.
Conclusion
Today, we peeled back the layers of abstraction and saw that ADKs are modular frameworks built from distinct, powerful components.
Here are the key takeaways:
- ADKs are composed of concrete building blocks that solve specific engineering problems.
- Executors (or Workflow Orchestrators) are the engines that run the agent, managing the flow of control using structures like state graphs (e.g., LangGraph).
- Memory Stores are pluggable modules that provide both short-term conversational memory and long-term knowledge retrieval through integrations with vector databases.
- Tool Integrations provide a standardized and simplified interface for connecting agents to the outside world, whether through pre-built tools or your own custom functions.
By providing these components, ADKs allow you to assemble sophisticated agents rather than building everything from the ground up. You get to focus on the what—your agent's logic, tools, and knowledge—while the framework handles the how.
Now that we understand what's inside an ADK, our next lesson will address a crucial strategic question: what are the trade-offs between building custom agents versus using ADKs? This will equip you to decide when to leverage a framework and when it might make sense to build your own components.