DTOC: Dynamic Tool Output Compression for Adaptive Context Management in AI Agents

1 Introduction

• Transformer attention scales as O(n^2), and retrieval of task-critical details can degrade before a model reaches its nominal context limit.The paper describes this degradation as “context rot.”Source: §1 · p. 2
• Long-horizon workflows accumulate prompts, tool outputs, and reasoning until context saturates, risking loss of early objectives, safety constraints, and assumptions through truncation.This can leave subsequent reasoning based on a distorted representation of the task.Source: §1 · p. 2
• Hard truncation irreversibly removes information, while summarization can introduce abstraction errors or hallucinations and static masking can miss relevant earlier outputs.These approaches may lead agents to overlook failure signals or repeat unproductive actions.Source: §1 · p. 2
• DTOC stores tool outputs externally and replaces them in active context with lightweight references that agents can selectively hide and restore.Context management becomes an explicit agent action rather than a fixed system mechanism.Source: §1 · p. 2

2 Related Work

• ReAct interleaves reasoning and actions but assumes relatively short histories and does not explicitly address finite context windows in long-horizon trajectories.The paper identifies ReAct as DTOC’s conceptual lineage [17].Source: §2 · pp. 2–3
• LLMLingua removes low-importance tokens for static-prompt compression, but its one-way deletion can discard task-specific details such as identifiers, parameters, and error codes.The passage reports compression up to 20× in some settings while maintaining benchmark performance.Source: §2 · p. 3
• Progressive Disclosure loads referenced resources selectively; DTOC extends this principle from files or queries to the evolving conversational state.The passage describes agents maintaining lightweight references and loading full content when needed.Source: §2 · p. 3
• ACE adapts strategic playbooks through a generator–reflector–curator cycle, whereas DTOC manages tool-output visibility and token use for the traces those strategies rely on [19].The passage describes ACE’s focus on strategy representations and DTOC’s complementary low-level role [19].Source: §2 · p. 3

3.1 General Mechanism Overview

• DTOC keeps tool outputs in a persistent external repository and assembles active context from the current query, reasoning trace, and a curated subset of prior outputs.Outputs remain recoverable through explicit retrieval and unloading rather than irreversible deletion.Source: §3.1 · p. 4

3.2 Implementation via Explicit Tool-Based Control

• A dedicated manage_context tool lets agents enable or disable outputs by orchestrator-assigned keys, replacing hidden results with metadata placeholders and restoring full results when enabled.The orchestrator wraps results in structured JSON with a key, raw output, and estimated token count; Figure 1 depicts the visibility changes.Source: §3.2 · p. 4, Figure 1 · p. 5

3.3 DTOC Data Structures and Tool Interface

• ToolOutput records persist raw results and metadata; context assembly includes visible results in full and substitutes placeholders for hidden ones, while ManageContext reports modified keys and token-count change.Token estimates use len(content)/4; placeholder size is approximately 30–50 tokens, and DTOC does not override provider-level truncation.Source: §3.3 · pp. 5–6

3.4 Context Engineering Perspective

• DTOC treats interaction history as an optimizable information payload, extending Progressive Disclosure to the full trajectory and making context selection an agent-invoked policy.Its compact action vocabulary includes select, enable, disable, and retrieve.Source: §3.4 · p. 7

3.5 Relation to ACE and Playbook Evolution

• DTOC handles low-level token and tool-output management while ACE evolves high-level strategic playbooks, helping keep those strategies and their evidentiary traces within the effective attention span.The methodology instruments decision traces and DTOC operations to study context pathologies alongside strategic failures.Source: §3.5 · p. 7

4 Experimental Setup

• The evaluation uses five models spanning three providers, context capacities from 128K to 1M tokens, and paired capability tiers where available, under DTOC ON and OFF conditions.The setup selects these variations to examine provider, context-size, and capability effects.Source: §4 · pp. 7–8, Table 1 · p. 8

4.1 Tasks and Environments

• DeepSWE’s six software tasks require complete features passing project tests and generate 30–285-step trajectories; OpenCode runs identical configurations except for DTOC’s manage_context tool.Task success is binary: all project tests passing receives 1.0, otherwise 0.0; the aggregate table reports solve rate and cost solved.Source: §4.1 · p. 8, Table 2 · p. 9

5.1 DeepSWE Benchmark

• DTOC’s effects vary by model: Sonnet 4.6, GPT-5.4, and GPT-5.5 improve solve rates, while Opus 4.8 is unchanged and Gemini 3.5 Flash is unchanged.The reported model results show that the aggregate response is not uniform.Source: §5.1 · pp. 9–10
• 50% versus 20% solve rate: Sonnet 4.6’s DTOC condition also lowers input tokens by 10.3% and cost per solved task from $26.27 to $8.65.Mashumaro was not evaluated for Sonnet without DTOC because of infrastructure timeouts.Source: §5.1 · p. 9
• 50% versus 33% solve rate: GPT-5.4 with DTOC reduces input tokens by 12.7%, agent steps by 32.3%, and cost per solved task from $9.30 to $2.64.It achieved the lowest cost per solved task among the reported models.Source: §5.1 · p. 9
• 2/6 versus 1/6 solve rate: GPT-5.5’s cost per solved task falls from $100.49 to $49.93 despite negligible input-token savings.Agent steps increase by 14.3% under DTOC.Source: §5.1 · p. 10
• Opus 4.8 remains at 3/6 solved tasks while input tokens rise 18.4%; Gemini 3.5 Flash remains at 1/5 while input tokens rise 48.7%.The task solve matrix indicates task difficulty also moderates DTOC’s effects: narwhals and fastapi remain unsolved, while DTOC’s largest effects appear on medium-difficulty tasks.Source: §5.1 · pp. 10–11, Table 3 · p. 10

5.2 Ablation Study

• The ablation compares no compression, tool tracking only, disable-only, and full enable-plus-disable DTOC configurations.Full DTOC reaches 83.6% success with 61K tokens and zero file re-reads; disable-only reaches 81.4% with 57K tokens and 0.1 average re-reads.Source: §5.2 · p. 11, Table 4 · p. 11
• Full DTOC achieves the ablation’s highest success rate, while tool tracking without disabling context reaches 77.8% success and uses 87K tokens.The results support the importance of recovery capability for peak reliability while retaining a leaner context footprint than the uncompressed baseline.Source: §5.2 · p. 11

6.1 Reflection on Results

• DTOC raises solve rates and lowers costs for Sonnet 4.6, GPT-5.4, and GPT-5.5, but provides little or no aggregate benefit for Opus 4.8 and Gemini 3.5 Flash.For Opus, DTOC solves mashumaro while DTOC OFF solves sqlite-utils, so aggregate neutrality masks differing task outcomes.Source: §6.1 · p. 11
• Native context-management behavior, output verbosity, and instruction-following fidelity may explain the model-level differences.The authors contrast models that avoid redundant interactions with models that make many small reasoning steps, and note Opus’s substantially larger average output.Source: §6.1 · pp. 11–12
• Medium-difficulty tasks such as sqlite-utils and mashumaro are often where DTOC separates success from failure; easier ts-pattern is consistently solved, while narwhals and fastapi remain unsolved.The authors say DTOC mitigates premature task abandonment by preserving a manageable active context during long trajectories.Source: §6.1 · p. 12
• Cost per solved task falls by approximately 67–72% for Sonnet 4.6 and GPT-5.4, while Opus and Gemini incur cost penalties when DTOC increases token consumption.The authors attribute the gains to direct token savings and improved solve rates, and highlight model-specific deployment as important.Source: §6.1 · p. 12

6.2 Limitations

• The evaluation covers six feature-request tasks, uses one trial per model–task–condition, and lacks direct comparisons with alternative context-management approaches.The authors also note that the binary all-tests-pass metric obscures partial progress.Source: §6.2 · p. 12

6.3 Future Work

• The authors characterize the work as a proof of principle and call for larger benchmarks, repeated runs, and additional baselines.Future directions include budget-aware prompting, hybrid compression, and model-adaptive policies.Source: §6.3 · p. 13

• For responsive models, solve rates rose (Sonnet 4.6: 20% to 50%; GPT-5.4: 33% to 50%) and cost per solved task decreased by 67–72%.Source: §7 · p. 13
• Claude Opus 4.8 and Gemini 3.5 Flash had unchanged solve rates and 18–49% higher token consumption; each condition was run once, requiring repeated-trial validation.Source: §7 · p. 13
• Agents adopted task-sensitive breadth-then-depth exploration, iterative refinement, and chunking, supporting compression decisions based on evolving beliefs and plans rather than fixed rules.Source: §7 · pp. 13–14
• DTOC is compatible with ReAct-style agents and tool ecosystems, using orchestrator-level output tracking and one added tool without provider-specific APIs.Source: §7 · p. 14
• The authors identify learned compression policies, hierarchical summaries, and multi-agent coordination as directions for future work.Source: §7 · p. 14