Proactive Agent Research Environment (PARE)

• PARE is a proactive agent research framework that models stateful, sequential user interactions in digital environments.
• It employs an asymmetric design where a simulated user navigates a finite state machine interface while a privileged assistant proposes interventions.
• The Pare-Bench benchmark tests diverse scenarios across communication, productivity, and lifestyle apps to assess goal inference, proposal acceptance, and robustness under noise.

The Proactive Agent Research Environment (PARE) is a framework for building and evaluating proactive agents in digital environments, designed around a harder setting than standard reactive tool use: an assistant must observe a user and a changing environment, infer latent goals, decide whether to intervene, obtain approval, and then act on the user’s behalf. PARE extends the Agent Research Environment (ARE) with active user simulation and asymmetric interfaces for user and assistant, and it is paired with Pare-Bench, a benchmark of 143 scenarios spanning communication, productivity, scheduling, and lifestyle apps to test context observation, goal inference, intervention timing, and multi-app orchestration (Nathani et al., 1 Apr 2026).

1. Conceptual basis and research scope

PARE is motivated by a specific critique of prior proactive-agent evaluation: many earlier environments model applications as flat tool-calling APIs, so both “user” and assistant can directly invoke backend functions such as message sending or event creation. PARE argues that this is acceptable for many reactive benchmarks but inadequate for proactive-assistant research, because it erases the stateful and sequential nature of real user interaction. In actual digital environments, available actions depend on what is currently visible and reachable through interface navigation; a human user does not interact with an email system in the same way that a privileged assistant with backend access does (Nathani et al., 1 Apr 2026).

The framework therefore treats proactive assistance as inherently relational and temporal. An intervention is only meaningful relative to the user’s evolving trajectory: what has been opened, what has been read, what is still only partially visible, and where the user is in an app workflow. Timing is consequently part of the task definition rather than a secondary evaluation detail. A proposal may be useful after the user has inspected a full message, yet premature if offered when the user has only seen a truncated notification. PARE’s central claim is that without statefulness, sequential interaction, and an active user model, one cannot evaluate whether proactive help was helpful, premature, unnecessary, or harmful (Nathani et al., 1 Apr 2026).

This places PARE within a broader shift in proactive-agent research from prompt-response settings toward temporally extended environments. Related work studies intent-conditioned monitoring and event-triggered follow-up in dynamic task-oriented interaction (Shi et al., 14 Jan 2026), idle-time anticipation of future needs (Hu et al., 25 May 2026), hidden-user-profile mobile assistance with consent handling (Chen et al., 9 Apr 2026), large-datastore bottleneck discovery (Pasternak et al., 22 Oct 2025), continuous real-workflow trigger prediction (Tang et al., 4 Feb 2026), and turn-level intervention in multi-user collaboration (Yang et al., 4 Jul 2026). Taken together, these works suggest that proactivity is being reframed from generic initiative to calibrated intervention under uncertainty.

2. Formal interaction model

PARE formalizes a proactive-assistance episode around a user $\mathbf{U}$, a proactive agent $\mathbf{A}$, a shared environment state space $\mathcal{S}$, an action space $\mathcal{A}$, and an observation space $\mathcal{O}$. The user has latent goals $\mathcal{G}_\mathbf{U}$, takes actions $\mathcal{A}_\mathbf{U}$, and receives environment notifications. The proactive agent observes user behavior and events, attempts to infer the user’s goals, and may propose a plan $\mathbf{p}$ consisting of one or more actions. The user can accept or reject that proposal; if accepted, the assistant executes it. The interaction is cast as a Stackelberg POMDP, with the user as leader and the assistant as follower (Nathani et al., 1 Apr 2026).

The paper gives proposal acceptance and task success as explicit evaluation targets. Proposal acceptance is defined as

$$R_\textrm{Accept} = \frac{1}{|\mathcal{P}_\mathbf{A}|}\sum_{\mathbf{p}_i\in\mathcal{P}_\mathcal{A}}\mathtt{ACCEPT}_\mathbf{U}(\mathbf{p}_i,\mathcal{G}_\mathbf{U}),$$

and goal completion as

$$R_\textrm{Succeed} = \frac{1}{|\mathcal{G}_\mathbf{U}|}\sum_{\mathbf{g}_i\in\mathcal{G}_\mathbf{U}}\mathtt{SUCCEED}(\mathbf{g}_i,\mathcal{A}_\mathbf{U}\cup\mathcal{A}_\mathbf{A},\mathcal{S}_\textrm{final}).$$

Here $\mathbf{A}$0 is the set of assistant proposals, $\mathbf{A}$1 the user goal set, $\mathbf{A}$2 and $\mathbf{A}$3 the realized user and assistant action sets, and $\mathbf{A}$4 the terminal environment state. The appendix also interprets reward as

$\mathbf{A}$5

with $\mathbf{A}$6 as a terminal binary reward and $\mathbf{A}$7 as a stepwise reward of $\mathbf{A}$8 for accepted proposals, $\mathbf{A}$9 for rejected proposals, and $\mathcal{S}$0 otherwise (Nathani et al., 1 Apr 2026).

The environment transition function is

$\mathcal{S}$1

The paper states that the base model is deterministic: a user action such as opening a specific contact from a list screen deterministically moves the app FSM from one state to another. A stochastic extension adds configurable tool failure probability for robustness experiments. Several printed equations in the paper are malformed, but the surrounding prose makes the intended state/action semantics explicit (Nathani et al., 1 Apr 2026).

3. Environment architecture and active user simulation

PARE’s technical core is its asymmetric environment design. Applications are modeled as finite state machines (FSMs). Each app exposes user-only tools as the interface between the user simulator and backend APIs, so a user’s available actions are determined by the current app state. A state corresponds to a screen or UI context; transitions correspond to actions such as opening a detail page, filling a form field, switching folders, composing a message, saving edits, or submitting a request. This yields a state-dependent action space for the user and preserves the sequential structure of interface navigation (Nathani et al., 1 Apr 2026).

The global state consists of at least four components: the current app screen, global foreground/background app context, persistent app databases, and bounded interaction history. The paper explains these in prose as the current screen within the active app, which app is in the foreground, persistent data such as emails, contacts, events, reminders, shopping carts, and saved apartments, and recent actions, notifications, and navigation stack information. By contrast, the assistant interface is deliberately state-independent at the interface level: the proactive agent gets read-only cross-app tools, proposal actions such as send_message_to_user, and wait; once a proposal is accepted, it can access the full flat API across all apps (Nathani et al., 1 Apr 2026).

The benchmark includes FSM-based apps for Cab, Note, Email, Calendar, Contacts, Reminder, Shopping, Messaging, and Apartment, plus the core apps System, Agent UI, and FileSystem. Email, for example, has Mailbox, Detail, and Compose; Calendar has Agenda, Detail, and Edit; Shopping has Home, Product, Variant, Cart, Orders, and OrderDetail; Messaging has List and Opened. Multi-app behavior is handled by the environment-level system app, which tracks which app is active and which apps are in the background, allowing users to open an app from home, switch to already-open apps, or return home (Nathani et al., 1 Apr 2026).

User simulation is implemented as a restricted ReAct-style agent on ARE’s BaseAgent. At each turn, it receives the current active app, current state, available tools, available apps, and notifications. It can explore open-endedly or react to incoming notifications, but its actions remain constrained by the current FSM state. The system prompt instructs it to behave like a real human user and to be extremely strict about accepting proactive proposals: vague, irrelevant, capability-mismatched, or poorly timed proposals should be rejected (Nathani et al., 1 Apr 2026).

On the assistant side, PARE uses an Observe-Execute architecture. In observe mode, the assistant can use only read-only tools plus wait and send_message_to_user. It monitors user actions and notifications, gathers context, and decides whether to intervene. If the user accepts a proposal, the assistant enters execute mode, where it receives the full flat API across all apps and autonomously performs the approved task; if the user rejects, it returns to observe mode. This separation is meant to preserve user autonomy by preventing silent state modification prior to approval (Nathani et al., 1 Apr 2026).

Environment events can update databases and send notifications to user and assistant. They may be scheduled at absolute times or relative to other events, enabling scenarios spanning simulated hours in compressed wall-clock time. Notification asymmetry is deliberate: users receive truncated notifications resembling phone behavior, while the assistant receives full serialized content. A plausible implication is that PARE is testing not only whether an agent can infer a useful action, but whether it can calibrate that action to what the user has actually seen.

4. Pare-Bench and scenario construction

Pare-Bench is the benchmark built on top of PARE. It contains 143 scenarios across communication, productivity, scheduling, and lifestyle, and is designed to stress four benchmark dimensions repeatedly highlighted in the paper: context observation, goal inference, intervention timing, and multi-app orchestration (Nathani et al., 1 Apr 2026).

Scenario construction uses an LLM-based generation agent with four phases: story generation, initial app data population, event flow construction, and validation. The generator is implemented using a code generation agent based on Claude-Agent-SDK with read-only access to the PARE codebase plus a selected app subset. First it generates a natural-language scenario description and checks it for uniqueness against existing scenarios using LLM-as-a-judge. It then generates code for app initialization, event-flow construction, and validation. For the latter stages, the scenario is run in oracle mode to ensure syntactic correctness and executable validity, with failed attempts retried using execution feedback. Final scenarios are manually verified by humans for semantic coherence, correctness of validation criteria, and realism of event content (Nathani et al., 1 Apr 2026).

The benchmark supports distractor notifications and tool failures inherited from ARE. Noise events are scheduled using a Poisson process and interleaved with core scenario events, allowing controlled robustness studies under notification noise and tool unreliability. A plausible implication is that PARE is not only a benchmark of whether a proposal is correct, but also of whether proposal timing and selectivity remain calibrated when the environment becomes cluttered (Nathani et al., 1 Apr 2026).

The evaluation protocol is turn-based. In the main experiments, episodes last at most 10 turns. The user gets 1 iteration per turn; the proactive assistant gets 5 iterations in observe mode and 10 iterations in execute mode. The default user simulation model is GPT-5-mini. The primary formal metrics are $\mathcal{S}$2 and $\mathcal{S}$3, but the experiments also report Success@4, Success$\mathcal{S}$4, Success Rate, Proposal Rate, and Read Actions. Proposal Rate is interpreted with “lower is better,” since too many proposals annoy the user (Nathani et al., 1 Apr 2026).

The appendix adds a finer-grained ternary timing analysis with accept, reject, and gather context. The authors interpret a high gather-context rate as evidence of premature intervention timing. This is significant because it distinguishes outright wrong interventions from interventions that are plausible in content but too early in the user trajectory (Nathani et al., 1 Apr 2026).

5. Empirical findings

The experiments evaluate seven LLMs as proactive assistants: Claude 4.5 Sonnet, GPT-5, Gemini 3 Pro, Gemini 3 Flash, Qwen 3 4B Instruct, Llama 3.2 3B Instruct, and Gemma 3 4B Instruct. The benchmark is difficult: the best overall success rates are only about 42%. From Table 1, Gemini 3 Flash reaches Success Rate $\mathcal{S}$5, Success@4 64.3%, Success$\mathcal{S}$6 16.1%, Proposal Rate $\mathcal{S}$7, Acceptance Rate $\mathcal{S}$8, and Read Actions $\mathcal{S}$9; Claude 4.5 Sonnet reaches Success Rate $\mathcal{A}$0, Success@4 60.8%, Success$\mathcal{A}$1 18.2%, Proposal Rate $\mathcal{A}$2, Acceptance Rate $\mathcal{A}$3, and Read Actions $\mathcal{A}$4 (Nathani et al., 1 Apr 2026).

The paper interprets these near-tied results as behaviorally distinct proactive styles. Claude is the most selective, with the lowest proposal rate and highest acceptance rate, suggesting better calibrated interventions. Gemini Flash reaches similar success with more proposals and lower acceptance, suggesting greater eagerness. GPT-5 is reported to propose the most, with moderate acceptance, which the authors interpret as overconfidence in goal inference. Among smaller models, Qwen 3 4B is the strongest, but still far behind frontier systems (Nathani et al., 1 Apr 2026).

Consistency analysis reinforces this gap. Claude drops from Success@4 60.8% to Success$\mathcal{A}$5 18.2%, a 3.3× reduction; Llama drops from 23.8% to 1.4%, a 17× reduction. Stronger models also perform more read-only actions: Gemini Flash 21.7, GPT-5 20.6, Claude 20.2, versus around 16.7 for Qwen and Llama and only 8.8 for Gemma. The paper concludes that sufficient environmental observation is a prerequisite for accurate goal inference, though not sufficient on its own (Nathani et al., 1 Apr 2026).

The robustness studies show that proposal and acceptance rates remain mostly stable under tool failure and noise, while success changes by model. Under tool failure probabilities of 0.1, 0.2, and 0.4, Claude remains around 40–45% even at 40% failure probability, whereas Llama drops sharply from 20% to 8%; Qwen remains roughly stable at 18–20%. Under environment noise at 2, 4, and 6 events per minute, Claude remains robust, whereas Gemini Flash and GPT-5 degrade at higher noise. The paper argues that robustness to noisy environments varies significantly across models and is not simply a function of scale (Nathani et al., 1 Apr 2026).

The appendix’s accept/reject/gather-context analysis is especially informative for timing. Claude has the highest direct acceptance rate at 72.1%, with reject rate 7.8% and gather-context rate 17.8%. Gemma is extreme in the opposite direction: 74.7% of its proposals trigger gather-context behavior, which the authors interpret as proposals that are usually premature rather than directly useful. Most gather-context cases end in truncation because of the 10-turn episode limit, implying that turn budget interacts materially with intervention timing (Nathani et al., 1 Apr 2026).

6. Position in the proactive-agent literature, misconceptions, and limitations

A recurring misconception in proactive-agent evaluation is that proactive assistance can be tested in the same way as ordinary tool use by giving both user and assistant a common flat API. PARE’s central rebuttal is that such symmetry destroys the distinction between a human user navigating stateful interfaces and an assistant with privileged backend access. The benchmark therefore treats asymmetry as constitutive rather than incidental (Nathani et al., 1 Apr 2026).

A second misconception is that proactive capability reduces to content generation. PARE separates proposal acceptance from downstream goal success and also analyzes premature-but-plausible proposals through the gather-context category. This suggests that intervention timing and intervention content are distinct axes. Related benchmarks make analogous decompositions in different settings: ChronosBench formalizes intent-conditioned monitoring and event-triggered follow-up in dynamic task-oriented interaction (Shi et al., 14 Jan 2026); KnowU-Bench evaluates direct execution, proposing an action for confirmation, or remaining silent in an Android GUI environment with hidden profiles and ask_user as a first-class action (Chen et al., 9 Apr 2026); ProActEval measures anticipation recall, user effort, and hallucination reduction for idle-time preparation (Hu et al., 25 May 2026); PROBE decomposes proactive problem solving into searching for unspecified issues, identifying bottlenecks, and executing resolutions over large personal datastores (Pasternak et al., 22 Oct 2025); ProAgentBench studies timing prediction and assistance generation from 28,000+ events collected across 500+ hours of real user sessions, preserving burstiness $\mathcal{A}$6 (Tang et al., 4 Feb 2026); ProACT targets breakdown-aware turn-level intervention in multi-user collaboration (Yang et al., 4 Jul 2026).

PARE is also explicit about its limitations. It models interactions as API-level stateful tools rather than visual screen interactions, which yields scalability and a natural privacy boundary but does not test multimodal visual grounding. The user simulator is LLM-based and may miss human traits such as fatigue, multitasking, trust variation, emotional state, and personality differences. The benchmark does not cover all real-world proactive scenarios, especially long-horizon tasks spanning multiple days. The main experiments also use a symmetric observe/execute model setup, even though the intended deployment pattern is asymmetric, with a smaller on-device observer and a larger executor (Nathani et al., 1 Apr 2026).

These constraints delimit PARE’s contribution. It is not a complete model of every proactive-assistant deployment problem, but it establishes a particular research object with unusual clarity: a shared digital environment in which the user is simulated as a stateful navigator, the assistant is evaluated as a privileged but permission-constrained proposer and executor, and performance is measured not only by successful completion but also by calibrated restraint. Within proactive-agent research, that combination makes PARE a reference environment for studying intervention timing, goal inference from trajectories, and the asymmetry between human interface use and assistant backend action.