Summary / 08. Context construction / Document
Paper 2026-09-05
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# The Frugal Window: Decision-Specific, Typed, and Aggressively Selective Context Construction for a Weak-Model Coding Harness *Component 08 of 27 — Coding-Harness Program. This document specifies the context-construction stage: the cross-cutting assembly engine that decides, for every model invocation, what of everything the pipeline knows is actually sent to the model, in what representation, in what order, and under what budget. It sits after component 07 (task decomposition and planning), which sequences the whole request into an executable schedule, and before the components that apply, verify, and repair the model's output. Where reconnaissance, retrieval, localization, impact analysis, and planning each produce candidate material about the repository and the task, and where retrieval (component 04) decides what enters the *candidate pool*, context construction decides what is actually *sent* — at what fidelity, in what order — for this particular decision. It is written to drive a reversible build; the executable specification follows in a companion document.* --- ## Abstract Context construction is the stage of the coding-harness program that bridges analysis and action: everything the earlier components know about the repository and the task must be narrowed, for each model invocation, into the single observation on which one decision is made. This paper argues that context construction should be decision-specific, typed, aggressively selective, and ephemeral. The window a model sees must be rebuilt from authoritative repository, execution, requirement, planning, and historical evidence for *every* invocation — never emitted once at task start and allowed to accumulate as the run proceeds. The material admitted must be typed, each field carrying its own rendering policy, because representation is as decisive as selection: the same retrieved entity, shown as a full body or a signature, produces a different decision. Selection must be aggressive, because irrelevant and mid-relevance material actively degrades output rather than merely wasting tokens, and no context — repository instructions, conversation history, or retrieved code — earns permanent admission merely because it may be generally useful. Ordering within the window must be deliberate, because attention is non-uniform and critical content buried mid-context is effectively invisible. And the whole must be assembled under a hard token budget and discarded once it ceases to be causally relevant. The paper reviews six lines of evidence — the agent-computer-interface result that observation design is a capability lever [1], the source-by-representation decomposition of prompt generation [2], the per-decision reconstruction of retrieved context [3], the noise-filtering result of context compression [4], the positional-attention curve of lost-in-the-middle [5], and the negative result on persistent repository context files [6] — together with the compression-tool lineage, honourable mentions, and classical roots beneath them. It derives seven design principles and specifies an architecture in which every stage except a single weak-LLM relevance-ranking call is deterministic software on CPU. It closes with the recursive self-improvement protocol and a measurement plan whose key instrument is the *window economy* — solve rate per token of context actually sent — because a context constructor that cannot be shown to beat a "stuff everything" baseline on tokens-per-solved has not earned its place in the pipeline. ## 1. Introduction The coding-harness program decomposes software engineering into a sequence of questions, and components 01 through 07 answered the opening seven: how to *interact* with code (01), how to *choose* an action (02), what the repository *is* (03), what context is *relevant* (04), *where the fault is* (05), *what an edit will break* (06), and *in what order the whole request should be executed, against what checkpoints* (07). This paper answers the question that sits between the answers to those seven and any further action — the question that precedes the very next model invocation, whatever it is: *of everything currently known, what exactly should the model see for its next decision?* Component 08, context construction, is the cross-cutting assembly engine of the pipeline: it consumes the candidate material that reconnaissance, retrieval, localization, impact analysis, and planning all produce, and decides what of it is actually *sent* to the model, at what fidelity, in what order, and under what token budget. Retrieval (component 04) decides what enters the *candidate pool* — the subset of the repository that might be relevant. Context construction decides the *observation*: which of those candidates, represented how, ordered how, against how large a budget. The distinction is sharp because the two stages optimize different things — retrieval optimizes recall of what could matter; context construction optimizes the precision of what the model actually attends to. The central fact of the problem is that the window is finite and it is the model's *only* contact with reality. A symbol, a test failure, a plan obligation, or a tool result that is not in the window does not exist for the purposes of the current decision; and a fact that is in the window but buried is nearly as absent. Attention is not uniform across a long context: accuracy is highest when the relevant item sits at the beginning or the end and collapses when it is forced into the middle, even for models whose stated window could technically hold everything [5]. Whatever the constructor fails to place it can lose, and whatever it places badly it can lose too. A second, reinforcing fact is that the window is an *economy*: instructions, code, conversation history, and tool output all compete for the same finite tokens, and every filler token displaces signal. The practitioner record shows why this matters in practice: raw tool observations — file contents and command output — routinely consume seventy to eighty percent of the entire token budget within a few iterations, crowding out the task material that the tokens were meant to serve [11]. A context constructor that does not treat this competition explicitly is not building context; it is passively watching one kind of content evict another. A third fact is the strongest warning in this component's literature, and it inverts a tempting engineering default: context that merely *sounds useful* is not necessarily useful, and can be actively harmful. A systematic evaluation of persistent repository context files — the architecture notes, conventions, and build-and-test instructions that coding systems are encouraged to inject into every turn — found that they did not generally improve task completion while increasing inference cost by over twenty percent, and that they drove agents to explore more broadly — more steps, more tool use — without converting that extra activity into better success [6]. The same theme recurs at a finer grain: a simple deterministic strategy that masks older environment observations, discarding them in favor of compact pointers while preserving the model's own reasoning and actions, halved cost relative to the raw agent while *matching* — and sometimes slightly exceeding — the solve rate of an expensive model-in-the-loop summarizer [9]. Reduction, applied where the evidence does not justify retention, does not merely save money; it removes noise that was degrading the decision. More information is not equivalent to more useful context [4]. The thesis follows from these observations. **Context construction should be decision-specific, typed, aggressively selective, and ephemeral: for every model invocation, rebuild the observation from authoritative repository, execution, requirement, planning, and historical evidence; choose the cheapest representation that preserves the information required for that decision; compress, deduplicate, and order it under a hard token budget; and discard information once it ceases to be causally relevant. No context — including repository instructions, history, or retrieved code — earns permanent admission merely because it may be generally useful.** The paper proceeds as follows. Section 2 reviews six lines of prior work plus the compression-and-placement tools, honourable mentions, and classical roots, each with its claims, numbers, and weak-model implication. Section 3 derives seven design principles. Section 4 specifies the architecture, labeling every node deterministic (D) or learned (L). Section 5 states the recursive self-improvement protocol. Section 6 gives the measurement plan. Section 7 concludes. ## 2. Related Work The literature divides into six modern lines — an agent-computer-interface anchor, a source-by-representation decomposition, a per-decision reconstruction result, a compression-as-noise-filter result, a positional-attention result, and a negative result on persistent context files that functions as the group's outlier — plus a set of compression-and-placement tools, a set of honourable mentions from the recent compaction lineage, and the classical roots beneath all of them. Each line answers one question the context-construction stage must resolve: what is the interface through which the model sees the world, what representation of an entity is chosen, when is context rebuilt, can reduction improve output, where in the window does critical content belong, and whether persistent "helpful" context earns its admission at all. ### 2.1 The anchor and the interface lesson: SWE-agent **SWE-agent** [1] is the anchor for this component, and it appears differently here than it does elsewhere in the program. Its central claim is broader than tool design: *what the model observes, and how those observations are represented, is a first-class capability lever.* The paper introduces the agent-computer interface (ACI) as the object of design, arguing that LM agents are a new category of end user that benefits from purpose-built interfaces the way humans benefit from IDEs, and shows that the same base model behaves very differently depending on what the harness exposes [1]. SWE-agent's interface formats file views with line numbers and a bounded scroll window, truncates command output deterministically, and emits a "no output" sentinel rather than empty noise — each a context-construction decision masquerading as a tooling detail. The numbers anchor the argument that observation design moves results at the same scale as model choice. SWE-agent reported pass@1 of 12.5% on the full SWE-bench split (12.47% of the 2,294 test tasks, solved 286/2294) and 18.0% on the Lite split (54/300), with a strong base model (GPT-4 Turbo); the paired 87.7% in the abstract is HumanEvalFix, not a Lite number, a point a careless reader can easily invert [1]. The interface ablations, which hold the model fixed and vary only what it sees, are among the few controlled measurements in this area: removing the file editor is the single largest drop (−7.7), the edit-linting guard alone costs −3.0, removing search costs −2.3 while removing iterative search costs −6.0, and degrading the file viewer to thirty lines or to a full file costs −3.7 and −5.3 respectively [1]. The lint guard is a guardrail on the editing component, not the largest single contributor — that is the file editor itself — but search and the edit-and-lint interface are jointly the principal levers. The lesson that ages best is the least glamorous: SWE-agent's history processor collapses observations older than a few turns into a one-line stub, a crude and deterministic eviction that the recent literature keeps rediscovering under better names [1]. A venue caveat belongs in the same breath: "NeurIPS 2024" is *not* stated in the arXiv record — the arXiv comment carries only a code-and-data URL — so the venue should be treated as unconfirmed rather than asserted. The weak-model implication is the reason this paper treats context construction as its own subsystem rather than a sub-case of retrieval. A weak model has less capacity to look past a noisy window, so the harness's job of delivering the right thing in the right form is *more* consequential, not less. The interface is the model's reality; for a weak model, garbage in the window becomes garbage in the patch more reliably than for a model that can route around it. ### 2.2 Source × representation: Repository-Level Prompt Generation **Repository-Level Prompt Generation** [2] supplies the cleanest decomposition in the area, and it is the most directly relevant paper for this component. It asks not merely *which code is relevant* but two separable questions: *prompt source* — where should context come from — and *prompt context type* — what representation should be extracted from that source [2]. The prompt proposals draw on repository relationships — the current file, parent-class files, sibling files, similarly named files, imports, and child classes — and vary the representation extracted from each: identifiers, fields, types, strings, method names, method bodies, and more. Combining ten sources with seven context types yields 63 prompt proposals (not the 70 the arithmetic suggests, because not every source-and-type combination is valid) [2]. The result is the oracle framing the whole stage needs: an *oracle* that always picks the best proposal for each example delivered a reported 36% relative improvement over Codex — a figure that must be read as the oracle upper bound, not an achievable result, since a learned model trained to predict the best proposal (their Repo-Level Prompt Generator) achieves up to 17% [2]. The ICML 2023 venue is confirmed by the arXiv journal-ref. The weak-model lesson is not the 36%; it is that *representation selection is an explicit, separable design operation with large headroom.* A retrieved entity is not synonymous with "insert its source." `SessionManager.refresh` might warrant a full body while `AuthMiddleware.login`, retrieved by the same query, warrants only a signature. Source selection and representation selection are two independent dials, and a context constructor that fuses them into a single "insert relevant file" action is leaving the second dial on the table [2]. ### 2.3 Context rebuilt per decision, not accumulated: RepoCoder **RepoCoder** [3] contributes the temporal principle: the correct context is conditional on the model's current state of understanding, so context is a *rebuilt artifact per decision*, not an accumulating transcript. RepoCoder alternates retrieval and generation in an iterative retrieval-generation (IRG) loop rather than retrieving once: each round constructs a fresh window, and the model's own intermediate output is fed back to seed the next round's retrieval, closing the gap between the retrieval context and the intended completion target [3]. Its retrieval-database mechanism is often misdescribed; the paper's phrase "coarse-to-fine" appears nowhere in it. The real mechanism is *sliding-window extraction*: a sliding window traverses repository files and extracts the most relevant contiguous *lines* that fit within the window, scored by token overlap with the query [3]. It reported improvements of more than 10% over its in-file baseline in all settings, consistently beating one-shot retrieval augmentation, on its own RepoEval benchmark covering line, API-invocation, and function-body completion scenarios; the EMNLP 2023 venue is confirmed [3]. The Part 8 lesson differs from the Part 4 lesson, where the takeaway was that *queries should evolve*. Here the takeaway is that *the context packet itself should be reconstructed for every decision*: each new draft, edit, test failure, or retrieved symbol is grounds to re-assemble the window, not to append another observation onto the one assembled at task start. A localization decision needs the issue, the repository skeleton, the failing stack, and candidate signatures. A repair-after-failure decision needs the current patch, the failed assertion, a short traceback, and the expected behavior. The two contexts barely overlap, and neither needs everything from the other [3]. For a weak model, treating context as working memory assembled on demand — rather than an accumulating transcript that eventually overflows — is close to the whole battle, because an overflowing transcript is where a weak model's attention degrades fastest. ### 2.4 Compression as a noise filter: Context Compression **On the Effectiveness of Context Compression for Repository-Level Tasks** [4] (Feng et al., 2026, a preprint the arXiv record labels "Work in progress") is almost tailor-made for this component's question. It is the first systematic empirical study of context compression for repository-level code intelligence, organizing eight compression methods into three paradigms — discrete token sequences, continuous latent vectors, and visual tokens — and evaluating them on code completion and generation against the two baseline facts that frame the whole problem: large multi-file contexts obscure critical information in noise, overflow context limits, and raise inference latency [4]. The finding is that compression acts as a *noise filter*, not merely a lossy cost-reduction: at 4× compression, the best continuous-latent methods *surpassed* full-context performance by up to 28.3% in BLEU score, because they removed distracting content rather than merely truncating it, and both visual and text-based compression achieved up to 50% reduction in end-to-end latency at high ratios, approaching the cost of inference without repository context at all [4]. The weak-model implication is the strongest single argument in this section for an aggressive default. If removing up to three quarters of the context can *improve* output quality by a quarter against full-context baselines on strong-model evaluations, then for a weak model — which is more susceptible to distractor degradation — the improvement from aggressive, well-chosen reduction is plausibly *larger*, and the harm from mindless stuffing is larger still. A twenty-percent latency cut is a nice efficiency win; a context that is simultaneously smaller *and* higher-signal is an efficiency win that also improves the decision. Because the paper is a 2026 preprint, its exact magnitudes need local replication, but the direction of its central claim — reduction is an information-quality mechanism, not merely a token-saving one — is consistent across this entire literature and is adopted here without reservation. ### 2.5 Ordering is correctness: Lost in the Middle **Lost in the Middle** [5] contributes the positional-attention result that makes *ordering within the prompt* a correctness variable rather than a cosmetic one. Across multi-document question answering and key-value retrieval, the authors find that performance is often highest when the relevant information sits at the beginning or the end of the input context and degrades significantly when the model must access it in the middle of a long context — even for models whose stated window fits everything [5]. With long distractor sets, closed-book answering sometimes beats placing the answer mid-context: better to have no context at all than to have the one thing you need buried where attention will not reach it. The implication for this component is concrete and operational. Critical content — the code immediately at the insertion point, the freshly failing test output, the key definition a change depends on — belongs pinned to the edges of the window; nothing that matters should be allowed to drift to the middle where it becomes attentionally invisible. The venue carries a minor correction the source material had wrong: the arXiv comment dates the paper to *TACL, 2023*, not 2024 — TACL is a rolling journal and the arXiv record itself says 2023 [5]. The ordering lesson is the same regardless, and it is one of the few places in this component where a purely deterministic rearrangement of existing content — costing zero tokens and invoking no model — buys real correctness. ### 2.6 The outlier, and the group's most important warning: Evaluating AGENTS.md **Evaluating AGENTS.md** [6] proposes nothing new; it *measures* the default. Modern coding systems routinely inject persistent repository context files — architecture descriptions, coding conventions, build commands, testing instructions, project rules — into the model's context every turn, on the intuition that this obviously useful grounding must help. Gloaguen et al. tested that intuition across multiple agents and models, in two settings: established SWE-bench tasks with LLM-generated context files, and a novel collection of issues from repositories that ship developer-committed context files [6]. Their finding is the negative result this component is built around: providing context files *did not generally improve task success*, while increasing inference cost by over twenty percent (the full text reports 20% and 23% on average), an observation that held across LLMs, agents, and both LLM-generated and developer-committed files [6]. The files' instructions *were* well followed — but repository overviews, though popular and recommended by model providers, were not helpful, and the extra context drove agents to explore more broadly — more steps (averaging +2.45 and +3.92 steps across settings) and more tool use — without converting that activity into better success, with five of eight settings dropping for the LLM-generated files [6]. No venue is stated in the arXiv record; the year 2026 is confirmed. The weak-model lesson is not "discard your conventions file." It is the much sharper policy that governs this whole stage: *context must justify its presence for the current decision, not merely be generally relevant to the repository.* A testing convention belongs in the window while the model decides how to run the tests, and should vanish while it modifies an arithmetic function. Architecture information matters while choosing an integration point and does not necessarily belong in the final repair prompt. The AGENTS.md authors' own conclusion — that such files are useful for specifying non-standard practices, but that any attempt to improve performance should be rigorously evaluated before deployment — is exactly the discipline this paper makes mechanical: never add context because it sounds sensible; prove it earns its tokens on the honest metrics of Section 6 [6]. ### 2.7 Compression and placement tools Two tools operationalize the compression and ordering principles of Sections 2.4 and 2.5. **LLMLingua** [7] compresses prompts with a small perplexity model that scores tokens for information content, allowing up to 20× token reduction with little performance loss across GSM8K, BBH, ShareGPT, and Arxiv-March23 — evidence that much prompt content is low-information and removable, and the anchor of the perplexity-model lineage. **LongLLMLingua** [8] extends it to long-context scenarios with two mechanisms this component borrows directly: *question-aware* coarse-to-fine compression, which scores chunks against the actual task rather than compressing blindly, and a *document reordering* strategy that moves the most relevant material to high-attention positions, explicitly operationalizing lost-in-the-middle [8]. Its gains — up to +21.4% on NaturalQuestions with about 4× fewer tokens, a 94.0% cost reduction on LooGLE, and 1.4×–2.6× end-to-end latency acceleration at 2×–6× compression of roughly 10k-token prompts — show that compression and placement are legitimate, measurable context-construction operations, not stand-ins for "get a bigger window" [8]. LLMLingua is confirmed EMNLP 2023 and LongLLMLingua ACL 2024. ### 2.8 Honourable mentions Four recent works sharpen specific decisions without anchoring the component. **The Complexity Trap: Simple Observation Masking** [9] is the negative result that should have ended a great deal of model-in-the-loop compression engineering: formalizing a trajectory as turns of reasoning, action, and observation, it shows that a simple deterministic strategy — condensing past *observations* while preserving the full history of the agent's reasoning and actions — *halves* cost relative to the raw agent while matching, and sometimes slightly exceeding, the solve rate of LLM-based summarization on SWE-bench Verified across five model configurations, with initial evidence of generality to the OpenHands scaffold and a hybrid strategy cutting costs a further 7% and 11% [9]. It is a clean argument against the assumption that history needs a model in the loop to be compressed, and it explains why SWE-agent's crude history processor aged so well. **CompactionRL** [10] is the current state of the art on the *learned* side: reinforcement learning that jointly optimizes task execution and summary generation for long-horizon agents, deployed in the training pipeline of GLM-5.2, with consistent coding gains (GLM-4.5-Air reaching 66.8% Pass@1 on SWE-bench Verified, +7.0). Its own caveat (§5.2) is the one this component carries forward: compaction-trained gains do not consistently transfer to single-context settings — under single-window evaluation the trained compactor can fall *below* its own base model — so a trained compactor is a model-plus-harness pair, not a drop-in component [10]. **Building Effective AI Coding Agents for the Terminal** [11] is the practitioner's account and supplies the number that frames the window economy: tool observations frequently consume 70–80% of the token budget, while emergency compaction at 95–99% capacity activates late, loses information, and compounds errors. Its OpenDev system instead applies graduated compaction at 70/80/85/90/99% pressure, moving observations through active, faded, and archived states, and replaces masked tool output with ~15-token pointers (e.g., "output offloaded to scratch file") so conversation structure survives [11]. **Context as an Environment: Scroll** [12] inverts the premise of all of the above: compression and external memory are lossy in the same way, because the agent sees history only through the summary or the store; Scroll instead keeps a lossless, append-only Event Log and provides summaries and indexes as *working views* that never become the sole representation, so the agent can grep, slice, and compute over its own history the way it does over the repository, evicting stale spans into an index that maps landmarks back to exact log addresses [12]. A one-week-old technical report, it is the most interesting reframing in the group and is held loosely. ### 2.9 The classical roots The modern lines rest on five classical results, cited here for lineage rather than numbers. Aider's repository map [13] ranks tree-sitter symbols under an explicit token budget to build a compressed map of the repo per task — the practitioner ancestor of typing and budgeting context by structure. AutoCodeRover [14] slices AST-aware context from the codebase instead of inserting raw files, the ancestor of representation choice as a first-class operation. MemGPT [15] treated context as paged memory managed like an operating system's — the ancestor of explicit eviction and an external home for state the model does not carry. Agentless [16] staged structure summaries as cheap coarse context rather than dumping files, an early instance of P3's cheapest-sufficient representation. And CodeAct / OpenHands [17] argued the action interface should be executable code — the ancestor of the guarded-output and apply-then-verify philosophy of P7. These five appear throughout later components; here they are the substrate the modern lines stand on. ## 3. Design Principles Seven principles follow from the review, each tied to the evidence above. **P1 — Decision-specific assembly.** The window is rebuilt from authoritative evidence for *every* model decision, not dumped once at task start and accumulated. RepoCoder's iterative retrieval-generation loop — a fresh window each cycle, seeded by the model's own most recent output [3] — is the warrant, and the weak-model argument is decisive: a weak model that is handed an ever-growing transcript must both retrieve the relevant item from it *and* decide correctly on top of it, two failure-prone operations where a constructor that sends only the current decision's material leaves the model one job. A localization decision, an edit decision, and a repair-after-test-failure decision need three different windows; nothing else should persist between them. **P2 — Typed context with per-field rendering policy.** The observation is a structured `DecisionContext` object whose fields — requirement, target, related symbols, impact obligations, tests, errors, history, constraints — each carry their *own* rendering choice: verbatim, signature, digest, truncated, or omitted. Prompt Generation's decomposition of context into an independent *source* dimension and *representation* dimension [2] is the warrant, made concrete: the source field of an edit may be verbatim while a dependency graph is digested and a stale historical observation is dropped, all in the same window. A requirement is usually kept exact; a related symbol usually needs only its signature. **P3 — Cheapest-sufficient representation.** Render each admitted piece of evidence in the *cheapest* form that still preserves the information that decision requires — a signature over a body, a digest over a full graph, a line over a file — expanding only when evidence demands it. Context Compression's 28.3% BLEU result — reduction *improving* output against a full-context baseline [4] — is the warrant that this is not a cost-compromise but an information-quality decision: a representation that drops the noise around the signal is not a lossy version of the evidence, it is a better version of it. The default is the cheap representation; expansion is the exception that must be earned. **P4 — Aggressive selectivity / distractor hygiene.** No context earns permanent admission merely because it may be generally useful; irrelevant and mid-relevance material actively harms the decision by competing for attention. The AGENTS.md negative result — persistent "helpful" context files did not improve success while raising cost over 20% and driving unproductive exploration [6] — is the warrant, and the RepoBench distraction finding (irrelevant or mid-relevance retrieved code degrades completion) reinforces it at the retrieval-granularity level. More context is a hypothesis about the current decision, not a default, and it must be tested like any other hypothesis. **P5 — Ordering is correctness.** Critical content — the code at the insertion point, freshly failing test output, key definitions — is pinned to the edges of the window, and nothing that matters is allowed to sit mid-context. Lost in the Middle's U-shaped attention curve [5] is the warrant, and LongLLMLingua's document reordering that operationalizes it into measurable gains [8] shows the placement is not a nicety. Because the same tokens in different positions yield different answers, ordering is a free correctness lever the constructor must not leave to chance. **P6 — Ephemeral and evictable.** Information is discarded once it ceases to be causally relevant: stale versions of edited code are dropped, superseded history is collapsed, and transient tool output is pruned first under pressure. SWE-agent's history processor, which collapses observations older than a few turns to a one-line stub [1], is the ancestor; OpenDev's graduated compaction that fades observations through active and archived states before summarization is ever needed [11] is the mature form; and the Simple Observation Masking result, that deterministic condensing of observations matches an LLM summarizer on solve rate while halving cost [9], is the warrant that eviction need not invoke a model at all. Scroll's caveat is the boundary: eviction may be lossless only if the raw ground truth remains recoverable by address rather than destroyed [12]. **P7 — The interface is the model's reality.** The harness controls the observation channel and must exercise that control deliberately: deterministic truncation with elision markers, bounded viewers, machine-parseable output, guarded apply-then-verify so that corrupted states never enter the window. SWE-agent's ACI result — that the same model performs very differently across interface variants, with the file editor's removal the single largest drop (−7.7) [1] — is the warrant that the channel is not a neutral pipe but an active determinant of capability. What the constructor fails to show the model, the model cannot know; what it shows badly, the model cannot trust. ## 4. The Architecture The pipeline is a sequence of stages; every node is labeled D (deterministic software) or L (a learned model). The invariant that governs the whole is: *the L column contains exactly one entry — a single weak-LLM relevance-ranking call — and every upstream and downstream step is deterministic software on CPU.* The deterministic path is the default; the single learned call fires only when the deterministic machinery cannot resolve relevance on its own. The concrete inputs are the user request and the candidate evidence the earlier components already produced: the recon graph of component 03, the retrieved candidate pool of component 04, the localization of component 05, the impact DAG of component 06, and the current plan node and its obligations from component 07. The flow, from evidence to the assembled decision window: 1. **Evidence-pool assembly [D].** Candidate material is gathered from every authoritative source into one working pool: source and symbols (03), retrieved hits (04), the fault/changed entity (05), graph edges, configs, and downstream obligations (06), the current plan node, acceptance criteria, and obligations (07), plus the current patch, live errors, tracebacks, and the most recent tool and test output. Nothing here is admitted to the window; this stage only makes everything available in a uniform, addressable form. Assembly is deterministic collection and normalization, not selection. 2. **Hard relevance gate [D].** From the assembled pool, causally relevant evidence is admitted deterministically. Two independent drivers feed the gate: *obligation-driven* relevance, from the current plan node's obligations and acceptance criteria of component 07, and *impact-DAG-driven* relevance, from the edges of component 06 — an evidence item is admitted if it is required to discharge the current obligation or is a direct consequence the current change must satisfy. Items that are neither, however plausible in the abstract, are rejected here without invoking a model. This is P4 executed structurally: the gate encodes "context must justify its presence for the current decision," and it does so in deterministic code, so that no plausible-sounding but irrelevant file, rule, or overview can ride into the window on the intuition that it might help [6]. 3. **Relevance ranking [L].** *The single learned node.* When the deterministic gate cannot resolve relevance — a candidate is semantically related to the current decision but structurally unlinked, so no obligation or impact edge reaches it, and the constructor cannot tell deterministically whether it is signal or distractor — the LLM ranks the unresolved candidates for this decision. The call emits, for each candidate, an identifier and a relevance score, in a schema-constrained output, at temperature zero, in one call, scoped strictly to the unresolved residue of the pool. The deterministic path is the default; this step fires only when the hard gate leaves genuinely ambiguous material. It is the sole entry in the L column, and re-invocation is always scoped to the current decision's residue, never a planner that runs continuously over the whole run. 4. **Representation choice [D].** Each admitted evidence item is assigned a rendering by deterministic policy, per P2 and P3: the change target and the code at the insertion point are rendered verbatim; a requirement and its acceptance criteria verbatim; related symbols as signatures; the impact neighborhood as signatures plus only the call sites of direct obligations; the wider impact DAG as a structured digest ("11 callers, 14 config/schema consumers, 22 indirect dependents, 15 tests — no direct evidence requires source expansion yet"); a related test as its body if it must be reasoned over, else its name. The policy is deterministic: a table from evidence type and role to representation, with expansion a gated exception rather than a default. 5. **Compression [D].** Structural compression runs first — signatures over bodies, AST slices, and line-level extraction (RepoCoder's sliding-window contiguous-line extraction [3]) — so that only the needed span of a large entity is represented. Where further reduction is required under budget, sliding-window selection drops the lowest-signal spans. The perplexity-model compression of the LLMLingua lineage [7][8] is *deferred*: the Simple Observation Masking finding, that a deterministic masking strategy matches an LLM summarizer while halving cost [9], suggests deterministic masking and structural compression may suffice in the weak-model regime, and a learned compressor would add a model call to the pipeline against the L-column invariant. Compression that would require a model is a candidate for a later round, gated by the ablation of Section 6, not a default. 6. **Deduplication [D].** Duplicate hits — the same definition retrieved through two paths, the same failure reported twice, the same symbol surfacing in both the target and related fields — are collapsed to a single reference, and mid-relevance filler is dropped. The same evidence appearing under multiple obligations is rendered once and pointed to. This is P4 at the token level: a window cluttered with near-identical renderings of one fact is paying distractor cost for no information. 7. **Ordering [D].** The surviving items are placed deterministically under P5: the insertion-point neighborhood, the freshly failing test output, and the critical definitions the current edit depends on go to the edges of the window, where attention is highest; supporting material fills the middle; nothing the decision depends on is allowed to sit mid-context where lost-in-the-middle would bury it [5]. The code immediately before the edit point — the strongest conditioning signal for an edit decision — is kept adjacent to the edit target. 8. **Token budgeting [D].** The assembled window is measured against a hard ceiling and allocated across three tiers: the *stable core* (the task, its acceptance criteria, and the current plan obligation — never evicted mid-decision), the *working set* (the current file and the needed definitions), and the *transient state* (the last tool output, the current errors). When the ceiling is exceeded, transient state is evicted first, then the working set is compressed by representation, and only as a last resort is the stable core trimmed. Nothing is ever allowed to overflow the budget by accumulation; the constructor accounts rather than overflows. This is the economy of Section 1 made explicit: instructions, code, and tool output compete for the same tokens, and the constructor, not the model, decides who wins [11]. The target is explicit and checkable: the L column holds exactly one entry — the relevance-ranking call that fires only on the deterministic gate's unresolved residue — and every stage before and after it is deterministic software on CPU. Any proposed addition that would put a language model elsewhere in the pipeline is a regression against P1–P7 and must clear the same bar as in earlier components: beat the deterministic stage on the honest metrics of Section 6, on held-out repositories, at a defensible cost, or be rejected. ## 5. Recursive Self-Improvement Protocol Component 08 of 27 follows the program's uniform protocol: the executable specification is written to 100%, round 1 lands at approximately 80% of the specified behavior, and later rounds close the gap. Each round is A/B-gated against the honest metrics of Section 6 — never the end-to-end resolve rate, which would let execution quality mask context-construction quality. The deterministic stages (1, 2, 4–8) improve by direct engineering, measured by ablation against the "stuff everything" baseline and against the fused candidate pool with no constructor at all. The single learned stage (3) improves only if a candidate model beats the deterministic relevance gate on held-out repositories — that is, only if the semantic ranking resolves genuine ambiguity better than the obligation- and impact-driven gate does alone. And because P4 holds that more context can actively hurt, a *removal* is as much an improvement as an addition: any context source or representation choice whose removal does not degrade the honest metrics is deleted, and the AGENTS.md lesson [6] is thereby made mechanical — a source that passes this test has demonstrated it earns its tokens, not that it merely sounds sensible. The window is diffable as it changes, so a constructor regression is visible in the assembled observation long before it surfaces as a failed resolve. ## 6. Measurement & Evaluation Context construction is measured *separately* and *honestly*, in five instruments, because a stage that cannot be scored apart from its consumer cannot be diagnosed apart from it. **Relevance precision.** The fraction of the context actually sent that was *causally needed* for the decision — required to discharge the current obligation, satisfy an impact edge, or answer the decision's question. This is the direct score of the hard relevance gate and of P4: a window full of plausible-but-unneeded material scores low even if the resolve eventually succeeds, because it succeeded *despite* the distractor burden, not because of it. It is measured against the human- or test-verified set of facts each decision truly depended on. **Token-budget adherence and tokens-per-solved-instance.** The key instrument — the *window economy*. Every constructed window must respect the hard ceiling of stage 8, and the run must be scored on solve rate per token of context actually sent: instances solved divided by total context tokens consumed across the run. The constructed window must strictly *beat* a "stuff everything" baseline on tokens-per-solved with no solve-rate regression. This is the instrument that makes P1–P3 falsifiable: if sending the full candidate pool costs the same per solved instance as sending the frugal window, the constructor is not earning its place, regardless of how elegant its principles read on paper. **Solve rate / cost / tokens.** The end-to-end regression guard: does the constructed-window run resolve the request, at what dollar-and-token cost? This is the coarse instrument kept for parity with the program's other components, and it is deliberately *not* the gate for constructor changes, because resolve rate cannot separate context quality from execution quality. It catches gross regressions; the instruments above diagnose them. **Ablation.** The instrument that enforces P4 mechanically: remove each context source (the impact DAG digest, the retrieved-code field, the history field, the constraints field, the plan obligation) and each representation choice (verbatim versus signature versus digest) in turn, and measure the honest metrics with it absent. A source or choice is *deleted* if its removal does not degrade the honest metrics — the AGENTS.md lesson [6] turned into a standing rule: never add context because it sounds sensible. A source whose *addition* degrades the metrics is a demonstrated harm and is removed outright. **Lost-in-the-middle probe.** The instrument that checks P5: verify that critical content (the insertion-point neighborhood, failing-test output, critical definitions) is actually placed at the edges, and that deliberately *burying* that content mid-context degrades the result — confirming the ordering rule is load-bearing rather than decorative, and that the constructor has not accidentally left a decision-critical fact where attention will not reach it [5]. Two honest caveats close the section. First, the strong-model-transfer caveat: the headline numbers of Section 2 — SWE-agent's 12.5% full and 18% Lite pass@1 on a GPT-4-class base [1], Prompt Generation's 36% *oracle* improvement over Codex (whose learned variant reached 17%) [2], Context Compression's 28.3% BLEU over full context [4], the masking-vs-summarization solve-rate parity [9] — were all obtained with strong models or as upper bounds, and a weak model should not be expected to reproduce them; this architecture's deterministic stages carry the load precisely because the learned stages will underperform, and the window-economy and relevance-precision instruments are the ones that will show whether the deterministic constructor is doing so. Second, the held-out and memorization caution inherited from the earlier components: a model that has memorized a repository's shape will score well in-benchmark without the context window having done any constructive work, so all context-construction metrics must be reported on held-out and out-of-benchmark repositories, exactly as the planning and localization metrics were. ## 7. Conclusion Context construction is the cross-cutting assembly engine that decides, for every model invocation, what of everything the pipeline knows is actually sent to the model, at what fidelity, in what order, and under what budget. This paper has argued that the observation must be decision-specific, typed, aggressively selective, and ephemeral: rebuilt from authoritative repository, execution, requirement, planning, and historical evidence for every invocation; typed into a structured object whose fields each carry their own rendering policy; assembled under a hard token budget through deterministic relevance gating, cheapest-sufficient representation, structural compression, deduplication, and edge-anchored ordering; and discarded once it ceases to be causally relevant. It has argued, on the strongest warnings in its review, that no context — repository instructions, history, or retrieved code — earns permanent admission merely because it may be generally useful: the AGENTS.md result showed that plausible persistent context files did not improve success while raising cost over twenty percent [6], and the observation-masking result showed that deterministic eviction matches a model-in-the-loop summarizer at half the cost [9]. The single learned decision is the relevance-ranking call that fires only when the deterministic obligation- and impact-driven gate cannot resolve ambiguity; everything around it — the evidence-pool assembly, the hard gate, representation choice, structural compression, deduplication, ordering, and token budgeting — is deterministic software on CPU, so the L column holds exactly one entry and the window is assembled, budgeted, and audited deterministically. For a weak model, the consequence is the design's slogan made concrete: the window the model sees is built by the harness, not begged for by the model, and the honest metrics of Section 6 — above all the window economy of tokens-per-solved — decide whether the constructor is earning its place or quietly burying the needle it was built to keep visible. --- ## References 1. John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. *SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.* 2024. arXiv:2405.15793. *(Venue caveat: "NeurIPS 2024" is not stated in the arXiv record — the comment field carries only a code/data URL. Numbers verified against full text: 12.5% = 12.47% of 2294 full SWE-bench; 18% = 18.00% (54/300) Lite; ablations GPT-4 on SWE-bench Lite.)* 2. Disha Shrivastava, Hugo Larochelle, and Daniel Tarlow. *Repository-Level Prompt Generation for Large Language Models of Code.* ICML 2023. arXiv:2206.12839. *(The source ID 2305.15183 resolved to the wrong paper and was corrected by title search. The 36% is the ORACLE upper bound over 63 prompt proposals; the trained prompt predictor reaches up to 17%. 63 = 10 sources × 7 context types, minus invalid combinations.)* 3. Fengji Zhang, Bei Chen, Yue Zhang, Jacky Keung, Jin Liu, Daoguang Zan, Yi Mao, Jian-Guang Lou, and Weizhu Chen. *RepoCoder: Repository-Level Code Completion Through Iterative Retrieval and Generation.* EMNLP 2023. arXiv:2303.12570. *(The phrase "coarse-to-fine line extraction" appears nowhere in this paper — the mechanism is sliding-window extraction of contiguous lines. Venue confirmed by the arXiv comment.)* 4. Jia Feng, Zhanyue Qin, Cuiyun Gao, Ruiqi Wang, Chaozheng Wang, Yingwei Ma, and Xiaoyuan Xie. *On the Effectiveness of Context Compression for Repository-Level Tasks: An Empirical Investigation.* 2026. arXiv:2604.13725. *(Preprint, arXiv comment "Work in progress"; no venue stated. All numbers confirmed in the abstract: 8 methods / 3 paradigms, 4× compression, up to 28.3% BLEU over full context, up to ~50% latency reduction.)* 5. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. *Lost in the Middle: How Language Models Use Long Contexts.* TACL. arXiv:2307.03172. *(Venue-year caveat: the arXiv comment dates it "TACL, 2023," not 2024 as some sources state.)* 6. Thibaud Gloaguen, Niels Mündler, Mark Müller, Veselin Raychev, and Martin Vechev. *Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?* 2026. arXiv:2602.11988. *(No venue stated in the arXiv record. Cost increase >20% (full text: 20% and 23%); increased exploration with steps averaging +2.45 and +3.92; five of eight settings dropped for LLM-generated files.)* 7. Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, and Lili Qiu. *LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models.* EMNLP 2023. arXiv:2310.05736. 8. Huiqiang Jiang, Qianhui Wu, Xufang Luo, Dongsheng Li, Chin-Yew Lin, Yuqing Yang, and Lili Qiu. *LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression.* ACL 2024. arXiv:2310.06839. *(Question-aware compression and document reordering are full-text, not abstract, claims.)* 9. Tobias Lindenbauer, Igor Slinko, Ludwig Felder, Egor Bogomolov, and Yaroslav Zharov. *The Complexity Trap: Simple Observation Masking Is as Efficient as LLM Summarization for Agent Context Management.* 2025. arXiv:2508.21433. *(Full title drops no part of the arXiv title's leading clause here; v3 comment notes DL4C workshop at NeurIPS '25. Abstract: masking halves cost while matching/exceeding LLM-summarization solve rate; hybrid further cuts cost 7% and 11%.)* 10. Yujiang Li, Zhenyu Hou, Yi Jing, Jie Tang, and Yuxiao Dong. *CompactionRL: Reinforcement Learning with Context Compaction for Long-Horizon Agents.* 2026. arXiv:2607.05378. *(Preprint; no venue. The §5.2 caveat — gains do not consistently transfer to single-context settings — is full-text, not abstract.)* 11. Nghi D. Q. Bui. *Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned.* 2026. arXiv:2603.05344. *(Work-in-progress preprint; no venue. Tool observations 70–80% of token budget, graduated compaction at 70/80/85/90/99%, ~15-token pointers — all full-text.)* 12. Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, and Jingren Zhou. *Context as an Environment: Programmatic Context Management for Long-Horizon Agents (Scroll).* 2026. arXiv:2608.21690. *(One-week-old preprint; no venue. Lossless Event Log + summaries/indexes as working views confirmed in abstract.)* 13. Paul Gauthier. *Aider repository map.* 2023. https://aider.chat/docs/repomap.html. 14. Yuntong Zhang, et al. *AutoCodeRover: Autonomous Program Improvement.* 2024. arXiv:2404.05427. 15. Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. *MemGPT: Towards LLMs as Operating Systems.* 2023. arXiv:2310.08560. 16. Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. *Agentless: Demystifying LLM-based Software Engineering Agents.* 2024. arXiv:2407.01489. 17. Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, and Heng Ji. *Executable Code Actions Elicit Better LLM Agents (CodeAct/OpenHands).* 2024. arXiv:2402.01030. *(Authors/full title for this entry not independently re-verified beyond the primary record.)*