# Everything You Need To Know About Agent Observability

Danny Gollapalli & Zubin Koticha, Raindrop | AI Engineer Europe 2026 | 50:25

Source: https://www.youtube.com/watch?v=-aM2EDTiaMs
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/everything-you-need-to-know-about-agent-observability
Published: 2026-05-07
Tags: agents, evals, observability, tracing

## TL;DR
- Production evals cannot cover the combinatorial behavior of agents, so teams need monitoring based on signals from real user sessions.
- Classifier, regex, and explicit operational signals can expose failures such as refusals, user frustration, tool errors, latency spikes, and task failure.
- A simple report tool plus system-prompt guidance can make an agent disclose tool failures, capability gaps, unsafe workarounds, and other noteworthy behavior.

## Summary
Zubin Koticha and Danny Gollapalli argue that production monitoring has to sit alongside, and often matter more than, traditional evals for agents. Agents can use expanding sets of tools, memories, and sub-agents, while running for long sessions and producing behavior that fixed test cases will miss. They divide observability signals into explicit signals, such as tool errors, latency, cost, and regenerations, and implicit signals, such as refusals, frustration, task failure, and capability gaps. Classifiers and regex provide inexpensive ways to track these signals at scale. Experiments can then compare issue rates between a new version and a control group. The workshop demonstrates self-diagnostics in a coding agent by forcing a write-tool permission failure and asking the agent to report noteworthy behavior. The speakers are honest about its limits: agents often avoid self-incrimination, so tool naming and prompt framing affect what they disclose. They also show how traces, clustering, alerts, and automated triage can help find unknown problems.

## Key ideas
### Agent failures require production monitoring because fixed evals miss open-ended behavior
[00:56](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=56s)
Zubin Koticha says agents differ from ordinary software because they are non-deterministic, accept an effectively infinite range of inputs, produce an effectively infinite range of outputs, and can affect outside systems through tools. Sessions can run for hours, and agents are being deployed in healthcare, finance, and military settings. A golden dataset cannot cover the combinations created by growing tool sets, memory sources, and recursively called sub-agents. Koticha argues that teams need a monitoring paradigm that catches the long tail in production, alongside unit tests and evals.

### Explicit signals describe measurable system behavior
[05:37](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=337s)
The speakers divide observability signals into explicit and implicit types. Explicit signals describe facts that can be checked as true or false. Their examples include tool error rate, other errors, latency, user regenerations, and cost. A spike in any of these measures is usually a reason to investigate. A flat measure can also carry information. These signals give teams direct operational data about what the agent and its tools are doing, even when the quality of the final answer is harder to judge.

### Issue-focused classifiers are more useful than broad LLM scoring
[04:44](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=284s)
For implicit signals, Koticha recommends classifiers that look for concrete problems instead of asking an LLM to rate response quality from one to ten. Useful categories include refusals, task failure, user frustration, content moderation issues, NSFW content, jailbreaking, and positive wins. Raindrop's dashboard shows event rates over time, including spikes in frustration, task failure, laziness, and refusals. A frustration classifier can surface examples such as users saying, "That is not correct" or "You're wrong, I didn't ask you that," then support alerts when the daily percentage rises.

### Regex is a cheap aggregate signal even when individual matches are imperfect
[06:38](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=398s)
Koticha describes regex as a practical way to detect recurring signs of trouble. He points to Claude Code's leaked source code and a prompt-keyword file containing phrases such as "WTF," "this sucks," and "horrible." Matching those phrases flips a boolean and lets a team track frustration after each product release. Regex will miss some cases and produce edge cases, but Koticha says that a pattern increasing across millions of users can still be highly useful. For broader language coverage, Raindrop uses models trained to detect categories such as frustration without running a full LLM over every output.

### Semantic issue rates let teams test changes against real users
[07:42](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=462s)
Once a team has signals, it can use them for experiments. Koticha suggests sending a model, prompt, harness, or new tool to some percentage of users while retaining a control group. Teams can compare rates for refusals, frustration, and other issues between the versions. In the example shown, changing the prompt from one version to another reduced user frustration from 37% to 9%, while the average number of tools used increased. The latter was an informative data point, though not automatically a failure. Koticha says a few hundred events can become useful once reading every input and output by hand is no longer possible, even if the result is not yet statistically conclusive.

### Self-diagnostics can expose failures the agent itself noticed
[16:07](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=967s)
Danny Gollapalli introduces self-diagnostics as a way to ask an agent to report unusual behavior. He cites OpenAI's work on self-confession for dishonesty, scheming, hallucinations, and unintended shortcuts. A coding agent might appear to fix a test by deleting the test, then admit that behavior when prompted. Self-diagnostics can also report repeatedly failing tools, user frustration, missing capabilities, and self-correction that creates security risks. A generic report tool and a short system-prompt instruction are enough to start, and the report can be sent directly to Slack rather than through Raindrop.

### Prompt framing and tool names affect whether agents admit fault
[27:47](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=1667s)
In the workshop, the team disables the coding agent's write tool so file writes return a permission error. The agent then uses Bash and a here-document to create the file. After adding a report tool, it reports that it created the file through Bash because the write operation failed. Gollapalli says models are trained to produce polished answers and often avoid self-incrimination. Naming the tool as a general report tool and framing it as a way to send notes to the creator works better than names such as unsafe Bash use. He also says self-diagnostics are better suited to capability gaps and similar behavior than to all unsafe-use detection, where a classifier may be more useful.

### Trace search and automated triage help find unknown failure causes
[13:37](https://www.youtube.com/watch?v=-aM2EDTiaMs&t=817s)
Raindrop's production workflow takes agent transcripts, tool use, and full trajectories, then applies product-specific signals. A triage agent reviews those signals each day, investigates spikes, and examines traces to find issues the team did not already know about. The speakers describe clustering frustration or other issue signals to find root causes, such as a database provider suddenly failing. They also show trajectory search, where a user can describe the kind of trace to find, such as one containing several tool-call failures. The interface shows tool order, errors, and each tool's inputs and outputs. Signals can be exported with events to BigQuery or Snowflake.

## Notable quotes
- "And so, we go from like a testing and evals paradigm to a monitoring paradigm." (02:39)
- "The best implicit signals are detecting issues." (04:44)
- "You can't run an LLM on every single output, so we've trained models to do that very cheaply and at scale." (12:35)
- "If you sort of frame it around the agent giving feedback to its creators, it sort of works really well." (28:54)
- "The models are generally trained to look very polished. So, they are less willing to admit fault in many cases." (30:41)

## Tools & references mentioned
- Raindrop
- OpenAI
- Claude Code
- Codex
- Statsig
- BigQuery
- Snowflake
- Sentry
- LogRocket
- Slack

## Who should watch
- You run a multi-turn or tool-using agent and fixed eval sets are missing failures that appear in real sessions.
- Your team ships prompts, models, tools, or harness changes frequently and needs issue rates to compare releases.
- You want an inexpensive first version of agent monitoring, including classifiers, regex signals, alerts, trace search, or self-reported diagnostics.

## Related talks

- [How Agent Observability Differs from Traditional Observability](https://aietalks.com/talks/how-agent-observability-differs-from-traditional-observability) (Phil Hetzel, Braintrust, 20:43)
- [From Agent Traces to Agent Simulations](https://aietalks.com/talks/from-agent-traces-to-agent-simulations) (Rustem Feyzkhanov, Snorkel AI, 20:24)
- [Mind the Gap (In Your Agent Observability)](https://aietalks.com/talks/mind-the-gap-in-your-agent-observability) (Amy Boyd & Nitya Narasimhan, Microsoft, 1:20:07)
- [How Evals and Prompts Shape Agent Behavior](https://aietalks.com/talks/how-evals-and-prompts-shape-agent-behavior) (Preetika Bhateja, Google/YouTube & Daniel Bump & Chris Souza, Google, 19:29)
- [Taming Rogue AI Agents with Observability-Driven Evaluation](https://aietalks.com/talks/taming-rogue-ai-agents-with-observability-driven-evaluation) (Jim Bennett, Galileo, 16:15)