Long-Horizon AI Agent Tasks: Capability Evaluation and Production Acceptance

1. Evaluation moves from answer quality to task duration

Model capability has often been measured through short interactions: single-turn Q&A, single-file code completion, and similar bounded tasks. More recent progress is about agents taking on cross-day work: sessions extending from hours to days, with dozens to hundreds of execution steps, interruption recovery, sub-task assignment, and artifact merging.

These long-horizon tasks are special because they stress three capabilities at once:

• State across sessions: Context windows cannot hold the entire run. Task plans, intermediate artifacts, and rejected options must be externalized into files, logs, or task stores rather than left inside the conversation.
• Sub-task decomposition and parallelism: An orchestration layer must break a goal into milestones, modules, and atomic changes, then assign many of them to parallel executors.
• Machine-judgeable deliverables: Completion should be determined by compilers, tests, and checkers, not by subjective impression.

Only when these three conditions are met can a long task move from “demonstration” to “deliverable.” Two recently reported cases illustrate different aspects of this shift.

2. Two reference scenarios: what each proves and what each does not prove

2.1 Large-scale collaborative prototype construction

The first case starts from an empty directory. The model layer acts as an orchestrator and schedules thousands of sub-agents to write code, run tests, and review one another. After several days, the result is a prototype operating system that can boot on an ordinary laptop. Its scope includes a kernel, disk and keyboard drivers, a networking stack, a persistent file system, a windowing system, a login interface, an installer, and a built-in agent module.

Three practices are notable:

1. Layered decomposition. The top level splits milestones, the middle level splits modules, and the bottom level gives each executor a single atomic change, usually one file or one function. No single executor needs to hold the entire system in context.
2. Contracts first. Modules first define stable interfaces with stub implementations. This lets the system compile and boot as soon as possible, after which stubs are replaced with real implementations. This lesson applies to multi-agent collaboration: make errors observable first, then make features complete.
3. Feedback loop. Compile errors, test failures, and boot failures automatically become inputs for the next round of tasks. Humans appear only when arbitration is required.

The validation boundary is equally clear. Successful boot does not mean long-term usability. The case does not cover long-running stability such as memory or handle leaks, concurrency races, and driver exception paths. It also does not cover hardware/software compatibility matrices, performance and power behavior, version upgrades, or rollback paths. The hardest part of systems software is not writing the first version, but keeping it from breaking for months.

2.2 Long formal proof reproduction

The second case is formal verification. Formalization means rewriting a proof so that every inference step can be checked by a machine one by one. If any step is unsound, the checker fails. The evaluation criterion is binary: pass or fail.

The observed progress is that a cluster of roughly one thousand agents completed the formal reproduction of an existing mathematical proof in about thirty hours, whereas comparable work previously took more than ten days.

The task is difficult for three reasons: the goal is clear but there is no ready-made path; intermediate steps are extremely tedious, with proof scripts often running to tens of thousands of lines; and error localization is hard, because failure points are often far from the real error, requiring long trial-and-error without losing sight of the goal.

The boundary must also be stated: reproducing an existing proof is not the same as producing a new proof. Formalization only guarantees that there are no gaps under the given axioms and definitions. It does not guarantee that the theorem choice is appropriate, that the mathematical model is defined well, or even that the chosen axiom system and verification tool behave as expected. It proves that the inference chain is sound, not that the conclusion is meaningful.

3. Translating “bootable” into executable acceptance criteria

Long tasks usually fail not because capability is insufficient, but because “done” is undefined. Before dispatching a task, acceptance criteria should be written in a script-checkable form:

acceptance:
  functional:
    - smoke: empty environment -> build -> boot -> critical-path smoke tests
    - coverage: core module line coverage >= X%, branch coverage >= Y%
  robustness:
    - soak: run continuously for 72h with no monotonic growth in memory/handles/CPU
    - fault_injection: no filesystem loss after 50 random power-off/reboot cycles
    - concurrency: P99 latency and error-rate thresholds under target concurrency
  compatibility:
    - hardware and peripheral matrix, mainstream runtime version list
  deliverability:
    - reproducible build: dependency pinning + fixed parameters, identical artifacts across two builds
    - handover materials: design notes, interface documentation, test scripts, known-defect list

The accompanying engineering constraints are: acceptance items should be handled by scripts, tests, and benchmarks wherever possible. Human review should remain only where machines cannot decide: irreversible changes, security boundaries, external dependencies, and licensing compliance.

4. Same base model, different service surfaces: capability and access must be recorded separately

A common industry pattern is to expose the same underlying model through multiple product surfaces. The differences are not model weights, but safety and compliance policies, domain routing rules, and eligibility requirements. This structure is easy to misread during selection:

• Public-facing versions usually have stronger dual-use safeguards. Penetration testing, exploit-code generation, binary vulnerability analysis, and most research-grade biology tasks are restricted. When a request is blocked, the system is taken over by a more conservative model. This means the behavior you see as “capable” may be produced by another model.
• Versions available to verified organizations have higher entry barriers and narrower safeguards. As a result, some high scores on cybersecurity, vulnerability reproduction, and de novo protein design benchmarks are attributed only to restricted-access versions.
• A lower interception rate does not mean capability is unrestricted. A version may reduce total interception volume compared with the previous version, which only indicates fewer false blocks and better usability. Whether a specific high-risk task is allowed must be confirmed item by item according to the safeguard scope.

Therefore, a selection table should not contain only “model name + score.” It should at least include:

Capability	Public version available	Restricted version available	Organization eligibility required	Fallback after interception	Measured result	Acceptance method
Long-task orchestration	Yes	Yes	No	—	To be measured	End-to-end scripts
Security analysis	No	Yes	Yes	Conservative model	Not reusable	Independent evaluation
Formal derivation	Yes	Yes	No	—	To be measured	Checker decision

The conclusion is direct: if a leading score comes from a product surface you cannot access, its value to you is zero.

5. Collaboration structure: the human role expands rather than shrinks

Large-scale parallelism creates four typical failure modes. They must be addressed in the structural design stage:

• Goal drift: early constraints are gradually forgotten during long tasks. Mitigation: encode constraints as machine-readable checklists and automatically verify them after each milestone.
• Cascading errors: incorrect conclusions from upstream are treated as established facts downstream and amplified. Mitigation: introduce independent-context reviews and third-party recalculation at critical points.
• Review blind spots: reviewers and implementers share the same context and may make the same mistakes. Mitigation: review tasks should use isolated contexts, receiving only interface contracts and acceptance scripts, not implementation ideas.
• Merge conflicts: parallel branches modify the same area. Mitigation: clear module ownership and file-level write locks.

A minimal orchestration skeleton:

def run_milestone(spec, budget):
    plan = decompose(spec)               # milestones -> modules -> atomic changes
    verify = compile_acceptance(spec)    # compile acceptance criteria into executable checks
    while not verify.all_pass() and budget.remaining:
        for task in schedule_unblocked(plan, max_workers=CONCURRENCY):
            apply_and_test(task)         # apply change + compile + unit tests + record artifacts
        human_sign_off(scope=["irreversible", "security", "licensing"])
    return package_deliverables(spec)

The division principle is: give automatable parts to machines and parallel executors; irreversible operations, security boundaries, external dependencies, and licensing compliance require human sign-off.

6. Full cost accounting: cost structure matters more than unit price

Comparing only price per million tokens is almost certainly misleading. Long tasks involve at least six cost components:

1. Main inference cost: input-side cost can grow significantly in long tasks because context is repeatedly reread; output-side cost is one-time production.
2. Fan-out cost: the more sub-agents and the higher the parallelism, the more repeated context and tool calls.
3. Rework cost: the difference between first-pass success and third-pass success often affects total cost more than unit price differences.
4. Validation cost: compute and storage resources occupied by builds, tests, sandboxes, and long-running checks are routine overhead. They can be carried by common cloud capabilities such as container platforms and object storage, and observed through logging, monitoring, and alerting.
5. Human review cost: usually the most expensive item in long tasks, and the easiest to omit.
6. Sunk cost: intermediate artifacts later judged undeliverable still consume all the resources above.

A rough estimate can be expressed as:

Total cost ≈ Σ inference cost + Σ validation environment cost + human hours × hourly rate
Cost per qualified deliverable = total cost / number of deliverables passing acceptance

The metric worth optimizing is not token unit price, but cost per accepted deliverable. A small-sample comparison pilot is recommended using the same task set: run each strategy for several rounds and record pass rate, total duration, total cost, and number of human interventions before deciding on a configuration.

7. Adoption checklist

1. Write acceptance before starting tasks: make all acceptance items script-checkable to avoid “it feels done.”
2. Start with reversible tasks: internal tools, test generation, documentation organization, and data migration scripts should come first; changes to production systems should be last.
3. Expand permissions in stages: read-only -> sandboxed write -> controlled production. Each stage should include least-privilege credentials, audit logs, and alert thresholds.
4. Store external memory and artifacts: task states, outputs, and decision records must be written to disk to ensure cross-day recovery and traceability to specific changes.
5. Isolate execution environments: each sub-agent should have separate credentials and a limited working directory, with cross-task read/write prohibited.
6. Use dual-path review at key nodes: interface contracts, permission changes, and external release content should be reviewed by independent contexts or independent models.
7. Feed retrospectives back into the system: turn each failure into a new acceptance item or constraint so that acceptance criteria evolve with the project.

8. Conclusion

Three takeaways: long-horizon agent capability has moved from demonstration to deliverable, but “deliverable” must be bound to explicit acceptance criteria; capability scores must be recorded together with safeguard policies and eligibility requirements; and cost should be measured per qualified deliverable, not by token unit price. Only when these three points are written into selection tables and pilot plans does a cross-day long task become controllable engineering rather than an experiment based on luck.