---
title: 'PreAct: Predictive Planning & Replay'
url: https://www.emergentmind.com/topics/preact
type: topic
---

# PreAct: Predictive Planning & Replay

Searching arXiv for recent 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 [2402.11534] [2606.17929]. 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 [2602.23668] [2605.25971] [2605.09228].

## 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" [2402.11534] | 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" [2606.17929] | 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 [2603.11370]. Likewise, **PseudoAct** is framed as planning-before-acting through pseudocode synthesis rather than as a PreAct-branded method [2602.23668].

## 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** [2402.11534]. 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:
\[
history_i=\{o_0,t_1,a_1,o_1,\ldots,t_{k-1},a_{k-1},p_{k-1}\}.
\]
In **Reflexion mode**, a reflection generated after failure is prepended:
\[
history_r=\{ref,o_0,t_1,a_1,p_1,o_1,\ldots,t_{k-1},a_{k-1},p_{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** [2402.11534]. Representative permanent-mode results include **HH test: ReAct 10.0 \(\rightarrow\) PreAct 18.0** for GPT-3.5, **OS test: 16.7 \(\rightarrow\) 20.1**, and **DB test: 39.3 \(\rightarrow\) 45.7**. For GPT-4, the strongest gains again appear on HH, with **68.0 \(\rightarrow\) 78.0** on test; DB is a tie at **51.3 \(\rightarrow\) 51.3**, and LTP drops from **29.0 \(\rightarrow\) 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 \(\rightarrow\) 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% \(\rightarrow\) 70% \(\rightarrow\) 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 [2606.17929]. 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
\[
P = (S, T, M, V),
\]
where \(S\) is the set of states, \(T\) the transitions, \(M\) metadata, and \(V\) data-extraction predicates. A transition has the form
\[
(s_i, s_j, a),
\]
meaning that from state \(s_i\) the system performs action \(a\) and expects to move to state \(s_j\). 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 \(P'\) is admitted to the corpus only if, after an independent reset,
\[
r'.success \land score' \ge 1.0.
\]
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** [2606.17929]. 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: \(+1.2 \pm 0.45\) tasks**, **Gate OFF: \(-1.4 \pm 0.89\)**, a gain of **2.6 tasks**. On **OSWorld test_tiny**, **Gate ON: \(+0.2 \pm 0.45\)**, **Gate OFF: \(-2.4 \pm 0.55\)**, again **2.6 tasks**. On **WebArena shopping_admin**, **Gate ON: \(-4.0 \pm 2.94\)**, **Gate OFF: \(-5.75 \pm 1.71\)**, 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 \(t\)-test on warm-\(\Delta\) of \(p \approx 0.84\) [2606.17929]. 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 recent 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 [2602.23668]. Its two-stage formulation is
\[
\pi_{\text{plan}: Q \rightarrow \mathcal{P}}
\quad\text{followed by}\quad
\pi_{\text{exec}: (h_{<t}, \mathcal{P}) \rightarrow a_t.
\]
The plan language includes explicit control-flow primitives such as `EXECUTE`, `IF-ELIF-ELSE`, `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 [2605.25971]. Its candidate-level acquisition score is
\[
S(z) = w_r r_z + w_g g_z + w_v v_z + w_{\tau} \tau_z, \qquad w_r + w_g + w_v + w_{\tau} = 1.
\]
On **ProActEval**, a 200-scenario benchmark, the paper reports that **Directed Idle** reduces \(T_{100}\) 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** [2605.09228]. 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 [2603.11370]. 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** [2410.23970]. 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
\[
z = f(x;W), \qquad f(x;W)=W\cdot x,
\]
and the standard first-layer gradient
\[
\nabla_W \mathcal{L}(W) = \nabla_z \mathcal{L}(z)\cdot x^\top.
\]
It then constructs an activation proposal
\[
z^\star \leftarrow z - \eta \cdot b \cdot \nabla_z \mathcal{L}(z),
\]
and solves a regularized least-squares problem over \(\Delta W\). The resulting closed-form update is
\[
\Delta W^\star = -\,\eta \cdot \nabla_z \mathcal{L}(z)\cdot x^\top \cdot \left(\frac{xx^\top}{b} + \lambda I_n\right)^{-1}.
\]
The paper reports that TrAct speeds up training by factors between **1.25× and 4×**, with small computational overhead, across convolutional and transformer architectures [2410.23970].

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** \(z=f(x;W)\), 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 [2402.11534]. The 2026 framework shifts computation **across repeated tasks** by compiling successful behavior into executable artifacts that can later bypass deliberative inference [2606.17929]. 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 [2402.11534]. 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 [2606.17929].

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 [2602.23668]. **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 [2605.25971]. **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 [2605.09228].

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.

Source: https://www.emergentmind.com/topics/preact