Long-Horizon AI Agent Task Evaluation and Engineering Implementation

1. From Single-Turn Q&A to Multi-Day Delivery: What Changes?

The usual metrics for an AI agent are the accuracy and fluency of a single-turn answer. But when the task cycle stretches from minutes to hours, days, or even weeks, the factors that determine success become different:

• State persistence: The task must retain its goal, progress, failure history, and intermediate artifacts across processes and sessions.
• Task decomposition and re-decomposition: A large goal must be split into independently verifiable subtasks and further decomposed when a subtask becomes blocked.
• Failure recovery: When tests fail or dependencies conflict, the agent should locate the cause and retry instead of starting over from scratch.
• Integration and self-review: Many local outputs must be merged into a coherent whole, and the agent should actively check consistency.
• Verifiability: Every stage should have objective signals, such as compilation, unit tests, type checks, or proof checkers, rather than relying on subjective judgment.

Two publicly reported experiments illustrate the two extremes of this capability.

In a prototype operating-system experiment, starting from an empty folder, a model coordinated more than 1,000 subagents to continuously write code, run tests, and perform reviews. The outputs covered a kernel, disk and keyboard drivers, a network stack, persistent file storage, a windowing system, a login interface, an installer, and a built-in assistant feature. The final artifact was able to boot on a laptop.

In a formal-proof reproduction experiment, about 1,000 agents ran for roughly 30 hours to complete a formal reconstruction of a known result, while prior comparable work had taken 11 days.

What these numbers show is that the deliverability of long-running tasks has moved up a level. They do not show that a broad class of problems has been solved.

2. Multi-Agent Orchestration: The Engineering Backbone of Long-Horizon Tasks

No single model call can simultaneously hold the goal, thousands of lines of code, test logs, and review comments inside one context window. Multi-agent orchestration has become the backbone of long-horizon tasks because it addresses three problems at once:

1. Context isolation: Each subagent receives only the minimal context related to its subtask, preventing the main thread from being overwhelmed by noise.
2. Parallel search: Multiple instances can attempt the same subproblem using different approaches, improving the chance of passing on the first try.
3. Role specialization: Planning, implementation, testing, and review can be handled by different roles, each constrained by its own prompts and tool permissions.

A typical control loop for long-horizon orchestration can be written as pseudocode:

# Skeleton for long-horizon task orchestration (illustrative, not a specific product API)
def run_long_task(goal, verify, budget):
    plan = planner.decompose(goal)            # 1. Decompose the goal into verifiable subtasks
    graph = DAG(plan)                          # 2. Record dependencies and identify parallel branches
    for wave in graph.waves():                 # 3. Advance layer by layer according to dependencies
        results = parallel_map(executor.run, wave, concurrency=budget.fanout)
        for r in results:
            if not verify(r):                  # 4. Objective checks: compile/test/static analysis
                plan = replanner.split(r.task, r.failure)   # If blocked, keep splitting the task
                break                          # 5. Return to planning after local failure to avoid cascading failures
    return integrator.merge(results)           # 6. Merge results and run a consistency review

The costs of this structure must also be recognized: merge conflicts, duplicated work, and cost inflation. When more than 1,000 subagents write code in parallel, the probability of inconsistent interfaces is much higher than in single-threaded development. As a result, the integration layer and interface contracts often become the bottleneck of the entire pipeline, not code generation speed.

3. Acceptance Criteria Decide the Conclusion: The Boundaries of the Two Experiments

The prototype operating-system case proves that the system can boot. The verification range covered by the official demo does not include long-term stability or hardware compatibility. Driver coverage, behavior under stress tests, and filesystem consistency after abnormal power loss remain unverified areas.

The formal-proof case proves that a proof can be checked step by step by a machine. It is a reconstruction of an existing result, not the resolution of an open mathematical conjecture.

Therefore, it is not valid to directly translate these results into “this can take over my project.” When selecting an agent system, teams should at least define four levels of acceptance:

Level	Question to Answer	Objective Signals
Runnable	Can it build, boot, and run the main workflow?	Build artifacts, boot logs
Correct	Does the functionality match the specification?	Unit tests, integration tests, property tests
Robust	Does it degrade under long duration or abnormal inputs?	Long-running soak tests, fault injection, compatibility matrix
Economic	Is the total cost per usable function acceptable?	Full bill + rework rate

As long as acceptance criteria remain at the first level, any conclusion that a system can “complete a complex project across multiple days” will be overestimated.

4. Formal Verification: Turning “Correct” into Auditable Evidence

Formal verification means writing a proof in a form where every step can be checked by a computer, with a proof checker verifying whether each inference is valid. Its value in agent scenarios is often underestimated:

• Regressable: After a specification or implementation changes, the check can be rerun instead of relying on human memory from a manual review.
• Hallucination-resistant: Because the reasoning chain is verified step by step by a machine, a model cannot pass simply by sounding plausible.
• Usable as an acceptance signal: It fits naturally into the control loop described earlier and can directly serve as verify().

The limitations are also clear. Formal verification only holds under the given premises. If the specification itself is wrong, the proof can still be “correct.” In addition, the cost of formal verification, including writing lemmas and maintaining proof scripts, is significantly higher than ordinary testing.

A pragmatic engineering approach is to replace full proofs with lightweight contracts:

# Use invariants + property testing instead of a full formal proof (illustrative)
def check_queue_invariant(q):
    assert q.size() >= 0                      # Precondition invariant
    for _ in range(1000):                     # Randomized property test
        op = random.choice(["push", "pop", "peek"])
        before = q.snapshot()
        getattr(q, op)()
        assert reconstructible(before, q)     # Operation explainability

5. Do Not Select Only by Benchmark Score: Capability, Guardrails, and Access Must Be Read Together

An easily overlooked structural fact is this: the same underlying model can be delivered in different product forms, with different guardrails and access rules, resulting in different available task ranges.

Public materials describe this situation. For the same underlying model, one version is open to all users but has stronger guardrails in cybersecurity and biology. Tasks such as penetration testing, exploit-generation requests, binary vulnerability analysis, and most research-grade biology tasks are restricted. When a request is intercepted, another model takes over and provides the answer. Another version is available only to organizations that pass verification, does not have the same strength of guardrails in these two areas, and the benchmark scores associated with it refer to this latter form.

This leads to three selection disciplines:

1. Scores must include attribution. A benchmark score must state which product form and guardrail level it came from; otherwise, it cannot be aligned with the capabilities available to a specific account.
2. A lower interception rate does not mean the task can be performed. A change in the total number of intercepted requests only means that the allow rate has increased. High-risk subtasks still need to be checked one by one against the guardrail scope.
3. Fallback routing can pollute evaluation. If an intercepted request is handled by another model, scores reproduced in your own environment are not comparable with official scores.

The selection table should therefore be expanded from a single “capability” column into three columns:

Candidate model | Capability benchmark (with product form and guardrail level) | Guardrail status | Organizational access eligibility | Measured cost per task

6. Cost-Benefit Analysis: Calculate the Full Bill

The economics of long-horizon tasks cannot be judged only by the unit price per token, because costs are amplified by parallel fan-out, retries, and review. At least the following items must be included:

• Inference cost: The total calls of the main agent and all subagents. Under a 1,000-agent fan-out, the total is often one to two orders of magnitude higher than intuition suggests.
• Retries and rework: Reruns caused by failed verification. This is usually the most undercounted item.
• Review loops: Code review, proof checking, and regression testing are continuous costs in themselves.
• Infrastructure: Sandboxes, containers, compilation caches, object storage, logs, and metrics storage.
• Human effort: Time spent by people on interface design, integration fixes, and final acceptance.

A more decision-relevant metric is the composite cost per usable function:

Cost per usable function = (inference + retries + review + infrastructure + human effort) / accepted function points

Only when “accepted” is strictly defined is this number comparable. Otherwise, high output can be quietly offset by a high rework rate.

7. Implementation Path: Start with Tasks That Can Be Automatically Verified

1. Select the task. Prioritize scenarios with objective verification signals: refactoring legacy codebases that already have complete test suites, batch data-processing pipelines, internal toolchain migrations, and consistency checks between documentation and specifications. Avoid starting with tasks where acceptance depends on human visual inspection.
2. Isolate execution. Run agents in sandboxes or containers. Minimize credentials. Disable default outbound internet access. Dangerous operations, such as deletion, release, or permission changes, must have human checkpoints.
3. Connect observability. Log token consumption, number of subtasks, verification pass rate, and retry counts. Monitoring and alerting should make it possible to attribute costs to specific tasks and stages. If the team is already using Baidu AI Cloud, this observability layer can be built on its container platform, object storage, logging service, and monitoring/alerting capabilities instead of building everything from scratch.
4. Set circuit breakers. Give each task a total budget and a maximum number of rounds. When the limit is exceeded, save intermediate artifacts and return control to a human to avoid a multi-day task running out of control.
5. Keep humans at key checkpoints. Architecture decisions, interface contracts, and release actions should retain human confirmation. Other stages should be automated as much as possible.

8. Conclusion

The real progress in multi-day task capability is that AI agents can now handle the full chain of “decompose, execute, integrate, and return checkable results.”

But deliverable does not mean usable. A prototype that can boot does not mean long-term stability. Reproducing an existing proof does not mean solving a new problem. Leading benchmark scores also do not mean that a specific account can access the corresponding capability range.

The engineering task is therefore to define acceptance criteria clearly, automate verification signals, calculate the full bill, and begin scaling from tasks that can be checked by a machine.