Building Enterprise AI Agents with ADK 2.0 and Managed Agents API
Introduction
AI agents are moving beyond simple chatbots. In real-world applications, an agent may need to reason, call tools, access data, follow business rules, pause for human approval, maintain state, and operate securely at enterprise scale.
Two important concepts in the Google agent ecosystem are:
- ADK 2.0 — focuses on building and orchestrating sophisticated agent workflows.
- Managed Agents API on Gemini Enterprise Agent Platform — focuses on running and managing enterprise agents with centralized infrastructure, security, and governance.
This blog explains both concepts in a simple, practical way.
Part 1: ADK 2.0
What is ADK?
ADK (Agent Development Kit) is a framework for building AI agents.
A simple mental model is:
React → Build user interfaces
Express → Build APIs
ADK → Build AI agents
An ADK agent can use:
- LLMs
- Tools
- State
- Other agents
- Routing
- Workflow logic
- Human-in-the-loop steps
Why ADK 2.0?
A basic AI agent might work like this:
User
↓
LLM
↓
Tool
↓
LLM
↓
Tool
↓
Response
The LLM may end up deciding almost everything.
For simple tasks this can work, but enterprise workflows often need more control.
ADK 2.0 introduces a stronger workflow-oriented approach where the application can explicitly control execution.
Think:
User
↓
Security Check
↓
Router
├── Order Agent
├── Refund Agent
└── Device Agent
↓
Tool
↓
Human Approval
↓
Action
The key idea is:
Use the LLM for reasoning and use workflow logic for predictable execution.
The 7 ADK 2.0 Concepts to Understand
1. Nodes — A Step
A node represents one unit of work in a workflow.
A node can represent:
- An agent
- A function
- A tool
- A security check
- A router
- A human approval step
Example:
Security Check
↓
Intent Detection
↓
Order Agent
↓
Get Order
↓
Human Approval
Each box is a node.
Remember:
Node = What should happen here?
2. Edges — Where to Go Next
An edge connects nodes.
Security
↓
Router
├──→ Order Agent
└──→ Refund Agent
An edge determines what happens after the current step.
Types include:
- Fixed paths
- Conditional paths
- Loops
Remember:
Edge = Where should execution go next?
3. State — What the Workflow Remembers
State contains information accumulated during an agent execution.
For example:
state = {
"userId": "U123",
"orderId": "1234",
"intent": "cancel_order",
"orderStatus": "SHIPPED",
"riskScore": 0.8,
"approvalRequired": True
}
Different workflow steps can read or update relevant state.
Remember:
State = What does the workflow know right now?
4. Routing — Which Path Should I Take?
Routing determines which branch of the workflow should execute.
For example:
Router
│
┌───────────┼───────────┐
↓ ↓ ↓
Order Refund Device
Agent Agent Agent
The LLM could identify the user's intent, while normal application logic determines the next route.
This makes business-critical execution more predictable.
Remember:
Routing = Which path should the workflow take?
5. Agents — Reasoning Components
An agent is where LLM-based reasoning happens.
For example:
Order Agent
↓
Understand request
↓
Reason about order
↓
Decide what information/action is needed
An agent can then use a tool to perform an operation.
Remember:
Agent = Reasoning
6. Tools — Perform Actions
Tools allow an agent to interact with external systems.
Examples:
getCustomer()
getOrder()
cancelOrder()
searchProducts()
sendEmail()
queryDatabase()
createTicket()
For example:
Order Agent
↓
getOrderDetails()
↓
Order API
↓
Order Status
Remember:
Agent = Decides what to do
Tool = Performs the action
7. HITL — Human-in-the-Loop
HITL means the workflow can pause and ask a human to make or approve a decision.
Example:
Agent
↓
Refund ₹50,000?
↓
YES
↓
PAUSE
↓
Human Approval
↓
Approved
↓
Refund API
This is useful for sensitive or high-impact operations.
Remember:
HITL = Human takes control when required.
Putting the 7 Concepts Together
A realistic workflow might look like:
User
↓
Security Node
↓
Router
↓
Order Agent
↓
Get Order Tool
↓
Risk Check
↓
Human Approval?
↙ ↘
YES NO
↓ ↓
Execute Tool Stop
↓
Done
Now map it:
| Concept | Example |
|---|---|
| Node | Security, Agent, Router, Tool, HITL |
| Edge | Connections between steps |
| State | Order ID, risk, approval status |
| Routing | Order vs Refund vs Device |
| Agent | LLM reasoning |
| Tool | API/database/action |
| HITL | Human approval |
ADK 2.0 + Antigravity + Vibecoding
You do not necessarily need to memorize the complete ADK API.
This is where Antigravity + vibecoding becomes useful.
You can describe the architecture in high-level terms:
Create an ADK 2.0 graph with a security check before the LLM, route requests based on intent, and pause for human approval for high-value transactions.
Antigravity can help translate that design into implementation.
However, coding agents can sometimes fall back to older ADK patterns when the prompt is ambiguous or when a long session causes earlier context to become less prominent.
The Agents CLI skills provide reference material that keeps the coding agent aligned with the intended API patterns.
A useful mental model is:
You
↓
High-level architecture
↓
Antigravity + ADK skills
↓
ADK 2.0 implementation
↓
Graph workflow
If the generated code starts using older patterns, explicitly remind the coding agent to use the ADK 2.0 API and reload the relevant skill context.
Agents CLI: Scaffolding and Development
The Agents CLI can help create and manage the project development workflow.
A typical project creation flow is:
agents-cli scaffold create my-agent --prototype --yes
cd my-agent
agents-cli install
What does scaffold mean?
Scaffolding means creating the initial project skeleton.
Instead of manually creating:
my-agent/
├── app/
├── tests/
├── pyproject.toml
├── uv.lock
├── Makefile
└── README.md
the CLI generates the starting structure.
What does agents-cli install do?
Inside the project:
agents-cli install
runs the project's dependency synchronization process using uv.
It installs the dependencies specified by the project's pyproject.toml and lock file.
The Makefile
A generated project may contain a Makefile.
It provides convenient shortcuts for common commands.
For example:
make install
make playground
make lint
make test
Instead of remembering the underlying commands, developers can use these consistent shortcuts.
Think:
Makefile = collection of project command shortcuts.
The app Object
A scaffolded ADK project has an app/agent.py file.
The module-level app object is the entry point used by the development and runtime tooling.
Conceptually:
app/agent.py
↓
app
↓
root_agent
↓
Model + Instructions + Tools
The important convention is:
app = App(
root_agent=root_agent,
name="app"
)
It should be available at the module level with the expected name app.
Testing the ADK Agent
There are several levels of testing.
1. Quick Smoke Test
agents-cli run "Approve expense for $45 from bob@company.com"
Useful for a quick one-off check.
2. Interactive Playground
agents-cli playground
This launches the local ADK Developer UI.
You can:
- Chat with the agent
- Inspect tool calls
- Inspect arguments
- Inspect results
- Inspect execution traces
The playground also supports rapid development because changes to the agent code can be picked up during development.
3. Linting
agents-cli lint
This checks code quality and can catch problems such as import and formatting issues.
Remember:
Lint checks the code structure; it does not prove that the AI workflow behaves correctly.
Testing an Ambient Agent
An ambient agent can be triggered by an external event rather than a person typing directly into the playground.
For example:
Expense System
↓
Pub/Sub
↓
ADK Trigger
↓
Expense Agent
During local development, you can simulate the Pub/Sub request with curl.
The idea is:
Real Pub/Sub message
↓
Production trigger
curl request
↓
Local simulation
The lesson's example uses a subscription such as test-sub and maps that to the ADK session/user ID for inspection.
Evaluation: Testing Agent Behavior
Running the agent once is not enough.
AI agents can produce the correct final response while taking the wrong execution path.
For example:
$45 expense
Expected:
No LLM call
→ Auto approve
But the agent might do:
$45 expense
→ LLM call
→ Approve
The final answer looks correct, but the workflow is not behaving as intended.
This is why agent evaluation looks at the execution behavior and trace.
Evaluation Dataset
A dataset contains scenarios to test.
For example:
1. Low-value expense
2. High-value expense
3. Expense containing PII
4. Prompt-injection attempt
5. Human rejection
A useful evaluation dataset tests both normal and problematic situations.
Evaluation Configuration
The evaluation configuration describes how the agent should be judged.
For example:
metrics:
- name: routing_correctness
description: >
Under $100 must auto-approve with no LLM call.
$100 or more must route to LLM review
and then pause for human approval.
score_range: [1, 5]
The dataset answers:
What should I test?
The metric configuration answers:
How should I judge it?
Generate vs Grade
There are two important commands:
agents-cli eval generate
agents-cli eval grade
generate
Runs the test scenarios and captures execution traces.
Dataset
↓
Run agent
↓
Execution traces
grade
Scores those existing traces against your evaluation metrics.
Execution traces
↓
Evaluation criteria
↓
Scores
If you change your agent code, run both:
agents-cli eval generate && agents-cli eval grade
Why?
Because grade alone only re-scores the existing traces. It does not execute your newly changed code.
A Complete ADK Development Loop
The complete workflow looks like:
Scaffold
↓
Install
↓
Build
↓
Lint
↓
Run / Playground
↓
Evaluate
↓
Fix
↓
Evaluate again
↓
Deploy
This is the local ADK development loop.
Part 2: Managed Agents API
ADK focuses heavily on building the agent workflow.
The Managed Agents API focuses on running and managing enterprise agents in a managed environment.
Think:
ADK 2.0
↓
Build sophisticated agent workflows
Managed Agents API
↓
Run and manage enterprise agents
↓
Security + Governance + Operations
Why Use a Managed Agent?
A simple chatbot may only need:
User → LLM → Response
A real enterprise task may need:
Request
↓
Reasoning
↓
Company Data
↓
Tools
↓
Business Rules
↓
Actions
↓
State
↓
Audit / Security
At enterprise scale, manually managing all of these agents can create operational and security problems.
Control Plane vs Data Plane
This is the most important concept in the Managed Agents API chapter.
The platform separates management from execution.
Gemini Enterprise
Agent Platform
│
┌─────────┴─────────┐
↓ ↓
CONTROL PLANE DATA PLANE
↓ ↓
Agents API Interactions API
↓ ↓
Define / manage Run / interact
agents agents
Control Plane
The Agents API is used to manage the agent.
Think:
What agents exist and how are they configured?
Data Plane
The Interactions API is used to interact with the running agent.
Think:
Run the agent and perform the task.
The simple rule:
Agents API → manage the agent
Interactions API → interact with the agent
Managed Agent Components
A managed agent can be thought of as a combination of:
Agent Definition
+
Sandboxed Environment
+
Mounted Data
+
Tools
+
Skills
+
MCP Servers
1. Agent Definition
The definition describes the agent's identity, instructions, configuration and capabilities.
Think:
Agent Definition = Blueprint
2. Sandboxed Environment
The agent executes inside an isolated environment with controlled resources.
The goal is to prevent the agent from having unrestricted access to your environment.
Think:
Agent
↓
Sandbox
↓
Controlled resources
3. Mounted Data
Agents often need access to business data.
Mounted data provides controlled access to the information required for the task.
Think:
Company Data
↓
Controlled Mount
↓
Agent Environment
4. Tools
Tools allow the agent to perform actions.
Examples:
Query database
Call API
Search inventory
Update product
Generate report
5. Skills
Skills provide reusable capabilities or instructions that extend what the agent can do.
For example:
Retail Agent
├── Sales analysis skill
├── Inventory analysis skill
└── Product recommendation skill
6. MCP Servers
MCP provides a standardized way for agents to connect to external tools, data and services.
Conceptually:
Agent
↓
MCP
↓
External capability
Running Managed Agents
The course introduces four important interaction capabilities:
Background interactions
Streamed reason-act loop
Resilient typed results
Multi-turn state
Background Interactions
Some agent tasks take time.
For example:
Analyze thousands of products
↓
Query data
↓
Run multiple operations
↓
Generate recommendation
Instead of keeping the caller waiting synchronously, background interactions allow longer-running work to proceed asynchronously.
Think:
Start the task → let it work → retrieve/follow the result.
Streamed Reason-Act Loop
Agents often operate as:
Reason
↓
Act
↓
Observe result
↓
Reason again
↓
Act again
↓
Final result
For example:
Analyze sales
↓
Search sales data
↓
Observe results
↓
Check inventory
↓
Observe results
↓
Generate recommendation
Streaming allows progress/events to be delivered as the interaction continues rather than waiting only for the final result.
Resilient Typed Results
Typed results
Instead of returning only free-form text:
"Phone X should be promoted."
an application can work with structured results such as:
{
"product": "Phone X",
"recommendation": "Promote",
"reason": "High inventory and declining sales"
}
Structured results are easier for applications to consume.
Resilience
Enterprise systems must also handle interruptions and failures reliably.
The goal is not to assume:
Request → Response → Everything works
but to support robust execution.
Multi-Turn State
State allows an agent to maintain continuity across interactions.
Example:
Turn 1
User:
Analyze product sales in India.
Turn 2
User:
Now compare that with last quarter.
The second request can build on the previous interaction through persisted state.
Think:
Turn 1
↓
State
↓
Turn 2
↓
Same agent/session
Enterprise Security
Managed agents are designed for organizations that may have many agents.
Without centralized management:
Team A → Agent 1
Team B → Agent 2
Team C → Agent 3
Team D → Agent 4
Each team might configure security and infrastructure differently.
This can lead to configuration drift.
What is Configuration Drift?
Suppose company policy requires:
✓ Approved identity
✓ Authorized data access
✓ Controlled networking
✓ Auditing
✓ Security controls
One manually deployed agent might accidentally have:
✗ Excessive IAM permissions
✗ Too much data access
✗ Different network configuration
✗ Missing audit controls
That difference is configuration drift.
Managed platforms aim to provide more centralized control and governance.
Zero-Trust AI
Zero trust means:
Don't automatically trust an agent just because it is inside the organization.
Access should be explicitly controlled.
Conceptually:
Agent
↓
Who are you?
↓
What are you allowed to access?
↓
Which resource?
↓
Is this action allowed?
↓
Allow / Deny
This is why IAM and networking concepts such as VPC and DNS are relevant to the course.
ADK 2.0 vs Managed Agents API
The easiest comparison is:
| Area | ADK 2.0 | Managed Agents API |
|---|---|---|
| Primary focus | Build agent workflows | Run/manage enterprise agents |
| Graph workflows | Core concept | Agent runtime context |
| Nodes / edges | Important | Less central |
| Routing | Important | Runtime interaction |
| Tools | Yes | Yes |
| State | Yes | Multi-turn state |
| HITL | Workflow capability | Managed interaction context |
| Sandbox | Application/workflow concern | Managed environment |
| Enterprise governance | Can be implemented | Major platform focus |
| Control plane | Development/application | Agents API |
| Data plane | Agent execution | Interactions API |
| Security | Build-time/runtime design | Centralized enterprise security |
| Operations | Developer focused | Enterprise focused |
Final Mental Model
The two chapters fit together like this:
AI AGENT SYSTEM
│
┌────────────┴────────────┐
↓ ↓
BUILD IT OPERATE IT
↓ ↓
ADK 2.0 Managed Agents API
│ │
↓ ↓
Workflows Enterprise Runtime
│ │
┌─────┼─────┐ ┌─────┼─────┐
↓ ↓ ↓ ↓ ↓ ↓
Nodes State Tools Security Data Governance
│ │ │ │ │ │
└─────┼─────┘ └─────┼─────┘
↓ ↓
Routing Operations
↓ ↓
HITL Enterprise
│ Scale
└──────────┬──────────────┘
↓
Production AI Agent
The 12 things worth remembering
- ADK = framework for building AI agents.
- ADK 2.0 = stronger workflow/graph-oriented agent development.
- Node = one step in a workflow.
- Edge = connection/path between steps.
- State = information maintained during execution.
- Routing = deciding which workflow path to take.
- Agent = LLM-based reasoning.
- Tool = performs an external action.
- HITL = human approval/intervention.
- Managed Agents API = managed enterprise agent runtime.
- Agents API = control plane; Interactions API = data plane.
- Enterprise focus = isolation, security, governance, auditability, state, resilience and controlled operations.
One final sentence
ADK 2.0 helps you design and build the agent's brain and workflow; the Managed Agents API helps you run that kind of agent as a controlled, secure, and scalable enterprise service.
Top comments (0)