How to Evaluate Large Language Model Intelligence and the Real-World Value of AI Agents

1. Start by Asking the Right Questions

When a new generation of large language models is released, discussion often centers on three questions:

• Is it the most intelligent model available?
• Can it complete work independently?
• Has artificial general intelligence arrived?

These questions are related, but they are not interchangeable.

A model may perform exceptionally well in knowledge-based question answering and complex reasoning while struggling to operate real software. Another model may be better at calling tools, editing code, or navigating user interfaces without leading across every knowledge domain. Whether either model qualifies as artificial general intelligence cannot be determined from a single demonstration or benchmark result.

The evaluation focus should therefore shift away from “Which model has the highest score?” and toward three more practical questions:

• On which tasks does the model demonstrate stable and reproducible capabilities?
• How much useful work can it complete within explicit limits on time, cost, and permissions?
• When the environment changes, information is missing, or an action fails, can it detect the problem and recover safely?

The term “intelligence” becomes meaningfully comparable only after the task boundaries, resource constraints, and acceptance criteria have been clearly defined.

2. Why General Intelligence and Task Execution Can Diverge

2.1 General evaluations sample only part of a model’s capabilities

Broad model evaluations commonly cover areas such as knowledge comprehension, mathematical reasoning, code generation, instruction following, and multimodal understanding. These tests can reveal the shape of a model’s capabilities, but every aggregate score depends on the tasks selected and the weights assigned to them.

If an evaluation gives greater weight to mathematical reasoning, a model that excels at formal derivation may rank higher. If the evaluation adds realistic software-operation tasks, the ranking may change.

A higher aggregate score should therefore mean that a model performed better under a particular set of questions, scoring rules, and test conditions. It should not be interpreted as evidence that the model is superior at every kind of work.

At a minimum, comparisons should examine:

• Whether the test set represents the target business workload
• Which subcategories contribute to the total score and how they are weighted
• Whether the models receive access to the same tools and external information
• Whether reasoning time, retry limits, and context length are controlled consistently
• Whether the reported difference is larger than the variation observed across repeated tests

Without these controls, a single overall score can create an unjustified sense of certainty.

2.2 Agent performance depends on the entire execution system

A conventional question-answering task primarily measures whether a model can produce a correct response. An AI agent must repeatedly complete an observation-planning-action-verification loop.

Consider fixing a defect in a business application. The agent may need to:

1. Read and interpret the requirements.
2. Locate the relevant code.
3. Analyze dependencies.
4. Modify the implementation.
5. Run tests.
6. Check whether the change introduced regressions.

A model may explain the cause of the defect accurately without being able to complete all of these actions successfully.

From an engineering perspective, task performance can be expressed conceptually as:

Task outcome = the combined effect of model capability, tool capability, context management, the execution environment, and verification mechanisms.

This is not a mathematical law. It is a framework for breaking down system performance. Any weakness in the execution stack may constrain the final result.

The same underlying model can produce substantially different outcomes when paired with different tool orchestration, retrieval strategies, context-management methods, or validation workflows. An evaluation should therefore state whether it measures the model in isolation or the complete system formed by the model and its execution framework.

3. Computer-Use Capability Is More Than Clicking the Right Button

Computer-use capabilities allow an agent to interact with software through graphical user interfaces. This is valuable when business systems lack stable APIs or when a workflow spans multiple applications and cannot be completed through text generation alone.

Typical tasks include:

• Searching for information
• Organizing spreadsheets
• Completing forms
• Managing files
• Reconciling records across multiple systems

Reliable computer use, however, requires much more than locating buttons on a screen.

3.1 A complete workflow must extend from interface understanding to outcome verification

A practical computer-use agent must handle at least the following stages:

1. Observe the current state: Identify the active window, visible content, input focus, and system messages.
2. Build a plan: Break the business objective into executable steps and identify prerequisites.
3. Perform actions: Enter data, select controls, navigate between pages, or move files.
4. Inspect feedback: Confirm that each action took effect rather than assuming every operation succeeded.
5. Correct deviations: Adjust the workflow when it encounters timeouts, pop-ups, insufficient permissions, or layout changes.
6. Validate the final state: Verify that the business result meets the requirements instead of treating a click on “Submit” as proof of completion.

Outcome verification is often more important than action generation. A system may display a success message even when the wrong record was submitted, a field contains incorrect data, or an outdated attachment was used.

3.2 Long workflows amplify small error rates

Assume, for illustration, that every action has a 98% success probability and that the steps are independent. The probability of completing 30 consecutive steps successfully would be approximately:

0.98³⁰ ≈ 54.5%

This is only a simplified illustration of long-workflow risk, not a performance claim about any real system. In production environments, errors may be correlated, and some operations can be retried or recovered.

The example nevertheless highlights an important point: strong performance on individual actions does not guarantee reliable end-to-end execution.

Improving business-level success rates requires more than increasing click accuracy. Teams must also remove unnecessary steps, introduce checkpoints, verify intermediate states, and design effective recovery paths.

3.3 Graphical interaction should not replace every other integration method

When a stable and controlled API is available, structured calls are generally easier to validate, audit, and maintain. Graphical user interface interaction is better used as a supplement when APIs are unavailable, workflows cross systems, or processes are not standardized.

A sound engineering strategy is to:

• Prefer stable interfaces for deterministic operations
• Use graphical interaction only where necessary
• Apply consistent outcome verification across both methods
• Enforce appropriate permission controls

The fact that a model can operate a graphical interface does not mean every workflow should be redesigned as a sequence of screen interactions.

4. Building a Trustworthy Model Evaluation Framework

4.1 Define success with real tasks, not answer quality alone

Organizations should extract representative tasks from actual work and define independent acceptance criteria for each one.

For a code modification task, it is not enough to decide whether a patch appears reasonable. The evaluation should also determine:

• Whether the original problem was reproduced correctly
• Whether the change passes the relevant tests
• Whether existing functionality was broken
• Whether the modification expands permissions or introduces security risks
• Whether unrelated files were changed
• Whether the delivery notes provide enough information for human review

For an information-processing task, acceptance criteria may include factual accuracy, field completeness, source traceability, and correct handling of duplicate records.

Whenever possible, these criteria should be established before testing begins. Otherwise, evaluators may unintentionally adjust the standard after seeing the results.

4.2 Standardize resource budgets for fair comparisons

Additional reasoning time, candidate attempts, or tool calls can improve performance, but they typically increase both cost and latency.

A useful evaluation should provide two complementary views:

• Fixed resource budget: Compare success rates under the same limits on time, cost, or tool usage.
• Fixed quality target: Compare resource consumption and human intervention required to meet the same acceptance criteria.

These perspectives are more relevant to business decisions than a comparison of maximum scores. A system may have a higher theoretical ceiling but still be unsuitable for high-volume production work if it requires frequent retries or extensive human correction.

4.3 Separate first-attempt success from success after retries

Completing a task on the first attempt is not equivalent to completing it after multiple tries. The two outcomes represent different levels of reliability.

Evaluations should record metrics such as:

• First-attempt success rate
• Success rate within a defined retry limit
• Average number of retries
• Human takeover rate

Failures should also be classified. Relevant categories may include:

• Incorrect task interpretation
• Tool failure
• Interface-recognition failure
• Insufficient permissions
• Missing or inadequate verification

Failure classification provides a clear direction for improvement. Without it, every problem may be incorrectly attributed to the model being “not intelligent enough.”

4.4 Report variability instead of overinterpreting small leads

Generative systems are stochastic, and their execution environments may also change. A small difference in one test run does not necessarily indicate a stable advantage.

Important tasks should be tested repeatedly. Reports should include the sample size and the number of successful and failed runs. Where appropriate, they should also provide confidence intervals.

Evaluations should incorporate newly created tasks, business variations, and non-public samples. This reduces the risk that a model has been overly optimized for known benchmark content.

5. Measure Cost per Accepted Outcome

A low cost per model call does not necessarily translate into a low delivery cost. A single task may involve multiple reasoning rounds, page observations, tool calls, failed attempts, and human review.

A more practical metric is:

Cost per accepted outcome = total execution cost ÷ number of tasks that pass acceptance

Depending on the business definition, total execution cost may include:

• Model usage
• Execution infrastructure
• Human review
• Failure handling
• Other operational resources

For high-risk actions, potential losses should be assessed separately. Risk should not be hidden inside a narrow calculation of model-call fees.

Time should also be measured end to end. Faster initial text generation does not necessarily mean faster task completion. Waiting for pages to load, repeatedly reading files, or following an incorrect execution path can substantially increase total latency.

At least three dimensions should be considered together:

• Quality: How many outputs actually pass acceptance?
• Latency: How long does it take from task submission until the result is usable?
• Cost: How many resources are consumed for each accepted result?

Organizations should choose the combination that satisfies their operational constraints rather than selecting a system solely because it leads on one isolated metric.

6. Greater Capability Requires Clearer Security Boundaries

An agent that can perform real actions has a different risk profile from a system that only provides recommendations. It may access sensitive data, modify business records, or trigger irreversible operations.

6.1 Separate what the agent can do from what it is allowed to do

Permissions should be granted dynamically according to the task and should follow the principle of least privilege.

Reading, drafting, submitting, deleting, and sending information externally should not automatically receive the same authorization level. High-risk operations, such as making payments, deleting records in bulk, or changing critical configurations, should require human approval or additional confirmation rather than relying entirely on the model’s judgment.

6.2 External content must not automatically become an instruction

Web pages, emails, documents, and logs may contain misleading or manipulative text. An agent must distinguish between the objective authorized by the user and content found in external materials.

For example, text on a web page that asks the agent to upload a file should not be allowed to change the original task or expand the agent’s authorized access.

Protection requires multiple layers, including:

• Restricting tool permissions
• Isolating sensitive credentials
• Validating the target of an operation
• Triggering alerts for abnormal behavior

6.3 Design for recovery and auditing

Before critical actions, the system should preserve the required state or use a rollback-capable process. Execution records should capture input sources, important decisions, tool actions, and results. At the same time, logs must be designed to avoid exposing sensitive information.

These records are not only for accountability. They are also essential for diagnosing failures, reproducing problems, and improving the system.

Without sufficient observability, production failures are often difficult to explain.

7. Does Leading a Benchmark Mean AGI Has Arrived?

This question requires a distinction among three separate concepts:

• Exceeding a human reference level on a particular test
• Demonstrating transferable and adaptable capabilities across a broad range of tasks
• Possessing consciousness or subjective experience

These concepts are not equivalent. Leadership on an individual test does not establish broad generality. Consciousness is also not the sole universally accepted criterion for artificial general intelligence, and there is no broadly accepted direct method for measuring it.

From an engineering perspective, more useful questions include:

• Can the system develop an effective strategy for an unfamiliar task with limited guidance?
• When information is insufficient, can it ask for clarification and communicate uncertainty?
• During long-running execution, can it maintain goal consistency and detect its own deviations?
• Can it transfer existing capabilities when the environment changes?
• Can it deliver stable results within safety constraints rather than depending on repeated trial and error?

Larger training scale may improve capabilities, but compute investment, hardware volume, or reports about training scale cannot by themselves establish specific performance.

Similarly, using models to generate data, write code, or design experiments does not prove that a self-improvement loop can operate without external validation. Any proposed improvement still requires independent testing, quality control, and safety evaluation.

8. Moving from Experimentation to Production

A cautious deployment strategy begins with tasks that have clear boundaries, easily verified outcomes, and recoverable failures. It should not begin with fully autonomous, high-risk workflows.

Step 1: Establish a baseline

Measure the existing human or automated process. Record completion time, error rate, and cost so that the agent can be compared against a meaningful reference.

Step 2: Build a realistic task set

Create a set of sanitized tasks based on real work. Include normal cases as well as unusual inputs, insufficient permissions, and environmental changes.

The distribution of task difficulty should reflect the production workload as closely as possible.

Step 3: Test in an isolated environment

Use a controlled environment with a fixed resource budget. Record the complete execution process and validate the outcome through independent rules or human review.

Step 4: Introduce human confirmation

Begin with a collaboration model in which the agent performs the task and a person confirms the result. This allows the organization to evaluate both output quality and the cost of human intervention on a limited scale.

Step 5: Expand permissions and scope gradually

Increase the agent’s permissions and task coverage according to the level of risk. Define stop conditions in advance.

If the error rate, abnormal-action rate, or human takeover volume exceeds a predefined threshold, expansion should pause until the cause has been investigated.

Evaluation must continue after deployment. Business rules, interface layouts, tool versions, and data distributions all change over time. Passing a test once does not guarantee continued effectiveness.

Conclusion

Determining whether a large language model is advanced requires more than reviewing an aggregate benchmark score. A smooth demonstration should not be mistaken for stable production capability.

For developers and organizations, the more important question is whether the complete system can consistently produce acceptable results for a defined task while staying within limits on budget, time, permissions, and risk.

Model capability determines potential. Tools, context management, and execution mechanisms determine whether that potential can be realized. Verification, security, observability, and operational controls determine whether the system is ready for real business use.

Evaluating these layers separately—and then making a decision based on their combined performance—is a more reliable way to assess both model intelligence and the practical value of AI agents.