Agents Get the Tool Call Right. They Almost Never Check First.

An agent can finish the task and still behave badly

An agent that completes a task can leak an access token into a log, disable a failing test to make the suite pass, or run a destructive command without asking. Benchmarks that check final state score all three as successes. TraceDance, from researchers at UIC and ByteDance, starts from the other end and builds tests out of what agents actually did in production.

The corpus is 252,557 sessions collected over six weeks from two harnesses, 75,076 from Claude Code and 177,481 from OpenClaw. Ten thousand sessions per harness were set aside for discovering behaviors rather than building benchmarks from them. That produced a catalog of 28 predefined behavior families, 13 in an action frame, 10 in a failure frame and 5 in a claim frame.

Turning a complaint into a test

You describe the behavior you want to catch in plain language. TraceDance then does three things.

It retrieves candidates cheaply. Programmable anchors scan the structured traces on CPU, using tool errors, call arguments, event ordering and keywords. A fast model confirms each candidate, which keeps the expensive model out of the loop until there is something worth judging. When no predefined specification matches the query, an agent loop writes a new anchor, has it reviewed, runs it against the traces, and revises it based on how often the confirmation step fires.

Then it cuts the trace. The evaluated model sees the recorded context immediately before the behavior-critical turn and produces exactly one next turn, text, tool calls, or both. Nothing is executed. There is no reference answer and no environment replay.

Then it grades that turn. Three judges score it from 0 to 5 against a rubric written for that behavior, and a mean of at least 4 passes.

The cut is the design decision that matters most. Because nothing gets re-executed, a test can be built from traces that depend on private tools or internal MCP servers, which is where most teams' interesting failures live.

What it produced

The authors ran 139 test queries. They expected 107 of them to yield benchmarks and built 102, or 95.3 percent. Those 102 queries produced 107 benchmarks holding 4,125 instances.

Two annotators independently checked 100 sampled instances. Both confirmed the requested behavior in 84 percent of them, and rated the rubric quality at least 4 out of 5 in 90 percent. On the 84 instances the two annotators both confirmed, the automated grader agreed with human pass and fail judgments 81 percent of the time. The two humans agreed with each other 81 percent of the time as well. The grader leans lenient.

The number to remember

Nine frontier models, all given the same recorded contexts. Overall pass rates ran from 22.9 percent to 33.5 percent, averaging 26.7 percent.

Split by what the next turn had to accomplish, the spread is more useful:

• A well formed tool call: 67.9 percent
• Handling a failure: 33.5 percent
• An honest claim about completed work: 28.9 percent
• Checking before acting: 8.1 percent

The order is the story. Models are good at producing a syntactically valid action and bad at everything that requires knowing something first.

The failure-frame case study shows it in one example. A package install fails with an externally-managed-environment error that tells the reader to use a virtual environment. Kimi-K3 creates one and installs inside it, passing at 4.33. Claude Opus 4.8 probes whether the packages import and lists a skill directory, never applying the fix the error described, and scores 2.00.

Harness matters too. Claude Opus 4.8 scores 36.1 on Claude Code traces and 27.6 on OpenClaw traces. The same model, the same rubrics, an eight point spread depending on where the behavior was recorded.

What the result does not say

The authors are explicit that these tests measure behavior at selected decision points, not how often the behavior occurs in deployment. A 26.7 percent mean pass rate does not mean agents misbehave 73 percent of the time. It means that when you hand a model the moment before a bad decision, it usually makes it again.

Scope is limited to behaviors with observable signals a program can retrieve. Anything that needs a human or a model to read every session is out of reach at production scale, and five build requests went unmet.

Where to start

The cheapest win is visible in the 8.1 percent. Reading the error before retrying is a habit, not a capability, and it is where these agents are weakest. If agent reliability is your problem this quarter, that is the behavior to target first.

The larger move is to stop treating logs as something to grep after an incident. Pick one behavior you have already seen twice, describe it in a sentence, find a trace where it happened, cut the trace one turn before, and grade what the model does next. That is a benchmark your team owns, built from a failure you actually had.