PARSER Read in Parallel, Reason in Depth for Long-Context LLM Agents

The order of a document should not dictate the order of reasoning.

Kun Li* Zexuan Qiu* Tianhua Zhang* Irwin King Helen Meng

The Chinese University of Hong Kong *Equal contribution

Paper Code Dataset Checkpoint
896Kevaluation context
+12.0points at 896K
11×lower latency
01

Introduction

Decouple reading from reasoning.

Sequential memory agents read long documents chunk by chunk while maintaining a compact memory state. This couples document traversal to reasoning depth, making accuracy sensitive to where evidence appears and forcing latency to grow with document length.

PARSER turns document length from sequential depth into parallel width. Lightweight subagents read every chunk concurrently, while a lead agent iteratively asks focused questions, gathers evidence, and reasons across only the rounds the problem actually requires.

1
⇶

Parallel reading

Every document chunk is inspected concurrently and symmetrically by a dedicated reader.

2
↻

In-depth reasoning

The lead agent refines queries across scatter–gather rounds as new evidence emerges.

3
✦

RL-trained coordination

Only the lead policy is optimized with verifiable rewards; lightweight readers stay frozen.

“Read the document in parallel. Reserve sequential computation for reasoning.”
02

Method

Parallel Reading, Sequential Reasoning

Given a question q and a long document D, PARSER first divides D into T fixed-size chunks. Multi-hop evidence is usually sparse and distributed across these chunks, so the central challenge is not merely fitting the document into a context window, but locating and composing the right evidence in the right reasoning order.

Sequential memory agents repeatedly compress each new chunk into a textual memory. PARSER instead turns document length into parallel width. At every round, all T subagents read their respective chunks concurrently, while the lead agent keeps only the K question-driven reasoning rounds sequential.

Comparison between sequential memory agents and PARSER's parallel reading workflow
PARSER replaces T dependent memory updates with K reasoning rounds, where all chunk-level reads run in parallel.
01 / PARALLEL READ

Parallel chunk readers

Each frozen subagent is permanently bound to one short chunk. When it receives a focused query, it inspects only that chunk and returns a grounded finding or abstains. All T readers execute concurrently, giving every chunk symmetric access regardless of its position in the document.

02 / REASON

Question-driven lead agent

The lead agent sees the original question and previously gathered findings, but no raw document tokens. In a ReAct-style loop, it decides whether to issue one or more new queries or commit to a final answer.

03 / ADAPT

Multi-round scatter–gather

At round k, focused queries are scattered to all readers and non-empty findings are gathered into the lead agent's history. Those findings condition round k + 1, allowing later hops to be discovered without recurrent compression or irreversible information loss.

04 / OPTIMIZE

Agentic reinforcement learning

Only the lead policy is optimized; all readers remain frozen. GRPO uses a binary exact-match outcome reward to teach query decomposition, reader coordination, and answer timing. Gathered observation tokens are masked so gradients apply only to lead-agent decisions.

Critical path
Sequential memory: O(T) → PARSER: O(K), where K ≪ T
03

Experiments

Stable accuracy at extreme length.

01 / MAIN RESULTS Across HotpotQA and 2WikiMultiHopQA from 7K to 896K tokens, PARSER remains nearly length-invariant while full-context and sequential-memory methods degrade.

HotpotQA · ID 2WikiMultiHopQA · OOD Sub_EM · 3 runs
BASELINE PARADIGMS

Full-context directly feeds the question together with the entire document into a single model call, without document chunking or an external memory.

MemAgent reads document chunks sequentially, repeatedly compressing each chunk and the previous state into a fixed-length textual memory from which it produces the final answer.

HOTPOTQA · IN-DISTRIBUTION

Accuracy across context lengths

Sub_EM (%) · average over 3 runs

Backbone Method 507K 10014K 20028K 40056K 800112K 1600224K 3200448K 6400896K Max δpp Avg.
DeepSeek-V4-Pro Full-context (non-think) 78.1277.3476.5679.69 77.3475.7873.4462.50 17.1975.10
Full-context (think-max) 82.0382.8180.4780.47 80.4781.2577.3478.91 5.4780.47
Qwen3.5-4B Full-context (non-think) 75.7875.7871.8874.22 67.9761.7253.1334.38 41.4064.36
Full-context (think) 80.4778.9178.1276.56 74.2260.9446.0931.25 49.2265.82
MemAgent 81.2581.5183.5977.86 77.8679.6973.9672.92 10.6778.58
ReMemR1 82.0379.9582.0378.91 77.8679.9577.0873.44 8.5978.91
PARSER 85.6884.64 83.6085.68 85.4283.07 83.0785.42 2.61 84.57
Qwen3.5-9B Full-context (non-think) 75.0072.6672.6671.88 70.3165.6258.5947.66 27.3466.80
Full-context (think) 77.3474.2278.9176.56 77.3465.6253.9146.88 32.0368.85
MemAgent 81.7780.7382.0379.95 79.9581.2579.6975.00 7.0380.05
ReMemR1 81.2579.6977.6078.39 78.1378.1377.8676.04 5.2178.39
PARSER 86.7288.80 87.2485.68 86.4686.72 86.7285.94 3.12 86.79

Column headers show the number of paragraphs and the approximate total token length. Max δ is the range (max − min) across the eight context lengths.

HotpotQA · 4B

84.6% average accuracy +5.7 points over the strongest sequential baseline

HotpotQA · 9B

86.8% average accuracy +6.3 points over DeepSeek-V4-Pro

896K tokens · 4B

+12.0 percentage points over the strongest sequential memory baseline
LENGTH STABILITY · HOTPOTQA

Max δ stays inside 3 points

From 7K to 896K tokens, PARSER's accuracy range is only 2.61 pp on the 4B backbone and 3.12 pp on 9B. Sequential memory and full-context methods swing by tens of points as the document grows.

02 / Controlled analysis

Robust to evidence position, order, and distance.

A

Evidence position

In 894K-token documents, all supporting paragraphs are placed inside one 10-percentile window, swept from 0–10% through 90–100%.

PARSER stays stable across all ten position bins. Sequential memory agents drop when evidence sits in the middle of the document, where earlier findings are most easily overwritten.

B

Evidence order

Each of 512 two-hop bridge-comparison questions is paired with two 894K-token documents that differ only in whether the supporting paragraphs follow or reverse their annotated logical order.

PARSER holds accuracy when the supporting paragraphs are reversed. Sequential memory agents degrade, because an early hop can be evicted before its relevance becomes visible.

C

Evidence distance

For questions that need two evidence pieces, a varying number of distractor paragraphs are inserted between them.

PARSER remains flat as the gap between the two evidence pieces grows. Sequential methods deteriorate, because the first finding must survive more memory updates before the second hop arrives.

PARSER robustness under controlled evidence position, order, and distance
Sequential methods exhibit large accuracy swings as evidence placement changes. PARSER remains stable because every chunk can be revisited under evolving queries.
03 / Inference efficiency

Latency advantage scales with context length.

MEASUREMENT PROTOCOL

Amortized wall-clock time at concurrency 1

Workload. We run the same 128 HotpotQA questions at each of eight document lengths from 50 to 6,400 paragraphs, corresponding to approximately 7K–896K tokens.

Timing and ratio. For each length, we measure the wall-clock time required to finish the entire 128-sample subset and divide by 128, obtaining amortized time per sample. Each plotted point is then MemAgent amortized time ÷ PARSER amortized time; at 896K tokens, 876.20s ÷ 78.22s gives an 11.2× speedup.

CONCURRENCY = 1

Speedup over MemAgent

Ratio = MemAgent latency ÷ PARSER latency

PARSER latency speedup over MemAgent by context length The speedup increases from 2.0 times at 7K tokens to 11.2 times at 896K tokens. 12× 9× 6× 3× 0× 2.0× 2.7× 4.5× 6.7× 8.5× 9.9× 10.4× 11.2× 7K 14K 28K 56K 112K 224K 448K 896K Context length (tokens)
At single-request concurrency, PARSER's wall-clock latency grows from 5.33s to 78.22s, while MemAgent grows from 10.56s to 876.20s.
WHY THE GAP GROWS

Inference steps stay on the critical path

MemAgent updates memory one chunk after another, so its sequential depth grows with the document. PARSER reads every chunk in the same round; only the lead agent's question-driven rounds stay serial.

The same HotpotQA questions are used at every length, so PARSER's step count stays near 4—from 7K through 896K tokens—while MemAgent climbs from 3.1 to 177.

PARSER ≈4 steps at every length MemAgent 3.1 → 177 steps
Inference step counts of MemAgent and PARSER by context length MemAgent steps grow from 3.1 at 7K tokens to 177 at 896K tokens. PARSER stays near 4 steps at every length. 200 150 100 50 0 177 ≈4 7K 14K 28K 56K 112K 224K 448K 896K Context length (tokens)
Sequential depth tracks document chunks for MemAgent, and reasoning hops for PARSER.
04 / Other analyses

Lightweight readers, short chunks, swappable implementations.

1

Subagent size

With the 4B lead agent held fixed, moving from 2B to 4B subagents lifts average HotpotQA accuracy from 78.3% to 84.6%; a 9B reader then saturates at 84.8%. After question decomposition and chunking, each subagent only answers a focused query over a short context, so a lightweight 4B reader is already enough.

2

Chunk size

Feeding the full document to a single subagent drops the average from 84.6% to 73.8%, with the largest losses on the longest subsets. Accuracy also falls as the chunk grows from 4K to 131K tokens. Short chunks keep each reader inside a compact window and avoid context rot.

3

Compatibility with subagent implementations

The same lead agent, without retraining, coordinates thinking and DCI subagents and beats the matching standalone baselines: 85.6% vs. 65.8% for thinking, and 84.7% vs. 75.6% for DCI. The lead agent's coordination is not tied to one reader design.

05 / Case study
PARSER-4B 2WikiMultiHopQA 6400 paragraphs

Which film has the director who died earlier, Everything's Ducky or Karthika (Film)?

The lead agent broadcasts parallel director queries, then parallel death-date queries, and selects the film whose director died earlier.

Question User

Which film has the director who died earlier, Everything's Ducky or Karthika (Film)?

Step 1 Find both directors
<think>

This is a multi-hop question that requires information about two films: “Everything's Ducky” and “Karthika”. I need to find who directed each film, then determine which director died earlier. Let me start by querying the agents for the directors.

</think>
query_agents Everything's Ducky film director
query_agents Karthika film director

Observations

agent_15

Everything's Ducky is a 1961 comedy film directed by Don Taylor

Don Taylor
agent_121

Karthika is a 1968 Indian Malayalam film, directed by M. Krishnan Nair

M. Krishnan Nair
Step 2 Compare death dates
<think>

“Everything's Ducky” is directed by Don Taylor; “Karthika (Film)” is directed by M. Krishnan Nair. Now I need to find which of these two directors died earlier.

</think>
query_agents Don Taylor director death date
query_agents M. Krishnan Nair death date

Observations

agent_172

Donald Richie Taylor (December 13, 1920 – December 29, 1998) was an American actor and film director.

December 29, 1998
agent_175

M. Krishnan Nair (2 November 1926 – 10 May 2001 in Thiruvananthapuram) was an Indian film director of Malayalam films.

10 May 2001
Step 3 Compose the answer
<think>

Don Taylor died on December 29, 1998; M. Krishnan Nair died on 10 May 2001. Don Taylor died earlier, so the film with the earlier-deceased director is “Everything's Ducky”.

</think>

<answer> Everything's Ducky </answer>

Success case · PARSER-4B on 2WikiMultiHopQA (6400 paragraphs / ~896K tokens).

04

Engineering Design

Fully Asynchronous RL Training

↯
SGLang Rolloutscontinuous generation
trajectoriesparameters
∇
Megatron Trainercontinuous policy updates
SGLang Model Gateway

Serving frozen subagents continuously

KEY SYSTEM BENEFIT Eliminating idle time of subagents

Policy updating and rollout generation run continuously on separate compute pools. While the lead policy is being updated, the subagent cluster keeps serving rollout requests instead of waiting for the next synchronous training stage.

  • ✓
    Decoupled resourcesRollout and actor training proceed asynchronously.
  • ✓
    Cache-aware routingSGLang Radix Cache reuses fixed chunk prefixes across rounds.
05

Conclusion

Reason by the question, not by the document order.

PARSER shows that effective long-context reasoning does not require every reasoning step to carry the document forward. By separating local reading from global reasoning, it remains accurate across extreme lengths and robust to where evidence is placed.

The resulting architecture is simple to optimize: freeze lightweight readers, train one lead policy with verifiable rewards, and scale document coverage through parallel width.

06

Citation

Cite PARSER

@misc{li2026parserreadparallelreason,
      title={PARSER: Read in Parallel, Reason in Depth for Long-Context LLM Agents}, 
      author={Kun Li and Zexuan Qiu and Tianhua Zhang and Irwin King and Helen Meng},
      year={2026},
      eprint={2609.06702},
      archivePrefix={arXiv},
      primaryClass={cs.CL},
      url={https://arxiv.org/abs/2609.06702}, 
}