Michael Brenndoerfer | Data & AI, Private Equity, Technology

Michael Brenndoerfer

Digital and Software Environments › Long-Horizon Task Simulation

Michael BrenndoerferJuly 29, 202610 min read

World Models HandbookAll chapters

Part 10 of 12Application Domains

Chapter 59Digital and Software Environments › Long-Horizon Task Simulation

Reading section 4 of 9 · Long-Horizon Task Simulation · 10 minSection 4 of 9 · 10 min

Section 4 of 9 · 10 min read

Digital and Software Environments › Long-Horizon Task SimulationOne section · Sections in this chapter4 / 9 ↓

Sections in this chapter9

Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

Our issue-tracker task uses three actions. Real workflows can contain many more, including branches and dependencies: create a ticket, identify a duplicate, update the assignee, then verify the final record. The exact action count depends on the interface and task definition. Long-horizon simulation asks how prediction errors affect that sequence, not just whether the final screen looks plausible.

The reason long horizons are hard is compounding error. Suppose a transition model has per-step accuracy $p$ , defined as the probability of predicting a single step correctly, and per-step error probability $\epsilon = 1 - p$ , defined as the complementary probability that the model predicts a single step incorrectly. These two quantities are related by:

p = 1 - \epsilon

where:

$p$ : the probability that the model predicts a single step correctly
$\epsilon$ : the per-step error probability, defined so that $p = 1 - \epsilon$

If correctness events were independent with the same probability $p$ , the probability of tracing $k$ steps correctly would be

p^k = (1 - \epsilon)^k

since each of the $k$ steps must succeed independently. Here $k$ is the rollout horizon (the number of steps in the trace). The intuition is simple: every step is an independent chance to be wrong, and the chance of getting every one of $k$ steps right is the product of their individual success probabilities. With $\epsilon = 0.05$ : we can compute this quantity for ten-step and fifty-step rollouts:

\begin{aligned} p^{10} &= (1 - 0.05)^{10} && \text{(ten-step clean-trace probability; one minus the probability of at least one error)} \\ &\approx 0.60 && \text{(compute: } 0.95^{10} \approx 0.5987 \text{)} \\ p^{50} &= (1 - 0.05)^{50} && \text{(fifty-step clean-trace probability; same logic extended to a longer rollout)} \\ &\approx 0.08 && \text{(compute: } 0.95^{50} \approx 0.0769 \text{)} \end{aligned}

where:

$p$ : the per-step success probability of the transition model, equal to $1 - \epsilon$
$\epsilon$ : the per-step error probability; for $\epsilon = 0.05$ , the model is wrong about one in every twenty steps
$p^k$ : the probability that a rollout of $k$ steps is traced correctly under the assumption that step errors are independent
$k$ : the rollout horizon, i.e. the number of steps in the trace

Under this independent, constant-probability model, nineteen out of twenty correct predictions per step still yield a low chance of an entirely correct long trace. At fourteen steps the probability of at least one error is about fifty-one percent; at fifty it is about ninety-two percent. These are clean-prediction probabilities, not task-success measurements. A real model's errors can be correlated and concentrated on decisive actions, so a measured marginal one-step accuracy cannot generally be exponentiated. For example, if an entire episode is either wholly correct or wholly wrong, every step can have marginal accuracy $p$ while the all-correct episode probability remains $p$ , not $p^k$ .

The same product can be plotted directly instead of evaluated at two points. The next cell evaluates $(1-\epsilon)^k$ on a horizon grid and records the ten-step and fifty-step checkpoints that the chapter quotes. The chart cell that follows only renders those precomputed values.

In[3]:

Code

import numpy as np

# Closed-form evaluation of the independent-error product (1 - eps)^k.
# No sampling is involved, so no random seed is required. The three error rates
# span an optimistic regime (0.01), the chapter's working value (0.05), and a
# pessimistic regime (0.20). The horizon grid runs from one to one hundred
# steps, and the checkpoints are the ten-step and fifty-step horizons quoted in
# the text.
error_rates = [0.01, 0.05, 0.20]
horizons = np.arange(1, 101)
success_curves = {eps: (1.0 - eps) ** horizons for eps in error_rates}
checkpoints = [10, 50]

Out[4]:

Visualization

Three log-scale curves decrease from 1 to 100 steps; larger per-step errors produce smaller probabilities of an entirely correct trace. — Probability that every prediction in a trace is correct under independent, constant per-step errors, plotted on a log scale. All three curves remain visible through 100 steps, including the twenty-percent-error curve below 10^-9. Vertical reference lines and derived labels show the five-percent curve at 10 and 50 steps. These probabilities are not measured task-success rates.

Where the Errors CompoundLink Copied

The independent product is an illustration, not a bound on actual software tasks. Three mechanisms deserve separate attention.

First, an incorrect predicted observation can redirect planning. If a model treats an unfilled field as filled, later predictions may use an incorrect state estimate. This can propagate through an autoregressive rollout, but need not corrupt every later prediction: dynamics, new observations, and policies can attenuate or correct the error. Interleaving observations helps only when they expose the relevant discrepancy.

Second, some effects cannot be reversed by a simple inverse action. A completed order may require cancellation or a refund, which is a new workflow rather than a reset. For high-impact actions, verify preconditions, permissions, and user authorization before acting as well as checking effects afterward; post-hoc detection cannot undo all harm.

Third, queues, caches, and webhooks can delay effects beyond the immediate response. Include pending events and timing in the full state when modelling them. Delayed consequences can make a screen-only representation non-Markovian without contradicting a sufficient full-state Markov model. They also complicate credit assignment and the choice of when a verifier should check.

These mechanisms concern different failures: propagation of a mistaken estimate, costly recovery from an irreversible effect, and incomplete observation of delayed work. A single drift score cannot diagnose all three.

Snapshots, Reset, and ReplayLink Copied

In a controlled local environment, snapshots and replay can support inexpensive branching. A valid snapshot contains all relevant state within the controlled boundary, including pending work, time conventions, and random-generator state when needed. Restoring only a database is insufficient if an external queue or client buffer still differs. Chandy and Lamport's distributed snapshot algorithm illustrates why process and channel state both matter. With that qualification, a branch samples

s'_{t+1} \sim T(\cdot \mid s_{\text{snap}}, a')

where:

$s'_{t+1}$ : the next state sampled on the counterfactual branch
$T$ : the true transition kernel
$s_{\text{snap}}$ : the fixed snapshot state
$a'$ : the alternative action replayed from the snapshot

This compares alternative actions from an equivalent controlled starting condition. As discussed earlier in Part VII, it can support search and belief-space planning. Snapshot storage and replay still have a cost, and experimental isolation is part of the design rather than an automatic property of software.

A production snapshot cannot retract an email or erase a payment's external consequences. Some internal changes are reversible, while others need compensating workflows, audit records, or approval. The reliable-world-model discussion in Part XII builds on this boundary between controlled experimentation and real intervention.

Hierarchical DecompositionLink Copied

One way to organize a checkout flow is as a sequence of milestones with local actions beneath them. "Open the cart" and "confirm shipping address" can be separate milestones. The useful boundaries depend on the application and task; the analogy does not establish how every human or agent plans.

If a task has $K$ milestones with about $m$ actions each, a planner can make local rollouts of roughly $m$ actions rather than one rollout of $K m$ . This reduces the horizon of an individual planning call, not the total number of actions or the probability of an entirely error-free task. Local repair works when milestone boundaries are meaningful and errors do not invalidate earlier dependent work. Milestone outcomes and high-level decisions can themselves be uncertain. See the earlier hierarchical planning discussion in Part VII.

Interface structure can suggest milestones, preconditions, and postconditions. Using that structure may reduce a planner's search space. Whether it reduces data requirements or improves task completion is an empirical question, especially when the documented flow omits exceptions.

Reset and Verification TogetherLink Copied

Verification and local replanning address different parts of the loop. A reliable observation can correct the variables it reveals; replanning can change the actions chosen from that revised belief. Neither repairs hidden variables automatically. The verification schedule should reflect information quality, action risk, and cost.

An agent can alternate prediction, action, observation, correction, and replanning instead of committing to one long imagined trajectory. This can limit uncorrected drift in observed variables. It is not a guarantee of stability for arbitrarily long tasks: missed effects, unavailable evidence, repeated errors, and unrecoverable actions remain possible.

The next calculation isolates one limited benefit: under independent errors with probability 0.05 per step, a segment of $v$ steps is more likely to be predicted cleanly when $v$ is shorter. It does not calculate the success of a hundred-step task. If every one of those hundred predictions must be correct, then splitting them into twenty five-step segments still gives $(0.95^5)^{20}=0.95^{100}$ . Task success with correction additionally depends on detection, repair, cost, and the consequences of mistakes.

In[5]:

Code

# Independent, constant-error illustration: these are clean segment
# probabilities, not whole-task success probabilities under correction.
task_horizon = 100
verified_epsilon = 0.05
verify_intervals = [1, 2, 5, 10, 25, 50, 100]
interval_success = {
    v: (1.0 - verified_epsilon) ** min(v, task_horizon)
    for v in verify_intervals
}
no_verification_success = (1.0 - verified_epsilon) ** task_horizon
segmented_full_clean = interval_success[5] ** (task_horizon // 5)
assert np.isclose(segmented_full_clean, no_verification_success)

Out[6]:

Visualization

Bars show clean-segment probabilities decreasing with segment length; a dashed line marks the much smaller all-correct 100-step probability. — Probability of a completely correct prediction segment of v steps under independent, constant five-percent errors. The dashed reference is the probability that all 100 predictions are correct. The shorter-segment probabilities do not measure full-task success with verification or recovery; requiring every segment to be clean still multiplies to 0.95^100.