A Missing Primitive for AI Agent Improvement

Why Continuous Improvement Breaks in Production

Agents are increasingly growing in capabilities to autonomously take on longer horizon tasks. However, take a peek into what’s been driving these capabilities, and you’ll find teams passively waiting on frontier model releases or mimicking the newest harness engineering trend.

The industry has long known the mechanism to achieve continuous self-improvement: have an intelligent system (agent) define its own hill to climb, design its own feedback loop then let it recursively learn from its own past experiences. Projects like Auto Research show the loop working in miniature setups and on verifiable domains: give an agent a small training setup, let it edit the code, run a bounder experiment, check whether the metric improved then repeat. But most production long-horizon agents are never a single training file with a single hill to climb.

In production, the improvement signal is buried across millions of sessions. Teams take their best jab at continuous improvement by hand-rolling eval CI/CD pipelines on top of tracing and observability tools. In practice, that usually means handing exploratory data analysis off to a brutal raw-log query to coding agents.

A typical query from an engineer might look like: "For USWest1 and USEast1 service areas, what are the top 5 most frequently asked user requests, out of those requests, which ones are product-feature related and where the user expressed frustration, and how is this agent failure trending over the last month?"

Imagine what you’re actually asking Claude/Codex to do. The agent has to first find the right slice of latest production traces across service areas, users, timestamps, tools and sessions. Then it has to infer which requests are actually product-feature related (keyword-match “feature” or “product” is never enough). Then it has to attribute user frustrations to an agent failure, a missing product capability, or a incomplete environment response. Then it has to aggregate the pattern over time without losing the trace examples that prove the claim.

It’s easy to see how quickly this pipeline breaks down. Once a long-horizon agent grows in complexity and starts producing GB-scale session trajectories across scaled production interactions, the same queries keeps getting rerun. Each investigation forces the agent to re-read raw traces, re-infer the same concepts: cost exponentially climbs, and accuracy becomes impossible to trust.

The missing layer is a way to make the petabytes of data reusable before the question is even asked.

In Judgment, we call this Behaviors.

What are Behaviors in AI Agents?

Traces show what happened in a single session, but they do not by themselves, tell you which patterns are recurring, which ones map to product outcomes, or which ones are worth finding again. Behaviors become the semantic tags for recurring patterns inside production agent sessions.

At Judgment Labs, we see three types of behaviors that matters in practice:

• User behaviors: what the user is asking for or implying in the session. Repeated asks after a missed answer, explicit complaints, escalation or handoff requests.
• Agent behaviors: what the agent decides or does. Stopping after one empty search result, saying it cannot find a record that exists, claiming a failed action succeeded, or leaking/editing data it should not.
• Environment behaviors: what the agent is given by its environment. Empty tool results, stale knowledge, schema mismatches, and timeouts or rate limits.

These behaviors highlights the important windows of a full session trajectory (e.g user frustration on unresolved support tickets, agent stopping after one empty search result, stale retrieval that sends the agent down the wrong path.)

The important part is that the tag stays attached to the trace. Once Judgment creates a Behavior, it becomes a durable signal that teams can monitor, search, collect into a dataset, or use to test whether an agent change climbed the right hill.

How Behaviors Close the Improvement Loop

Once a Behavior exists, it does two jobs.

The first obvious use case is online monitoring. Teams need to watch over high consequence workflows: PII leakage, unauthorized edits, false refusals across your production interactions. This is uniquely hard for long-horizon agents because the failure happens deep inside the trajectory. We instrument these with Agent Judge so the signal is cost-effective to product and accurate enough to act on.

The second is behavior-indexed search. With Behaviors, teams can semantically query over traces that already have rich precomputed meaning. "Support tickets are not resolving" becomes searchable indexes like user frustration, agent premature stops, irrelevant refund-policy retrieval, and repeated escalation. Once Behaviors give you the ability to get down to the right slice of data, you can turn that slice into a dataset to curate specific benchmarks, use automations to chain downstream actions like alerts or triage root-cause agents, and run tests to compare whether the proposed change actually affect new rollouts.

Getting the most out of your production data starts with monitoring behaviors. Bring us a sample set of your traces and we’ll show you which user, agent, and environment behaviors are hiding within them.