PreAct: Predictive Planning & Replay

• PreAct is a term describing distinct frameworks: one enhances agent planning by predicting future observations to guide actions.
• The prediction-augmented variant modifies the ReAct loop with multiple history modes to improve reasoning and performance on various benchmarks.
• The replay-based approach compiles successful computer-use runs into verified state-machine programs to enable up to 13× faster execution on repeated tasks.

Searching arXiv for papers using the term “PreAct” and closely related variants to ground the article. In current arXiv usage, PreAct does not denote a single method. It refers primarily to two distinct agent frameworks: a 2024 large-language-model agent architecture that augments ReAct with explicit prediction of future observations, and a 2026 computer-using-agent system that compiles successful executions into reusable verified state-machine programs for faster replay on repeated tasks (Fu et al., 2024, Li, 16 Jun 2026). The term also sits near a broader cluster of planning-first and proactive systems—such as PseudoAct, ProAct, and ProactBench—that are often relevant in conceptual searches for “pre-action,” “planning-before-acting,” or proactive assistant behavior, but are not themselves named PreAct (Yihan et al., 27 Feb 2026, Hu et al., 25 May 2026, Harfi et al., 9 May 2026).

1. Terminological scope and principal usages

The most direct contemporary uses of the name are organized around two papers with materially different problem settings.

Usage	Paper	Core idea
PreAct	"PreAct: Prediction Enhances Agent's Planning Ability" (Fu et al., 2024)	Add a prediction step to ReAct so the agent anticipates possible future feedback and corresponding handling measures
PreAct	"PreAct: Computer-Using Agents that Get Faster on Repeated Tasks" (Li, 16 Jun 2026)	Compile a successful computer-use run into a verified state-machine program and replay it on later runs

A strict nomenclature point is important. Several nearby papers are not PreAct despite lexical or conceptual overlap. The longitudinal acquisition paper titled REACT explicitly states that it contains no use of the term “PreAct,” no method named PreAct, and no cited prior method with that name; its contribution is instead joint optimization of onboarding context and longitudinal sensing (Qu et al., 11 Mar 2026). Likewise, PseudoAct is framed as planning-before-acting through pseudocode synthesis rather than as a PreAct-branded method (Yihan et al., 27 Feb 2026).

2. PreAct as prediction-augmented ReAct

The 2024 PreAct framework extends the standard ReAct interaction loop by introducing a new variable $p_k$, defined as a prediction of future observation(s) and corresponding measures (Fu et al., 2024). In the underlying agent-environment formalization, the action at step $k$ is

$a_k=\pi_{agent}(o_{k-1}, history),$

and the environment returns

$o_k=\pi_{env}(o_{k-1}, a_k).$

PreAct changes both the policy prompt and the stored trajectory by inserting prediction into the loop. The operational pattern becomes reason $\rightarrow$ act $\rightarrow$ predict $\rightarrow$ observe $\rightarrow$ compare $\rightarrow$ replan, rather than the more local ReAct pattern of interleaved reasoning and acting.

The paper defines three history modes. In permanent mode, all prior predictions are preserved: $$history_p=\{o_0,t_1,a_1,p_1,o_1,\ldots,t_{k-1},a_{k-1},p_{k-1}\}.$$ In immediate mode, only the most recent prediction is retained: $k$0 In Reflexion mode, a reflection generated after failure is prepended: $k$1 This design is meant to let the model compare actual observations against anticipated feedback categories and use mismatches as a trigger for reflection and plan revision.

Empirically, the framework is evaluated on four AgentBench sub-datasets: HH (Householding), OS (Operating System), DB (Database), and LTP (Lateral Thinking Puzzles), using gpt-3.5-turbo-1106 and gpt-4-1106-preview (Fu et al., 2024). Representative permanent-mode results include HH test: ReAct 10.0 $k$2 PreAct 18.0 for GPT-3.5, OS test: 16.7 $k$3 20.1, and DB test: 39.3 $k$4 45.7. For GPT-4, the strongest gains again appear on HH, with 68.0 $k$5 78.0 on test; DB is a tie at 51.3 $k$6 51.3, and LTP drops from 29.0 $k$7 24.9 in permanent mode. The paper also reports that PreAct combines productively with Reflexion, for example on DB test, GPT-3.5: 45.6 $k$8 55.3 when moving from ReAct+Reflexion to PreAct+Reflexion.

The paper’s process-level analysis argues that prediction improves both diversity of reasoning and directional strategy. For HH/ALFWorld, GPT-4 directional-strategy scores rise from 1.89 to 2.29 on dev and 1.91 to 2.30 on test. A historical-prediction ablation further reports that retaining more prediction history improves performance in most settings, such as HH: 66% $k$9 70% $a_k=\pi_{agent}(o_{k-1}, history),$0 74% for GPT-4 when using 0, 1, or all historical predictions. The principal limitation identified in the paper is that the method increases prompt length and context pressure, and that LTP can deteriorate because additional context increases refusal probability under model safety mechanisms.

3. PreAct as verified program replay for repeated computer-use tasks

The 2026 PreAct paper addresses a different problem: repeated-task inefficiency in computer-using agents (CUAs) that interact with software through the screen (Li, 16 Jun 2026). Its central idea is that when a base agent successfully completes a task once, PreAct compiles the run into a reusable executable program and replays that program on later runs instead of invoking the full agent at every step.

The stored program is formalized as

$a_k=\pi_{agent}(o_{k-1}, history),$1

where $a_k=\pi_{agent}(o_{k-1}, history),$2 is the set of states, $a_k=\pi_{agent}(o_{k-1}, history),$3 the transitions, $a_k=\pi_{agent}(o_{k-1}, history),$4 metadata, and $a_k=\pi_{agent}(o_{k-1}, history),$5 data-extraction predicates. A transition has the form

$a_k=\pi_{agent}(o_{k-1}, history),$6

meaning that from state $a_k=\pi_{agent}(o_{k-1}, history),$7 the system performs action $a_k=\pi_{agent}(o_{k-1}, history),$8 and expects to move to state $a_k=\pi_{agent}(o_{k-1}, history),$9. Replay is guarded rather than blind: before every action, PreAct checks that the live screen satisfies the state’s verification predicate. If the predicate fails or an action errors, replay stops and control transfers back to the base CUA.

The paper makes a second verification move at store time. A newly compiled program $o_k=\pi_{env}(o_{k-1}, a_k).$0 is admitted to the corpus only if, after an independent reset,

$o_k=\pi_{env}(o_{k-1}, a_k).$1

This is described as a double gate: runtime verification checks state-by-state consistency during replay, and store-time verification prevents “runs-but-doesn’t-work” programs from polluting the corpus.

The experimental setting spans AndroidWorld official-15, OSWorld test_tiny, and WebArena shopping_admin subset (Li, 16 Jun 2026). The headline systems result is that successful replay is 8.5–13× faster in wall-clock time, with no per-step language-model calls. The first successful run is more expensive because of compile-and-verify overhead, reported as +162% wall time on Android and +217% wall time on OSWorld per stored program. This positions the method as an amortization strategy: pay more once, then save substantially on recurrence.

The paper’s strongest empirical claim concerns the verify-before-store gate. Across the three benchmarks, the cold-to-warm delta changes as follows. On AndroidWorld official-15, Gate ON: $o_k=\pi_{env}(o_{k-1}, a_k).$2 tasks, Gate OFF: $o_k=\pi_{env}(o_{k-1}, a_k).$3, a gain of 2.6 tasks. On OSWorld test_tiny, Gate ON: $o_k=\pi_{env}(o_{k-1}, a_k).$4, Gate OFF: $o_k=\pi_{env}(o_{k-1}, a_k).$5, again 2.6 tasks. On WebArena shopping_admin, Gate ON: $o_k=\pi_{env}(o_{k-1}, a_k).$6, Gate OFF: $o_k=\pi_{env}(o_{k-1}, a_k).$7, a gain of 1.75 tasks. These results support the paper’s claim that replay-time checks alone are insufficient; without store-time filtering, faulty compiled programs accumulate and warm performance degrades.

A further result is that PreAct needs a cache-miss-to-CUA fallback on WebArena to remain competitive with strong record-and-replay baselines. On the 12-task subset, Muscle-Mem has warm mean 6.25/12; PreAct gate-ON + fallback also reaches 6.25/12, with a reported Welch two-sided $o_k=\pi_{env}(o_{k-1}, a_k).$8-test on warm-$o_k=\pi_{env}(o_{k-1}, a_k).$9 of $\rightarrow$0 (Li, 16 Jun 2026). The paper is correspondingly explicit that prompt wording, runtime guardrails, and selector type were not the main drivers of performance.

4. Adjacent planning-first and proactive systems

Several papers occupy neighboring conceptual territory without using the name PreAct. The nearest in agent architecture is PseudoAct, which splits the agent into a planner that synthesizes a pseudocode blueprint before action execution and an executor that follows that blueprint while delegating local atomic tool usage to a ReAct-style sub-agent (Yihan et al., 27 Feb 2026). Its two-stage formulation is

$\rightarrow$1

The plan language includes explicit control-flow primitives such as EXECUTE, IF-ELIF-ELSE, [FOR](https://www.emergentmind.com/topics/feasible-operating-region-for) x IN C, WHILE \phi, TRY-ON_FAILURE, PARALLEL, and DATA-FLOW. On FEVER, the paper reports ReAct: Accuracy 60.78%, F1 62.63%, DFSDT: 67.31%, 64.16%, and PseudoAct: 88.24%, 83.35%, highlighting a 20.93% absolute accuracy gain over DFSDT. On HotpotQA, PseudoAct reaches 82.14% accuracy versus 73.21% for DFSDT.

A second neighboring line is ProAct, which treats proactive assistance as the use of idle time between interactions to anticipate future user needs, retrieve evidence, and create artifacts for later push, queue, or storage decisions (Hu et al., 25 May 2026). Its candidate-level acquisition score is

$\rightarrow$2

On ProActEval, a 200-scenario benchmark, the paper reports that Directed Idle reduces $\rightarrow$3 from 8.110 to 6.910, reduces User Effort from 9.140 to 8.075, and reduces Hallucination Rate from 0.132 to 0.095 relative to the reactive baseline. The stated headline reductions are 14.8% fewer turns to full must-have coverage, 11.7% less user effort, and 28.1% lower hallucination rate.

A third related contribution is ProactBench, which is not an agent framework but a benchmark for conversational proactivity (Harfi et al., 9 May 2026). It decomposes proactivity into Emergent, Critical, and Recovery, using 198 curated dialogues and 624 trigger points. Its main result is that Recovery is the hardest type: the best Recovery pass rate is 37.2% for GPT-5.5, and 14 of 16 models pass fewer than 20% of Recovery triggers. This benchmark is relevant because it operationalizes proactive behavior beyond instruction following, but it does not define a method named PreAct.

The biomedical acquisition framework REACT is conceptually more distant. It studies Relaxed Efficient Acquisition of Context and Temporal features, with a two-phase structure consisting of onboarding context selection followed by longitudinal active feature acquisition (Qu et al., 11 Mar 2026). The paper is explicit that it is not about “PreAct” in the standard naming sense, even though its onboarding phase may loosely evoke a “pre-acquisition” interpretation.

5. Distinction from pre-activation terminology in optimization

The string “PreAct” can also arise in searches because of work on pre-activations, especially in vision optimization. The relevant paper here is TrAct: Making First-layer Pre-Activations Trainable (Petersen et al., 2024). TrAct is not an agent method. It changes how the first layer of a vision model is updated so that the induced change in first-layer outputs better matches a desired gradient step in representation space.

The method starts from the first-layer output

$\rightarrow$4

and the standard first-layer gradient

$\rightarrow$5

It then constructs an activation proposal

$\rightarrow$6

and solves a regularized least-squares problem over $\rightarrow$7. The resulting closed-form update is

$\rightarrow$8

The paper reports that TrAct speeds up training by factors between 1.25× and 4×, with small computational overhead, across convolutional and transformer architectures (Petersen et al., 2024).

This use of “pre-activations” should not be conflated with either agent-oriented PreAct paper. The TrAct paper itself clarifies the distinction: its object is the first-layer pre-activation outputs $\rightarrow$9, not an agentic plan-before-act or predict-before-act controller. A plausible implication is that searches for “PreAct” are often contaminated by semantically adjacent but technically unrelated pre-activation terminology.

6. Comparative significance and open issues

Taken together, the two papers actually titled PreAct define two different ways of shifting computation earlier in time. The 2024 framework shifts computation within a trajectory by forcing the agent to anticipate future feedback before it arrives (Fu et al., 2024). The 2026 framework shifts computation across repeated tasks by compiling successful behavior into executable artifacts that can later bypass deliberative inference (Li, 16 Jun 2026). This suggests that, in recent arXiv usage, PreAct is less a single algorithmic lineage than a recurrent design move: represent likely future structure explicitly and use that representation to reduce purely reactive control.

The limitations are correspondingly different. In prediction-augmented PreAct, the main trade-offs are longer prompts, more generated tokens per step, and degradation on LTP when longer histories interact poorly with safety filtering (Fu et al., 2024). In replay-based PreAct, the principal constraints are verification overhead, lossy compilation, the need for resettable or idempotent environments for store-time verification, weak out-of-distribution transfer, and uncharacterized behavior at much larger corpus sizes (Li, 16 Jun 2026).

The neighboring literature sharpens the boundary conditions of the term. PseudoAct shows that plan-first control can be implemented as pseudocode-guided traversal with explicit logic primitives, but the paper does not provide controlled ablations isolating pseudocode planning from other execution constraints (Yihan et al., 27 Feb 2026). ProAct argues that proactive gains come not from idle-time compute alone but from prediction-guided use of that compute; it also notes that directed proactive behavior can regress on some scenarios and that real-world deployment would require consent, rate limits, privacy controls, and monitoring (Hu et al., 25 May 2026). ProactBench indicates that proactive dialogue ability, especially Recovery, is poorly predicted by standard benchmark suites, making evaluation of “acting before being asked” a distinct measurement problem rather than a simple extension of general capability testing (Harfi et al., 9 May 2026).

The resulting encyclopedia-level picture is therefore specific. PreAct most properly names either prediction-enhanced planning in LLM agents or verified program replay for repeated computer-use tasks. In broader searches, it often functions as a magnet term for planning-first, pre-action, or proactive-agent work. But the exact referent matters: prediction scaffolding, executable replay, pseudocode workflow control, idle-time anticipation, conversational proactivity, and first-layer pre-activation optimization are all different technical objects, even when they appear in the same lexical neighborhood.