Google Uses BigQuery Telemetry to Fix Agent Crashes and Cut Token Waste
Ai4
Replacing volatile in-memory runners with persistent database sessions and BigQuery telemetry prevents catastrophic context loss during runtime crashes while enabling secondary agents to audit reasoning trajectories.
## Background
Published on YouTube by Ai4 on August 14, 2026, this talk features Jason Davenport, Area Technical Lead at Google. The presentation details how to engineer durable, intelligent agents using the Google Agent Development Kit (ADK), showing developers how to implement telemetry pipelines into BigQuery and manage multi-turn session state across infrastructure restarts.
## TL;DR
Jason Davenport explores the engineering requirements for transitioning from fragile, stateless LLM scripts to production-grade, durable AI agents. Contrasting a minimal in-memory runner with a telemetry-instrumented implementation using Google ADK, he demonstrates how persistent session storage prevents repetitive context loss and enables crash recovery during data engineering workflows. The session shows how streaming full execution trajectories—including prompt traces, thinking tokens, and generated SQL queries—into BigQuery turns opaque model reasoning into an auditable knowledge loop. Davenport concludes by urging teams to treat telemetry harvesting and database-backed session management as fundamental architectural pillars rather than afterthoughts.
## Atmosphere & style
The presentation carries the pragmatic, grounded tone of an enterprise architecture briefing tailored for engineers moving beyond superficial AI demos into production operations. Davenport speaks with candid clarity, wryly pointing out the absurdity of stateless agents that immediately forget user names while burning costly tokens on redundant loops. Watching the dual-pane UI demonstration feels like peering directly into the diagnostic engine room of autonomous agents, replacing speculative AI mysticism with the reassuring familiarity of structured trace logs, database queries, and distributed systems design.
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=4s) An intelligent, durable agent architecture relies on five core components: instructions, progressive skills, tools, the foundation model, and memory.
- [00:04](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=4s) Memory serves as the persistent glue that prevents agents from resetting to a stateless loop across multi-turn interactions.
- [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) Production agent challenges like API rate limits (429s), tool crashes (500s), and token bloat necessitate restartability, state management, and observability.
- [06:16](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=376s) The Google Agent Development Kit (ADK) provides native telemetry integrations that stream prompts, model responses, span IDs, and execution metadata directly into BigQuery.
- [08:30](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=510s) Persistent session management prevents redundant tool calls and database schema re-scans across multi-turn conversations.
- [11:40](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=700s) Logging tool trajectories and raw generated SQL to analytical sinks allows developers to identify agent looping behavior and refine skill directives.
- [14:25](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=865s) Managed remote Model Context Protocol (MCP) endpoints handle authentication and connectivity natively, eliminating the need for local sidecar containers.
- [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) Analyzing intermediate thinking tokens often provides more valuable diagnostic insights into agent logic than evaluating final output responses.
- [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) Operational telemetry enables a virtuous development cycle where secondary evaluation agents inspect logged data to continuously refine agent capabilities.
- [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) Ephemeral in-memory session stores fail during container restarts, requiring external database layers for production-grade state durability.
- [18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) Harvesting agent interaction logs into centralized data warehouses establishes the foundational dataset needed for persistent memory architectures and offline learning systems.
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=4s) The Anatomy of an Intelligent Agent
Jason Davenport, Area Technical Lead at Google, introduces the session’s core objective: moving past building "dumb agents" and instead engineering truly intelligent, durable agents through robust telemetry and session management. While the developer community spent much of the prior eighteen months obsessing over basic tool usage, the modern focus shifts toward analyzing agent behavior over time and constructing technical architectures that persist across interactions. Davenport breaks down a foundational agent into five core anatomical components: instructions (which establish the agent's persona, domain directives, and operating parameters, whether acting as a travel assistant or a data engineering agent), skills (curated organizational knowledge and processes progressively disclosed to the agent), tools (external interfaces such as MCP servers or custom APIs connecting to Jira or GitHub), the underlying model, and memory.
While instructions, skills, tools, and the model represent the directive, compute, and functional layers, memory acts as the additive glue that transforms a system from a purely stateless loop into a durable process capable of accomplishing long-term goals without forgetting critical context over time.
```mermaid
flowchart TD
accTitle: Anatomy of an Intelligent Agent
accDescr: Five core components comprising an intelligent agent architecture.
- **Five core pillars of an agent**:
- **Instructions & Persona**: Tailors how the model approaches problems and identifies parameters (e.g., travel planner vs. data engineer).
- **Progressive Skills**: Layered capabilities enabling an agent to load high-level engineering workflows and disclose specialized sub-skills as needed.
- **Tools**: Protocol connections (e.g., Model Context Protocol / MCP) enabling live interactions with external systems like Jira and GitHub.
- **Model**: The intelligence and inference layer powering decision-making.
- **Memory**: The temporal substrate that keeps context additive rather than stateless.
---
[03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) Failure Modes, Tokenomics, and Core Requirements
Deploying agents into real-world production environments quickly exposes developers to standard application failures compounded by non-deterministic agent quirks. Agents inevitably run into network outages, 500 server errors on tool endpoints, rate-limiting `429` API errors from model providers, and unexpected reasoning trajectories. When an application crashes, an agent without persistent state resets to square one, frustrating users with repetitive questions: "Hi, like what's your name?" / "Oh, my name is Jason." / "And you just asked me that three turns ago. Please don't do that again."
Beyond runtime crashes, Davenport highlights "tokenomics" as a defining engineering concern. Organizations routinely waste thousands of dollars due to inefficiently managed context windows and redundant multi-turn queries. To counteract these pitfalls, modern agent architectures require three non-negotiable capabilities: restartability (allowing an agent to pick up a task seamlessly after an interruption, much like a person pausing work to answer a question), state management across multiple layers, and comprehensive observability and tracing. Davenport urges developers to never let tokens go to waste: "Harvest them and start to analyze them for behaviors that you can, you know, change and improve."
- **Common Production Hazards**:
- Unhandled tool exceptions (HTTP `500`s) and network dropouts.
- Model rate limits (HTTP `429`s).
- Looping or unexpected decision paths in agent trajectories.
- Costly context bloat from unmanaged conversation histories.
- **Essential Agent Capabilities**:
- **Restartability**: Resuming long-running operations across interruptions without repeating prior steps.
- **State Management**: Preserving conversational context and variables outside volatile memory.
- **Observability & Tracing**: Capturing full trajectories, prompts, and tool payloads to audit agent logic and optimize prompt efficiency.
---
[06:16](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=376s) Implementing Telemetry with the Google Agent Development Kit (ADK)
Davenport transitions from architectural principles to concrete code using the Google Agent Development Kit (ADK)—Google's opinionated framework for agent construction. Rather than demonstrating a conventional standalone agent, the demo contrasts two distinct implementations side-by-side: a bare-bones "base agent" relying solely on an in-memory session runner with no external telemetry, and a telemetry-enabled agent instrumented with session stores and automated logging sinks.
The base agent uses a Gemini Flash-Lite model with minimal imports and an ephemeral in-memory session service, meaning state vanishes whenever its execution container restarts. In contrast, the telemetry-enabled agent integrates ADK's native BigQuery logger and custom telemetry handlers. This setup captures incoming user prompts, model responses, span IDs, and application-specific metadata, exporting structured event streams directly into BigQuery for post-hoc analysis and real-time session continuity.
```mermaid
flowchart LR
accTitle: ADK Telemetry and Session Architecture
accDescr: Flow comparing stateless runner execution versus telemetry-backed session logging.
subgraph BaseAgent ["Stateless Base Agent"]
B1["User Prompt"] --> B2["Runner"]
B2 <--> B3["In-Memory State\n(Volatile)"]
B2 --> B4["Model Response"]
end
- **Base Agent Configuration**: Employs Gemini Flash-Lite with minimal setup and ephemeral in-memory storage; drops context on container restart.
- **ADK BigQuery Logger**: Automatically streams prompts, completions, span IDs, and execution metadata into BigQuery tables without manual instrumentation boilerplate.
- **Custom Telemetry Extensions**: Supports capturing custom application headers, user identifiers, and domain-specific attributes alongside standard model payloads.
---
[08:30](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=510s) Live Demo: Base Agent vs. Telemetry-Enabled Analytics Agent
To illustrate the behavioral difference, Davenport demonstrates a dual-pane web UI contrasting the base analytics agent on the left against the telemetry-enabled agent on the right. Both agents are tasked with analyzing an e-commerce sales dataset within a Google Cloud project named `Davenport Boutique`. When given the prompt to inspect schemas, the stateless agent treats the query as a blank slate: it invokes an MCP server to list BigQuery datasets, inspects related tables, and deduces that "sales" and "orders" are synonyms before returning a schema breakdown.
The telemetry-enabled agent on the right executes the required tool calls but anchors them to a persistent session. When multi-turn interactions occur, the telemetry agent leverages historical context stored across previous executions to recognize previously discovered database objects, eliminating redundant schema scans. Furthermore, the telemetry pipeline wraps every invocation in distinct span IDs, turning opaque LLM reasoning into structured trajectories. Davenport reflects on historical software practices, remarking that distributed tracing used to be an expensive aspiration only activated during outages, whereas modern agent trajectories make full lifecycle logging standard practice.
---
[11:40](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=700s) Auditing Agent Trajectories, Tool Calls, and SQL Generation
Davenport opens the BigQuery telemetry viewer to examine the raw event streams generated by the agent. The logs capture three distinct event categories: user prompts, agent responses, and tool trajectories. Inspecting tool trajectories is critical because agents frequently exhibit looping behaviors when querying tools via MCP, repeatedly querying an endpoint when searching for elusive schema definitions or parameters.
```mermaid
flowchart TD
accTitle: ADK Harness and MCP Tool Call Loop
accDescr: Interaction loop between the Foundation Model, ADK Harness, MCP Server, and Telemetry Store.
subgraph TelemetrySink ["Telemetry Data Store"]
BQ[("BigQuery Session\n& Trace Logs")]
end
M -->|Proposes Tool Call| H
H -->|Executes Call| MCP
MCP -->|Returns Result/Schema| H
H -->|Passes Output| M
H -.->|Logs Span, SQL & Trajectory| BQ
```
The telemetry record reveals the exact mechanism: the foundation model informs the ADK harness which tool to call along with target parameters, and the harness executes the call against the MCP server before passing the output back to the model. In the BigQuery console, developers can audit the precise SQL statements generated by the agent—such as status counts and aggregation queries. Storing these trajectories inside a scalable data warehouse like BigQuery provides an inexpensive audit trail that allows engineering teams to refine MCP skill directives, enforce schema constraints using open knowledge formats, and debug faulty model reasoning loops.
- **Logged Trajectory Entities**:
- **Prompt & Response Records**: Complete text records for both user prompts and model completions.
- **Tool Trajectories**: Parameter payloads, targeted tool names, and raw execution outputs.
- **Generated SQL Auditing**: Exact queries submitted to BigQuery, enabling teams to catch unoptimized queries or incorrect aggregations.
- **Trace & Span Identifiers**: Unique keys stitching multi-step autonomous loops into cohesive sessions.
---
[14:25](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=865s) Session Recovery and Remote MCP Server Architecture
Demonstrating system resilience, Davenport restarts the application's front-end interface mid-interaction to show how each agent recovers. When asked a follow-up prompt to generate analytical SQL queries based on the previously discovered schemas, the base agent fails to retrieve earlier context, forcing the developer to re-explain table structures. The telemetry agent immediately pulls previous conversational state and table schemas from the session store, producing the correct SQL syntax without re-querying the database metadata.
Davenport explains the underlying infrastructure: the agent interacts with Google Cloud through remote Model Context Protocol (MCP) endpoints. Rather than requiring developers to deploy and maintain local sidecar containers alongside their application containers, Google Cloud exposes managed remote MCP endpoints that natively handle authentication, access control, and API connectivity. Davenport showcases the broader ecosystem through the Data Agent Kit, a collection of Google Cloud data services allowing developers to chat with complex database schemas and execute secure data engineering workflows without managing local tooling infrastructure.
- **Session Continuity**: Survives front-end crashes and browser reloads by hydrating conversational context directly from the backing store.
- **Managed Remote MCP Endpoints**: Eliminates local sidecar maintenance by providing secure, authenticated, managed endpoints for Google Cloud services.
- **Data Agent Kit**: A pre-integrated suite of tooling and services designed to interface LLMs directly with enterprise data platforms like BigQuery and Cloud Spanner.
[16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) Inspecting Thinking Process and the Virtuous Feedback Loop
Looking directly into the order details, the developer can request basic summary information or drill down to ask much more intricate questions about the underlying data. This visibility proves invaluable during active development and ongoing agent monitoring. By employing secondary agents to inspect and evaluate operational data, developers can "create a virtuous cycle where we're improving the agent's ability to do different work by using agents to analyze our data."
There is also substantial value in peeling back the curtain on the model's internal reasoning. Observing the reasoning trail reveals the exact operational choices the agent makes when navigating tasks. In fact, "I find the thinking tokens actually to be probably more interesting than some of the outputs." In the demonstration, the system displays the retrieved list of ordered products; because the setup relies on generated test data, the resulting distribution appears relatively uniform—perhaps even unnaturally uniform compared to real-world purchase behavior.
- **Virtuous Development Cycle**: Running specialized analysis agents over system operational data continuously surfaces performance bottlenecks and refines agent task execution.
- **Thinking Tokens Over Raw Output**: Inspecting the internal reasoning traces provides deeper diagnostic insight into agent logic than evaluating final output strings alone.
- **Sample Data Uniformity**: Synthetic testing datasets often produce artificially flat distributions across product orders compared to organic consumer patterns.
---
[17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) Managing Stateful Sessions and Harvesting Telemetry
For developers looking to replicate or experiment with this setup, the code and configuration patterns are hosted in a public GitHub repository. A central consideration when moving past proof-of-concept designs is session management strategy. Basic in-memory session tracking works initially, but all conversational state evaporates the moment a container crashes or restarts. Production environments require durable storage layers, whether through Google Cloud managed options or standard relational and NoSQL engines, because "let's be very honest, that's what databases are great at is managing state."
Telemetry forms the second critical pillar. Developers can use the pre-packaged telemetry built directly into frameworks like the Agent Development Kit (ADK) or construct custom instrumentation pipelines. Instrumenting agent interactions allows teams to begin "harvesting all that information that your agents are generating on your behalf" and route it into analytical storage like BigQuery.
- **Container Volatility**: Pure in-memory session persistence leaves workloads vulnerable to sudden state loss when hosting containers terminate.
- **Database Specialization**: External databases provide the durable consistency guarantees necessary for multi-turn, long-lived agent interactions.
- **Turnkey vs. Custom Instrumentation**: The Agent Development Kit offers native telemetry out of the box, while still accommodating customized metric and trace schemas.
---
[18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) Architecture Recap and Closing Remarks
Bringing the presentation to a close, the demonstration highlights how pairing Google Cloud infrastructure with modern agent frameworks establishes reliable session handling and end-to-end observability. Ingesting telemetry into BigQuery transforms transient interaction logs into reusable institutional knowledge, which can power persistent agent memory architectures or downstream "dream systems" that synthesize learnings offline.
Crucially, adopting structured agent toolkits ensures teams do not have to burn "weeks of development time or break the bank" simply to introduce reliable state management into their applications. With the session concluding and only a few minutes remaining, attendees are invited to connect directly on LinkedIn to follow up on architecture details and operational questions.
- **BigQuery as Memory Foundation**: Centralized telemetry sinks allow raw operational logs to be harvested into synthesized memories and retrospective analysis models.
- **Fast-Tracked Statefulness**: Standardized agent SDKs eliminate the overhead of engineering custom persistence mechanisms from scratch.
- **Community Q&A**: Follow-up discussions and technical questions are routed to LinkedIn due to time constraints at the conference venue.
## Notable quotes
> [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) Hi, like what's your name? / Oh, my name is Jason. / And you just asked me that three turns ago. Please don't do that again. — Jason Davenport
> [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) Harvest them and start to analyze them for behaviors that you can, you know, change and improve. — Jason Davenport
> [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) create a virtuous cycle where we're improving the agent's ability to do different work by using agents to analyze our data. — Jason Davenport
> [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) I find the thinking tokens actually to be probably more interesting than some of the outputs. — Jason Davenport
> [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) let's be very honest, that's what databases are great at is managing state. — Jason Davenport
> [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) harvesting all that information that your agents are generating on your behalf — Jason Davenport
> [18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) weeks of development time or break the bank — Jason Davenport
## Mentioned
Jason Davenport, Google, Google Agent Development Kit (ADK), Google Cloud Spanner, Google BigQuery, Gemini Flash-Lite, Model Context Protocol (MCP), Data Agent Kit, GitHub, Jira, LinkedIn
## Video description
Jason Davenport - Area Technical Lead, Google
Learn how to build agents that share relevant informaiton with you. You'll see how to enable telemetry in frameworks like Google ADK that can give you the ability to create powerful insights from your agent using tools like Google Cloud Spanner and BigQuery. Learn how to use session information to create durable agents that can run over long periods of time and manage their own context windows.
谷歌利用 BigQuery 遥测修复智能体崩溃并减少 Token 浪费
用持久化数据库会话与 BigQuery 遥测替代易失性内存运行器，可防止运行时崩溃引发的灾难性上下文丢失，同时支持辅助智能体审查推理轨迹。
Jason Davenport 探讨了从脆弱、无状态的 LLM 脚本转向生产级持久 AI 智能体的工程要求。通过对比极简内存运行器与采用 Google ADK 配置遥测的实现方案，他展示了持久化会话存储如何在数据工程工作流程中防止重复的上下文丢失并实现崩溃恢复。本次内容展示了将包括提示追踪、思考 Token 和生成的 SQL 查询在内的完整执行轨迹流式传输至 BigQuery，如何把不透明的模型推理转变为可审计的知识闭环。Davenport 最后呼吁团队将遥测数据采集与基于数据库的会话管理视为基础架构支柱，而非事后补救措施。
智能且持久的智能体（Agent）架构依赖于指令、渐进式技能、工具、基础模型与记忆五大核心要素，其中记忆作为黏合剂，能防止系统在多轮交互中退化为无状态循环。 (0:04)
生产环境中的 API 限流（429）、工具调用报错（500）与 Token 膨胀成本，要求智能体架构必须具备任务可重启性、跨层状态管理及端到端的可观测性追踪。 (3:15)
Google Agent Development Kit (ADK) 提供了原生遥测集成，能将用户提示、模型响应、Span ID 和工具轨迹直接输出至 BigQuery，便于排查循环调用并审计生成的 SQL 语句。 (6:16)
持久化会话管理可避免服务重启后重复扫描数据库 Schema，结合 Google Cloud 托管的远程 MCP 端点，开发者无需自行维护本地 Sidecar 容器即可安全连接后端数据平台。 (14:25)
分析模型中间思考 Token（Thinking Tokens）比单看最终输出更具诊断价值，配合专门的分析智能体挖掘运维遥测数据，可构建持续迭代能力的良性优化闭环。 (16:53)
Reading summary
Google Area Technical Lead Jason Davenport argues that building production-ready intelligent agents requires moving beyond basic tool-calling to implement durable session management and comprehensive telemetry. Without external state and observability, agent architectures remain vulnerable to runtime failures, repetitive user interactions, and costly context bloat.
Agent Anatomy and Production Failure Modes (0:04)
Davenport outlines five core anatomical components of an intelligent agent: instructions establishing domain directives and personas, progressive skills disclosed as needed, external tools connected via protocols like the Model Context Protocol (MCP), the underlying foundation model, and memory. While the first four components manage compute, directives, and external execution, memory provides the additive substrate that prevents an agent from acting as a purely stateless loop.
In production, agents frequently encounter network dropouts, tool endpoint HTTP 500 errors, provider HTTP 429 rate limits, and runaway reasoning trajectories. In stateless setups, any container crash resets memory entirely, forcing the user to repeat basic information. Davenport highlights "tokenomics" as a primary operational risk, noting that unmanaged context windows and redundant multi-turn queries waste thousands of dollars. Mitigating these hazards requires three foundational capabilities: restartability to resume interrupted tasks, multi-layered state management, and comprehensive tracing.
State Persistence and Mid-Session Recovery (8:30)
Contrasting an in-memory base agent with a telemetry-enabled agent built on Google's Agent Development Kit (ADK) illustrates the necessity of persistent state. In a simulated e-commerce analysis scenario, a stateless agent running Gemini Flash-Lite treats follow-up queries as blank slates, repeatedly invoking MCP tools to scan database schemas and deduce table relationships.
When front-end sessions reset or containers restart, an in-memory agent loses all conversational history, requiring the user to re-explain table structures. By contrast, an ADK agent backed by persistent storage rehydrates context immediately, generating valid analytical SQL without repeating metadata discovery calls. Davenport points out that Google Cloud's managed remote MCP endpoints eliminate the operational overhead of running local sidecar containers to authenticate and connect agents to enterprise data services.
Auditing Trajectories and Model Reasoning (11:40)
Modern agent observability transforms opaque LLM execution into structured, auditable trajectories. By routing execution logs directly into BigQuery through ADK telemetry sinks, engineering teams can capture user prompts, model completions, application metadata, and unique span identifiers across multi-step autonomous loops.
This visibility allows teams to inspect tool trajectories for looping behavior, such as repeated queries caused by elusive schema parameters, and to audit the exact SQL statements the agent executes. Davenport notes that inspecting internal "thinking tokens" often yields deeper diagnostic insights than reviewing final text outputs alone, allowing developers to see how an agent navigates ambiguous directives and to refine MCP skills before deployment.
Harvesting Operational Data for Feedback Loops (16:53)
Rather than discarding token streams after interaction cycles conclude, Davenport urges developers to harvest telemetry into analytical data warehouses. Routing interaction logs into systems like BigQuery creates a durable audit trail that can power retrospective "dream systems" and secondary analysis agents designed to monitor operational performance.
By deploying secondary agents to analyze operational traces, engineering teams create a virtuous feedback loop where monitoring agents identify bottlenecks and refine the operational capabilities of primary task agents. Davenport emphasizes that external databases provide the durable consistency guarantees necessary for stateful agents, while standardized SDKs allow developers to implement this persistence without engineering bespoke telemetry scaffolding.
Davenport concludes that leveraging standardized agent frameworks and managed cloud data endpoints provides durability and observability without requiring weeks of custom infrastructure development. While persistent session storage solves immediate operational recovery, the longer-term advantage lies in harvesting interaction telemetry to audit reasoning and systematically refine agent behavior over time.
## Background
该内容由 YouTube 频道 Ai4 于 2026 年 8 月 14 日发布，由 Google 区域技术主管（Area Technical Lead）Jason Davenport 进行分享。视频主要探讨如何通过 Google ADK 等框架启用遥测功能，并结合 Google Cloud Spanner 和 BigQuery 实现深度分析，利用会话信息构建能够长期稳定运行并自主管理上下文窗口的高可用智能 Agent。
## TL;DR
分享首先解剖了智能 Agent 的五大核心要素（指令、技能、工具、模型与记忆），并针对生产环境中常见的崩溃中断、行为漂移与 Token 浪费问题，提出了“重启恢复、状态管理与可观测性”三大工程支柱。随后通过对比无状态 Base Agent 与遥测赋能 Agent 的具体架构，展示了如何利用 BigQuery 捕获完整的工具调用轨迹、思考过程（Thinking Tokens）与 SQL 审计日志，并依托云端 Remote MCP 端点实现无缝的跨刷新上下文恢复。最终阐述了如何借助遥测数据构建“分析 Agent 反哺自身”的良性进化循环，低成本落地企业级持久化 Agent 架构。
## Atmosphere & style
整场技术分享务实且充满工程师视角的幽默感，主讲人以轻松亲切的节奏将严谨的云原生架构和生产痛点娓娓道来。通过真实的“氛围编程”前端并排对比演示以及突发刷新的破坏性测试，现场体验非常硬核直观，尤其是对“思考过程比最终输出更有趣”以及“让专业数据库管状态”等观点的生动阐述，让观众在极具沉浸感的技术拆解中感受到前沿 Agent 开发的落地可行性与工程美感。
## Key takeaways
- [00:04](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=4s) 智能 Agent 由指令/人设（Directives）、技能体系（Skills）、工具对接（Tools）、底座模型（Model）以及记忆与状态（Memory）五大基础解剖结构构成。
- [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) 生产环境下 Agent 容易遭遇网络异常、工具 500 报错、模型 429 速率限制及行为漂移等挑战，单纯重启会导致多轮对话上下文彻底丢失。
- [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) 健壮的企业级 Agent 必须具备三大工程支柱：支持被打断后重拾上下文的重启恢复能力（Restartability）、跨轮次持久化的状态管理（State Management）以及行为可观测性与链路追踪（Observability & Tracing）。
- [06:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=403s) 基础分析 Agent 依赖容器内存存储会话，遇重启即丢失上下文；而遥测赋能 Agent 能自动将完整 Prompt、模型响应与元数据写入 BigQuery 沉淀为持久化日志。
- [10:47](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=647s) 通过链路追踪（Traces）与轨迹（Trajectories）审计，开发者可精准监控 MCP 工具调用参数、返回值以及模型生成的 SQL 语法，有效防范死循环与逻辑偏差。
- [10:47](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=647s) 将交互数据与 Trace 信息全量沉淀到现代云数据仓库（如 BigQuery）存储成本极低，能为后续大规模行为挖掘与 Prompt 迭代提供黄金数据集。
- [14:25](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=865s) Google Cloud 提供远程 MCP（Remote MCP Server）端点与 Data Agent Kit，开发者无需部署本地 Sidecar 容器即可安全连接云端数据服务实现多轮数据探索与对话。
- [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) 审查 Agent 的思考过程与思考 Token（Thinking Tokens）有助于理解模型推理链路，并可利用分析型 Agent 反哺其他 Agent 数据以形成能力进化的良性循环。
- [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) 状态管理应解耦并交给专业的外部数据库（如 Cloud Spanner），以彻底摆脱内存易失性限制并提升系统容灾水平。
- [18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) 结合 Google ADK 与 BigQuery 遥测沉淀的数据，不仅能构建长期持久化记忆，还可支撑离线反思与演练的“梦境系统”（Dream Systems），大幅压缩企业开发周期。
## Detailed walkthrough
### [00:04](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=4s) 智能 Agent 的解剖结构与核心构成
来自 Google 的区域技术主管（Area Technical Lead）Jason Davenport 开启了本次分享，重点探讨如何借助遥测（Telemetry）与会话管理（Session Management）构建真正的“智能 Agent”，而非呆板的“愚蠢 Agent”。他提到自己在 Google 的日常工作主要是帮助开发者更好地使用 Google 及 Google Cloud 产品，并将开发者的反馈反哺回产品迭代中形成良性循环。要让 Agent 具备长期运行和深度行为分析的能力，首先需要拆解 Agent 的五大基础解剖结构。
```mermaid
flowchart TD
accTitle: Agent 核心架构五大要素
subgraph Directives["指令与认知层 (Directives)"]
A["指令与人设<br/>(Instructions & Personality)"]
B["技能体系<br/>(Skills & Progressive Disclosure)"]
end
subgraph Execution["执行与模型层 (Execution & Compute)"]
C["工具对接<br/>(Tools & MCP Servers)"]
D["底座模型<br/>(Foundation Model)"]
end
subgraph Persistence["持久化层 (Persistence)"]
E["记忆与状态管理<br/>(Memory & State)"]
end
A --> D
B --> D
C --> D
D --> E
```
Agent 的前四个组成部分相当于指令、功能与计算层，而记忆则是让它们随时间持续演进的纽带：
- **指令与人设（Instructions & Personality）**：定义 Agent 的角色定位与行为准则，例如专注于行程规划的“旅行 Agent”或专门执行数据工程任务的“数据 Agent”，引导模型在特定边界内寻找参数并匹配目标。
- **技能（Skills）**：将人类关于工具或业务流程的专业知识打包。Agent 支持“渐进式披露”（Progressive Disclosure），比如顶层设定为软件工程任务，随后按需逐步加载组织内部的具体细分技能，高效传递人类经验。
- **工具（Tools）**：在当今开发环境中，通过 MCP（Model Context Protocol）服务器或自定义函数连接外部世界已成为日常，例如直接连接 Jira 读取工单或对接 GitHub 抓取特定 Issue 数据。
- **底座模型（Model）**：一切智能调度的计算与推理引擎。
- **记忆（Memory）**：区分无状态系统的关键所在。无状态系统会随着时间遗忘交互细节，而记忆层能将指令、技能与工具执行沉淀下来，实现长期递进式任务处理。
---
### [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) 生产环境痛点与三大核心支柱：重启能力、状态管理与可观测性
当 Agent 正式部署到实际生产环境中时，开发者会面临一系列与传统软件工程相似却更为复杂的挑战。首先是系统脆弱性与故障，网络中断或工具抛出 500 错误是家常便饭。在普通应用中崩溃重启即可，但如果 Agent 崩溃后直接丢失前五轮对话状态，就会陷入反复询问用户姓名的尴尬局面——“嗨，你叫什么名字？”“我叫 Jason。”“你三轮对话前刚问过我，别再问了！”其次是 Agent 做出非预期决策的行为漂移，如果缺乏对 Agent 完整轨迹的追踪，开发者将无法针对性地优化 Prompt 或技能。此外，模型接口的 429 速率限制（Rate Limit）也需要优雅的容错与恢复机制。
```mermaid
flowchart LR
accTitle: 智能 Agent 的三大必备工程支柱
A["Agent 生产落地挑战<br/>(崩溃 / 漂移 / 429 / Token浪掷)"] --> B["重启恢复能力<br/>(Restartability)"]
A --> C["状态管理<br/>(State Management)"]
A --> D["可观测性与链路追踪<br/>(Observability & Tracing)"]
B --> E["无缝衔接中断任务"]
C --> F["跨轮次数据持久化"]
D --> G["行为审计与 Token 优化"]
```
另一个关键现实是“Token 经济学”（Tokenomics）。企业往往因为上下文管理效率低下而浪费成千上万美元。开发者的职责不仅在于精简 Prompt，更在于长期分析交互数据并持续优化。针对这些痛点，健壮的 Agent 必须具备三大核心支柱：
- **重启恢复能力（Restartability）**：允许 Agent 像人类一样在被打断后快速重拾上下文。如同处理工作 15 分钟后因孩子提问离开 5 分钟，回来时依然能无缝继续推进任务。
- **状态管理（State Management）**：采用成熟的应用架构思路解决多层级状态的沉淀与持久化。
- **可观测性与链路追踪（Observability and Tracing）**：这是最关键的工程环节，“不要让你的 Token 白白浪费，把它们收集起来，分析其中的行为模式，以此改进个人或团队的工作流。”
---
### [06:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=403s) 对比演示：无状态 Base Agent 与遥测赋能 Agent
在演示环节中，Jason 展示了基于 Google Agent Development Kit（Google ADK，Google 针对 Agent 开发的规范化框架）构建的双 Agent 对比系统。为了让技术实现更加直观，他通过“氛围编程”（Vibe Coding）快速搭建了一个交互式 Web 前端，将两个 Agent 并排呈现以展示底层机制的差异。
```mermaid
flowchart TD
accTitle: Base Agent 与 Telemetry Agent 架构对比
subgraph BaseAgent["基础版 Agent (Base Analytics Agent)"]
B1["Gemini Flash 模型"] --> B2["内存会话服务 (In-memory Session)"]
B2 --> B3["无状态 / 容器重启即丢"]
end
subgraph TelemetryAgent["遥测增强版 Agent (Telemetry Analytics Agent)"]
T1["Gemini Flash 模型"] --> T2["持久化会话存储 (Session Store)"]
T1 --> T3["ADK BigQuery 遥测日志记录器"]
T3 --> T4["BigQuery / 集中式可观测性分析"]
end
```
代码与架构层面的核心差异包括：
- **Base Analytics Agent（基础分析 Agent）**：代码极其精简，仅导入了基础 Runner，采用内存级（In-memory）会话服务，模型选用 Gemini Flash。由于未接入任何遥测与持久化机制，一旦容器重启或请求生命周期结束，所有上下文即刻清空。
- **Telemetry-enabled Analytics Agent（遥测赋能分析 Agent）**：内置 ADK 的默认 BigQuery 日志记录器（Logger），并支持扩展自定义字段（如跨应用透传的 ID 字段）。该 Agent 会将用户发送的所有 Prompt、模型生成的所有 Response 以及底层元数据全量写入 BigQuery。
- **业务场景验证**：在针对 Google Cloud 项目 `Davenport Boutique` 进行电商销售与订单表结构探索时，左侧基础 Agent 每次接收输入都视作全新提问；而右侧遥测 Agent 依靠持久化会话，能够自动识别多轮交互历史并推断用户真实意图。
---
### [10:47](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=647s) 链路追踪（Traces）与 BigQuery 审计：工具调用轨迹与 SQL 审查
链路追踪（Traces）与轨迹（Trajectories）构成了 Agent 可观测性的核心骨架。回顾 2018 至 2019 年的前生成式 AI 时代，分布式链路追踪通常因开销高昂而仅在排查系统故障时开启；但在 Agent 时代，追踪记录了从用户输入到最终产出的完整行为链路，是排查死循环和逻辑漂移的必备手段。
```mermaid
flowchart LR
accTitle: Agent 遥测数据入库与审计流
UserPrompt["用户 Prompt"] --> Harness["ADK Harness / MCP 调度"]
Harness --> ToolCall["工具轨迹 (Tool Trajectory)"]
ToolCall --> SQLAudit["SQL / 参数审计"]
Harness --> AgentResp["Agent 完整响应"]
UserPrompt -.-> BQ[("Google Cloud BigQuery<br/>(低成本会话与日志存储)")]
ToolCall -.-> BQ
AgentResp -.-> BQ
SQLAudit -.-> BQ
```
在实际排障与优化中，BigQuery 承载了全面的审计能力：
- **防范死循环与工具调用轨迹**：许多 Agent 在接入 MCP 工具时容易陷入反复尝试抓取数据的死循环。通过 ADK Harness 捕获的 Trace ID 与工具轨迹，开发者可以清晰看到底座模型在何时发出工具调用请求、传递了何种参数以及 MCP 服务器返回了什么内容。
- **SQL 语法与业务逻辑审计**：在数据分析场景下，系统能完整捕获 Agent 生成并执行的 SQL 语句（例如订单状态汇总统计 `status counts` 等），方便安全与合规审计，或借由 MCP Skills 及开放知识格式（Open Knowledge Format）进一步修正数据统计指令。
- **低成本全量归档**：将包含 Prompt、Response、模型参数和 Trace 信息的完整会话沉淀在 BigQuery 这类现代数据仓库/数据湖中，存储成本极低，却为后续的大规模行为挖掘和 Prompt 迭代提供了黄金数据集。
---
### [14:25](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=865s) 跨刷新持久化与云端 Remote MCP 服务
为了验证持久化会话的稳健性，Jason 在演示中直接刷新并重启了前端浏览器界面。当再次向两个 Agent 发送后续指令（要求基于此前探查到的表结构编写 SQL）时，基础 Agent 彻底丧失了前置探索的记忆，无法完成连续任务；而遥测 Agent 依靠后端的 Session Store 瞬间找回前序会话，流畅地衔接上下文并生成对应的查询语句，完全不需要在客户端手写复杂的历史拼接代码。
```mermaid
flowchart LR
accTitle: 远程 MCP 云原生架构
Agent["Google ADK Agent"] -->|"HTTPS / gRPC 安全连接"| CloudMCP["Google Cloud 远程 MCP 端点<br/>(Remote MCP Server)"]
CloudMCP --> DataKit["Data Agent Kit<br/>(数据服务合集)"]
CloudMCP --> IAM["统一身份认证与鉴权 (IAM)"]
```
在工具接入架构上，该方案采用了云端远程架构：
- **远程 MCP 服务（Remote MCP Server）**：Google Cloud 上的数据服务均提供了远程 MCP 端点。开发者无需在 Agent 宿主机旁边额外运行复杂的 Local Sidecar 容器，直接通过安全端点连接，身份验证与权限访问均由云平台全托管。
- **Data Agent Kit**：Google 将旗下丰富的数据服务聚合打包为 Data Agent Kit，使开发者能够快速实现“与数据对话”（Chat with your data），在统一的经典模型架构下完成高效的 Schema 探查与多轮交互式数据分析。
### [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) 利用遥测数据与思维过程构建 Agent 的良性循环
在展示具体的订单详情时，开发者不仅能向 Agent 询问概要性信息，还可以深入挖掘并提出极其详细的数据问题。Jason Davenport 指出，这种深入分析在开发阶段以及日常监控 Agent 表现时尤为重要，它能够形成一个强大的“良性循环”（virtuous cycle）——借助 Agent 自身强大的数据分析能力来洞察并反哺其他 Agent 生成的数据，从而持续迭代并增强 Agent 完成多样化任务的能力。在演示过程中，Jason Davenport 饶有风趣地提到，除了最终生成的业务产出，审查 Agent 的思考过程（thinking process）和思考 Token（thinking tokens）往往更具启发性，甚至“比某些直接输出的结果更加有趣”，能让工程师直观透视底层模型在决策时究竟经历了怎样的推理链路。在检查订购产品的数据时，他也坦诚指出，由于当前使用的是测试样本数据，数据分布显得相对平缓，“甚至可以说有点过于均匀了”。
```mermaid
flowchart LR
accTitle: Agent 数据与自身迭代的良性循环架构
subgraph AgentRuntime["Agent 执行与捕获"]
A["Agent 交互与执行"] --> B["思考过程与遥测数据<br/>(Thinking Tokens & Telemetry)"]
end
subgraph StorageAnalysis["存储与分析"]
B --> C["数据沉淀<br/>(BigQuery / Cloud Spanner)"]
C --> D["分析型 Agent<br/>(Data Analysis Agent)"]
end
subgraph Improvement["能力进化"]
D --> E["生成长期记忆 / 洞察反馈"]
E --> A
end
```
### [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) 状态持久化与遥测生态：从内存会话到外部数据库
针对系统的部署与实践落地，整个项目的开源代码已发布至 GitHub 仓库供大家自由体验与调试。开发者可以在代码中验证不同的会话管理策略：如果仅仅依赖传统的内存型会话，一旦底层容器发生故障或重启，整个会话状态就会彻底丢失；而通过引入受管服务或各类外部数据库，即可轻松解决持久化难题，正如 Jason 直截了当地指出：“说白了，管理状态本来就是数据库最擅长的事情。”除状态管理外，无论是利用 Google ADK（Agent Development Kit）原生开箱即用的遥测功能，还是根据特定业务需求定制遥测埋点，都能全面收割 Agent 在后台运行所产生的关键调用与交互信息。
- **状态管理策略**：对比了轻量但易失的容器内存会话与高可靠的持久化数据库方案，提倡将状态解耦至专业数据库。
- **开箱即用与定制化兼备**：Google ADK 提供了内置的标准遥测支持，同时也允许开发者无缝扩展自定义遥测，用于捕获深层指标。
- **开源资源**：演示中的所有配置与代码均已整理在 GitHub 仓库，便于开发者自行克隆并在本地或云端环境复现。
### [18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) 会话可观测性总结与企业级开发落地
在最后的总结中，Jason Davenport 梳理了整场分享的技术核心：通过 Google Cloud 上的 Agent 平台，团队得以高效实现兼顾可观测性与会话管理的架构设计。所有运行时遥测数据均可实时沉淀至 BigQuery 中，企业不仅可以对这些数据进行深度收割以沉淀长期记忆，甚至能够基于此类日志运行“梦境系统”（dream systems）进行离线演练与自主反思。借助 Google ADK 以及 Any Gravity 等开发工具，构建有状态的持久化 Agent 不再需要耗费团队数周的开发工期，也无需承担高昂的基础设施与维护成本。分享尾声，由于现场仅剩 5 分钟且时间有限，Jason Davenport 热情邀请对该方案有深入疑问的观众在 LinkedIn 上与他取得联系并继续探讨交流。
- **核心技术栈整合**：依托 Google Cloud 基础架构，打通 Google ADK、BigQuery 与 Cloud Spanner 的集成链路。
- **进阶衍生应用**：借助 BigQuery 中的沉淀数据构建持久化记忆，并为模型梦境回放机制（dream systems）提供离线训练与微调养料。
- **降本增效成果**：将传统构建复杂状态化 Agent 所需的数周周期大幅压缩，兼顾工程落地速度与成本控制。
## Notable quotes
> [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) 嗨，你叫什么名字？我叫 Jason。你三轮对话前刚问过我，别再问了！ — Jason Davenport
> [03:15](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=195s) 不要让你的 Token 白白浪费，把它们收集起来，分析其中的行为模式，以此改进个人或团队的工作流。 — Jason Davenport
> [06:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=403s) 氛围编程 — Jason Davenport
> [14:25](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=865s) 与数据对话 — Jason Davenport
> [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) 比某些直接输出的结果更加有趣 — Jason Davenport
> [16:53](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1013s) 甚至可以说有点过于均匀了 — Jason Davenport
> [17:48](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1068s) 说白了，管理状态本来就是数据库最擅长的事情。 — Jason Davenport
> [18:43](https://www.youtube.com/watch?v=N6-WBqYQWMs&t=1123s) 梦境系统 — Jason Davenport
## Mentioned
Jason Davenport, Google, Google Cloud, Google ADK (Agent Development Kit), Google Cloud Spanner, BigQuery, Gemini Flash, MCP (Model Context Protocol), Data Agent Kit, Jira, GitHub, LinkedIn, Davenport Boutique, Any Gravity, Ai4
## Video description
Jason Davenport - Area Technical Lead, Google
Learn how to build agents that share relevant informaiton with you. You'll see how to enable telemetry in frameworks like Google ADK that can give you the ability to create powerful insights from your agent using tools like Google Cloud Spanner and BigQuery. Learn how to use session information to create durable agents that can run over long periods of time and manage their own context windows.
[Source](https://www.youtube.com/watch?v=N6-WBqYQWMs)
Source quotes
[3:15] Jason Davenport: 嗨，你叫什么名字？我叫 Jason。你三轮对话前刚问过我，别再问了！
[3:15] Jason Davenport: 不要让你的 Token 白白浪费，把它们收集起来，分析其中的行为模式，以此改进个人或团队的工作流。
[6:43] Jason Davenport: 氛围编程
[14:25] Jason Davenport: 与数据对话
[16:53] Jason Davenport: 比某些直接输出的结果更加有趣
[16:53] Jason Davenport: 甚至可以说有点过于均匀了
[17:48] Jason Davenport: 说白了，管理状态本来就是数据库最擅长的事情。
[18:43] Jason Davenport: 梦境系统
Source quotes
[3:15] Jason Davenport: Hi, like what's your name? / Oh, my name is Jason. / And you just asked me that three turns ago. Please don't do that again.
[3:15] Jason Davenport: Harvest them and start to analyze them for behaviors that you can, you know, change and improve.
[16:53] Jason Davenport: create a virtuous cycle where we're improving the agent's ability to do different work by using agents to analyze our data.
[16:53] Jason Davenport: I find the thinking tokens actually to be probably more interesting than some of the outputs.
[17:48] Jason Davenport: let's be very honest, that's what databases are great at is managing state.
[17:48] Jason Davenport: harvesting all that information that your agents are generating on your behalf
[18:43] Jason Davenport: weeks of development time or break the bank
Original transcript
[0:04] The topic of today's session is how we can build
intelligent agents. So, uh not dumb agents,
[0:10] uh with telemetry and session management.
So, here we'll really just be focusing on
[0:15] uh the technical components that we want
to do in order to essentially build,
[0:19] you know, ways that our agents can do things
over time and also start to analyze the
[0:23] different things that agents are doing and their
behaviors for it. Um my name's Chase Davenport. Uh
[0:29] as was mentioned, I'm an area tech lead at Google,
but I mostly help developers uh use our products
[0:34] uh with Google and Google Cloud and then help to
improve our products uh to make them easier to
[0:40] use for developers. It's kind of a virtuous cycle
when it all comes together. So, let's talk about
[0:45] uh just the anatomy of a basic agent for a couple
seconds um because this will be important when we
[0:50] then, you know, talk about how we start to wrap,
you know, tools like telemetry around this.
[0:55] Um and there's really kind of, you know,
five parts that I think about in an agent. Um
[1:00] first one is, you know, what are the instructions
that we're giving an agent and what's kind of the,
[1:04] you know, personality of the agent and what is
it supposed to be doing? So, think of this as,
[1:09] you know, maybe, hey, I'm a travel agent and I'm
going to, you know, help you accomplish a specific
[1:14] task. I'm a data agent where my job is to perform
data engineering roles and tasks. Um but just
[1:21] giving kind of that flavor of, you know, where the
model should instruct itself to actually look for,
[1:26] you know, parameters and other matches in it. The
second one is tool is skills. Um so, you know,
[1:33] one of the great things about skills, right, is
we can use our knowledge about either tools or
[1:37] processes and then, you know, give those to agents
in a way where an agent can progressively uh load
[1:43] skills up. So, you know, understanding, hey, if
I'm going to perform a software engineering task,
[1:49] you maybe that's the top-level skill and then we
have numerous other skills for our organization
[1:53] that we can progressively disclose to the agent.
Uh these are great ways for us to kind of curate
[1:58] the knowledge that we have and then transfer that
knowledge uh to an agent to be able to do its job
[2:03] more successfully. Uh tools is another thing. You
know, we kind of talked a lot about tools probably
[2:09] in you know, 2025 so a long long 18 months ago. Um
but now that's kind of the day-to-day stuff that
[2:16] we do, right? Like we have agents that use MCP
servers that use you know, different functions
[2:21] that maybe we define but interact with the world
to essentially accomplish a goal or a task. Um
[2:27] those are ways you know, here that we can say hey
like connect to my you know, Jira instance to get
[2:32] tickets or connect to you know, GitHub to find
specific information about an issue uh just as
[2:38] two examples. Um the model obviously like none
of this works if you don't have a have a model
[2:43] for it. Uh there are a number of great providers
out there. And then the last one um which I also
[2:48] talked a little bit about yesterday is memory and
this is really you know, if you think of kind of
[2:52] the top four things as being like directives um
and functions that we give to an agent along with
[2:57] you know, kind of the compute layer uh memory
here is really about then how we can use that
[3:03] all these things together over time in a way that
is additive and actually accomplishes the goal
[3:08] um versus being a stateless system uh which maybe
you have forgets things over time for it. [snorts]
[3:15] So, let's talk about you know, things that happen,
right? So, I just mentioned state. Um here here's
[3:21] just a number of things that I I kind of think
about when folks start deploying agents. Um and
[3:25] these are just you know, things that may happen,
right? So, first off is a common thing that we see
[3:30] in application development, right? Uh the system
breaks the thing. You know, there's a network
[3:34] connectivity failure. Um a tool you know, had a
had a had a 500 error on it. We have to manage
[3:41] those things in an agent just like we would an
application. Um but agents right? If you stop the
[3:46] agent and then if it crashes, well, you don't want
it to forget the last five turns of conversation
[3:51] that you had, right? Otherwise, like it's like,
"Hi, like what's your name?" It's like, "Oh, my
[3:55] name is Jason." It's like, "And you just asked me
that three turns ago. Please don't do that again."
[4:00] Uh second one is uh how we have agents that make
decisions that we didn't expect. So, you know,
[4:06] this is really coming into the memory management,
you know, improving our skills, our instructions,
[4:11] you know, what we're giving to the agent. We can't
do that, right, if we don't track all the all the
[4:15] things that the agent actually does. And so, how
your trajectories and traces come into this is a
[4:19] big one. Um tools and models, uh how many people
here have never seen a 429 error on a model?
[4:28] Uh I was I was hoping I'd get someone to raise
their hand cuz they heard 429. Thank you for
[4:32] making me uh feel better about that. Um you
know, here, right? We have to manage application,
[4:38] you know, issues, right? We have to manage,
you know, API issues, and we have to make
[4:42] sure that the agent can, you know, essentially
do these things gracefully, or if it fails to
[4:46] gracefully pick back up from where it started.
And then last but not least, um you know, so
[4:51] tokenomics is is I guess the buzzword,
right, of 2026, but it is real.
[4:56] You know, companies, you know, here, you know,
we spend you know, many, many thousands of of
[5:02] dollars on inefficiently managed contexts. And you
know, part of our our job as developers is to one,
[5:08] you know, get more efficient with our
prompts and build better systems on that,
[5:12] but also then to, you know, analyze this
information over time and see how we can
[5:16] do some of these things uh better and more
efficiently. [snorts] So, in summary, you know,
[5:21] what do our agents really need, right? We need
restartability. So, how can an agent, you know,
[5:26] pick back up from where it left off, just like,
you know, I was working on a task for 15 minutes,
[5:31] you know, my child asked me a question, I had to
leave for 5 minutes, and I pick it back up. How do
[5:36] we have similar processes and and flows like that
for our agent? How do we manage state? You know,
[5:42] state is is a multi-layered problem, but, you
know, there are luckily a number of ways that
[5:46] that we do this already in application development
and in agents it's really not that different.
[5:52] And then last is observability and tracing and
if there was anything I would encourage you to
[5:56] take away, I think this is probably the the most
important thing if you're not doing it today on
[6:01] agents that you run, you know, don't don't let
your tokens go to waste. You harvest them and
[6:06] start to analyze them for behaviors that you
can you know, change and improve in you either
[6:11] your personal flows or your organizations moving
forward. All right, so we're going to talk about
[6:16] two new components here. So if you think you of
demos where we focus on the agent, that is not
[6:22] this demo. We're going to show you how we're doing
how we can do session management in Google Agent
[6:27] Development Kit which is kind of our opinionated
way of building agents and then how we can also
[6:32] see what observability actually looks like and
then start to understand some different methods
[6:37] and things that we can do with it. [snorts] All
right, I'm going to go ahead and shift over here.
[6:43] So the first thing that I'll start with is
I'm going to show a little bit of code just
[6:47] for this application highlighting the the specific
things that we were talking about here. So let me
[6:52] do this and let me make it a little lot bigger.
There we go. All right. So I have an agent here.
[7:02] We have two agents just for reference because
we're going to see a base agent. So our base agent
[7:07] is just a very simple agent that does not have
any sort of state enabled in it. It's going to
[7:12] be using a Gemini 3.5 flashlight model and we're
going to have some very simple instructions that
[7:18] we give to it. So in this agent's behavior,
you can see that we have very little imports.
[7:24] You're essentially just importing your runner. We
have a very basic session service, but this is an
[7:30] in-memory one. So think of this is just when the
agent you has things that maybe it's it's running
[7:35] in a container, it might have access to it. And
then that's about it. So no telemetry or things
[7:42] enabled in it. Second one that we'll be looking
at here and seeing the behavior as a telemetry
[7:47] enabled agent. So, um, one of the things that
we can do here, you have, um, you can obviously,
[7:52] you know, use uh, agents to almost code anything
these days. Within ADK, we have a default, um,
[7:59] logger to BigQuery, which is great. And then we
can also build, you know, customized ones that
[8:04] actually capture additional information for,
you know, things that we need. Maybe there's,
[8:08] you know, ID fields that we need to pass uh, from
an application over uh, to the to the our, um,
[8:14] back end or something else. But we can essentially
start to log all of our different uh, prompts and
[8:19] responses for it. So, the benefit here, right, is
now we get that data. So, we have all the prompts
[8:24] that we're working with and we will be able to
see a in BigQuery as a result. All right, let's
[8:30] go ahead and see the app, right? Because that's
the most fun part of these things. Um, and then we
[8:34] can talk a little bit more about how it works. Uh,
so first thing, I'll make this a lot bigger, too.
[8:41] [snorts] All right. So, uh, one of the
things that I do love in this area is like
[8:45] I can show you a bunch of code, right? But I
can also vibe code the crap out of a UI to then
[8:49] talk through the different pieces that we're
going to do, um, and just make it a little bit
[8:53] more visually interactive so we can see these
pieces. Uh, we can see here uh, that I have
[8:59] uh, two agents that are side by side.
So, we have our base analytics agent
[9:04] and we have our telemetry enabled uh,
analytics agent. And so, first things first,
[9:08] um, let's see here. So, we can give the same
prompt. So, here I'm analyzing an e-commerce uh,
[9:14] project or e-commerce uh, sales object in this
project, Davenport Boutique, which is one of my
[9:19] Google Cloud projects. And we have one to inspect
and get some schema information uh, into this.
[9:25] So, uh, first things first, um,
we can see here that on the left,
[9:29] because we don't have state management, we don't
have that information connected up, that this
[9:34] agent just gives me a response back, right? It's
like the agent's never seen the question before,
[9:39] goes and analyzes uh some different things. We can
see that it's calling uh my big query objects here
[9:44] uh using an MCP server, but it's uh getting the
data sets in my project, which are just schemas,
[9:50] and then it's inspecting a couple of the the
tables that it thinks are useful. In this case,
[9:55] uh we're asking about sales, and
sales and orders are kind of synonyms,
[9:59] so it's finding those things for it.
So, what's interesting, right, is that
[10:04] on our telemetry-enabled one, because I've run
this a few times, we can actually see that the
[10:09] this recognizes that in within sessions that
I've had as a user, it's can understand that,
[10:15] hey, there is actually history here, and the user
asked a question, and then we can go back through,
[10:20] recognize some of the objects, and then return
that. So, just by using session memory, right,
[10:26] we can assume you have things about a user
like over time that maybe we want to accomplish
[10:36] or not. There we go. All right. So, let's talk
about a few other things here. So, we can see
[10:43] here, you know, we still had those tool calls that
are made, but we also logged these results. So,
[10:47] let's talk a little bit more about logging and and
why that's so important. First, you can see that
[10:52] we have a span here. So, um how many people have
used uh traces in application development before?
[10:59] Couple folks, okay. Um traces used to be one
of those things that you always aspired to do,
[11:05] but you would only do it if there was a problem
because they were so expensive to run, and this
[11:09] was, you know, back when I was probably doing it
in like 2018 or 2019. Um in this world, right,
[11:14] with with traces and and what we call trajectories
in the agent world, so think of that is, you know,
[11:19] from the to the end, uh what behaviors the agent
actually elicits. So, what are the prompts, you
[11:26] know, what are those loops the agent is working
in? Um here, really, the benefit, right, is that
[11:30] by logging all these things and having those trace
IDs, we can now see behaviors that agents are
[11:35] undertaking. So, let's go ahead and look at that.
So, uh here I just have a very uh simple window
[11:41] for us to go and look at some of our different
data uh in BigQuery. And we can see here that,
[11:46] you know, we can look at a couple things. So, one
is I can look at the what's in the session store.
[11:51] And think of that as uh essentially the different,
you know, things that we want to do um with some
[11:56] of our different data points. Here, I'll make
sure that we go. Uh that was my authentication uh
[12:01] kicking in. But here, so we can see great. I have,
you know, a couple of different logs. We have
[12:07] our agents. You let's select the telemetry agent,
and now we can actually see a number of different
[12:12] events uh that we were logging from our from our
agents. So, I've uh have some user uh prompts.
[12:19] I have some agent responses, and I also have tool
trajectories. So, let's uh take a look first.
[12:25] Think here that's great with the tool
trajectory. So, think of it as, you
[12:31] uh many agents go through and like you actually
will end up in like looping behavior in MCP
[12:36] sometimes. Like the agent just keeps trying and
trying and trying to find information in a tool.
[12:41] Well, here we can actually see the tools uh that
the agent requested to call. So, you keep in mind
[12:47] what the model does uh with the ADK harness is the
model says, "Well, hey, I need you to call this
[12:52] tool, and here's the parameters." And then the MCP
server will actually, as a part of the harness,
[12:57] be called and then will go and get the information
that's provided. We can see here that we have
[13:02] a couple different tool calls that were that
were made. We can actually audit the SQL that's
[13:06] associated with that. So, if there are maybe, you
know, specific commands that we want our users to
[13:11] execute or our want our agents to use, you we can
go and essentially audit those different results.
[13:18] Uh maybe, you know, in this case, like I'm looking
at the the essentially just doing some status
[13:22] counts, uh but maybe there are specific fields
when you think about summations and other things
[13:26] that you want to do, we could specify your more
directives of both with MCP skills and then with
[13:32] the open knowledge format as a part of that. All
right, so let's look at a couple other ones here
[13:37] so we can see the agent response. [snorts] So
here is one of the agent responses that we've
[13:43] logged. We can see that we actually have
you the the full response from the agent.
[13:48] And then we can also you see other ones with
that and then if we put all these together,
[13:53] uh we actually have you a full you session
that we could see. So we can see we have
[13:58] we have a response, we have tools, we have what
the user originally asked, and then also the
[14:03] models and the traces that users uh were executing
for that. Um one of the great things here, right?
[14:09] You because we're just logging all of this um to
a data warehouse or a lake tool like BigQuery,
[14:14] real relatively cheap to store all of this
stuff and then to start figuring out what in
[14:18] these sessions actually makes sense uh for users
to go uh and and build on top of that. All right.
[14:25] So let's talk about just a few other things
here. You one of the things that I mentioned uh
[14:29] so let's see here we have this restarted.
Let's go ahead and just see what happens.
[14:33] So we're going to you run our first term which
is to discover those table those table schemas.
[14:40] So you can see that we're asking the same you
question to each of these uh different ones.
[14:44] We can see that we have those data sets back.
That's pretty cool, right? You we can see that
[14:48] we have uh some things here. Here because
we have some session memory though, right?
[14:53] Think keep in mind like my web browser literally
just restarted like the front end for this,
[14:58] we still have our session that's active, right?
So this is really nice for us to come back
[15:02] you and maintain that state and make sure that our
users have those different pieces of information.
[15:07] And I can go ahead and let's just you assume we're
going to run another one. So I want it to you
[15:12] essentially start building us some SQL for it. So
I go I think I went ahead and hit that. [snorts]
[15:19] And again on the left right because we're just you
[15:22] retrieving the responses from an agent, we're
not, you know, trying to append, you know,
[15:26] all these different objects together. Our code is
very simple. We can see that as a result of that,
[15:30] you know, we don't have that that
history or even those prompts.
[15:35] And so, now, you know, it's not going to be
able to retrieve it. Where this one is going
[15:38] back to our session store and then still getting
that information and and retrieving it through.
[15:45] All right. I have just a few minutes left
here. Um so, a couple things here, you know,
[15:53] we'll also just go through it and highlight. So,
I could go through and I could ask, you know,
[15:56] maybe some different questions of these models and
I can see how these, you know, things will will
[16:01] look in in multi-turn responses. Um and then I can
also do things like compare, you know, how much
[16:05] memory do I actually want to recall and what's in
in the audit logs and all those those fun things.
[16:11] But the other thing that I'll actually
talk through, so in our agent, um
[16:15] what our agent is doing is using a remote MCP
server. Uh so, everything in Google Cloud uh
[16:20] has a remote MCP endpoint. So, think of it
as you don't have to run like a local sidecar
[16:25] you know, with your agent. You can just
connect to us. We manage, you know,
[16:28] authentication and and access and all those
things. Um but what's great about that is let's
[16:32] say I'm actually doing some exploration and I want
to learn more. Um here I'm in the data agent kit.
[16:39] So, the data agent kit is essentially collection
of all of our services uh with for data that we've
[16:44] put together. And what it allows you to do is to
do things like come over and you start chatting,
[16:49] you know, with your data. So, we can see
that we have our in our classic model schema,
[16:53] there's order details. I can go through, you know,
just maybe ask some summary summary information,
[16:59] but I could also go through and then start asking
more detailed questions about the data. And this
[17:04] really just helps me to, you know, as as I'm in
development and then also looking at my agent
[17:09] to essentially create a virtuous cycle where we're
improving the agent's ability to do different work
[17:14] by using agents to analyze our data and all
those those those things within it. [snorts] So,
[17:20] it's pretty cool. I can even, you know, look at
what's the the thinking process for these things.
[17:25] Um you know, these are always interesting to
go through and then understand like what's
[17:29] the agent actually doing. I find the thinking uh
tokens actually to be probably more interesting
[17:33] than some of the outputs. And we can see here,
right, that you know, we have now our products
[17:37] that have been ordered. And uh because this
is obviously some sample data that we have,
[17:42] you know, the data is is relatively skewed
or uniform, probably too uniform within it.
[17:48] All right. So, um last thing here uh that
I will cover uh and then we'll shift over.
[17:56] Um if you want to uh deploy this on your own,
um I'll put this up afterward, but all this is
[18:01] up on a GitHub repo that you are welcome to go and
play with. Um you can also, you test out different
[18:07] methods for, you how to manage sessions. Um
there's, you know, we talked about obviously
[18:11] just the in-memory session and what happens when
the container dies. But then, you if you have
[18:16] different services that you want to use, you know,
for your own, we obviously have some managed ones,
[18:20] but any database will also work. You know, let's
be very honest, that's what databases are great at
[18:25] is managing state. And then, you know, also see
how, you know, with agents we can build either
[18:31] out of the box telemetry, which um ADK obviously
has, um or how to build your own custom telemetry,
[18:37] so you can start harvesting all that information
that your agents are generating uh on your behalf.
[18:43] So, uh let's just do a quick summary here.
So, what did we do? We used agent platform uh
[18:48] with Google Cloud to see how we could uh
do session management and observability.
[18:53] Uh we saw that all that data land uh in BigQuery
that we could then start to harvest and, you know,
[18:57] create memories or even use dream systems off
of. And then, most importantly, we highlighted,
[19:03] you know, with agent development kit and even with
tools like Any Gravity, um how we can actually
[19:08] build stateful agents in a way that doesn't, you
know, and use like weeks of development time or
[19:14] or break the bank in it. All right. I'd like to
thank you all for attending today. Hopefully,
[19:20] this was useful and there's some good tidbits
in there. But, I'm here for questions if if
[19:24] folks have anything to ask. Or actually, I think
there's only 5 minutes. So, if you have questions,
[19:29] please feel free to hit me up on LinkedIn. I am
happy to answer them on your behalf. Thanks again.
