AI Agent Evaluation on Real Tasks: Behavioral Signals, Causal Tracing, and Net Improvement Rate

Why Traditional Evaluation Methods Fall Short

As AI agents move from research labs into production, objectively measuring how a model performs on real tasks has become a shared concern for developers and enterprise users. Traditional evaluation approaches fall into two broad categories: static benchmarks that score models against fixed question sets, and human preference voting, where users compare two responses and choose the better one.

Both have significant limitations. Static benchmark questions are often disconnected from real-world usage—a model can achieve high scores through targeted optimization while performing only averagely on actual tasks. Human voting does bring human judgment into the loop, but voting scenarios usually involve short, single-turn exchanges, which fail to capture the dozens of steps of planning, tool calling, and error recovery that agent work often requires. More importantly, votes measure which response looks better, not which model actually drove the task to completion.

What the industry needs, then, is an evaluation paradigm that is closer to real usage, less dependent on subjective preferences, and able to scale.

Mining Evaluation Signals from Real Sessions

One practical approach is to stop constructing artificial evaluation scenarios and instead analyze the agent sessions that real usage already generates. When users collaborate with agents on long-horizon tasks, they naturally leave behind a large volume of high-value signals. These signals require no extra voting from users—they can be extracted automatically from behavior.

Common extractable signals include:

• Explicit confirmation: The user acknowledges that the task result is acceptable—for example, confirming a problem is solved or accepting generated code or configuration.
• Praise and complaints: Users express satisfaction or dissatisfaction in natural language. Such signals are sparse, but they carry high confidence.
• Correction instructions: The user points out a mistake and gives a direction for fixing it—for example, “No, you should validate the parameters first.” These signals directly expose where the model struggles to adjust course.
• Command execution errors: In tasks involving command-line operations, failed executions, error messages, or unexpected output are direct evidence of reliability problems.

What these signals share is that they occur while the task is in progress, not as a subjective rating after the fact. They reflect whether the task actually moved forward, not whether a response was pleasing.

Causal Tracing: Estimating the Net Improvement Rate

Once the signals are available, the next step is turning them into comparable metrics. Simply counting signal occurrences introduces bias: tasks differ in difficulty, and users differ in how they express themselves. A model may appear better merely because it happened to be assigned easier tasks.

This is where a randomized inference method—referred to here as causal tracing—comes in. The core idea: across a large volume of real sessions, model selection and task assignment are approximately random, so by comparing how different models perform on the same category of tasks, you can estimate each model’s net improvement relative to the overall average.

In simplified terms:

Net improvement rate = the model's success rate on a task - the average success rate of all models on that task

By stratifying on variables such as task type, user behavior patterns, and session length, causal tracing can partially strip out confounding factors and produce estimates closer to a true causal effect. In the end, each model receives a net improvement rate relative to the average: positive means above average, negative means below.

The appeal of this method is that it requires no active voting from users and no manual annotation, and it can update continuously as real usage grows—forming a scalable, sustainable evaluation loop.

Evaluation Dimensions: Beyond “Answering Correctly”

The biggest difference between agent tasks and ordinary Q&A is that agents must execute multiple steps, call tools, and adjust dynamically. Evaluation dimensions must expand accordingly. Beyond the overall net improvement rate, several fine-grained metrics matter:

• Command execution reliability: When running scripts or configuring environments, can the agent consistently produce commands that are both executable and correct? This directly determines whether the task can be delivered.
• Steerability: When the user issues a correction or adjustment, can the agent quickly understand it and change course? A poorly steerable model repeatedly makes the same mistakes and drags down task progress.
• Long-horizon task maintenance: In tasks spanning dozens of interaction rounds, does the model drift from the goal, lose context, or redo work?
• Reasonable tool usage: Does it call the right tool at the right time, without over-calling or skipping critical steps?

These fine-grained metrics complement the overall net improvement rate and help developers locate specific weaknesses rather than looking at one aggregate ranking.

How Open-Weight Models Perform in Real-Task Evaluations

Under evaluation systems of this kind, the performance of open-weight models is worth watching. Recent open-weight models, after substantial increases in parameter count, have taken the leading position among open models in real agent task evaluations, with balanced performance across categories such as work, coding, and chat.

Public evaluation data points to clear progress in several areas:

1. Higher overall net improvement rate: Compared with previous generations, the net improvement rate has grown by several percentage points, indicating that average real-task performance is genuinely improving.
2. Better command execution reliability: In tasks involving command-line operations, failure rates have dropped and the executability of generated results has improved.
3. Improved steerability: Faced with user corrections, these models converge on the right direction faster, reducing the cost of back-and-forth communication.

These gains usually trace back to training data quality, coverage of task diversity, and post-training reinforcement of tool use and long-horizon planning. That said, a single leaderboard ranking should serve only as a reference—actual model selection still requires validation against your own business scenarios.

Practical Recommendations for Developers and Enterprise Users

If you are choosing an agent model for your team or organization, consider the following:

• Prioritize real-task metrics: Don’t rely on static benchmark scores alone; examine performance on long-horizon tasks, tool calling, and error recovery.
• Build your own evaluation set: Sample real tasks from your business to construct a small but highly representative evaluation set, and run regression tests on it regularly.
• Watch steerability and reliability: In production, whether a model follows corrections and executes commands reliably usually matters more than how polished its answers sound.
• Track continuously instead of deciding once: Models iterate quickly and evaluation results are time-sensitive. Establish an ongoing evaluation process rather than making a one-time choice and never revisiting it.

Conclusion

Evaluating agents on real tasks is shifting from preference voting toward behavioral signals combined with causal inference. By mining confirmations, complaints, corrections, and execution errors from real sessions, and by using randomized inference to estimate net improvement rates, we can measure a model’s real-world value more objectively. For developers and enterprise users, understanding this evaluation logic not only helps you read leaderboards critically—it also helps you build an evaluation framework that fits your own needs.