Packing for the Job Ahead: Deciding What Actually Belongs in Context

Opening Scene

Two travelers leave the same lodge on the same morning, one heading for a single afternoon ridge walk, the other for a four-day traverse with an exposed glacier crossing. They start from the same shelf of gear, but no competent guide would send them out with identical packs — the ridge walker needs water, a map, and a light shell; the glacier traveler needs crampons, a rope, and food for four days. The job ahead decides the pack, not the shelf of gear that happens to be available.

In Plain English

Deciding what belongs in an agent’s context means starting from the specific task at hand and working backward to the minimum set of instructions, data, and tools that task actually requires — rather than starting from everything available and hoping the model sorts it out. This is a task-driven curation process, and it treats every candidate piece of context as needing to justify its place, using a standard of genuine necessity, not mere relevance.

The Old Way

Before task-driven context curation was a recognized practice:

Teams often included every document, tool, and instruction that seemed topically related to a task, rather than what the specific task actually required.
“Relevant” and “necessary” were frequently treated as the same thing, when a document can be topically relevant to a domain without being necessary for a specific step.
Context was often assembled once for a whole agent, rather than reconsidered for each distinct job that agent might be asked to do.

Building a pack around the specific route ahead, rather than everything in the gear shed, is precisely what disciplined context curation restores.

What’s Changing (and Why AI Is the Reason)

Teams are increasingly building context assembly logic that varies by task type, rather than a single fixed context template applied to every request.
This connects directly to the retrieval practices covered in this content library’s dedicated retrieval-augmented generation series, where fetching only what a specific query needs — rather than everything in a knowledge base — is the same underlying discipline applied to one particular source of context.
As AI agents are asked to handle a wider range of distinct tasks within a single system, dynamically curating context per task, rather than relying on one static setup, has become necessary to keep every one of those tasks reliable.

The Metaphor, Fully Extended

The Route-Specific Pack	Context Curation Concept
Starting from the specific route, not the whole gear shed	Starting from the specific task, not everything available
A ridge walker’s light pack versus a glacier traveler’s full kit	Different tasks warranting genuinely different context assemblies
An item needing to justify its place in the pack	A piece of context needing to justify its place in the window
Relevant gear in the shed that still stays behind	Topically relevant information that still doesn’t belong in this task’s context

For Beginners: What to Actually Do

For any agent task, write down the minimum information needed to complete it correctly before adding anything else.
Practice distinguishing “this is about the same topic” from “this is required for this specific step.”
Build the habit of removing something from context and testing whether the agent still succeeds, rather than only ever adding.

For Practitioners and Leaders: The Deeper Layer

Design context assembly as a function of task type, with different templates or retrieval strategies for meaningfully different jobs an agent performs.
Apply the same “fetch only what’s needed” discipline used in this content library’s dedicated retrieval-augmented generation series to every other context source, not just retrieved documents.
Instrument context curation decisions so you can audit, after the fact, why a given piece of information was or wasn’t included in a specific run.

Quick Recap

Context curation starts from the specific task and works backward, rather than starting from everything available.
Relevance and necessity are different standards — genuinely relevant information can still not belong in a given task’s context.
Different tasks warrant genuinely different context assemblies, not one fixed template.
Deliberately removing context and testing the result is as important a habit as deciding what to add.

Where This Fits in the Series

Article 2 established the context window as a finite space to budget. Article 3 has covered the discipline of deciding what actually belongs in that space for a given job. Article 4 looks at what happens when that discipline slips — when genuinely irrelevant context gets packed in anyway and starts working against the agent.