The Harness as Context Manager

Source Note This page synthesizes a Twitter thread by Arvind Jain (Glean CEO) and a linked blog post by Tony Gentilcore, both published April 29, 2026. The post describes Glean's third-generation agent harness and the engineering patterns that emerged from scaling agents to enterprise work. Key Findings The Harness, Not the Model, Drives Performance > "LangChain improved Terminal-Bench by +13.7 points through harness changes alone that held the model constant. Vercel cut 80% of its agent's tools and saw higher reliability at 3.5x lower latency. In these cases, the performance delta came from the harness, not the model." This is the extended frontier thesis stated in engineering terms: the performance boundary is not intrinsic to the model but is shaped by what surrounds it. The harness is the extension infrastructure. Progressive Skill Discovery > "We reduced our own system prompt by 45%+ by moving instructions into skills that load progressively instead." Glean implements a three-phase discovery pattern: (1) search an index of skills, (2) see a short list of candidates with lightweight descriptions, (3) hydrate the full schema only at execution time. The agent never pays the context cost of capabilities it doesn't use. This is the same pattern as deferred tool loading in Claude Code, where 100+ tools are listed by name but their schemas are fetched only when needed. The extension (the skill) exists as a capability-in-waiting until the task calls for it. Context Compaction as Extension Management > "Compaction preserves the parts of conversation state that are load-bearing for continued execution: user intent, decisions made so far, approaches that failed, planned next steps, and recent high-signal tool outputs." Compaction is a form of extension management — deciding which prior extensions (tool outputs, search results, sub-agent findings) remain active in the working context and which get archived to a filesystem. The frontier doesn't just depend on what extensions are available; it depends on which ones are currently loaded. Sub-Agents as Context Isolation Sub-agents give each decomposed task its own context window. This is spatial context management — distributing extensions across parallel workers so no single agent is overwhelmed. The orchestrator sees summaries, not raw intermediate state. Programmatic Tool Calling > "20 tool calls can happen inside one sandbox run, and the orchestrator sees only the summary and structured metadata that come back." Code becomes the execution primitive — loops, filters, branches expressed in Python rather than conversational turns. This compresses the extension surface: instead of 20 sequential tool-call extensions consuming context, one code-execution extension produces a summary. Relevance to the Extended Frontier The Glean post provides strong practitioner evidence for several extended frontier claims: 1. The frontier is shaped by extensions, not just model capability. Glean's own data shows harness changes (extension infrastructure) producing larger gains than model swaps. 2. Extensions are not static. Progressive discovery, compaction, and sub-agent isolation all describe a frontier that changes during a task as extensions load, unload, and compress. 3. The harness is constitutive, not supplementary. Jain frames the harness as "a distributed context management system" — not scaffolding around the model, but part of what the model is during execution. This aligns with the extended frontier argument that extensions are not add-ons but constitutive of practice. 4. Practitioner knowledge matters. The post is engineering knowledge about building extensions, not about improving models. The frontier literature underweights this kind of knowledge — knowing how to build the harness is itself an extension of the frontier.