Reason-Plan-ReAct: A Reasoner-Planner Supervising a ReAct Executor for Complex Enterprise Tasks¶

🕒 Published (v1): 2025-12-03 08:28 UTC · Source: Arxiv · Venue: AAAI 2026 · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

TL;DR¶

RP-ReAct is a multi-agent architecture that separates strategic planning (Reasoner-Planner Agent, RPA) from low-level tool execution (Proxy-Execution Agent, PEA) to improve reliability on complex enterprise tasks. The RPA uses a Large Reasoning Model to issue sub-questions and dynamically re-plan on failure, while PEAs execute tool calls via ReAct and apply a context-saving mechanism to handle large outputs. Evaluated on ToolQA across five domains with six open-weight models, RP-ReAct outperforms ReAct and Reflexion on hard tasks with better stability across model scales.

Problem¶

Single-agent ReAct architectures suffer two compounding failure modes in enterprise multi-tool settings: (1) trajectory deviation — tool errors and verbose outputs flood the context window, causing the agent to lose its goal; (2) context overflow — open-weight models (required for data privacy) have small context windows that are rapidly consumed by large SQL/CSV tool outputs. Existing single-agent approaches conflate planning and execution, making error recovery fragile and generalization poor across domains.

Method¶

RP-ReAct separates the agent into two roles:

Reasoner-Planner Agent (RPA): Powered by a Large Reasoning Model; receives the user task, generates sub-questions enclosed in <|begin search query|>...<|end search query|> tags, reads PEA results via <|begin search result|>...<|end search result|> tags, and either advances to the next sub-step or dynamically re-plans on failure.
Proxy-Execution Agent (PEA): Receives abstract sub-questions from the RPA and executes concrete tool calls (SQL, Python, text retrieval, etc.) using the standard ReAct (think–act–observe) loop. Tool errors never enter the RPA's context.
Context-saving mechanism: When a tool output (SQL query result, filtered CSV) exceeds a token threshold T=100, only the first T tokens are injected into the PEA's context; the full output is stored in a temporary variable accessible via the Python execution tool. The PEA reports this overflow to the RPA, which directs further analysis via code rather than raw data.

Evaluation uses ToolQA (five domains: Airbnb, Flight, Coffee, SciREX, Yelp; easy and hard splits; 13 tools) against ReAct and Reflexion baselines, across six open-weight models: gpt-oss-20B/120B, Qwen3-14B/32B, DeepSeek-R1-Distill-7B/8B.

Key Contributions¶

Multi-agent architecture decoupling RPA (planning/reasoning) from PEA (tool execution), keeping the planner's context free of low-level noise
Context-saving strategy that offloads large tabular tool outputs to external variables, preventing context window overflow in open-weight models
Demonstration that PEA sample efficiency improves generalization: one abstract tool-use example suffices for PEA, vs. full end-to-end examples needed by monolithic ReAct
Robustness/stability analysis across six open-weight models of varying scale using Standard Deviation, Saturation, and Combined Performance Score (CPS) metrics
Step-limit ablation (React-100) confirming that performance degradation in ReAct is trajectory failure, not insufficient steps (+4.8% average from doubling steps)

Results¶

Hard benchmarks (primary claim): - RP-ReAct achieves higher mean accuracy than ReAct on Airbnb (0.26 vs. 0.22), Coffee (0.27 vs. 0.08), SciREX (0.19 vs. 0.13) hard domains - Lower standard deviation than ReAct on most hard domains (e.g., hard Yelp: Std 0.09 vs. 0.26; hard Coffee: 0.12 vs. 0.04) - CPS (combined performance score) favors RP-ReAct on hard benchmarks: Coffee 0.36 vs. ReAct 0.12, Airbnb 0.33 vs. 0.28

Easy benchmarks: - ReAct outperforms RP-ReAct on easy tasks (e.g., easy Yelp mean: ReAct 0.63 vs. RP-ReAct 0.52), attributed to planning overhead introducing redundant steps for simple tasks

Step-limit ablation (gpt-oss-20B): - Extending ReAct from 20 to 100 steps on questions where RP-ReAct succeeded but ReAct failed: only +4.8% average accuracy gain

Small models (<10B): - DeepSeek-7B/8B fail consistently across all approaches; hard benchmark accuracy ≤0.11

Limitations¶

Evaluated only on ToolQA; broader benchmarks (OfficeBench, MINT) not yet tested
No post-training optimization (SFT/RL) applied to either RPA or PEA; reported numbers are baseline capability
Context-saving threshold T=100 tokens is a fixed heuristic; optimal value and interaction with token summarization not analyzed
Only 1 RPA + 1 PEA configuration tested; multi-PEA parallelism not evaluated
Static temperature (0.6) for all agents; RPA-specific tuning (e.g., deterministic T=0) not explored
Sub-10B models cannot reliably follow the architecture's role constraints (premature answering, trajectory deviation)
RP-ReAct underperforms ReAct on easy tasks, indicating overhead penalty for simple, few-step problems

Relevance to Agentic AI / LLM Agents¶

This work directly addresses a central open problem in agentic AI: how to maintain stable long-horizon trajectories when agents must orchestrate many tool calls in sequence, particularly under context-window constraints imposed by privacy-compliant open-weight deployment. The RPA/PEA decomposition is a clean instantiation of the planner-executor separation pattern, and the empirical confirmation that trajectory failure—not step budget—is the binding constraint in monolithic ReAct agents is a practically important finding. The context-saving mechanism is a lightweight, deployment-ready complement to more complex memory architectures. For researchers tracking LLM agents, this paper provides a concrete multi-agent template and a rare robustness analysis across six models of different scales, filling a gap where most agent papers evaluate on a single large or proprietary model.