Open Agents

The latest release of the Google Agent Development Kit, version 1.12.0, has landed, and with it comes a feature that significantly changes the agent authoring workflow: Agent Config. Until now, building an ADK agent has been an entirely code-first, Python-centric experience. With Agent Config, Google is introducing a declarative, YAML-based approach to defining agent structure and behavior.

The Core Shift: From Imperative Python to Declarative YAML

The fundamental change is moving the "scaffolding" of an agent from Python code into a YAML file. Instead of defining an agent class and instantiating it, you now describe its properties.

A minimal agent definition looks like this:

# root_agent.yaml
name: assistant_agent
model: gemini-1.5-flash
description: A helper agent that can answer users' questions.
instruction: You are an agent to help answer users' various questions.

This is a clean, readable, and self-documenting way to define an agent's identity and core instructions. For anyone familiar with infrastructure-as-code (like Terraform or Kubernetes configs), this pattern will feel right at home.

The Practical Workflow

Getting started is straightforward. The ADK CLI now includes a new type flag for scaffolding a config-based project:

# 1. Create the project structure
adk create --type=config my_agent

# This generates my_agent/ with root_agent.yaml and a .env file

After configuring your API keys in the .env file, you edit root_agent.yaml to define your agent. To run it, the existing ADK commands work as expected, now loading their context from the YAML file in the current directory:

cd my_agent/

# 2. Run the agent
adk web         # Launch the web UI
adk run         # Run in the terminal
adk api_server  # Expose as a service

This significantly lowers the barrier to entry for simple agents and makes rapid prototyping much faster.

The Real Power: Composition and Hierarchy

The true value of a declarative approach becomes apparent when building complex, multi-component agents. Agent Config provides clean primitives for composition.

1. Integrating Tools: Connecting built-in or custom tools is now a matter of adding them to a tools list. Here’s an agent that can use Google Search:

# search_agent.yaml
name: search_agent
model: gemini-1.5-flash
instruction: Perform Google search queries and answer questions about the results.
tools:
  - name: google_search # A built-in ADK tool

2. Orchestrating Sub-Agents: More powerfully, you can define hierarchical agent systems where a root agent delegates tasks to specialized sub-agents. Each sub-agent is defined in its own YAML file, promoting modularity.

# root_agent.yaml
name: root_agent
model: gemini-1.5-flash
instruction: |
  You are a learning assistant. 
  Delegate coding questions to the code_tutor_agent and math questions to the math_tutor_agent.
sub_agents:
  - config_path: code_tutor_agent.yaml
  - config_path: math_tutor_agent.yaml

This is a massive improvement for readability and maintainability over wiring up agent dependencies in Python code. It allows you to reason about your agent architecture at a higher level of abstraction.

A Reality Check: What Agent Config Doesn't Solve

While Agent Config is an excellent step forward for agent definition, it's crucial to understand its boundaries. The two hardest parts of building sophisticated agents remain largely untouched:

1. Tool Development is Still Core Engineering. Agent Config simplifies connecting a tool, but not building it. The real business logic—querying a database, calling a proprietary API, performing a complex calculation—still needs to be implemented in Python.

Consider this example from the docs:

tools:
  - name: my_llm_module.check_prime

The my_llm_module.check_prime function is where the actual work happens. The YAML is just the glue. The complexity of building, testing, and maintaining these tools—the very heart of any capable agent—is still a code-intensive engineering task.

2. The Deployment Hurdle is Still There. You've defined your agent in a clean YAML file and implemented your custom tools in Python. Now what? Getting it into production is the same challenge it's always been. You still need to:

Containerize the application.
Set up a CI/CD pipeline.
Manage infrastructure on a platform like Cloud Run or Agent Engine.
Handle secrets, scaling, logging, and monitoring.

The adk api_server provides an endpoint, but building a robust, production-ready service around it is a significant DevOps and infrastructure effort.

Bridging the Gap from Definition to Production

Agent Config elegantly solves the problem of agent definition. But for those of us building real products, the two biggest bottlenecks remain tool implementation and production deployment.

This is precisely the gap we're tackling with Open Agents. Our platform is designed for builders who recognize that a defined agent is only the first step. We abstract away the undifferentiated heavy lifting of deployment and channel integration, letting you focus on the agent's core value.

With Open Agents, you move beyond local execution:

No-Code to Low-Code Tooling: Integrate with common services or add your own business logic without writing boilerplate for every function.
Instant Deployment: Go from a tested agent to a production-ready endpoint available via API, WhatsApp, or Telegram with a single click. We handle the containers, scaling, and infrastructure so you don't have to.

In short, Agent Config is a welcome evolution for the ADK ecosystem, making agent authoring more structured and accessible. It's a tool every ADK developer should adopt. But when you're ready to move past adk run and deliver your agent to real users without the DevOps overhead, a platform built for deployment is the logical next step.

For more information, refer to the official ADK documentation:

Agent Config Syntax Reference: https://google.github.io/adk-docs/api-reference/agentconfig/
Official Agent Config Guide: https://google.github.io/adk-docs/agents/config/