More context can make an agent worse. Important facts vanish into the middle, old tool results crowd out the current job, and a catalog of 100 tools gives the model another search problem before it can begin the user's task. Truncation, retrieval, progressive disclosure, memory and active context editing each decide what survives inside the conversation. Tool routing makes that choice earlier by searching a catalog and loading only the relevant schemas. From there, context engineering reaches beyond the prompt. Browser agents need a compact view of the page, performance agents need summaries shaped for diagnosis, and Cloudflare exposes 2,600 endpoints through two tools so one generated program can complete many steps. Each design gives the model a smaller, more useful working set.
Why start here: Sharma names the failure that motivates Delucia's design: a model can accept a long prompt while losing what sits in the middle. Her split between open discovery and bounded validation gives Delucia a useful principle to make concrete: different work deserves different context.
Why here: Sharma explains why more input does not guarantee more attention. Delucia shows the failure in a running product: blunt truncation breaks follow-up questions, so Alyx keeps the head and tail and makes the middle retrievable. Bouchard follows by testing whether any compaction is needed in the first place.
Why here: Delucia has a working compression rule. Bouchard tests that instinct against prompt caching and finds that untouched history can be cheaper, faster and better at recall. His safer common ground is progressive disclosure, which Lesse turns into concrete platform controls.
Why here: Bouchard warns against compacting by default. Lesse separates two actions that can be evaluated on their own: memory stores useful information outside the window, while context editing removes stale tool results. Shaikh and Rastogi apply the same discipline before tools enter the window at all.
Why here: Lesse edits context after a session has accumulated it. Shaikh and Rastogi prevent the buildup by routing a request before the model sees any schemas, then injecting only a few relevant tools. Monigatti widens that routing problem from tool catalogs to every source an agent may search.
Why here: Shaikh and Rastogi retrieve tools. Monigatti argues that the same search decision governs all context, whether it comes from files, databases or memory. Her mix of simple specialist tools and flexible general tools leads into Dougherty's practical advice: let the agent retrieve structure instead of stuffing it into a prompt.
Why here: Monigatti chooses search interfaces according to the query. Dougherty brings that choice inside the agent loop: retrieve tables and columns as needed, then tune the tool's input and output format for the model using it. Raj takes the same interface argument into the browser.
Why here: Dougherty shows that a small change from Markdown to JSON can fix a database agent. Raj makes page representation the central design choice: give the browser agent a compact view of the whole page and report what changed after each action. Hablich follows with the same lesson from a production developer tool.
Why here: Raj compresses browser state so the model can see the page. Hablich compresses Chrome performance traces so the model can still reason after reading them, then measures the interface by tokens per successful outcome. Pai shrinks the model-facing interface again, replacing thousands of tool schemas with two executable tools.
Why end here: Hablich shows how much careful work it takes to make 25 tools usable. Pai asks whether the model needs that menu at all. Cloudflare exposes 2,600 endpoints through search and execute, so one generated program can perform many steps without repeated model round trips. It is the pack's clearest example of context engineering changing the interface, not merely trimming the prompt.