Your Agents Need a Save Button - Hamza Tahir, ZenML

Hamza Tahir argues that a “save button” or checkpointing mechanism is the most underrated primitive in AI agent infrastructure, crucial for debugging, optimizing, and scaling agents efficiently. While document editing has had persistent state for decades (Ctrl+S/Cmd+S), agents currently lack this, relying mostly on traces.

The Problem with Current Agent Observability

Existing agent observability primarily relies on traces, which provide emitted telemetry data such as tool calls, inputs, and outputs. However, traces are disconnected from the actual runtime state. Critical information like in-flight variables, file system changes, execution decisions, and the code itself are lost. This read-only trace sits far from the code, creating a disconnect between observability spans (e.g., from OpenTelemetry) and the actual execution.

The “Save Button” Solution: Durable Runtime and Checkpointing

A durable runtime sits atop existing agent frameworks and harnesses, augmenting traces with actual code execution and environmental context. This enables checkpointing, which captures a complete snapshot of the agent’s state at various points during its execution. This includes configuration, where it ran, the code executed, and the artifacts (inputs/outputs) involved. This snapshotted state can include the Docker image or sandbox environment.

Benefits of Checkpointing for Agent Development and Production

1. Replay and “What-If” Analysis: With a persistent state, agents can be replayed from any point in their trajectory. This allows developers to ask crucial “what-if” questions:
   • Swapping out models (e.g., to a cheaper open-source model).
   • Mocking or overriding tool returns.
   • Intentionally degrading components to test resilience.
   • Analyzing decisions in scenarios like customer resolution and refunds (e.g., if order status changed language, if escalation was needed, or if a smaller model would suffice).
2. Closing the Evaluation Loop: Checkpointing enables a methodology described as “checkpoint, replay, diff, decide.” This involves:
   • Identifying cohorts of runs (e.g., expensive, long, risky).
   • Replaying changes to these runs.
   • Diffing the new outcomes against the baseline.
   • Deciding on improvements and shipping them.
   • This effectively evaluates agents using production traces and checkpoints.
3. Cost and Performance Optimization: By replaying with different configurations (e.g., cheaper models), organizations can identify trade-offs between cost, speed, and efficacy. The DoorDash example demonstrated reducing testing time from hours to minutes, achieving 90% fewer hallucinations with hundreds of simulations grounded in real production data.

Kitaru: An Open-Source Durable Runtime for AI Agents

The speaker introduced Kitaru, a new tool launched by the ZenML team, which serves as a runtime layer for agents. Kitaru provides the checkpointing capabilities discussed, allowing for replay scenarios and detailed analysis.

Kitaru Demo Highlights:

• Support Agent Example: Demonstrated with a customer support agent escalating requests to humans.
• Detailed Checkpoint View: Each tool call checkpoint reveals configuration, runtime environment, code, and input/output artifacts.
• Model Swap: Showed how to replay an execution from a specific tool call, changing the LLM to a cheaper GPT-5 Nano and skipping earlier checkpoints as their state is preserved.
• Tool Mocking: Illustrated replaying with a mocked lookup_policy tool by replacing its function with a different implementation in the codebase, enabling analysis of how policy changes affect outcomes.
• Side-by-Side Diffing: Kitaru’s diff command allows visual comparison of original and forked runs, highlighting differences in execution flow and final artifacts. In one example, changing the policy led to an agent declaring a case “safe to answer” instead of “needs review.”

The Importance of Cohort Analysis and Nuance

While single replays are useful, Hamza emphasizes that “one replay is just an anecdote.” For robust evaluation and optimization, cohort analysis is essential. This involves running experiments across a distribution of data (e.g., all expensive runs) to understand broader impact.

• Automated Analysis: Kitaru’s “MCP server” (likely referring to a multi-cohort processing server or similar) can analyze JSON reports from cohort replays using agents/LLMs, flagging issues and providing insights, especially when dealing with thousands of runs.
• Avoiding False Economies: A naive model swap focusing only on cost can lead to a “false economy” where a cheaper model fails to resolve requests effectively, negating cost savings. Value creation and overall outcome must be considered, not just single dimensions like speed or cost. Studies (like BrainTrust’s) show that even models passing 60% of tests are self-consistent only about 25% of the time, reinforcing the need for comprehensive cohort analysis.

A Playbook for Production Agents

1. Start from Real Runs: Use actual production data, not just synthetic ones.
2. Build Meaningful Cohorts: Group runs based on relevant criteria (e.g., expensive, long, risky).
3. Scale Experiments: Never ship based on one or two replays; conduct experiments at scale.
4. Automate the Loop: Strive to automate the “ship, route, and hold” loop as much as possible, potentially with agents analyzing results, keeping a human-in-the-loop for final decisions.

In conclusion, building agents with a durable runtime that can checkpoint and replay state from code, with different scenarios, is critical for answering “what if” questions, improving agent design, and driving better, cheaper, and faster outcomes at scale. Kitaru is an open-source tool facilitating this vision.

• Tags:
• AI Agents
• LLM Evaluation
• Observability
• Model Optimization
• Cohort Analysis
• Cost Efficiency
• Agent Infrastructure
• Durable Runtime
• Checkpointing
• Replay
• What-if Analysis
• Kitaru
• ZenML