Building AI Agents with Google ADK

AI agents are moving beyond simple chat interfaces. With frameworks like Google’s Agent Development Kit (ADK) and Azure AI Foundry, we can build agents that reason, use tools, and take actions on behalf of users.

Why agents matter

Traditional LLM interactions are stateless, you ask a question, get an answer. Agents go further:

  • Tool use: agents can call APIs, query databases, run code
  • Multi-step reasoning: breaking complex tasks into sub-tasks
  • Memory: maintaining context across interactions
  • Orchestration: coordinating multiple agents for different responsibilities

Getting started with Google ADK

Google ADK provides a structured way to define agents with:

  1. Agent definition: what the agent does and its available tools
  2. Tool declarations: functions the agent can invoke
  3. Session management: maintaining conversation state
  4. Evaluation: testing agent responses against expected outcomes
from google.adk.agents import Agent
from google.adk.tools import FunctionTool
def search_docs(query: str) -> str:
"""Search internal documentation."""
# implementation here
return results
agent = Agent(
name="docs_assistant",
model="gemini-2.0-flash",
tools=[FunctionTool(search_docs)],
instruction="You help developers find information in our docs."
)

💬 Interview angle: “How would you design a production AI agent?”: this pattern is your answer. Separate the agent definition from tool implementations, use typed function signatures (the model uses docstrings to decide when to call each tool), and evaluate with real-world scenarios. Observability matters from day one: log tool calls, token usage, and latency.

Pairing with Azure AI Foundry

Azure AI Foundry complements this with:

  • Model catalogue: access to multiple LLMs (OpenAI, Mistral, Llama)
  • Prompt flow: visual orchestration of agent workflows
  • Evaluation tools: built-in metrics for quality, groundedness, relevance
  • Enterprise security: managed identity, private endpoints, content safety

Lessons from building

  1. Start with clear tool boundaries: each tool should do one thing well
  2. Test with real scenarios: synthetic tests miss edge cases agents will hit
  3. Monitor token usage: multi-step reasoning can burn through tokens quickly
  4. Keep instructions concise: agents perform better with focused system prompts

Common pitfalls

  • Vague tool descriptions: the model uses your function docstring to decide when to call a tool. Ambiguous descriptions lead to incorrect tool selection or tools being ignored entirely
  • Unbounded reasoning loops: agents can get stuck retrying failed tool calls. Always set maximum iteration limits
  • Prompt injection via tool results: if a tool returns user-controlled content, a malicious input can embed new instructions that redirect the agent. Sanitise tool outputs
  • Multi-agent complexity too early: start with a single, well-scoped agent. Add orchestration only when the single-agent approach demonstrably breaks down
  • Ignoring the token budget: multi-step reasoning accumulates context fast. Long histories or large tool responses can hit context limits, causing truncation or unexpected behaviour

What’s next

The agent space is moving fast. Multi-agent systems, where specialised agents collaborate on complex tasks, are becoming practical with tools like ADK and AI Foundry.


Key takeaways

  • Agents = LLMs + tools + state + reasoning: they can take actions, not just answer questions
  • Google ADK provides the structure (agent definition, tool declarations, session management); you focus on the domain logic
  • Azure AI Foundry adds enterprise needs: multi-model access, evaluation pipelines, content safety, and managed identity integration
  • Start simple: one agent, clear and well-documented tools, test with real-world scenarios before scaling to multi-agent
  • Watch your token budget: multi-step reasoning accumulates fast, and costs follow

Happy Coding! 🎉