How to Evaluate Long-Horizon AI Agents: From Code Execution to Knowledge Work

From model performance to task performance

It is easy to judge an AI system for programming or knowledge work by two weak signals: the quality of a single reply, or a subjective impression after a short trial. For work that lasts hours and spans multiple stages, what matters is not whether one answer looks impressive, but whether the system can steadily move a task to a deliverable state.

A development task may require understanding existing code, tracing dependencies, planning changes, editing multiple files, running tests, and fixing failures. Knowledge work follows a similar chain: gathering sources, verifying facts, organizing material, drafting, and revising. If any step is skipped, interrupted, or wrong, the final output may be unusable.

The evaluation focus should therefore shift from “can it answer?” to “can it complete a set of related work under explicit constraints?”

Four core evaluation dimensions

1. Task completion: is the result actually usable?

Completion is the most direct metric, but it cannot rest on the system’s own claims. For coding tasks, check whether the code meets requirements, passes relevant tests, avoids breaking existing behavior, and covers necessary edge cases. For research and writing, check whether sources support the conclusions, key facts are verifiable, the structure is complete, and the delivery format matches the brief.

A useful practice is to define “done” as inspectable conditions before work starts. For example, “optimize a module” can be broken into: behavior unchanged, specified scenarios improved, tests passing, and change notes complete. The more specific the target, the easier it is to tell real completion from apparent completion.

Separate result quality from process narration. An agent may claim it ran tests without doing so, or offer a plausible conclusion without evidence. Acceptance should rely on reproducible artifacts—test results, change logs, citations, or calculation traces—not verbal assurances.

2. Process reliability: can it keep moving and handle deviations?

Long-horizon tasks rarely follow a planned path. Code may fail to compile, sources may conflict, and an initial plan may prove infeasible. The ability to detect problems, locate causes, and revise the plan is as important as final quality.

Useful process signals include: whether it first restates goals and constraints; whether it splits large work into verifiable steps; whether it analyzes failures instead of retrying blindly; whether it can say what is done and what remains uncertain; and whether it updates the plan when key assumptions change.

Reliable execution is not continuous content generation. It is work with checkpoints: finish a stage, verify the intermediate result, then decide the next step. That exposes drift early, limits error accumulation, and makes human intervention easier.

3. Cost efficiency: compare accepted output, not advertised limits

Usage caps, billing rules, and how tasks are hosted differ across products. Nominal quotas are a weak proxy for value. The better question is how much accepted work the system can deliver under a given budget and time.

Efficiency is accepted output versus total input. Input includes API or subscription cost plus human review, correction, waiting, and rework. A fast generator that needs heavy manual repair may be inefficient. A slower run that cuts coordination and rework may be better for complex work.

Evaluate on representative tasks with aligned inputs, acceptance criteria, and environments. Record completion rate, human edits, failures, elapsed time, and resource use. Separate lightweight tasks from high-complexity ones: a system may handle simple requests well and still be unstable on long chains.

4. Controllability and risk: can errors be found and contained?

When an agent edits code, organizes data, or handles internal knowledge, mistakes have real impact. Evaluation should ask not only how it usually performs, but what happens when it fails.

Define permission boundaries. Execution environments should follow least privilege and limit unnecessary file, network, and data access. High-impact actions—deletes, publishes, production data changes—should require human confirmation, not run from a natural-language instruction alone.

Keep an audit trail: inputs, key decisions, file changes, tool results, and deliverables should be reviewable. That helps locate failures and distinguish unclear requirements, missing context, execution errors, and weak acceptance criteria.

Surface uncertainty in the delivery. When evidence is thin, sources conflict, or tests are incomplete, the system should state those limits instead of packaging guesses as facts. For enterprise work, an honest list of unfinished items is often more valuable than a superficially complete answer.

A reproducible evaluation process

To reduce luck in the results, run tests in a structured way.

1. Build a task set. Use real work: code comprehension, bug localization, multi-file edits, document cleanup, source synthesis, and report writing. Scale should require multi-step collaboration, not single-turn Q&A.

2. Define acceptance criteria. For each task, specify inputs, expected artifacts, hard constraints, and how judgment is made. Code can combine tests and review; knowledge work can check evidence, argument completeness, and format. Freeze criteria before seeing results.

3. Log process data. Record time, retries, human interventions, rework, and resource use—not only pass/fail. Without process data, differences are hard to explain and fitness for a workflow is hard to judge.

4. Repeat and analyze variance. Run similar tasks more than once. Context length, task splitting, and occasional errors can swing outcomes. One success does not prove stability; one failure does not prove the system is unusable. Watch worst-case behavior as well as averages, because production needs predictability.

5. Pilot on a small scope. Before wider rollout, try low-risk, well-bounded work. Assign human review, and update task specs and checklists from real failures. Expand only when benefit, risk, and maintenance cost match expectations.

Task design sets the evaluation ceiling

Even capable systems look unstable when the brief is vague. Provide goals, background, constraints, references, and delivery format, and state which actions need confirmation. For large work, stage it: restatement and plan, then execution, then checks against acceptance criteria.

Do not confuse “autonomous” with “unsupervised.” A sound split is to let the system handle repetitive, inspectable work while people keep key decisions, risk judgment, and final acceptance. That uses automation without unbounded error impact.

Conclusion: stable delivery over one-off brilliance

The value of long-horizon agents is whether they can keep finishing real tasks and ship verifiable results at acceptable cost. Evaluate completion, process reliability, efficiency, and risk together, using shared tasks, explicit standards, repeated tests, and small pilots.

For individuals, this shows whether a tool fits how they work. For teams, it turns impressions into comparable evidence. Prefer how the system behaves across tasks, difficulty levels, and failure cases over a demo or a single anecdote.