PaperlayerView exact revision on arXiv

Source-linked AI summary

ContextRender: From Execution Dependencies to Agent Context

Savini Kashmira, Jayanaka L. Dantanarayana, Lingjia Tang, Jason Mars

arXiv:2609.37743v1cs.AI

TL;DR

Long-horizon agents need earlier tool results, but full-history carryover is costly and context reduction risks omitting needed information. ContextRender records execution dependencies and uses observed reuse alongside recency and semantic relevance to select results within a fixed history budget. Across two benchmarks and three execution models, it outperforms evaluated managed-context baselines at 6K history while staying close to or above Full history and reducing mean inference cost.

  • Problem

    Long-horizon agents may need earlier tool results, but carrying the full interaction history is costly and reducing it risks omitting information needed later.

    Source: §1 · pp. 1–2

  • Method

    ContextRender stores execution history and reuse relationships in a persistent graph, using Tool-Flow Analysis to combine observed reuse with recency and semantic relevance for budgeted selection.

    Source: §1 · p. 2

  • Results

    At 6K history, ContextRender outperforms evaluated managed-context baselines across AppWorld and 8-objective QA with three models, stays close to or above Full history, and reduces mean standardized inference cost 10.2%–32.2%.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Ablations show that observed reuse improves task performance and retention of later-reused results, with particularly large recall gains after long intervals.

    Source: §1 · p. 3

    In the motivating AppWorld trace, recency and task relevance both omit a contact result later needed for Nancy’s email.

    Source: §2.1 · p. 3

Abstract

from arXiv · show

LLM agents performing long-horizon tasks accumulate tool results that later steps may need. Passing the full history to every invocation is costly even when it fits within the context window, while reducing it risks omitting needed information. Existing context management methods can overlook how earlier tool results are used in subsequent execution, leaving needed information out of context. We introduce ContextRender, which manages context through a persistent graph of execution dependencies. We develop Tool-Flow Analysis to track how later operations reuse information from earlier tool results, providing a signal called observed reuse. A renderer combines this signal with recency and semantic relevance to select results within a fixed history budget, retaining omitted results for later use. Across AppWorld and 8-objective QA with three execution models, ContextRender outperforms the evaluated context management baselines using a 6K history budget, well below the models' maximum context windows. Within this budget, it achieves task performance close to or above that of passing the full history while reducing mean inference cost by 10.2%-32.2% relative to Full history. Ablations show that observed reuse improves task performance and retention of results reused later.

1 INTRODUCTION

Long-horizon agents need earlier tool results, but carrying or reducing the full interaction history creates cost and omission trade-offs. ContextRender uses execution dependencies to select history within a budget; across two benchmarks and three models, it performs strongly against managed-context baselines while reducing inference cost.

1 INTRODUCTION

  • Passing the full accumulated history at every invocation is costly, can exceed the context window, and may expose the model to irrelevant context.Managing history can reduce inference cost even when the history fits within the context window.Source: §1 · p. 1
  • Pruning, compaction, and other context-management approaches can leave earlier tool-result details absent or incomplete when later steps need them.If complete results are not retained elsewhere, recovering details may require additional tool calls.Source: §1 · pp. 1–2
  • Execution dependencies reveal when earlier results remain useful beyond their age or semantic similarity to the current step.Source: §1 · p. 2
  • Tool-Flow Analysis tracks later reuse of values from earlier tool results, while a persistent graph stores execution history and reuse relationships for budgeted selection.The renderer combines observed reuse with recency and semantic relevance; unselected results remain available for later invocations.Source: §1 · p. 2
  • At 6K history, ContextRender leads managed-context baselines across both benchmarks with all three models, stays close to or above Full history, and cuts mean standardized inference cost 10.2%–32.2%.The benchmarks are AppWorld and 8-objective QA; the 6K history budget is well below the models’ maximum context windows.Source: §1 · p. 2
  • Ablations show that adding observed reuse improves task performance and retention of results reused later, with particularly large recall gains after long intervals.Source: §1 · p. 3

2 MOTIVATION

The dinner-bill example shows how a result can be omitted by recency and task relevance even when a later step needs its information. Recording execution dependencies provides another signal for selecting earlier results within a small history budget.

2 MOTIVATION

  • The example illustrates the trade-off: full-history carryover incurs inference cost, while selecting history within a budget risks omitting information needed later.Source: §2 · p. 3

2.1 LIMITATIONS OF RECENCY AND RELEVANCE

  • At Turn 18, both recency and task relevance omit the Turn 8 contact result, although Nancy’s email is needed and remains available only there.Recency favors later turns, while task relevance favors Venmo APIs and payment operations.Source: §2.1 · p. 3

2.2 EXECUTION DEPENDENCIES FOR CONTEXT SELECTION

  • A persistent context graph and Tool-Flow Analysis record execution dependencies as evidence of reuse, adding a selection signal beyond recency and task relevance.The goal is to preserve useful information within a small history budget while supporting performance close to or above passing the full history.Source: §2.2 · p. 4

3 CONTEXTRENDER

CONTEXTRENDER stores execution history in a persistent context graph and selects complete tool results under a fixed history budget. Its renderer combines observed reuse with recency and semantic relevance.

3 CONTEXTRENDER

  • At each model invocation, CONTEXTRENDER combines observed reuse, recency, and semantic relevance to select earlier tool results from a persistent graph under a fixed budget.The graph stores messages, tool calls, and complete tool results.Source: §3 · p. 4

3.1 PERSISTENT CONTEXT GRAPH

  • The persistent graph stores messages, tool calls, and complete tool results in chronological order, with each result’s content, position, timestamp, and embedding.Result age and content embeddings support recency and semantic relevance, respectively.Source: §3.1 · p. 4

3.2 TOOL-FLOW ANALYSIS

  • Tool-Flow Analysis links later exact, case-sensitive value matches to the first earlier result containing each value, while its reuse score counts distinct matches and downweights values shared by results.Matches are counted once per later model output or tool call; the weighting reduces the contribution of values appearing in multiple historical results.Source: §3.2 · p. 5

3.3 CONTEXT RENDERING

  • The renderer combines recency, semantic relevance, and reuse evidence, then selects complete results by usefulness while avoiding near-duplicates and retaining omitted results for later reconsideration.Reuse contributes with diminishing returns; usefulness is recomputed before subsequent invocations as the graph changes.Source: §3.3 · p. 5

3.4 RUNTIME INTEGRATION

  • A separate server receives execution updates through an adapter and returns budget-rendered context before each model invocation, while the agent continues its normal execution.The implementation uses Jac and its Object Spatial Programming abstractions to represent and operate over the graph.Source: §3.4 · p. 6

4 EVALUATION

The evaluation compares ContextRender with managed-context baselines and Full history across two long-horizon benchmarks, measuring task performance, inference cost, observed-reuse ablations, and history-budget sensitivity.

4 EVALUATION

  • The evaluation measures task performance and inference cost against un-managed Full history and selected context-management baselines, then tests observed reuse and budget sensitivity.The primary history budget is B = 6K.Source: §4 · p. 6, §4.1 · p. 6

4.1 BENCHMARKS AND BASELINES

  • The benchmarks are AppWorld’s 168 Test-Normal and 417 Test-Challenge tasks and 100 8-objective QA tasks; five managed-context baselines share the 6K history budget.Full history passes the entire accumulated execution history as a reference, even when it exceeds that budget.Source: §4.1 · p. 6

4.2 EVALUATION METHODOLOGY

  • GPT-4.1, Muse Glimmer 30B, and DeepSeek V4 Pro were evaluated; AppWorld TGC, QA F1, Later-Used Result Recall, and mean inference cost measure performance, reuse retention, and efficiency.The reported cost comparison uses the same tasks that trigger context management after history exceeds 6K; Figure 4 plots performance against mean standardized cost, with Full history normalized to 1.Source: §4.2 · pp. 6–7, §4.3 · p. 7, Figure 4 · p. 7

4.3 TASK PERFORMANCE AND INFERENCE EFFICIENCY

  • Across nine settings, CONTEXTRENDER beats all five managed-context baselines (3.3%–32.5% AppWorld TGC; 1.7%–14.4% QA F1), while matching or exceeding Full history and cutting cost 10.2%–32.2%.Performance gains over Full history were 2.9%–8.5% in seven of nine settings.Source: §4.3 · p. 7, Table 1 · p. 8

4.4 ABLATION STUDY

  • Adding observed reuse to recency plus relevance raised task performance by 4.1% on AppWorld TGC and 4.5% on QA F1, with recall gains of 41.6% and 19.6%, respectively.For AppWorld results reused more than 25 turns later, CR–Full achieved approximately 3× the recall of CR–Recency + Relevance.Source: §4.4 · p. 8

4.5 SENSITIVITY TO THE HISTORY BUDGET

  • Across tested budgets, CONTEXTRENDER beat the strongest evaluated baseline by up to 4.7 percentage points in AppWorld TGC and 1.4 points in QA F1.AppWorld performance moved closer to Full history as the budget increased, with little further improvement beyond 6K; QA varied within a 3.0-point range and stayed close to or above Full history.Source: Figure 5 · p. 9, §4.5 · p. 9

5 RELATED WORK

Prior work compresses, retrieves, or adaptively edits agent histories; ContextRender instead preserves complete tool results and uses execution dependencies as selection evidence.

5 RELATED WORK

6 CONCLUSION

The conclusion presents CONTEXTRENDER as a graph-based selector that combines observed reuse, recency, and semantic relevance while retaining omitted results for later use.

6 CONCLUSION

  • Across AppWorld and 8-objective QA with three execution models, CONTEXTRENDER outperforms evaluated managed-context baselines at 6K, stays close to or above Full history, and cuts mean inference cost 10.2%–32.2%.The 6K history budget is well below the models’ maximum context windows.Source: §6 · p. 9

A IMPLEMENTATION DETAILS

  • The appendix covers execution procedure, TFA matching rules, scoring configuration, history-budget accounting, evaluation protocols, cost accounting, numerical results, and runtime integrations.Evaluation settings and protocols appear in Appendix B, cost accounting and numerical results in Appendix C, and runtime integrations in Appendix D.Source: A IMPLEMENTATION DETAILS · p. 12

A.1 EXECUTION PROCEDURE

  • Before each invocation, the server updates the persistent graph; if history exceeds B, the renderer greedily selects fitting tool results, while unselected complete results remain available for later reconsideration.If accumulated history fits within B, it is included in full.Source: §A.1 · p. 12

A.2 TOOL-FLOW ANALYSIS IMPLEMENTATION

Tool-Flow Analysis (TFA) tracks reuse of values from earlier tool results, and the renderer selects results using usefulness scores under a history budget. Omitted results remain stored for possible later selection.

A.2 TOOL-FLOW ANALYSIS IMPLEMENTATION

  • TFA extracts qualifying tokens from tool results and detects later uses through exact, case-sensitive whole-token matches in model outputs or tool calls.Candidates must meet the stated character filters; file paths are checked as separate segments.Source: §A.2 · pp. 12–13
  • TFA links a reused value to the first earlier tool result containing it, but this attribution is a ranking signal, not proof of original provenance or causal dependency.Match contributions are weighted by how many historical tool results contain the value.Source: §A.2 · pp. 12–13

A.3 USEFULNESS CONFIGURATION

  • The usefulness score combines result age, semantic relevance, and observed reuse, with equal weights, λ = 0.3, and γ = 0.2.Relevance uses the first user message and latest visible user and assistant messages; result embeddings use up to 8,000 characters.Source: §A.3 · pp. 13–14

A.4 SELECTION AND BUDGET ACCOUNTING

  • The history budget covers retained history messages, associated tool calls, and selected result text; non-tool history is retained chronologically and charged first.The history budget is separate from the system prompt, current user message, and total model context window.Source: §A.4 · p. 14
  • The renderer greedily adds the feasible result with the highest adjusted usefulness score, skips results that do not fit, and stops when none remain feasible.Selected results return in chronological order; omitted results remain stored in full and can be selected again as scores change.Source: §A.4 · pp. 14–15

B.1 MODEL AND API SETTINGS

  • The evaluation uses three execution models with temperature 0.0, top-p 1.0, and seed 42, and sets its primary history budget to B = 6K.The GPT-4.1 budget-sensitivity study also tests other budgets on both benchmarks.Source: §B.1 · p. 15

B.2 BASELINE IMPLEMENTATION DETAILS

The baseline implementations use a shared history-budget scope, while differing in how they retain, summarize, or retrieve earlier tool results. Full history serves as an unbudgeted reference.

B.2 BASELINE IMPLEMENTATION DETAILS

  • All budgeted context-management baselines use the same history budget, tokenizer-based counting, and budget scope, including historical messages, tool calls, results, and summaries.The history cap is distinct from complete model-input length.Source: §B.2 · p. 15
  • Prune keeps the newest complete tool results that fit, while Compact (LLM) compresses the accumulated history and Recency + Summary keeps recent results and summarizes older ones.Both summarization baselines use the same summary prompt; Recency + Summary merges earlier summaries with newly summarized content.Source: §B.2 · p. 15
  • Semantic Retrieval considers the three most recent turns first, using up to 60% of the budget, then ranks remaining results by cosine similarity; unselected results remain available for later selection.ACON uses the authors’ released history-compression implementation with its optimized compression guideline.Source: §B.2 · p. 15
  • Full history passes the entire accumulated execution history without context management, even when it exceeds the history budget, as a task-performance and inference-cost reference.Table 3 lists the scoring weights used in selector ablations; zero disables a term and retained weights remain unchanged.Source: §B.2 · p. 15, Table 3 · p. 16

B.3 SCORING PARAMETERS AND ABLATION CONFIGURATION

The selector ablations vary which scoring terms are active while holding the graph, budget, and selection procedure constant. Their combined-signal ordering is specific to the fixed configuration.

B.3 SCORING PARAMETERS AND ABLATION CONFIGURATION

  • The ablations disable omitted scoring terms by setting their weights to zero, without renormalizing or retuning retained weights.λ and γ remain fixed wherever their corresponding terms are active.Source: §B.3 · p. 16
  • All ablation variants share the persistent graph, history budget, budget accounting, and greedy selection procedure, differing only in the enabled usefulness-score terms.Removing observed reuse does not add separate identifier-based protection.Source: §B.3 · p. 16
  • Under fixed weights, one signal can displace a result favored by another, so the observed combined-signal ordering does not establish how separately tuned variants would compare.Recency + Relevance therefore need not outperform either signal alone.Source: §B.3 · p. 16

B.4 LATER-USED RESULT RECALL PROTOCOL

The recall protocol evaluates whether complete earlier tool results are visible at labeled lexical reuse events on recorded traces. Its event rules and interpretation distinguish this evaluation proxy from production TFA.

B.4 LATER-USED RESULT RECALL PROTOCOL

  • A lexical reuse event occurs when a later assistant turn contains an eligible exact-match token first appearing in a tool result, including in prose, code, or tool-call arguments.Eligible tokens have at least six letters, digits, or underscores and include an uppercase letter or underscore.Source: §B.4 · p. 16
  • Production TFA ranks results using value-level matches, whereas recall evaluation uses a fixed lexical event set on recorded traces, independent of each selector’s TFA detections.The evaluation’s first-appearance rule excludes values already present in task input or earlier assistant text.Source: §B.4 · p. 16
  • Each distinct assistant-turn and earlier-result pair counts once, and a result is visible only when its complete original text is present before the evaluated turn.A previously omitted result counts if it is selected again and restored in full.Source: §B.4 · pp. 16–17
  • The evaluator applies each selector to the same recorded histories before labeling the evaluated turn, with reuse counters based only on preceding turns.Higher recall indicates better retention for this reference event set, but does not establish dependency-detection accuracy or causal correctness.Source: §B.4 · p. 17
  • The recorded AppWorld histories contain 3,174 result-level reuse events, and the recorded 8-objective QA histories contain 335 across 100 tasks.Tables 4 and 5 report the respective event distributions by result age.Source: §B.4 · p. 17, Table 4 · p. 17, Table 5 · p. 17

C.1 COST COMPARISON TASKS

The cost comparison uses tasks whose uncapped histories exceed 6K tokens before an invocation and reports token use and standardized mean-cost ratios.

C.1 COST COMPARISON TASKS

  • Cost-comparison tasks are selected from reference runs when history exceeds B = 6K tokens before a model invocation.The selected task IDs are fixed for comparisons across methods.Source: §C.1 · p. 17

C.2 TOKEN USAGE, STANDARDIZATION, AND NORMALIZATION

  • Token usage counts input, output, and embedding tokens across agent and context-management calls, including compression and summarization.Input-token accounting includes the complete model input, while the history-token count enforcing B covers a different scope.Source: §C.2 · pp. 17–18
  • Standardized costs use the uncapped Full history cache fraction for every method and exclude graph storage and local selection computation.The measure compares token costs under common prices and cache assumptions; it is not a provider bill.Source: §C.2 · p. 18
  • Figure 4 normalizes Full history to 1 and plots a ratio of mean costs, not a mean of task-level cost ratios.The tables report mean inference cost in reference USD and normalized cost on the same selected tasks.Source: §C.2 · p. 18, Table 6 · p. 18

C.3 NUMERICAL PERFORMANCE AND COST RESULTS

The numerical results are presented as overall benchmark performance and mean inference costs; the runtime adapters modify outgoing model context at exposed integration points.

C.3 NUMERICAL PERFORMANCE AND COST RESULTS

  • Tables 6–8 report overall AppWorld TGC or QA F1 and mean inference cost, with AppWorld TGC covering 168 Test-Normal and 417 Test-Challenge tasks.The supplied table captions identify model-specific results and describe cost as measured on tasks exceeding B = 6K.Source: §C.3 · p. 18, Table 7 · p. 19, Table 8 · p. 19
  • Table 1 relative changes use each comparison method’s value as the denominator, and negative cost changes indicate reductions.Performance changes are relative percentages.Source: §C.3 · p. 18

D RUNTIME ADAPTERS

  • Adapters intercept outgoing context through runtime hooks, overridden history-building methods, or a configurable OpenAI-compatible proxy.Prompting, tool execution, parsing, and grading are not rewritten.Source: D RUNTIME ADAPTERS · p. 18, Table 9 · p. 20
  • The current adapter design requires a runtime to expose a point for inspecting and modifying outgoing context or a configurable model endpoint.Compatibility with every agent runtime is not claimed.Source: D RUNTIME ADAPTERS · p. 19
Loading 2609.37743v1…