The Agent Development Kit
Google's Agent Development Kit (ADK) provides tools for building agents, managing workflow execution, and tracking events and state changes. Developers must connect agents to trusted data sources and inspect execution traces to distinguish model responses, tool calls, and state updates. In ADK, agents define behavior, runners manage execution and sessions, and tools perform external operations. Execution produces events that applications can inspect or process. Developers must configure dependencies, session state, tool permissions, and error handling, then test the workflow to verify correct request processing and state updates.
Trace A retrieves the current inventory and inspection records, then responds: "Three K-17 kits are available, but pickup is not confirmed." Trace B retrieves the inventory record but uses inspection state from the previous day to generate the same response.
Which execution provides stronger evidence that the response reflects the current inventory and inspection status?
An Agent Development Kit (ADK) application's response is easier to verify when its execution trace shows the tool operations, events, and state changes used to produce it.
Two identical answers
Compare the relevant operations and state changes in these two execution traces:
Trace A:
lookup_inventory(kit_id='K-17')returnsavailable_units=3.lookup_inspection(kit_id='K-17')returnsinspection_status='pending'andpickup_confirmed=false. The application generates its response using both retrieved records.Trace B:
lookup_inventory(kit_id='K-17')returnsavailable_units=3. No inspection lookup occurs during this invocation. The application generates its response using aninspection_resultretained from an earlier invocation.
Both responses match the current facts, but only Trace A demonstrates that the application retrieved inventory and inspection data during the current invocation. A test that checks only the final response would also pass Trace B, leaving the stale-state defect undetected until the inspection status changes.
In ADK, an event records part of an agent's execution and may contain model content, tool-call information, or state updates. Inspecting events helps verify which operations actually ran, what they returned, and how their results contributed to the final response.
Agent, runner, tools
The responsibility split used here is: an agent defines behavior; a runner coordinates invocation using configured services; a tool executes an application operation. Agent logic emits events reporting responses, tool requests, or state changes; the runner processes associated actions and forwards the events. FunctionTool wraps a user-defined Python function. Agent configuration examples show models, instructions, tools, and child agents. These references support the conceptual responsibilities, but do not establish compatible dependencies or exact interfaces for a selected release. That release-specific verification remains unresolved.
For the equipment assistant, the two read operations have deliberately narrow contracts:
def lookup_inventory(kit_id: str) -> dict:"""Read current stock for the specified equipment kit."""if kit_id != 'K-17':raise ValueError('Unknown kit')return {'kit_id': kit_id, 'available_units': 3}def lookup_inspection(kit_id: str) -> dict:"""Read inspection and pickup confirmation for the specified kit."""if kit_id != 'K-17':raise ValueError('Unknown kit')return {'kit_id': kit_id,'inspection_status': 'pending','pickup_confirmed': False,}
Lines 1–5: Read inventory and reject an unsupported identifier rather than manufacturing a stock record.
Lines 8–16: Read inspection and pickup separately. Inspection status and pickup confirmation are distinct fields; neither follows from stock quantity.
Configure the LLM-backed agent with these functions and an explicit model identifier supplied through local configuration. Its instruction requires fresh reads from both tools before answering a collection request, preserves pending inspection and unconfirmed pickup, and prohibits treating a read as a reservation.
As established in chapter 2, a model-requested function call is an application operation, not an operation the model executes. Here, inspect ADK’s events to connect that request to the Python tool execution, returned observation, and subsequent response.
A model-requested function call is still a request for execution. ADK supplies coordination; your functions supply the operation and its semantics.
Run it locally
The ...