Long-Horizon AI Agents and Formal Verification: Engineering Practices for Multi-Hour Autonomous Work

1. The starting point: from a single answer to tens of hours of continuous work

Over the past year, the center of discussion around frontier model capabilities has shifted. Earlier attention focused on single-turn answer quality, single-file code completion, and the correctness of one inference step. More recent discussions focus on a different question: can a model work autonomously around a large objective for tens of hours, perform tens of thousands of tool calls, and deliver a result that can be checked by a machine?

A case frequently cited in technical discussions is that a complete formal proof of a large mathematical theorem was completed within a time window ranging from several hours to tens of hours. Such claims deserve caution. What outsiders usually see is only a conclusion and a duration. The more informative part is the form of the artifact: whether the proof compiles, whether unfinished placeholder goals remain, which axioms or assumptions are ultimately used, and what the code volume and iteration count look like.

This article therefore does not focus on which model is faster. It addresses a more durable question: when task duration jumps from minutes to tens of hours, what qualitative changes must occur in the engineering architecture?

This shift creates four hard constraints:

1. Context budgets cannot expand indefinitely. Reasoning traces spanning tens of hours far exceed any context window. Memory must be externalized to file systems, databases, or retrieval layers, and the model should load only the minimum context relevant to the current subtask in each round.
2. State must be persistent and rollback-capable. Interruptions are normal in long-running tasks: rate limits, process crashes, and checker timeouts all occur. “Continue from where it stopped” requires explicit checkpoints and idempotent executors.
3. Errors must be exposed early. Discovering that a first-step definition was wrong after ten hours is unacceptable. Verification cycles must be compressed from hours to minutes.
4. Reward signals must be objective. Self-evaluation is prone to drift in long-horizon tasks. A model may sincerely believe that an incorrect proof is complete. The only trustworthy judge is an external deterministic checker: a compiler, proof kernel, test suite, or simulation environment.

These constraints determine the design paradigm of long-horizon agents. The following sections expand them layer by layer.

2. Why formalizing large theorems is a test case for long-horizon capability

Fermat’s Last Theorem is a useful example. The statement itself is simple: when an integer n ≥ 3, there are no positive integers a, b, and c such that a^n + b^n = c^n. However, formalizing it is close to the ceiling of difficulty in mathematical formalization, because the workload is distributed across four tightly coupled layers.

Layer 1: Definition burden. Formalization cannot simply “reference” concepts already established in mathematical literature. It must rebuild them from the bottom up. Algebraic number systems, unique factorization, ideals and prime ideals, local fields, elliptic curves, modular forms, Galois representations, and other concepts must be precisely defined in the type system, and their expected textbook properties must be proved. In practice, “definitions and foundational lemmas” often account for more than half of a large formalization project, even though they produce no new mathematics.

Layer 2: Lemma granularity and assembly order. A phrase in a paper proof such as “by standard theory” may correspond to thousands of lines of formal code. The real dependency structure is a large directed acyclic graph with many branches that appear independent but share prerequisite lemmas. A wrong assembly order causes repeated rework: a later lemma may be proved first, only to discover later that a definition it depends on has changed.

Layer 3: Type and abstraction-level expansion. The same mathematical object often has multiple equivalent representations, such as constructive definitions, set-theoretic definitions, or type-class instances. Formalization must establish isomorphisms among them and transport properties between them. Compilation time and memory usage in this part grow quickly and are often the most common performance bottleneck in real engineering work.

Layer 4: Completeness verification. There is a difference between a formal proof that “looks complete” and one that is actually complete. Several checks matter: whether placeholder or unproved goals remain, whether the final theorem uses additional strong assumptions, which axioms are used, and whether the whole project can be built successfully from a clean environment in one pass.

Taken together, these layers show what long-horizon agents are truly required to do. The requirement is not merely “think of a clever step.” It is to maintain a consistent goal structure over an extremely long period, record progress precisely, and make local repairs in response to hundreds of thousands of compilation feedback signals without breaking global consistency. This is the core capability that distinguishes long-horizon agents from conversational models.

3. Engineering skeleton of a long-horizon agent

A system that can run stably for more than ten hours usually consists of several reusable architectural components. They are largely independent of the specific model used.

3.1 Task blueprint: compiling a large goal into a dependency graph

The first step is not to let the model start writing immediately. Instead, it should produce a structured proof blueprint or implementation blueprint: a list of subtasks with dependencies. Each node should contain the goal statement, dependent nodes, acceptance criteria, and current status. The blueprint is a contract between humans and the agent, and it is also the only reliable basis for recovering from interruptions.

blueprint:
  - id: def.integers
    goal: "Construction of the integer ring and its order structure, with basic properties"
    depends_on: []
    acceptance: "Construction check passes; no unfinished placeholder goals in basic lemmas"
    status: done
  - id: lem.unique_factorization
    goal: "Unique factorization theorem"
    depends_on: [def.integers]
    acceptance: "Compiles successfully; axiom dependency list has been exported"
    status: in_progress
  - id: main.reduction_to_primes
    goal: "Reduce the general exponent case to n=4 and odd prime cases"
    depends_on: [lem.unique_factorization]
    acceptance: "The reduction lemma can be compiled independently"
    status: todo

A key design rule is that acceptance criteria must be decidable by scripts. Any node that requires a human judgment such as “this seems close enough” will become one of the first points where a long-running task loses control.

3.2 Externalized memory: the file system is the agent’s long-term memory

Do not try to force the entire historical trajectory into the context window. A practical approach is to treat the agent like an engineer working inside a code repository:

• The proof or code itself is the single source of truth and is naturally persistent.
• After each blueprint node is completed, append a structured log entry: node ID, elapsed time, token consumption, summary of failed attempts, and key decisions.
• At the start of each round, load only two things: the current blueprint state and the code or log fragments relevant to the current node.

This decouples context growth from task duration. Context size then depends mainly on the complexity of the current subtask rather than on how long the overall job has been running.

3.3 Verification loop: let checkers, not the model, decide correctness

The heartbeat of a long-horizon system is a loop like the following:

while not blueprint.all_done():
    node = blueprint.next_ready_node()      # topological order + priority
    ctx  = memory.load(node.id)             # minimal necessary context
    patch = model.propose(node, ctx)        # generate a candidate implementation
    if not checkpointer.write_draft(node.id, patch):
        continue
    report = verifier.run(node.id, timeout=600)   # the only judge
    if report.passed:
        blueprint.mark_done(node.id, evidence=report.artifact)
        memory.append(node.id, report.summary)
    else:
        failure = diagnoser.localize(report)  # localize the error to the smallest relevant fragment
        memory.append(node.id, failure)
        retries.incr(node.id)                 # repeated failures trigger a policy downgrade

Three points are critical:

• Verification must be short-cycle. Feedback must arrive in minutes, not hours. Otherwise, trial-and-error efficiency collapses.
• Failure information must be minimized. If thousands of lines of error output are handed directly to the model, the context is quickly filled with noise. The relevant fragment should be extracted first.
• Repeated failures must trigger a strategy switch. Instead of retrying the same approach indefinitely, the agent should change the decomposition method, add auxiliary lemmas, or fall back to a finer granularity.

3.4 Parallelism and races

Once a dependency graph exists, parallelism becomes natural: nodes without dependency relationships can be explored concurrently. A common engineering pattern is to run multiple candidate solutions for the same node in parallel and let the first candidate that passes verification win. This trades compute for latency.

However, shared-resource conflicts must be managed carefully. Build caches, intermediate artifact directories, and verification environments must be isolated per node. Otherwise, parallel workers will pollute each other’s results.

3.5 Checkpoints, rollback, and idempotence

A checkpoint should be written immediately after each node state change. The executor should also be made idempotent: repeated execution of the same node should not produce side effects. For example, writes can first go to a temporary directory, and changes are atomically committed only after verification passes.

This is the dividing line between a ten-hour task that can be safely restarted and one that cannot.

3.6 Quota and rate-limit governance

Long-horizon tasks are naturally heavy consumers of quota. Useful engineering measures include:

• Allocating token budgets per node and setting upper limits.
• Using exponential backoff when rate limits are hit, instead of dense polling.
• Routing high-frequency, low-value operations such as file reads and status checks to smaller and cheaper models.
• Using higher-throughput tiers for non-critical paths while keeping default tiers for critical paths.

Because quota reset mechanisms commonly used in the industry are time-window based, budgets should be planned by time window rather than spent as a single uncontrolled total.

3.7 Deployment shape

The executor described above can be containerized and run on a container platform. A common separation is that stateless executors handle scheduling, while dedicated build nodes handle compilation and checking.

If deployed in a cloud environment such as Baidu AI Cloud, a typical combination is: container platforms host the executor and build cluster, object storage stores proof artifacts, checkpoints, and evaluation datasets, logging and monitoring services provide visibility and alerting for tasks that run for tens of hours, and a secrets management service stores credentials for code repositories and model services.

The selection principle here is simple: long-running tasks require much stronger observability and state persistence than ordinary online services.

4. Extending the verifiable paradigm to software engineering

The value of formal verification is not limited to mathematics. The real opportunity is this: any domain with a deterministic checker can use the same long-horizon agent architecture.

Three high-value scenarios stand out:

1. Core algorithm libraries and foundational components. Code such as sorting algorithms, graph algorithms, concurrency primitives, and memory management has correctness that acts as a global multiplier. An agent can help complete precondition and postcondition assertions, loop invariants, and related checks, while checkers and test suites provide dual verification.
2. Protocol and state-machine implementations. Distributed protocols, payment state transitions, and device communication handshakes are expensive to get wrong and difficult to cover adequately with sampling-based tests. Model-based state search combined with invariant checking can support more exhaustive verification.
3. Equivalence verification for large-scale migration and refactoring. This is often underestimated. When migrating an old system to a new architecture, the hardest part is often not writing new code, but proving that the new behavior is equivalent to the old behavior. A practical method is to build an executable behavioral specification for the old system, for example by recording traffic or using symbolic execution to generate input-output pairs, and then use “the new implementation matches the specification” as the acceptance criterion for the migration agent. This is far more reliable than manually comparing diffs.

A boundary must be made clear. In all of these scenarios, the model should act as a candidate generator, assertion completer, and counterexample repairer. It should not act as the final judge. The judge must be a deterministic checker that the model cannot bypass. Once this boundary becomes blurred, long-horizon tasks degrade into high-quality self-deception.

5. Evaluation: long-horizon capability cannot be measured with a single score

If systems are compared only by a single benchmark percentage, long-horizon capability will be systematically misjudged. A reasonable evaluation should include at least three layers:

Layer	Evaluation target	Typical metrics
Atomic capability	Single-step reasoning, single-file generation, instruction following	Single-task accuracy, format compliance rate
Task-level	Full feature implementation, defect fixing, code migration	End-to-end pass rate, number of human interventions, regression introduction rate
Long-horizon project	Engineering goals spanning tens of hours, multiple files, and strong dependencies	Goal completion rate, time to completion, token and cost expenditure, artifact verifiability, interruption recovery success rate

Several design points for long-horizon evaluation are easy to overlook:

• Treat the number of human interventions as a first-class metric. A system that ultimately succeeds but requires forty human corrections is far less practical than one that succeeds with zero interventions.
• Record cost distribution, not just averages. Long-tail tasks may consume several times the median budget. Averages can hide budget risk.
• Include held-out variants. Once a benchmark is public, it is exposed to overfitting. Equivalent unpublished variants, such as renamed variables, changed data distributions, or altered dependency orders, should be retained to test generalization.
• Report verifiable artifacts. For formalization tasks, this means the full project, clean build logs, and lists of axioms and assumptions, not just a screenshot.

6. Tiered availability and compliance design for high-risk capability domains

Offering the same base model at different protection levels has become a common industry practice. Public-facing versions may strengthen abuse prevention and refusal policies, while versions intended for specific research use may relax capability boundaries under conditions such as application review, declared use cases, and usage auditing.

For enterprise developers, several engineering rules are worth adopting directly:

• Data classification and outbound control. Define which data may enter the model inference chain, mask sensitive fields at the gateway layer, and establish clear policies for cross-border and cross-tenant data movement.
• Least privilege and credential isolation. Separate the agent’s execution identity from human identities, authorize tool calls through allowlists, and require separate approval for write and delete operations.
• Full-chain audit logging. Record each tool call, code change, and verification result so that long-running tasks remain traceable, reproducible, and rollback-capable at any point in time.
• Human confirmation gates. Actions that involve production changes, data deletion, or external release must include confirmation points that cannot be bypassed.

7. Cost structure: how pricing models shape architecture

Mainstream model services usually price input tokens and output tokens separately, with output tokens typically more expensive. Higher-throughput tiers may also be available, usually at a multiple of the base price. This simple pricing structure directly affects architecture choices:

Cost per task ≈ Σ_call ( T_in × P_in + T_out × P_out ) + Σ_retry (same billing)

Several practical conclusions follow:

• Output is the most expensive side. Any change that lets the model write less and verify more is usually worthwhile. Having the verifier report errors and the model make small patches is better than letting it rewrite entire sections.
• Input can be compressed. Prompt templates, retrieval-based loading, reuse of cached build artifacts, and summarization of historical context are all direct cost levers. Repeated full-repository context injection is one of the most typical forms of waste.
• Use higher-throughput tiers for interactive or search-like phases. Writing a single file or completing assertions, where humans are waiting, is suitable for acceleration. For offline search phases that generate many candidates and verify them in batches, whether it is worth paying a premium for speed depends on the ratio of human time cost to machine cost. In most unattended scenarios, the default tier combined with higher concurrency is more economical.
• Failed retries are a hidden major cost. A task without clear acceptance criteria will burn budget on repeated retries. Writing acceptance criteria clearly is one of the most cost-effective optimizations available.

8. Deployment checklist

Before attempting to build a long-horizon agent, confirm the following items one by one:

1. Does the task have a deterministic acceptance criterion? If not, build that capability first before discussing automation.
2. Has a structured blueprint been produced, and have node granularities been frozen? Nodes that are too large cannot be parallelized or recovered effectively, while nodes that are too small make scheduling overhead unmanageable.
3. Is memory externalized to the file system and retrieval layers, and is context loading decoupled from task duration?
4. Has the verification cycle been compressed to minute-level feedback, and are failure messages trimmed to the smallest relevant fragments?
5. Are there checkpoints, idempotent executors, and rollback paths that can tolerate interruption at any moment?
6. Have token budgets and time-window quota limits been established, along with rate-limit backoff strategies?
7. Is there a layered evaluation setup with held-out variants, so that selection decisions are not based only on single-point scores?
8. Are there non-bypassable human confirmation gates for high-risk actions, and is the full chain audited?

Conclusion

The real value of headlines about completing a large objective in tens of hours is not the duration number itself. It is the shift in capability shape: models are moving from tools that answer questions to executors that work continuously under deterministic judging.

Whether this shape can truly be deployed inside enterprises depends on three things that are independent of the model itself: whether you have decomposed goals into acceptable nodes, whether you have built a verification loop that the model cannot bypass, and whether you treat cost, quota, and audit as first-class engineering problems.

Formal verification is a good entry point because it pushes all three requirements to the extreme: goals must be precise, proofs must be checkable, and budgets must be controlled. Find the part of your business where correctness can be judged automatically first, and then let long-horizon agents handle the rest.