Long-Horizon Multi-Agent Autonomy: Capability Boundaries and Effective Task Cost

Recent public technical demonstrations show a clear step change in large-scale agent swarms on long-horizon tasks. One class of task translates mathematical proofs into machine-checkable formal languages. Another builds a runnable software system from an empty directory. In these demonstrations, swarms of thousands of agents can complete difficult tasks over tens of hours to several days, with division of labor and collaboration decided autonomously by the system. This is worth developers’ attention, but it should not be simplistically treated as “models comprehensively leapfrogging to the next level.” A more rigorous discussion should return to general technical questions: Why can multi-agent systems complete long-horizon tasks? Where are their capability boundaries? How should enterprises evaluate their real cost-effectiveness? This article is not centered on any specific product; instead, it abstracts the problem into reusable engineering methods.

1. Where the Capability Leap Comes From: From Single Generation to Closed-Loop Autonomy

The ceiling of a single model generating a single response is usually limited by context length, task complexity, and error accumulation. The core change in long-horizon multi-agent tasks is not “a longer answer in one shot,” but organizing the task into a closed loop of “decompose—execute—review—repair.” A planner first breaks the goal into subtasks that can run in parallel or in sequence. Executors then call tools in restricted environments to complete subtasks. A verifier checks intermediate artifacts, and failures trigger replanning or local repair.

This loop brings three capability gains. First, task decomposition lowers the complexity of each reasoning step. Second, concurrent execution improves throughput for long tasks. Third, the verification loop suppresses error propagation. But these gains have preconditions: the goal must be acceptance-testable, intermediate artifacts must be inspectable, and failures must be recoverable. Without these preconditions, multi-agent systems merely amplify single-point errors into concurrent errors.

2. Lessons from Two Hard Task Classes: Formal Verification and End-to-End Construction

The key to formal-verification tasks is converting natural-language proofs into machine-checkable steps and using an intermediate theorem list or proof state as the scoring basis. Multi-agent systems can divide labor autonomously, searching for lemmas, constructing proofs, and patching gaps. Their advantage is that the search space can be explored in parallel. The difficulties are verifier cost, search explosion, and the quality of the intermediate checklist. If the scoring standard is poorly designed, agents may optimize for intermediate results that “look passable” rather than proofs that are truly verifiable.

The key to end-to-end software construction is generating a bootable system from an empty directory, involving multiple layers such as basic drivers, storage, interactive interfaces, and installation flows. Multi-agent systems running continuously for several days indicate that long-term memory, task scheduling, and failure recovery already have some degree of engineering feasibility. However, acceptance criteria for software construction are more complex: bootable does not mean maintainable, and runnable does not mean secure. Enterprises must add regression tests, interface contracts, static checks, and security audits when deploying such systems; otherwise, “autonomous construction” will turn into future maintenance debt.

3. Five Hard Constraints for Engineering Deployment

First, acceptance criteria must be machine-checkable. Long-horizon tasks cannot rely only on manual visual inspection. Goals should be broken into executable checks, such as successful compilation, passing unit tests, passing a formal verifier, and consistent interface contracts.

Second, task decomposition must include interface contracts. Sub-agents must agree on input/output formats, error codes, and timeout policies. Otherwise, the more concurrency there is, the higher the integration cost.

Third, execution environments must be sandbox-isolated. Code execution, file writes, and network access should all be authorized under least privilege to prevent long-horizon tasks from performing unauthorized operations.

Fourth, observability must cover the full chain. Plans, tool calls, artifacts, verification reports, and retry reasons should all be written to audit logs and support interruption recovery.

Fifth, resource budgets and quota governance must be established up front. Set time, concurrency, storage, and invocation budgets per task. When thresholds are reached, automatically downgrade or pause the task to prevent runaway consumption by long-horizon work.

When deploying on cloud infrastructure, container platforms can provide isolated execution environments, object storage can preserve intermediate artifacts and audit snapshots, and log services plus monitoring and alerting can build observability. For example, on Baidu AI Cloud, you can combine container platforms, object storage, log services, and monitoring and alerting as general capabilities to form a reusable runtime foundation for long-horizon tasks. The key is not any specific interface, but making isolation, auditing, budgeting, and recovery into platform capabilities.

4. The Right Way to Calculate Cost-Effectiveness: Effective Task Cost

When evaluating multi-agent systems, you should not look only at per-call pricing or subscription fees. A more reasonable measure is “effective task cost”:

Effective task cost = (model and tool consumption + verifier cost + human review cost + retry and long-tail failure cost + security audit cost) / number of tasks passing acceptance

Among these, retry cost and long-tail failure cost are the most easily underestimated. Multi-agent concurrency amplifies invocation volume. If the first-pass rate is not high, total cost may exceed that of a single-agent approach. It is advisable to build tiered routing: short, low-risk tasks use a single agent or small-scale collaboration; long, high-value tasks enable multi-agent systems; tasks with high failure rates get a human review gate. Evaluation metrics should include first-pass rate, average retry count, human intervention time, verifier latency, quota utilization, and incident rate.

5. Reference Architecture and Observability Design

A deployable long-horizon task orchestration framework usually includes a planner, a task graph, an executor, a verifier, an audit log, and a quota manager. Pseudocode:

def run_long_task(goal, acceptance, budget):
    graph = planner.decompose(goal, acceptance)
    while not graph.done():
        node = scheduler.next(graph)
        ctx = memory.load(node.inputs)
        result = executor.run(node, ctx, sandbox=isolated)
        report = verifier.check(node.criteria, result)
        audit.log(node, result, report)
        if not report.passed:
            graph = replanner.repair(graph, node, report)
        if budget.exhausted():
            graph.pause_and_alert()
            break
    return final_verifier.check(acceptance, graph.artifacts)

The focus of this framework is not “letting agents freely improvise,” but constraining free exploration within boundaries that are verifiable, auditable, and rollback-capable. For systems that issue elastic quotas on a periodic basis, quota reset and budget tiering should also be supported to prevent long-horizon tasks from crowding out other business resources.

6. Evaluation and Selection Recommendations

Before introducing multi-agent long-horizon tasks, enterprises should first run a small-scale benchmark: select 3 to 5 tasks with clear acceptance criteria, run them with a single agent, small-scale collaboration, and large-scale collaboration, and record pass rate, cost, and human intervention time. Then conduct shadow runs that do not enter production directly, comparing only output quality. In the gray-release stage, set exit conditions: roll back if the consecutive failure rate exceeds a threshold, the budget is exceeded, or the security audit fails.

Suitable scenarios include formal verification, complex refactoring, end-to-end test generation, and long-cycle builds. Unsuitable scenarios include tasks with vague requirements, acceptance that cannot be machine-checked, and unclear permission boundaries. The conclusion is that multi-agent long-horizon autonomous tasks already have engineering exploration value, but cost-effectiveness depends on the verification loop and cost governance. Putting capabilities into an observable, auditable, and budgetable engineering framework is the key to moving from demonstrations to production.