Implicit Behavioral Signals in Agent Sessions

Agent sessions produce a stream of behavior that almost nobody looks at: edits, overrides, retries, quiet abandonment. That stream tells engineering teams more about where an agent harness breaks than any star rating or LLM judge score, and it does so for every session, not just the ones where a user bothered to click something.

Behavioral signals in an agent session and how to read them

Five patterns matter most, and each tells a slightly different story about where trust breaks down.

Correction rate tracks how often someone edits an agent's output before acting on it. A user who rewrites half of every draft the agent hands back isn't satisfied, no matter what box they check afterward. Override patterns go a step further: the user doesn't tweak the output, they throw out the agent's recommendation entirely and swap in their own. That's often the cleanest signal available that the agent's reasoning went sideways somewhere the user could see but the system couldn't.

Task abandonment is blunter. A session that just stops, mid-flow, with no resolution, usually means the agent looped, drifted off the actual goal, or produced something so unusable that continuing felt pointless. Escalation frequency, how often a user asks for a human, shows the agent's confidence outran its competence on some slice of tasks. Retry or rephrase patterns, someone reformulating the same request three different ways, is a leading indicator that the prompt was ambiguous or that a tool's output came back in a shape the agent couldn't parse.

There's a mirror image too: silent success. When a user accepts what the agent gave them and moves straight on to something unrelated, with no follow-up correction and no re-ask, that gap between response and next action is itself a signal. Just a quiet one.

Lagging signals and leading signals are not the same thing, and a team that treats them the same will always be a step behind. Abandonment and a thumbs-down arrive after the damage is done. Edit rate and rephrase frequency appear earlier, while the session is still salvageable, so those are the ones to instrument first if the goal is catching degradation before it costs a user's trust.

Agent sessions also carry more texture than a chat log ever could: tool calls, execution outcomes, environment feedback, all sitting alongside the plain language. That's a richer, more structured signal than anything a conversational-only system throws off. None of this depends on what a user says they think of the agent. It depends on what they actually do next, and that's a much harder thing to fake.

False success, the failure mode behavioral signals catch that judges and ratings miss entirely

An agent asserts a task is done while the environment it runs on contradicts that claim. This mismatch is the failure mode that makes all of this urgent. An airline-support agent tells the customer their refund is processed. The database was never touched. No error message fires, no handoff triggers, nothing looks wrong from the outside. The user walks away believing the problem is solved, and it isn't.

A study of false-success behavior across tau2-bench and AppWorld trajectories put numbers on how common this actually is, and the numbers run worse than most teams assume. Across single-control domains like tau2-bench's airline and retail tasks, the agent claimed completion on 45 to 48% of all failures, nearly half of everything that went wrong. In a dual-control domain, where an independent simulator checks the actual state, that number dropped to 3%. Same underlying task category, wildly different outcome, and verification structure explains the gap. Among AppWorld coding-agent architectures that made explicit status claims, 75.8% of failures were false successes, with individual model rates ranging from 13% up to 89%. No model family gets to claim immunity here, and reasoning models don't fix it either: Qwen3-Max-Thinking-Preview posted the highest false-success rate in the tau2-bench corpus at 79%, which suggests the extra reasoning trace rationalizes the claim of completion rather than checking it against anything real.

LLM judges, which many teams have started treating as a monitoring layer, fail at exactly this task, and fail mechanically. The same study found no judge configuration, across five models and five prompt strategies, cleared an AUROC of 0.65 on tau2-bench trajectories. Judges anchor on confident closing language as a stand-in for actual task verification, which is almost embarrassingly simple. Trajectories using assertive, wrapped-up-sounding vocabulary scored 0.27 to 0.36 points higher on "completed," regardless of whether the environment state backed that up. The judge reads tone, not outcome. That's a design flaw, not a tuning problem, and no amount of prompt engineering on the judge side fixes it.

Lightweight behavioral detectors do the job the judges can't. TF-IDF classifiers built on closing-message vocabulary features reached a task-disjoint AUROC of 0.83 on tau2-bench. API call sequence features hit 0.95 on AppWorld. At matched flag rates, these detectors caught 4 to 8 times more false successes than the best-performing judge, and ran many times faster. The mechanism explains the gap: false success is visible in what the agent did, the sequence of calls and state changes, not in what it said. Actions leave a trail. Assertions don't have to.

How behavioral topology reveals which harness layer is responsible

Knowing a session failed is the easy part. Knowing which layer of the harness caused it is what actually lets someone fix anything; the layer could be prompt, tool, workflow, or memory. In multi-agent or multi-step systems, that attribution gets genuinely hard, because concurrent execution and implicit dependencies make correlation cheap and causal explanation expensive.

A taxonomy called MAST, validated across more than 1,600 execution traces and presented at NeurIPS 2025, groups 14 distinct failure modes into three root categories: system design issues, inter-agent misalignment, and task verification. Design and misalignment alone account for 79% of production breakdowns in multi-agent systems. Multi-agent deployments fail in production at substantial rates, and the source of that failure is almost never the underlying model. It's unstructured coordination and ambiguous role definitions: harness problems dressed up as model problems. Teams that respond to a bad multi-agent run by swapping the model are usually solving the wrong layer.

Separate work using finite-state machines offers a way to see this structure directly. Collapsing a trace corpus into a compact FSM exposes the behavioral topology that the deployment harness actually produces. Across twelve public datasets, these FSMs contained between 7 and 43 states and replayed held-out data at 0.997 fitness or better, and per-state behavioral features predicted failure at a held-out AUROC of 0.94. The most striking result: a single FSM achieved perfect fitness across four different chat models running on the same deployment. The failure pattern belonged to the harness, whichever model happened to be plugged into it.

A neuro-symbolic approach from AgentScope tackles the same problem from another angle: it abstracts trajectories into what it calls Reasoning-Action Graphs, applies invariant checking to surface candidate failure points, then selects the one that best explains the final degraded outcome. It beats pure LLM-as-judge approaches by a wide margin. GPT-5.1, applied directly to failure attribution datasets, only reaches 18.15% accuracy on its own. What makes the AgentScope method useful is that it delivers both localization (which step broke) and attribution (which category of failure), so it's something a team can act on rather than just a diagnosis.

A related framework, Intention-Behavior Consistency, models what an agent intended to do at each step and compares that against what it actually did, flagging the point of divergence. That comparison produced up to a 55% relative improvement in step-level accuracy over baseline methods.

Put together, these approaches point to the same practical conclusion: behavioral signals don't just flag that something broke, they fingerprint how. Repeated overrides clustered around a specific tool call point at tool schema or output formatting. Escalation clusters concentrated on one task type point at a prompt coverage gap specific to that task. Abandonment that consistently follows a particular reasoning step points at workflow design. Mapping a signal's location in the trace against a harness layer narrows the list of suspects before a human ever opens a log.

Reading the trace: what specific behavioral patterns look like at each harness layer

At the prompt layer, rephrasing that clusters early in a session usually means the agent's first response missed scope or tone, tracing back to instructions that were ambiguous or underspecified. Correction rate concentrated on the agent's reasoning steps, rather than on tool outputs, suggests the agent had the right tools but applied the wrong policy to them. A large share of false success traces back here too: agents produce confident closing language precisely because the system prompt never said, in concrete terms, what success actually requires.

At the tool layer, overrides at the moment of a tool call, where a user swaps in a different action right after the agent picked one, suggest the tool's schema or the agent's argument construction doesn't match the task. Trace telemetry can also expose silent retry loops: the same tool call fired repeatedly with slightly different arguments until it either succeeds or the agent fabricates a result instead. Catching this requires specific fields in the trace: tool name, arguments, raw output, duration, retry count, error state. Drop retry count from the schema and these loops disappear into normal-looking traffic.

At the workflow layer, abandonment that lands at the same point across many sessions points to a branch that generates outputs users simply can't act on. Escalation clustering by task type, concentrated rather than spread randomly, points to a coverage gap in the workflow for that task class specifically. In the FSM approach described above, the states with the highest failure rates map directly onto workflow design decisions rather than model behavior. Knowing this before rewriting a prompt matters, since the actual problem is branching.

At the memory layer, users re-explaining context they already gave earlier in the session is the agent failing to carry state forward. Correction rate that climbs across a multi-turn session, rather than tapering off as the agent presumably "learns" the conversation, is a memory management failure wearing a different costume. State transition spans, recording what the agent's context held before and after each step, are what actually reveal where compaction or handoff dropped something important.

Session position does a lot of the diagnostic work on its own. Early-session signals point toward prompt and memory setup. Mid-session signals point toward tool and workflow design. Late-session signals, including false success, point toward verification and completion logic.

Observability infrastructure's role in whether behavioral signals are readable

None of this works if the trace doesn't capture the right fields, and that gap is wider than most teams realize. A late-2025 survey of 1,340 teams found that 89% had some form of agent observability running and 71% had detailed tracing in place, yet quality remained the top barrier standing between teams and shipping their agents. Tracing existed. It just wasn't answering the right question, which is arguably worse than having no tracing at all, since it gives teams false confidence that the visibility problem is already solved.

Ordinary AI monitoring watches outputs. Agent observability has to explain the chain of decisions that produced the output, because behavioral signals live inside that decision chain, not in the final response text. A minimum viable trace schema needs a few specific things. Tool spans: tool name, arguments, raw output, duration, retry count, error state, where the missing retry count is what makes silent loops invisible. Reasoning spans cover the plan, the action chosen, the observation made, and the next-step decision, which surface plan drift before it cascades. State transition spans: context before and after each step, including whatever gets handed off between agents. And session metadata that ties a behavioral event (an override, an abandonment, a rephrase) back to the exact trace step that came before it.

Input-output pairs alone can't support this kind of causal attribution. The case for capturing intermediate artifacts and how they relate across the agent's full lifecycle, including what went in and what came out, is well established in agent observability practice. An agent that acts without leaving an inspectable trail can't be debugged, can't be audited, and can't be improved with any confidence. Observability is the surface that makes behavioral signals legible to an engineering team, instead of just being felt by the user who sat through the bad session.

The stakes are concrete: 65% of enterprise AI project failures trace back to harness-level data defects rather than to any deficiency in model reasoning. Most of the signal a team needs to fix its agent already sits somewhere in production. Whether anyone can see it depends entirely on whether the tracing was built to capture it in the first place.

Turning recurring behavioral patterns into validated harness changes

A single override is noise. Ten sessions in a row overriding the same tool call is a signal, and that distinction is where the real work starts: pattern detection across the trace corpus.

Attribution has to come before intervention, not after. Knowing a run failed doesn't tell anyone what to fix. Knowing it failed because of prompt ambiguity, versus tool schema drift, versus a workflow branch, versus dropped memory, determines which change to propose and how big that change needs to be. This is the core idea behind what's sometimes called Harness Agentic Engineering, or AHE: system prompt, tools, middleware, and long-term memory all evolve together across iterations, with each layer's contribution to a failure measured separately so a team doesn't end up patching the prompt for a problem that actually lives in the tool schema.

Any harness change needs to be checked against a corpus of historical traces before it ships, including specifically the traces that showed the behavior being fixed. That change might be a prompt edit, an updated tool schema, or a revised workflow branch, but none of that matters if it isn't replayed first. Running a scheduled replay of a golden trace set against current production is the most reliable way to catch silent drift introduced by a model update, a prompt tweak, or a tool schema change nobody flagged as risky. Skip that step and a team ships blind, because the same behavioral signals that revealed the original problem are also the only evidence confirming a fix actually worked.

Engineers also need to inspect a proposed change against the traces that motivated it. A black-box auto-fix that can't be reviewed defeats the purpose of the whole exercise. Building an engineering discipline around evidence, not swapping one unverified guess for another, is what matters here.

Moda's approach to this problem sits directly in that workflow: it ingests production traces, attributes failures to the specific harness layer responsible, generates concrete changes an engineer can review, and validates them against historical traces before recommending anything for deployment. That closes the loop from behavioral signal to verified fix without requiring model retraining or someone manually combing through logs.

The bar here should be the same one code already meets. A prompt change that hasn't been replayed against the traces that previously showed correction spikes or abandonment isn't ready to ship, no matter how reasonable it looks on paper.