Building AI Agents with ADK Go

[0:00]Hi, I'm Ivan, an engineer working on the Agent Development Kit. I'm excited to announce Go ADK. Go ADK is a handcrafted AI agent library idiomatic for Go. In this video, we're going to learn all about what it is, how it works, and how you can get started. Building AI agents from scratch, dealing directly with LLM APIs or SDKs, can quickly become complex. You're managing state, memory, tool calls, control flow, and more, often reinventing the wheel for common patterns. That's precisely what the Agent Development Kit or ADK is designed to address. It's a flexible and modular open source framework specifically built to simplify the development, deployment and evaluation of AI agents. Let's get started with Go ADK. Our goal is to run your first Go agent in about 5 minutes. Then we'll dive deeper into some of the more advanced concepts. The first step, as with any library, is including ADK in your project. Since we're using go, it's as simple as running this go get command. Now, before we look at the code, let's discuss the notion of agent. In ADK, there are three main categories of agents. LLM based reasoning agents decide which tools to call or which agents to transfer to. Then there are workflow agents for more prescriptive and deterministic logic flows. Finally, you can also build custom agents where you can write arbitrary logic like combining both the LLM and workflow agents. Let's create an assistant for teaching science to students. The agent is defined by a name, a description, an LLM model object, and instruction prompt. To run the agent, we'll use an in memory session service. Create a session to hold the conversation and a runner to run the agent. Once the agent runs, it returns an iterator of events, which we can print out in parts. Okay, let's put this in a main function and run it just like any other go program with go run. First, I'm going to say hello. Great, now let's give it a science question. Nice. That looks good to me. We also have a web UI interface. After some initial setup, you can open up the web UI and choose your science agent from the menu. I'm going to say hello again. Why is the sky blue? In this event tab, you can see the events that are flowing through. Cool, let's move on. Now, what if we want our agent to talk about recent events that aren't in the LLM's training data? To do that, we have to give it access to Google search via tools. Think about it, a large language model is incredibly powerful with text or multimedia elements. But it can't natively browse the internet, query your database, send an email, or call an external API. Tools can augment your agents with these capabilities. ADK provides a structured mechanism for your agent to use these tools. The process generally looks like this. Your agent receives a user request. The LLM analyzes it, determines if an external action is needed, and decides which registered tool to use along with the arguments for that tool. The ADK framework then intercepts this function call from the LLM, executes the code or action you've defined for that tool, and finally, the tools result is sent back to the agent. Usually to the LLM again, so it can process the result and reformulate the final response to the user. ADK abstracts this away, providing a clean interface for defining tools and handling that entire execution loop for you. Go ADK provides three types of tools for your agents to use. Built-in tools like Google Search, third-party tools like the ones provided by MCP servers, or function tools. Let's talk about function tools. A function tool essentially wraps arbitrary go code and makes it available to the agent. If you're building a customer service agent to let customers ask about the status of their order, you can add a function tool in the tools method of your agent definition. Now, let's see how that function is defined. First, you define structs to represent the input and return values. Then a function with your custom Go logic. In this case, we just return the complete status for all orders. We then pass this function to the function tool function, which transforms it into a tool object for us. We provide a suitable description that the LLM will use to determine when it should call the tool. Let's chat about prompt quality. It's critical to give precise and explicit instructions to define the agent's purpose, its persona, its goals, and to provide guidance in how it should interact with the user and tools. The tool should also be described with great detail so that the LLM clearly understands its purpose and its arguments. With these basic steps, adding the dependency, defining tools, creating and configuring your agent, and calling the runner's run method, you can quickly get a functional agent up and running. It'll be capable of understanding natural language requests and performing actions through the tools you've defined. This forms the essential foundation for building more capable and complex agents in Go. Next, let's get into how we can implement more complex concepts. So far, we've only used a single agent, but we can have multiple agents collaborating together in a multi-agent scenario. Go ADK supports interoperability for tools via MCP and for agents via the agent-to-agent protocol. We'll talk more about these in future videos. For today, let's explore how to build multi-agent architectures using ADK's native functionality. A powerful pattern ADK enables is allowing one agent to use another agent as a tool. This agent tool concept lets you build hierarchical or collaborative systems where agents delegate tasks to others. Let's say your main agent needs a tool to create summaries of long text. You can define a summarizer agent like this. Then use the agent tool.new factory function to wrap it into a tool. In your root agent, pass in the summary tool on creation.

[5:58]The main agent can then call the summarizer agent to do a one-off summarization. For more prescriptive agent systems, ADK's workflow agents can orchestrate complex flows involving multiple agents. The sequential agent is the first of the workflow agents. It's simply a sequence of agents called one after another with the outputs of each agent being passed on to the next one. The parallel agent allows concurrent execution of each sub agent. For example, if you're building a research system, you might run multiple agents to find news for a given topic. The results can then be collected and summarized by a downstream agent. Similar to a sequential agent, the loop agent calls a chain of agents in sequence. However, it may run this chain multiple times until an exit condition is met. For example, you might have a story writing system that takes an initial draft and iteratively adds details, only exiting when a critique agent is satisfied with the final output. Now, this brings up an important question when designing agentic systems. How do you decide whether to use a single agent, multiple agents, or a workflow? A single agent is suitable when the task requires reasoning and dynamic tool use based on input, but the overall process isn't easily broken down into very distinct sub problems or domains. Similarly, a single agent is fine if there aren't too many tools at its disposal. So it'll be easy for it to figure out which one to use. For example, our science teacher agent from earlier was fine as a single agent system. Multiple agents enabled by ADK are ideal for complex problems that naturally decompose into smaller, more manageable subtasks. Or require different areas of expertise. For an e-commerce order processing system, you might use several agents. One to verify inventory levels, another to process the payment, and a third agent to coordinate shipping logistics. This approach offers modularity and can make the system easier to develop and maintain, although there might be some overhead in communication or latency. Choosing the right approach depends on the problem scope, required flexibility, and need for distinct areas of intelligence or capability. A key aspect for handling complex ongoing interactions is context and knowledge management. ADK provides comprehensive tools for managing this. The core concept here is the session. Each session represents a single ongoing conversation thread with a user. Sessions have key identifiers like a unique ID, an application name, and a user ID, helping you manage multiple conversations for different users and applications.

[8:29]Sessions also store the history, a shared state map, and tell you when the last event happened. These are stored as the sequence of events. Let's take a look at the Go definitions for session and state. The state is your agent's temporary scratchpad, a place to store data specific to this particular conversation. Let's see how we can specify the initial state by revisiting our science teacher example. We improve the agent by making the instruction generic, such that the teacher's topic can change depending on a state variable. Notice the curly brace placeholders accepting different subjects and audiences. When we initialize the session, we can specify the initial topic and audience. In our documentation and samples, you'll see examples of how to update state via callbacks, tools, and a special output key mechanism. Speaking of persistence, for knowledge that needs to survive beyond a single conversation, you need long-term memory. ADK addresses this with the memory service, which we'll cover in a future video. And that brings us to the end of our introduction to ADK Go. We've covered key concepts like session, state and events. We've also seen some examples of agents using tools and even calling other agents. By combining workflow orchestration, multi-agent collaboration, and robust state and memory management, ADK provides building blocks to create sophisticated AI agents for your most challenging problems. Start building today and check out ADK documentation and samples, available in Python, Java, and of course, Go. See you in the next one.