Callbacks: code around the loop

Your code

PretendModel

before_tool_callback

The tool

after_tool_callback

before_tool runs first and prints. It returns nothing, so the call goes ahead.

after_tool is handed the tool's response.

The guarded agent's model asks for refund with an amount of 500.

guard sees a refund over 100 and returns a refusal instead of nothing.

That dict becomes the tool's result. refund never runs.

The model reads the refusal and explains it.

Support desk agent: build it end to end

Customer

InMemoryRunner

support

billing

lookup_order

needs_a_person

refund

session.state

The runner hands the message to support, in a session seeded with the customer's name.

support calls lookup_order, which also writes last_order into state.

Same session, so state already holds last_order from turn one.

support calls transfer_to_agent. That empty result is the handover itself: billing takes the turn.

billing asks for refund with 500 as the amount. The callback runs before the tool does.

Over 100, and nobody has approved it, so the callback returns a refusal. That becomes the tool's result, and refund never runs.

billing explains instead of erroring. State holds only the name and the order, because no money moved.

Workflow: which shape to use

START

draft

shout

polish

The route starts at draft, which replies.

shout is handed that reply and upper-cases it. It prints nothing, and no model was asked.

polish gets shout's result as its input and replies.

LoopAgent: doing it again until it is right

writer

good_enough

Nothing said stop, and five passes are allowed, so the loop runs writer again.

Pass three. This time the model calls good_enough, which sets escalate on the actions.

writer answers the tool's result, and the escalation ends the loop after three passes rather than five.

Memory service: memory across conversations

listener

recaller

Session service

Memory service

The first conversation runs in its own session: I prefer email over phone.

Nothing is remembered on its own. Your code decides this session is worth keeping and adds it.

A brand new session asks: How should we contact you?

The recaller calls load_memory, and the keyword search finds the old conversation.

Google ADK overview

Runner and sessions: running an agent

Session

A message with role user goes to run_async, in a session created a moment before.

The agent asks the model, which replies with a request for lookup_order. That is an event.

ADK runs the function and puts its result into the history as another event.

The model sees the result and answers in words.

is_final_response() marks the answer, and your loop keeps its text.

SequentialAgent: steps in a fixed order

The sequence runs draft first, because it is first in the list. Nothing chose that at runtime.

output_key saves that reply in state under draft.

polish runs next. Before its model sees the instruction, ADK fills {draft} in from state.

polish's reply is saved under final, ready for whatever comes next.

ToolContext: tools that see the session

remember_name

The model asks for remember_name and fills in name. It never sees tool_context, so it cannot fill that in.

ADK passes a ToolContext in, because the parameter is typed as one.

The tool writes state["customer"]. The change travels on the event's actions before anything is saved.

The runner saves it on the session, where the next turn of this conversation can read it.

Sub agents: handing work to another agent

triage

triage reads the message. Its model calls transfer_to_agent with billing as the agent's name.

The handover travels on the event's actions.

billing answers the customer itself. A transfer is a handover, not a question.

ParallelAgent: two things at once

account

payments

summarise

The parallel group starts both lookups together. Neither can see the other's work.

Each one saves its reply under its own key. Run on its own, as checks, the same pair printed this.

Only when both have finished does the sequence run summarise, whose instruction reads both keys from state.

overview

install and setup

python functions

tool declaration

a stand-in model

runner and sessions

events

function tools

tool return values

multiple tools

ToolContext

built-in tools

instructions and state

output_schema

callbacks

max_llm_calls

sub agents

SequentialAgent

ParallelAgent

LoopAgent

Workflow

state

state prefixes

memory service

adk web, run, server

Gemini models

safety and guardrails

the support desk

adk web, adk run and api_server

adk run

adk web

adk api_server

my_agent/

Runner

root_agent

session service

The command looks for an agent folder beside it: agent.py with a root_agent in it.

It starts the same runner your scripts have been starting since lesson 5.

The runner drives root_agent, and every event it yields is a row in the browser's tree.

Sessions live in memory, so they are gone when you stop the command. That is the part to change first in production.

The agent loop

Tools

Shaping what it does

More than one agent

What it remembers

Running it for real

Safety and the support desk

Build a support agent with Google's Agent Development Kit: tools it chooses between, sub agents it hands work to, workflow agents that run steps in a fixed order, state that survives a conversation, and callbacks that watch every step. Every snippet was run against the real library, and a twenty line stand-in model keeps every lesson fast and repeatable.

The agent loop quiz

You call run_async with a session id you never created. What goes wrong?