These aren't headline-grabbing use cases. But when they run unsupervised, the stakes change. When an agent goes off the rails at 2am, it doesn't just produce bad output. It burns through tokens, racks up API calls, and consumes compute until something stops it. We've invested heavily in evals and they're a critical part of our reliability story. But we knew they weren’t the whole answer.
Why it’s hard to define “normal” for agents
Andrej Karpathy (a founding member of OpenAI and former Director of AI at Tesla) has described agents as "spiky entities": stochastic, sometimes unreliable, but extremely capable when directed well. He's right, and that tension is the whole point.
LLMs are non-deterministic, and that's why they're useful. The same prompt can produce different outputs every time. Non-determinism is what gives agents their creativity, their ability to adapt to novel inputs, their capacity to handle edge cases no rule book could anticipate. You wouldn't want a deterministic content agent because it would produce the same stale output on every run.
But non-determinism means you can't write a static rule for what an agent ‘should’ do. You can't hardcode the expected sequence of tool calls, because a good agent might take a different path each time and still get it right. The variability is the value.
Managing a non-deterministic system is a lot like managing a creative team. You don't want to script every decision; that's what makes them valuable. But you need to know when someone's gone off-brief. You can't define "good" as one exact sequence of steps. You have to learn what the range of normal looks like, and flag when something falls outside it.
That's the core challenge we wanted to solve. Not just "is the output safe?" (that's what content guardrails are for). Not just "did the output look good?" (that's what evals are for). But: is this agent behaving within its normal range, right now, in real time – and can we rescue it if it isn't?
Why evals only tell half the story
Most AI guardrails work like inspecting products as they leave the factory. You check every item at the door. If it looks right, it ships. But you never watch the assembly line.
A machine drifting out of calibration produces parts that look fine today but will fail next week. Suppose an agent calls the right tools in the wrong order, or usually searches three sources but suddenly searches twelve, or skips a step it has never skipped before. The output may pass inspection, but the behavior is wrong, and by the time the output starts looking wrong too, you've shipped thousands.
This is where the distinction between output quality and execution quality becomes critical. They are fundamentally different things. Evals focus entirely on output quality: Did we get the right answer? But they completely ignore execution quality: How did the agent get there, and what happened along the way?
We needed something that could watch the assembly line, not just inspect what comes off it.
Why behavioral monitoring is the missing layer
Before we built anything new, we needed to know what was already out there. We found that the landscape falls into three categories:
