Executor–Analyst Framework for Modular Reasoning

• Executor–Analyst Framework is a modular reasoning design that separates semantic planning from execution through intermediate, operational artifacts.
• It evaluates intermediate artifacts based on their downstream utility rather than superficial correctness, ensuring effective performance.
• The framework supports diverse applications—from code and tabular reasoning to video generation—demonstrating flexibility in tool-driven architectures.

The Executor–Analyst Framework is a modular pattern for reasoning systems in which one component produces an intermediate artifact and another component consumes that artifact to perform execution, synthesis, or answer generation. Across recent work, the intermediate artifact may be a tagged reasoning trace, a sequence of table operations, an aggregated evidence context, a latent plan, or a sequence of span-aware sub-prompts. The central premise is that correctness of the final output is often an incomplete training or evaluation signal: what matters is whether the intermediate artifact is faithful, useful to the downstream consumer, and aligned with the actual execution pathway. This perspective is explicit in TraceLift’s planner–executor formulation for math and code reasoning (Han et al., 5 May 2026), and it recurs in table reasoning (Mao et al., 2024), clinical reasoning (Xie et al., 5 Dec 2025), hybrid diffusion–autoregressive reasoning (Berrayana et al., 17 Oct 2025), and autoregressive video generation (Wang et al., 26 Jun 2026).

1. Core abstraction and terminology

The framework is not defined by a single ordering of modules, but by a division of labor. In TraceLift, a Planner or Analyst $\pi_\theta$ receives a problem $P$ and emits a tagged reasoning trace $R$, while a frozen Executor $E$ consumes $(P,R)$ and decodes a final artifact $A$ for verifier feedback (Han et al., 5 May 2026). In PoTable, the Analyst is a prompting-driven LLM that decomposes each stage of a table task into atomic operations, and the Executor is a live Python interpreter with pandas that executes generated code step by step (Mao et al., 2024). In TempAct, the Analyst is an LLM planner that outputs span-aware step prompts, and the Executor is an autoregressive video diffusion model that realizes those prompts under its own generated histories (Wang et al., 26 Jun 2026).

The nomenclature varies across domains. CureAgent uses “Executor” for the tool-using retrieval agent and “Analyst” for the long-context model that synthesizes retrieved evidence into a diagnosis (Xie et al., 5 Dec 2025). The diffusion–autoregressive hybrid likewise assigns planning to a discrete diffusion LLM and execution to an autoregressive LLM, but describes the setup as a planner–executor collaboration (Berrayana et al., 17 Oct 2025). A common misconception is therefore that “Executor–Analyst” names a fixed pipeline with reasoning always preceding execution. The papers instead support a more general definition: one module specializes in structured interaction with tools, environments, or low-level generation, while another specializes in semantic decomposition, synthesis, or interpretation.

A second defining property is that the intermediate artifact is treated as operational rather than decorative. TraceLift describes reasoning as a “consumable intermediate artifact” and argues that training should reward not only whether a trace looks good, but also whether it helps the model that consumes it (Han et al., 5 May 2026). That same logic appears in PoTable’s stage-by-stage operation chains, CureAgent’s aggregated evidence context, the DDLM–ARM system’s latent plan embeddings, and TempAct’s step prompts.

2. Intermediate artifacts as computational interfaces

The intermediate interface differs sharply across instantiations, but in each case it mediates between high-level reasoning and downstream execution.

System	Intermediate artifact	Consuming module
TraceLift	Tagged reasoning trace $R$	Frozen executor $E$
PoTable	Operation chain <START> → [OP.1] → … → <END>	Python interpreter with pandas
CureAgent	Aggregated Context $C=\{e_1,\dots,e_m\}$	Long-context Analyst
DDLM–ARM hybrid	Text plan or projected latent sequence $h^{ARM}_{1\ldots P}$	ARM executor
TempAct	Step prompts $P$0 and smoothed prompts $P$1	AR diffusion executor

In TraceLift, the planner’s trace may be a chain-of-thought, pseudo-code, or derivation steps, and the frozen executor turns that trace into the final artifact whose success is checked by unit tests or answer matching (Han et al., 5 May 2026). This makes the trace an interface with measurable downstream utility. In PoTable, the interface is more symbolic: the planner emits an operation list for a stage such as row selection or data type cleaning, and the executor realizes each operation as executable pandas code, with rollback and correction on failure (Mao et al., 2024). In CureAgent, the interface is evidentiary rather than procedural: TxAgent executors produce retrieved snippets from a ToolUniverse, and the Analyst ingests the resulting aggregated context and fact-checks via integrated Internet search before producing a diagnosis (Xie et al., 5 Dec 2025).

The DDLM–ARM hybrid introduces a more radical variant in which the interface can remain in latent space. A DDLM planner produces either a text plan or a sequence of latent embeddings $P$2, which are mapped into the ARM’s embedding space by a learned projector and consumed directly by the autoregressive executor (Berrayana et al., 17 Oct 2025). TempAct, in turn, treats the interface as a temporal decomposition: the planner emits sub-prompts indexed by spans, and the executor conditions on smoothed prompts to reduce abrupt semantic jumps at prompt-switch boundaries (Wang et al., 26 Jun 2026).

This variety suggests that the framework is best understood at the level of interface design. The central design question is not merely which model reasons first, but what representation can be produced by one module and reliably acted upon by another.

3. Supervision, rewards, and credit assignment

A major contribution of the recent literature is to show that outcome-only supervision is often misaligned with modular reasoning systems. TraceLift states that reinforcement learning solely on final correctness can reward “right for the wrong reasons,” encourage shortcuts that accidentally pass tests, and fail to penalize traces that produce correct artifacts via spurious correlations (Han et al., 5 May 2026). Its response is an executor-grounded reward with three parts: a Reasoning Reward Model score $P$3, an executor uplift term

$P$4

and a combined reward

$P$5

In the full system, this is mixed 50:50 with raw verifier reward:

$P$6

Planner training uses Group-Relative Policy Optimization, with per-group normalized advantages

$P$7

To make reasoning quality directly learnable, TraceLift also introduces TRACELIFT-GROUPS, a rubric-annotated reason-only dataset of 6,000 problems, containing one high-quality reference trace and four or more locally flawed traces per problem. The RM is fine-tuned with a multi-head classification loss for each rubric dimension, a Huber regression loss for the total score, and a within-group ranking loss ensuring that the reference trace scores above the flawed traces (Han et al., 5 May 2026).

TempAct extends the same concern with credit assignment into a hierarchical RL setting. Candidate plans form planning groups, each plan induces an execution group of multiple continuations from a shared visual context, and rewards are split accordingly. Planner rewards combine an LLM-judge term and a full-video temporal-following score, while executor rewards combine a local transition-level step-following score with aesthetic regularization and KL constraints (Wang et al., 26 Jun 2026). The planner and executor receive separate normalized advantages, so “Which plan is good?” and “Which execution under this plan is good at the switch?” are optimized at different granularities.

Not all Executor–Analyst systems rely on RL. PoTable uses real-time execution and error feedback: snippets are run in a Python interpreter, failed executions trigger rollback and re-prompting, and each operation can be retried up to 10 times (Mao et al., 2024). CureAgent is explicitly training-free: it uses self-consistency over multiple executor runs, stratified evidence aggregation, multiple Analysts, and majority vote instead of end-to-end finetuning (Xie et al., 5 Dec 2025). These cases show that the framework is compatible with both learned and nonparametric feedback loops.

4. Representative system families

TraceLift is the clearest formalization of the framework as a reasoning-training paradigm. Its two-stage planner–executor architecture is evaluated on code benchmarks—HumanEval, HumanEval+, MBPP-full, LiveCodeBench—and math benchmarks—GSM8K, GSM-Hard, SVAMP, MATH500—under fixed executors and verifiers (Han et al., 5 May 2026). The paper’s emphasis is not just better reasoning traces in isolation, but traces that improve the behavior of the exact executor used at test time.

PoTable applies the framework to tabular reasoning. It decomposes work into five stages: Initialization, Row Selection, Data Type Cleaning, Reasoning, and Final Answering. For each stage, the Analyst produces an operation chain, and the Executor translates each operation into Python/pandas code, runs it, catches errors, and updates the table state (Mao et al., 2024). The stage structure is meant to mimic a “standard human analyst,” and the final output is a fully executable program with stepwise comments.

CureAgent applies the framework to clinical reasoning under tool use. The Executor is a fine-tuned TxAgent based on Llama-3.1-8B, which parses a clinical vignette into subqueries and invokes multi-step API calls over a ToolUniverse that includes FDA labels, OpenTarget, and HPO. The Analyst is Gemini-2.5, which ingests up to tens of thousands of tokens of evidence, fact-checks via integrated Internet search, and outputs a clinical rationale and preliminary diagnosis (Xie et al., 5 Dec 2025). A post-processing module then enforces deterministic benchmark formatting.

The DDLM–ARM collaboration studies the framework as a hybrid generative architecture. A DDLM planner, specifically LLaDA-8B-Instruct, performs global planning, while an ARM executor, Llama-3.2-3B-Instruct, generates the final answer. The interface may be text-space or latent-space, with the latter using a learned two-layer MLP projector to map DDLM latents into the ARM’s embedding space (Berrayana et al., 17 Oct 2025). This formulation treats planning and execution as complementary model capabilities rather than as successive prompts inside a single autoregressive model.

TempAct applies the framework to autoregressive video generation. The planner receives a global instruction prompt $P$8, a desired total length $P$9, and a fixed step-span $R$0, then outputs a sequence of step prompts $R$1 with $R$2. The executor is an autoregressive video diffusion model, such as Self-Forcing or LongLive, that generates chunk by chunk under smoothed step prompts (Wang et al., 26 Jun 2026). Here the framework addresses temporal plausibility rather than symbolic reasoning.

In a distinct register, the earnings-calls study uses an executor–analyst lens to describe how corporate managers’ narratives shape sell-side analysts’ beliefs. Managers act as “executors” who deliver narratives, and analysts update expectations for earnings in response to both quantitative disclosures and soft information such as tone, optimism, and uncertainty (Matera, 19 Nov 2025). This suggests that the framework can also function as a conceptual model of information transmission rather than only as an agent architecture.

5. Empirical findings across domains

TraceLift reports consistent gains over execution-only RL across all model families and tasks. For Qwen2.5-7B, code micro-average improves from 52.28% to 54.89% and math micro-average from 64.72% to 69.23%; for Llama3.1-8B, code improves from 32.49% to 34.45% and math from 22.13% to 23.82%; for Qwen3-4B, code improves from 65.88% to 68.32% and math from 71.50% to 72.34% (Han et al., 5 May 2026). The gains hold under both LoRA and full-parameter fine-tuning, and ablations show that removing either the RM term or the uplift term sharply degrades performance.

PoTable reports strong results on WikiTQ and TabFact. On WikiTQ-Test, PoTable reaches 64.73 with GPT and 65.56 with LLAMA; on TabFact-Small, it reaches 88.93 with GPT and 87.06 with LLAMA. The paper states that PoTable outperforms the strongest runner-ups by 4–6 absolute points for GPT and 1.4–3.3 points for LLAMA (Mao et al., 2024). Its ablations further show that removing stages such as row selection or type cleaning, or collapsing to a single reasoning stage, drops accuracy by up to 3–4 points on TabFact and 0.6–1 point on WikiTQ.

CureAgent reports 83.80% Phase 2 accuracy on CURE-Bench for the stratified configuration with $R$3, $R$4, and search enabled, compared with 81.37% for the same stratified setup without search, 80.51% for global pooling with three Analysts, and 69.33% for a single TxAgent baseline (Xie et al., 5 Dec 2025). The paper also reports a Context-Performance curve in which accuracy is 95.0 in the 0–4k token range, 94.2 in 4k–8k, 94.5 in 8k–12k, and 87.9 beyond 12k, motivating the “Context-Performance Paradox.”

The DDLM–ARM study finds that shifting communication from text space to latent space yields major gains. On DART-5, DDLM→ARM text-space reaches 27.0%, while the latent-space pipeline with $R$5 reaches 54.0%; on AIME24, the same shift moves from 0.0% to 12.5% (Berrayana et al., 17 Oct 2025). The latent-space pipeline with 64 planner slots and roughly 5 executor tokens uses about 69 total tokens, yet surpasses Qwen3-7B on DART-5 and AIME24. The paper presents this as a different compute–accuracy frontier rather than merely a prompting variation.

TempAct reports that its planner–executor RL improves temporal consistency while preserving overall visual quality on Self-Forcing and LongLive (Wang et al., 26 Jun 2026). Although the provided overview does not include benchmark numbers, it does specify the mechanism: hierarchical exploration, plan-level and executor-level credit assignment, prompt smoothing, and multi-level rewards.

6. Conceptual significance, limitations, and open issues

The strongest unifying claim across these works is that intermediate artifacts should be evaluated by downstream utility, not only by surface plausibility. TraceLift explicitly warns that final-answer correctness can overstate reasoning gains by rewarding shortcuts and flawed intermediate states (Han et al., 5 May 2026). PoTable’s insistence on executable code and runtime validation makes a similar point in the table domain: systematic thinking is enforced by stage decomposition plus execution, not by free-form explanations alone (Mao et al., 2024). CureAgent extends the argument to evidence-grounded diagnosis, where retrieved evidence must be used rather than merely collected (Xie et al., 5 Dec 2025).

At the same time, the framework does not eliminate failure modes; it redistributes and clarifies them. CureAgent identifies a “Context Utilization Failure,” a “Context-Performance Paradox,” and a “Curse of Dimensionality” in tool retrieval as scaling problems for modular clinical agents (Xie et al., 5 Dec 2025). The DDLM–ARM work notes that interpretability remains a challenge because latent plans are opaque, even when they are more effective than text plans (Berrayana et al., 17 Oct 2025). TempAct emphasizes that long-horizon failures can arise either from bad decomposition by the planner or from prompt-switch drift in the executor, which is precisely why it separates credit assignment across levels (Wang et al., 26 Jun 2026).

A further misconception is that modularity is intrinsically training-free or intrinsically RL-based. The surveyed systems show both possibilities. CureAgent is explicitly training-free; PoTable relies on prompting, execution, and rollback; TraceLift and TempAct use RL with carefully designed rewards; the DDLM–ARM system freezes both main models and learns only a projector for latent-space exchange (Xie et al., 5 Dec 2025). This suggests that the Executor–Analyst Framework is a systems principle rather than a single optimization recipe.

A plausible implication is that future work will increasingly treat cross-module interfaces as objects of design in their own right: traces may be rubric-scored and uplift-weighted, evidence may be stratified to preserve minority signals, plans may migrate from text to latent space, and long-horizon control may depend on hierarchical reward decomposition. The existing literature already supports the broader conclusion that modular reasoning systems are most effective when the analyst’s product is judged not only for intrinsic quality, but for whether an executor can reliably act on it.