From Benchmark Scores to Closed-Loop Execution: How to Evaluate General-Purpose AI Agents

1. A High Benchmark Score Does Not Equal Higher Intelligence

As foundation models continue to evolve, industry discussions often begin with aggregate benchmark scores: mathematical accuracy, breadth of knowledge, code generation reliability, or performance on complex reasoning tasks. These metrics are useful, but judging whether a model has achieved a generational improvement based only on its overall score can obscure a more important shift.

The value of AI systems is moving from generating an answer that appears correct to continuously completing a verifiable task under defined constraints.

Traditional benchmarks generally use a relatively static input-output pattern:

• The model receives a question, context, or instruction.
• It produces an answer in a single turn or a limited number of turns.
• An evaluator calculates a score using a reference answer, rule matching, or human annotation.

This format is effective for measuring language understanding, knowledge coverage, local reasoning, and communication quality. However, it does not fully capture the complexity of real work. Enterprise tasks are rarely isolated questions. They often involve goal decomposition, information retrieval, tool selection, state tracking, retries, result validation, and access control across a continuous workflow.

As a result, a model whose aggregate benchmark score has not increased significantly may still have improved in important ways. Conversely, a major improvement in task-oriented metrics does not necessarily mean that the system has reached artificial general intelligence.

A more precise conclusion is that the model’s capability profile may be shifting—from static question answering toward dynamic task execution.

2. From Answering Questions to Completing Tasks

To understand next-generation agent systems, it is important to distinguish language-model capability from task-execution capability.

2.1 Question Answering Focuses on Local Correctness

In a question-answering scenario, the central question is:

Is the answer correct, complete, and clear?

For example, a user may ask when a particular system design pattern is appropriate. The model can provide a conceptual explanation, discuss its advantages and disadvantages, and include sample code. If the response is logically correct and clearly written, it can usually be considered high quality.

However, this capability has clear limits:

• The model does not need to access a real system.
• It does not need to execute the code.
• It does not need to handle external API failures.
• It does not need to take responsibility for the final business outcome.
• It does not need to maintain a stable state during a long-running process.

2.2 Task Execution Focuses on the End-to-End Loop

An agent performs a different kind of task:

Can it achieve a goal in a dynamic environment with limited resources and explicit constraints?

Consider the task of diagnosing an issue in an online service. An agent with genuine execution capability should do more than provide troubleshooting suggestions. It should be able to perform a process such as:

1. Identify key symptoms in the incident description, such as rising error rates, increased latency, or exhausted resources.
2. Use its permissions to read monitoring metrics, log summaries, and change records.
3. Prioritize possible causes.
4. Select appropriate tools to test each hypothesis.
5. Generate an auditable remediation recommendation after identifying an anomaly.
6. Request human approval before taking high-risk actions.
7. Verify whether key metrics have recovered after remediation.
8. Produce an incident report, evidence trail, and preventive recommendations.

The difficulty is not simply whether the model understands technical concepts. It is whether the system can make reliable decisions over time. It must maintain state across multiple execution rounds, interpret tool results, identify ineffective paths, revise its plan based on feedback, and control risk under uncertainty.

This is why evaluations for automation, terminal operations, scientific computing, code execution, and security validation can reveal more about an agent system’s practical engineering capability than a single knowledge benchmark.

3. Five Core Dimensions of Agent Capability

When determining whether a model is suitable as the execution core for complex tasks, evaluate it across several dimensions rather than relying on a single aggregate score.

3.1 Planning and Task Decomposition

Complex tasks usually need to be divided into multiple executable steps. A strong agent should not merely produce a long checklist. It should build a plan based on dependencies between tasks.

For example, a data analysis task may be divided into the following steps:

• Clarify the business question and reporting definitions.
• Check data availability and the relevant time range.
• Clean, deduplicate, and handle anomalous data.
• Calculate the core metrics.
• Verify that the results comply with common-sense expectations and defined constraints.
• Generate conclusions and visual explanations.

When evaluating planning capability, examine whether the model can:

• Identify prerequisites.
• Distinguish critical steps from supporting steps.
• Adjust its plan dynamically.
• Ask clarifying questions when information is insufficient.
• Avoid excessive decomposition and meaningless loops.

3.2 Tool Use and Environment Interaction

Real-world tasks are rarely completed through text generation alone. An agent may need to work with databases, file systems, retrieval services, code execution environments, monitoring systems, message queues, or internal business APIs.

Tool use is not equivalent to producing a correctly formatted tool call. The important questions are:

• Did the system choose the right tool?
• Does it understand the business meaning of the parameters?
• Can it extract useful information from the response?
• Can it identify failures, timeouts, and permission problems?
• Does it check constraints before performing high-risk operations?
• Can it record the call for later investigation?

From an engineering perspective, tools should be defined as structured capability units rather than allowing the model to construct arbitrary commands. A tool description should include, at minimum:

• Input constraints.
• Output structure.
• Permission level.
• Side-effect description.
• Rate limits.
• Semantics of error codes.

3.3 Long-Context Processing and State Management

Long-running tasks can span dozens or even hundreds of steps. If the system cannot maintain reliable state, it may repeat actions, skip steps, contradict previous decisions, or overwrite correct results.

A useful state model has three layers:

• Short-term working memory: Information being processed in the current turn.
• Task state: The goal, plan, completed steps, failure reasons, and pending confirmations.
• Persistent knowledge: Validated rules, historical cases, and indexes of business documents.

Not all information should be placed in the context window. As a task grows, redundant content increases reasoning costs and can interfere with the model’s decisions. State summarization, evidence references, and structured storage are more effective approaches.

A simplified task state could look like this:

{
  "goal": "Identify and mitigate slow API responses",
  "constraints": {
    "allow_write": false,
    "human_approval_required": true
  },
  "completed_steps": [
    "Read latency metrics from the past hour",
    "Checked recent deployment records"
  ],
  "current_hypotheses": [
    {
      "name": "A downstream dependency is responding slowly",
      "confidence": 0.72,
      "evidence": ["Dependency call latency has increased significantly"]
    }
  ],
  "next_action": "Query the health status of the dependency service"
}

Compared with a long natural-language log, this structured state is easier to audit, recover, and integrate into system orchestration.

3.4 Self-Validation and Error Recovery

Agent reliability depends not only on whether the first decision is correct, but also on whether the system can detect and correct errors promptly.

Common failures include:

• Tool parameters that violate constraints.
• Empty responses or changed data formats.
• Execution results that differ from expectations.
• Unsatisfied prerequisites.
• Ambiguity in the task objective.
• Changes in the external environment.

A mature task system should implement an execute-observe-validate-adjust loop. Each step can be represented as follows:

Plan an action
  ↓
Execute a tool
  ↓
Obtain an observation
  ↓
Check whether the result meets expectations
  ↓
If yes: continue to the next step
If no: revise the hypothesis, retry, or escalate to a human

Validation should rely on objective rules whenever possible, rather than asking the model to judge its own output. For coding tasks, this may include test cases, static checks, and runtime results. Data tasks can use data-quality rules. Operations tasks can use error rates, throughput, and latency as verification signals.

3.5 Security Boundaries and Permission Awareness

The more capable an agent is at executing tasks, the more important security governance becomes. A system that can proactively use tools, modify configurations, or access data can magnify risk if it lacks effective access controls.

A layered authorization model is recommended:

• Read-only access: Query logs, read metrics, and retrieve documents.
• Low-risk write access: Create drafts, generate tickets, and save analysis reports.
• Controlled execution access: Perform reversible operations subject to policy validation.
• High-risk access: Production changes, sensitive-data exports, financial actions, or identity operations that require human approval.

The system should also explicitly prohibit agents from bypassing security policies, expanding their own privileges, or writing sensitive information into uncontrolled context. For cybersecurity and vulnerability-validation scenarios, use isolated environments, least-privilege access, behavioral auditing, and human review to prevent technical capability from becoming an uncontrolled risk.

4. Why Aggregate and Task Benchmarks Can Diverge

Aggregate evaluations and task evaluations measure different things, so their scores can diverge without indicating a contradiction.

4.1 Traditional Questions Emphasize a Single Reasoning Result

Static questions generally ask the model to produce an answer within a limited context. Even if the model’s tool-use capability, memory mechanisms, and workflow-control ability improve substantially, the final score may not change much if those capabilities are not part of the test.

4.2 Task Evaluations Emphasize Process Quality

Task-oriented evaluations consider more than the final answer. They may examine:

• Whether the correct tool was selected.
• Whether all necessary steps were completed.
• Whether the system recovered from failure.
• Whether permission constraints were followed.
• Whether the task was completed within time and budget limits.
• Whether the final artifact is verifiable.

Therefore, a model that improves only slightly on knowledge-based question answering may still deliver a significant improvement in automation tasks if its planning, interaction, and validation capabilities become stronger.

4.3 Agent Performance Depends on System Engineering

Task outcomes are not determined solely by the foundation model. They are also shaped by the surrounding system, including:

• Prompts and task templates.
• Tool quality and interface design.
• Memory and retrieval strategies.
• Schedulers and workflow orchestration.
• Retry mechanisms.
• Validators.
• Permission management.
• Observability and alerting.

When evaluating an agent solution, enterprises should test both model capability and system capability. Comparing only the model’s standalone benchmark score cannot accurately predict performance in production.

5. Build an Evaluation Framework Around Business Outcomes

For development teams, a more practical approach is to create a tiered evaluation system based on their own tasks.

Tier 1: Basic Capability Evaluation

This tier confirms whether the model is fundamentally usable:

• Instruction-following accuracy.
• Structured-output success rate.
• Domain knowledge accuracy.
• Code or text generation quality.
• Consistency across multi-turn interactions.

Tier 2: Tool and Workflow Evaluation

This tier verifies whether the model can participate in real workflows:

• Tool-selection accuracy.
• Parameter accuracy.
• Successful tool-call rate.
• Failure-recovery success rate.
• Task-step completion rate.
• Average number of execution rounds.

Tier 3: Business Outcome Evaluation

This is the most important tier because it connects directly to business goals:

• Is ticket resolution time reduced?
• Are repetitive manual operations reduced?
• Is the delivery cycle for analysis reports shortened?
• Is the defect detection rate improved?
• Does the human approval rate for critical tasks improve?
• Are risks caused by automation controlled?

Each task category should have explicit acceptance criteria. For example, a report-generation task should not be judged only by language fluency. It should also verify whether data references are correct, calculations are reproducible, conclusions are supported by evidence, and uncertainties are clearly stated.

6. A Practical Architecture for Enterprise Agent Systems

An enterprise-oriented agent system can use the following layered design.

6.1 Interaction Layer

This layer receives user requests, displays execution progress, and collects human feedback. For high-risk tasks, it should provide confirmation points where users can review the plan, evidence, and potential impact.

6.2 Orchestration Layer

This layer handles goal decomposition, task scheduling, state-machine management, timeout control, and retry strategies. It should not rely entirely on the model’s unrestricted behavior. Explicit workflow constraints are especially important in finance, operations, security, and data-governance scenarios.

6.3 Model Reasoning Layer

This layer interprets requirements, generates plans, selects tools, explains results, and handles exceptions. The model should be treated as a decision component, not the sole controller of the system.

6.4 Tool Execution Layer

This layer packages callable capabilities as controlled tools, including data queries, document retrieval, code execution, notifications, and monitoring access. Each tool should have clearly defined inputs and outputs, permission boundaries, and audit records.

6.5 Validation and Governance Layer

This layer is responsible for result validation, content safety, permission checks, sensitive-information protection, audit logging, quality monitoring, and anomaly alerts. It is a key factor in determining whether a system can move from a demonstration environment into production.

When deploying in the cloud, organizations can use general-purpose container platforms, object storage, message queues, logging services, monitoring and alerting systems, and key-management capabilities to build the infrastructure. If an organization uses Baidu AI Cloud, the same principles apply: define task boundaries and security requirements first, then use appropriate cloud resources for isolation, observability, and elastic scheduling. Model capability should not be treated as equivalent to business automation capability.

7. Use Caution When Assessing Progress Toward General Intelligence

“Artificial general intelligence” is a far more complex question than model benchmark performance. A system approaching this goal would need to demonstrate strong and stable performance across multiple dimensions over an extended period:

• Understanding cross-domain objectives rather than solving only specific problem types.
• Learning and adapting in unfamiliar environments.
• Planning over long horizons while maintaining consistency.
• Reliably using external tools to complete closed-loop tasks.
• Recognizing uncertainty and actively seeking assistance.
• Following security constraints and social norms.
• Operating continuously and reliably within limited cost.

For now, a more accurate description is that some newer systems are exhibiting stronger agentic characteristics. They are gradually evolving from language generators into execution components that can participate in complex workflows.

This shift is already influencing software development, data analysis, operations support, customer service, and knowledge management. However, it remains far from proving that a system can autonomously handle any real-world problem. That question requires long-term, rigorous, and reproducible validation.

8. Conclusion: Focus on Verifiable Task Value

Model progress should not be judged by a single leaderboard. For developers and enterprise users, more useful questions include:

• Can the system complete real tasks rather than produce attractive answers?
• Can it recover from failure rather than stop after one error?
• Can it be monitored, audited, and constrained rather than become an uncontrollable black box?
• Can it consistently generate business value rather than perform well only in demonstrations?

Moving from answering better to finishing work reliably is a major direction for agent technology. Mature implementations are not defined by a particular label. They are built by combining task modeling, tool governance, result validation, and continuous evaluation to turn model capability into productivity that is controlled, reliable, and measurable.