Pith. sign in

REVIEW 4 major objections 5 minor 32 references

Toward Reliable Context Compression for Long-Horizon Agents: An Empirical Study of Execution Instability

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Pith's one-line read Recurrent context compression degrades long-horizon agents by weakening the influence of recent interactions, and TRACE shows that counting the resulting blocked and repeated actions at each compaction boundary is a better supervision…

desk verdict A genuinely novel boundary-local verifier for compression prompts, but the headline results rest on two runs without error bars and the proxy is never validated against task success. read the letter →

arxiv 2608.06503 v1 pith:SP4O3DVW submitted 2026-08-06 cs.LG

classification cs.LG
keywords contextcompressionlong-horizonagentsexecutioninstabilityblockedactionsrepeatedexplorationverifier-guidedpromptoptimizationmulti-runreliabilityAppWorld
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Recurrent context compression, which periodically replaces a growing agent context with a shorter summary, is usually judged by whether the final task still succeeds. This paper argues that terminal judgments miss the real failure mode: compression weakens the influence of recent interactions, and the frozen agent then loses its place in the trajectory, producing blocked actions and repeated exploration. To make the failure measurable, the authors introduce TRACE, which evaluates each summary at the compaction boundary where it replaces raw history by running paired continuations from the same environment state and counting the extra blocked or repeated actions the summary causes. Those boundary-local preferences revise a natural-language compression template while every model stays frozen. On AppWorld the result is higher accuracy, higher Pass2 reliability, and near-full-context efficiency compared with existing compression baselines, plus a template that transfers to a second agent model.

What carries the argument

The load-bearing object is the boundary-local execution verifier. At a compaction boundary, the verifier rolls out the frozen agent from the same environment state under two renderings: PRE, which keeps the pre-compaction context, and POST, which replaces the compressible history with a candidate summary. Each rollout's execution burden counts actions that are blocked by the environment's native error contract or whose canonicalized tool-call signature repeats a call made before the boundary or earlier in the same continuation, and the verifier score is the negative expected increase in that burden. The score never reaches the proposer as a number: it only orders summaries at the same boundary into better and worse pairs, and the proposer sees the compressor inputs, those pairs, and the downstream system prompt, but not the rollouts. The final template is then chosen by end-to-end Pass2 on the development split, so terminal outcomes serve model selection rather than per-summary supervision.

What would settle it

Take a set of compaction boundaries and hand-edit candidate summaries so that one summary silently changes a value the agent will later use, such as an ID, amount, or date, while another keeps it faithful, ensuring neither produces a blocked or repeated action in the rollout; if the verifier scores the corrupt summary as well as or better than the faithful one, the boundary-local signal misses the failure mode the paper concedes it may miss. A stronger version is to construct or select tasks whose failures are driven by such silent corruption and check whether TRACE's advantage over baselines shrinks on them.

Watch

Extended reading notes

Core claim

At its center, the paper claims that recurrent context compression degrades long-horizon agents not mainly by deleting facts but by breaking the agent's local sense of where it is in the task: what has been completed, what is actionable, and whether it may stop. It supports this with three probes on AppWorld: summary-conditioned agents terminate in the required form less often than FIFO- or full-history-conditioned agents at the same decision point; compressing a recent interaction weakens its behavioral effect relative to keeping it verbatim; and closed-loop rollouts after compaction show more blocked and error actions and more refetching or replaying of previously executed calls. From this diagnosis TRACE builds a training signal: at each boundary, paired rollouts from the same state, with and without the candidate summary, measure the compression-induced execution burden, and the induced preferences over summaries become the feedback for a frozen proposer rewriting the compression prompt. With this prompt, TRACE reaches 77.1 average accuracy and 67.3 Pass2 on AppWorld test-normal, versus 71.4 and 59.5 for the best existing compressed baseline, keeps average steps close to the full-context run, and the same template applied to a second model exceeds full-context accuracy and Pass2. The authors describe these results as early evidence for boundary-local evaluation rather than a settled claim.

Load-bearing premise

The method's whole optimization signal rests on the premise that compression damage shows up at the boundary as blocked or repeated actions; the paper itself concedes that silent state corruption might produce neither, and if that failure mode dominates, the verifier's preferences would not reward fixing it.

Editorial extensions

If this is right

  • Compression quality for long-horizon agents should be evaluated at the boundary where the context is replaced, not only by the terminal task outcome, because a defective summary can be masked by later recovery and a failed run can be unrelated to any particular summary.
  • Optimizing a compression prompt against blocked and repeated actions improves multi-run reliability as well as average accuracy, meaning the added signal reduces the run-to-run instability that single-run metrics miss.
  • The optimized template's transfer to a second agent model without further tuning implies that good compression policy is at least partly model-independent and can be reused across agents.
  • Because TRACE holds step count near full-context while cutting peak token use, reducing compression-induced regressive exploration is compatible with, and not opposed to, context efficiency.
  • Boundary-local preference feedback outperforms trajectory-level success and failure contrast on the same benchmark, suggesting that terminal labels are a noisier supervision channel per summary.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural testable extension is to replace the blocked and repeated action proxy with a richer boundary signal, such as the divergence between next-action distributions or a state-consistency check, and see whether gains grow on tasks whose failures are silent.
  • The same boundary-local preference signal could serve as a dense reward for training learned compressors, not just for prompting a frozen proposer; the paper optimizes only a natural-language template and leaves that route implicit.
  • The paper's observation that recency-only truncation is competitive at moderate budgets in a refetchable environment suggests a hybrid policy that keeps recent turns verbatim and summarizes only older state might capture much of TRACE's benefit at lower cost.
  • If boundary-local evaluation generalizes beyond compression, it could become a general diagnostic for context-management choices such as memory tiers and retrieval, by measuring whether any replacement of history changes future action distributions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper studies how recurrent context compression affects frozen long-horizon LLM agents. Using the AppWorld benchmark, it first presents diagnostic probes showing that replacing the working context with structured summaries increases blocked actions, repeated exploration, and run-to-run instability, especially on longer-horizon tasks. It then proposes TRACE, a framework that evaluates each compaction boundary by paired closed-loop rollouts from the same environment state, defines a verifier score Q_b(s) = -ΔG_b(s) based on blocked and repeated actions, and uses pairwise preferences between candidate summaries to have a frozen proposer revise a natural-language compression prompt. The final prompt is chosen by Pass2 on the development split and evaluated on the test split. On AppWorld, TRACE reports higher accuracy, Pass2, and Pass@2 than existing compression baselines, while keeping average steps near full-context execution, and the optimized prompt transfers to a second model (Kimi-K2.7-Code).

Significance. If the central claims hold, boundary-local evaluation would be an attractive way to optimize context compression for frozen agents, because it avoids modifying models and uses cheap, local signals instead of terminal rewards. The paper has several genuine strengths: the diagnostic studies use paired controls and bootstrap confidence intervals; the optimization protocol freezes all models; baseline prompts are taken from official repositories with recorded commits and hashes; and the authors explicitly acknowledge that the verifier may miss silent state corruption. These features make the empirical study more transparent than many similar papers. However, the main results are based on only two runs per condition with no error bars, and the reported gains are not yet causally attributable to boundary-local preferences because final prompt selection is end-to-end and the proposer also receives the downstream system prompt and an audit instruction. The significance of the paper therefore depends on additional validation steps that are feasible within the manuscript's scope.

major comments (4)
  1. [§5.2, Tables 1-2; §4.2 Eq. (9)] The main empirical claims rest on two runs per condition with no confidence intervals or significance tests. The development-selection rule in Eq. (9) and the test tables report Pass2 and Pass@2 computed from the same two runs, so the headline gaps (e.g., TRACE over Prompting-O by 5.7 accuracy and 7.8 Pass2 in Table 1) are well within the range that could be produced by sampling noise. The diagnostic probes in Section 3 use task-level bootstrap intervals; the main tables should provide the same treatment, including intervals over the selection step, before the paper claims that TRACE 'consistently outperforms' existing baselines.
  2. [§4.1-§4.2, Eqs. (2)-(4), (10); §7] The verifier score Q_b(s) is never validated as a predictor of eventual task success. The paper's central claim is that boundary-local supervision is better than terminal outcomes, but to support that claim the paper must show that ΔG_b(s) ranks summaries by their effect on terminal success. The current design cannot establish this: final template selection uses terminal Pass2 on the development split (Eq. (10)), and, with five candidates and two runs each, the selected template may win by noise. The paper also reports no post-optimization verifier scores or blocked/repeated rates, so the proposed mechanism is unverified. Section 7 explicitly concedes that the verifier may not capture silent state corruption, which is a limitation of the optimization signal itself, not only of the evaluation. A concrete fix would be to report the correlation between verifier preferences and Pass2 across the five candidate prompts, or to evaluate a version selected solely by verifier score.
  3. [§4.2, System-aware prompt proposal; Appendix B.2] The proposer receives the downstream system prompt and an explicit 'audit-first' instruction in addition to the preference pairs. The optimization therefore does not isolate the contribution of boundary-local preferences: TRACE's advantage over ACON could come from the system-prompt-aware audit, from the richer input (including the downstream contract), or from the end-to-end selection stage, rather than from the verifier. The paper needs an ablation that removes one component at a time, for example a proposer given the audit instruction but no preference pairs, or preference pairs without the downstream contract, to attribute the improvement.
  4. [§4.2, Eqs. (5)-(7)] The optimization signal is built from only 12 boundaries, selected because they exhibit blocked actions, and only three candidate summaries per boundary. This yields a small, non-random preference set, and the selected prompt may overfit these boundaries. Since the final claim concerns general compression reliability, the paper should report how the 12 boundaries were sampled, how many boundaries exhibited blocked actions in total, and the sensitivity of the final template to the choice of training boundaries.
minor comments (5)
  1. [Table 1, Medium Pass2 row] TRACE (58.3) is below LLMLingua-2 (62.5) on Medium Pass2, in tension with the 'consistently outperforms' phrasing in the Introduction and Abstract; please qualify this claim once intervals are added.
  2. [§4.1, Eq. (2)] The value of K in Eq. (2) is never stated; Section 3.3 uses five actions for the diagnostic rollouts, but the verifier's K should be specified explicitly.
  3. [§5.4, Table 2] The transfer claim is based on a single target model and the same two-run protocol; the sentence 'broader cross-model generalization remains to be established' is appropriate, but the abstract's 'transfers to a second model' should be reported with intervals or with a caveat about the two-run basis.
  4. [§2.2, Eq. (1)] B is called a 'context budget' but is compared with |...| in tokens; specify the unit and how the budget is measured for different models' tokenizers.
  5. [Appendix B.2] The proposer prompt is very long and contains task-specific details; a condensed description in the main text would help readers, with the full prompt left to the appendix.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the verifier preference signal is a proxy, while final prompt selection and test evaluation use terminal outcomes, so no reported result reduces to its own inputs by construction.

full rationale

The derivation chain is self-contained and the central claims are validated externally. The boundary-local verifier score Q_b(s) = -DeltaG_b(s) is constructed from paired PRE/POST closed-loop rollouts (Eqs. 2-4), and these verifier scores are used only to create contrastive preference pairs (Eqs. 6-7). The final compression template is selected by terminal Pass2 on the development split (Eqs. 9-10) and then evaluated on the held-out AppWorld test-normal split with terminal rewards. No equation reduces the reported test performance to the verifier definition: the preference signal is an explicit proxy, and the final selection criterion is a different, terminal measure. The acknowledged limitation in Section 7 that the verifier 'may not capture silent state corruption' is an assumption about proxy alignment, not a circular step; the same section also states that future work will develop richer boundary-local signals. The cross-model transfer result in Table 2 is an independent external check of the same frozen template on a different agent and compressor. No load-bearing self-citations or imported uniqueness theorems appear: references to OpenClaw, ACON, LLMLingua-2, and other baselines are used for harness adaptation and comparison, not to justify the central claim. The main risks are experimental confounding (terminal dev selection and the system-prompt audit instruction may contribute to the gains) and proxy misalignment, but these are correctness concerns, not circularity. The paper is preliminary and clearly marks its limits, including single-benchmark evaluation and single-target transfer, which further supports a non-circular, externally checkable design.

Assumptions & free parameters 6 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the proxy definition of execution burden as blocked and repeated actions, a small hand-selected optimization set of 12 boundaries, 3 candidates, and 5 proposer templates, and the representativeness of AppWorld. No new physical entities are introduced. These are the design choices that would need to be varied in a sensitivity analysis.

free parameters (6)
  • Rollout horizon K for verifier and diagnostic rollouts = 5 actions
    Used in Equations 2 through 4 and in Section 3.3; the choice of K determines which regressions are counted and the cost of evaluation.
  • Number of training boundaries selected = 12
    Stratified sampling across AppWorld error types in Section 4.2; the optimization supervision is built from these 12 examples.
  • Number of candidate summaries per boundary = 3
    Equation 5; preferences are computed among three samples of the frozen compressor, which may under-cover the summary space.
  • Number of proposer candidate templates = 5
    Equations 8 and 10; the final template is selected from five candidates on the development split, a small and potentially high-variance pool.
  • Context budget B = 4,096 tokens
    The compression window used in all main experiments in Section 5.1; results may shift at other budgets.
  • Sampling counts for paired rollouts = 10 next actions in Figure 2, 24 in Figure 3, 5 and 3 free rollouts per rendering in Section 3.3
    Chosen sample sizes for the diagnostic probes; larger counts would reduce variance of the divergence and marginal-effect estimates.
assumptions (4)
  • domain assumption Blocked and repeated actions are a sufficient proxy for compression-induced execution regressions.
    The verifier score Q is defined entirely from these events in Equations 2 through 4, and silent state corruption is excluded by the paper's own limitation statement in Section 7.
  • domain assumption Paired closed-loop rollouts from the same environment state isolate the effect of compression from intrinsic agent variability.
    PRE is used as a paired control in Section 4.1, but PRE itself is a stochastic rollout, so the difference estimator has sampling noise that the main tables do not quantify.
  • domain assumption AppWorld generalizes to other long-horizon tool-use environments.
    All optimization and evaluation use the AppWorld benchmark; Section 5.4 only tests one additional target model and the paper defers other benchmarks to future work.
  • domain assumption The frozen LLM proposer can infer effective policy revisions from 12 contrastive summary pairs without rollout details.
    The proposer sees only compressor inputs and ordinal preferences in Section 4.2; the quality of the final prompt depends on this inference step, which is not itself measured.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Toward Reliable Context Compression for Long-Horizon Agents: An Empirical Study of Execution Instability." pith.science (2026). https://pith.science/paper/SP4O3DVW

@misc{pith2026260806503,
  author       = {Pith},
  title        = {Pith review of: Toward Reliable Context Compression for Long-Horizon Agents: An Empirical Study of Execution Instability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SP4O3DVW}},
  note         = {Machine review of arXiv:2608.06503}
}
read the original abstract

Recurrent context compression controls context growth in long-horizon agents, but its behavioral effects remain poorly understood. In this preliminary empirical study, we show that compression can weaken the influence of recent interactions, increasing blocked actions, repeated exploration, and instability across runs. Motivated by these observations, we introduce TRACE, a verifier-guided framework that evaluates individual compaction events through paired closed-loop continuations from the same environment state and uses summary preferences to optimize a natural-language compression prompt while keeping all models frozen. Initial results on AppWorld show improvements over existing compression baselines in task performance, multi-run reliability, and context--execution efficiency. These findings provide early evidence for boundary-local evaluation as a promising direction for reliable agent context compression.

Figures

Figures reproduced from arXiv: 2608.06503 by the authors.

Figure 1
Figure 1. Repeated context replacement degrades agent behavior despite refetchable information. AppWorld allows agents to re-query persistent application state, so previously observed information remains recoverable after compaction. (a) Mean pass rate declines as the context budget shrinks. (b) The widening gap between P@2 and P 2 indicates reduced reliability across repeated runs. (c) Even with summary-based compaction, deg… view at source ↗
Figure 2
Figure 2. Terminal completion. Total height denotes the termination rate; dark segments denote termination in the required form. The degradation in Section 3.1 is often at￾tributed to the loss of facts, variables, or task progress during summarization. This account is incomplete in our setting: earlier observations remain re-queryable in App￾World, while FIFO truncation remains com￾petitive at moderate budgets despite dis￾car… view at source ↗
Figure 3
Figure 3. Effect of recent interac￾tions. Divergence from full-history behavior when the new interaction history is retained verbatim, com￾pressed, or omitted. Error bars de￾note task-level 95% bootstrap confi￾dence intervals. We independently sample 24 next actions under each context. Sampled actions are neither executed nor fed back to the agent. We canonicalize the primary API call and compute its noise-corrected total-var… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Blocked execution and regressive exploration. Marginal POST-minus-PRE ef￾fects at each of the first five actions after com￾paction. Blocked/error actions follow App￾World’s native error contract; refetch/replay denotes an exact action signature previously observed befo…
Figure 5
Figure 5. Figure 5: Overview of TRACE. At each compaction boundary, paired closed-loop continu￾ations are evaluated from the same environment state. PRE retains the context available before compaction, whereas POST replaces the compressible history with a candidate sum￾mary. The verifier …
Figure 6
Figure 6. Figure 6: Efficiency across task difficulty. Average peak input tokens versus average agent steps on AppWorld test-normal, grouped by task difficulty. Lower-left is better. Red dashed circles highlight TRACE. improvement in Pass2 indicates that the optimized prompt improves not …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

32 extracted references · 30 canonical work pages

  1. [1]

    In Progress

    [Ordered list of what should happen next] ## Critical Context - [Any data, examples, or references needed to continue] - [Or "(none)" if not applicable] Keep each section concise. Preserve exact file paths, function names, and error messages. OpenClaw iterative-update prompt The messages above are NEW conversation messages to incorporate into the existing...

  2. [2]

    VARS | name | value | purpose | |------|-------|---------| Record every runtime value the next session must re-declare (tokens, ids, lists, last page_index/page_limit, etc.)

  3. [3]

    TODO List pending actions with enough detail to execute directly

  4. [4]

    N. ACTION target --- outcome [tool: name]

    [Ordered list of what should happen next] ## Critical Context - [Any data, examples, or references needed to continue] - [Or "(none)" if not applicable] Keep each section concise. Preserve exact file paths, function names, and error messages. 17 Preprint. Work in progress. Prompting-H (Hermes-agent compaction).The Hermes baseline 6 summarizes middle turns...

  5. [5]

    - Note how earlier steps influence later ones

    REASONING - Key progress, decisions, outcomes, and their rationale. - Note how earlier steps influence later ones

  6. [6]

    So do not write code making calls to os-level modules and functions

    Any reference to a file system in the task instructions means the file system * app*, operable via given APIs, and not the actual file system the code is running on. So do not write code making calls to os-level modules and functions

  7. [7]

    E.g., do NOT use`spotipy`for Spotify

    To interact with apps, only use the provided APIs, and not the corresponding Python packages. E.g., do NOT use`spotipy`for Spotify. Remember, the environment only has the standard library

  8. [8]

    COMPLETED Bullet list of finished subtasks with brief results

Show all 32 references
  1. [9]

    - Memory resets; re-create VARS before use

    GUARDRAILS Short reminders that prevent repeat errors, e.g. - Memory resets; re-create VARS before use. - Paginate until empty page. - Validate API parameters against spec. - Avoid redundant logins or doc look-ups. Requirements: - Be concise-bullets and tables preferred; no ex...

  2. [10]

    REASONING One brief paragraph on key progress and rationale

  3. [11]

    VARS key=value pairs, comma-separated; only still-needed runtime values

  4. [12]

    TODO Bulleted next actions (<=5)

  5. [13]

    COMPLETED Bulleted finished subtasks (<=5)

  6. [14]

    global_rules

    GUARDRAILS Single concise bullet, or omit if none. Return only the <HISTORY_SUMMARY> block---no additional commentary or input echoes. BTracePrompts B.1 Optimized Prompt TraceOptimized Update Prompt <conversation> {{ history }} </conversation> <previous-summary> {{ prev_summar...

  7. [15]

    sections.critical_context

    [Update based on current state] >>> </slot> <slot name="sections.critical_context"> <<< - [Preserve important context, add new if needed] >>> </slot> <slot name="closing_rules"> <<< Keep each section concise. Preserve exact file paths, function names, and error messages. >>> <...

  8. [16]

    spotify_password) in the example above were only for demonstration

    The email addresses, access tokens and variables (e.g. spotify_password) in the example above were only for demonstration. Obtain the correct information by calling relevant APIs yourself

  9. [17]

    Any thoughts should be put as code comments

    Only generate valid code blocks, i.e., do not put them in```...```or add any extra formatting. Any thoughts should be put as code comments

  10. [18]

    You can use the variables from the previous code blocks in the subsequent code blocks

  11. [19]

    Make sure everything is working correctly before making any irreversible change

    Write small chunks of code and only one chunk of code in every step. Make sure everything is working correctly before making any irreversible change

  12. [20]

    But modules and functions that have a risk of affecting the underlying OS, file system or process are disabled

    The provided Python environment has access to its standard library. But modules and functions that have a risk of affecting the underlying OS, file system or process are disabled. You will get an error if do call them

  13. [23]

    All calls to APIs and parsing its outputs must be as per this documentation

    The provided API documentation has both the input arguments and the output JSON schemas. All calls to APIs and parsing its outputs must be as per this documentation

  14. [24]

    For APIs that return results in "pages", make sure to consider all pages

  15. [25]

    Do not rely on your existing knowledge of what the current date or time is

    To obtain current date or time, use Python functions like`datetime.now()`or obtain it from the phone app. Do not rely on your existing knowledge of what the current date or time is

  16. [26]

    All requests are concerning a single, default (no) time zone

    For all temporal requests, use proper time boundaries, e.g., if I ask for something that happened yesterday, make sure to consider the time between 00:00:00 and 23:59:59. All requests are concerning a single, default (no) time zone

  17. [27]

    Any reference to my friends, family or any other person or relation refers to the people in my phone's contacts list

  18. [28]

    supervisor

    All my personal information, and information about my app account credentials, physical addresses and owned payment cards are stored in the "supervisor" app. You can access them via the APIs provided by the supervisor app. 27 Preprint. Work in progress

  19. [29]

    If the task asks for some information, return it as the answer argument, i.e

    Once you have completed the task, call`apis.supervisor.complete_task()`. If the task asks for some information, return it as the answer argument, i.e. call` apis.supervisor.complete_task(answer=<answer>)`. For tasks that do not require an answer, just skip the answer argument ...

  20. [30]

    How many songs are in the Spotify queue?

    The answers, when given, should be just entity or number, not full sentences, e. g.,`answer=10`for "How many songs are in the Spotify queue?". When an answer is a number, it should be in numbers, not in words, e.g., "10" and not "ten"

  21. [31]

    You can also pass`status="fail"`in the complete_task API if you are sure you cannot solve it and want to exit

  22. [32]

    preserve everything

    You must make all decisions completely autonomously and not ask for any clarifications or confirmations from me or anyone else. USER: Using these APIs, now generate code to solve the actual task: My name is: {{ supervisor.first_name }} {{ supervisor.last_name }}. My personal e...

  23. [2024]

    doi: 10.18653/v1/2024.findings-acl.57

    Association for Computational Linguistics. doi: 10.18653/v1/2024.findings-acl.57. URLhttps://aclanthology.org/2024.findings-acl.57/. 13 Preprint. Work in progress. Shivam Shandilya, Menglin Xia, Supriyo Ghosh, Huiqiang Jiang, Jue Zhang, Qianhui Wu, Victor Rühle, and Saravan Ra...

  24. [2025]

    doi: 10.18653/v1/2025.acl-long.1219

    Association for Computational Linguistics. doi: 10.18653/v1/2025.acl-long.1219. URLhttps://aclanthology.org/2025.acl-long.1219/. Miao Lu, Weiwei Sun, Weihua Du, Zhan Ling, Xuesong Yao, Kang Liu, and Jiecao Chen. Scaling llm multi-turn rl with end-to-end summarization-based con...

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.