What belongs in the first context window?

Suppose a team gives its coding agent a large collection of project documents, then asks it to change a filter on an order dashboard. Without an explanation of which documents apply, the agent has to work out which statements govern the change and whether they are still current. The team could save that work by supplying the relevant instructions and showing the agent where to find anything else it needs.

In this synthetic example, I would start with a brief that explains the requested change and the rules that apply to it. Include references to additional evidence the agent may need as it works. Another engineer should be able to read the same brief and understand how to begin without having to sort through the whole project history.

Three places information can live

Put the intended outcome and the relevant constraints in the initial brief. For a dashboard filter, that means what the user should be able to do, what data they may see, and what behavior must remain unchanged. Include the location of the access-control tests. You do not need every test result from every prior release.

Keep task-specific evidence retrievable. A source file, a policy section, or a current order snapshot can be loaded when the next decision requires it. Its name, owner, version, and access boundary often matter as much as the content. A file called final-policy is not sufficient evidence of authority or freshness.

Information that is unrelated to the task or outside the permitted access should stay out of it. In the workbench, you can mark a source for the initial context, make it available for later retrieval, or exclude it. These choices document your plan, and your application still has to implement the corresponding access and retrieval rules.

Freshness is a property of the decision

An architectural convention may remain useful for months, while a shipment status needs to be checked when the agent is about to act on it. Set the refresh rule according to what could change the decision. A single retention period is unlikely to suit both kinds of information.

The tool records freshness in days as a planning aid. If the task depends on a live operational record, specify that the application must read it again at the point of use. You can put that requirement in the source description or fallback, so the implementation does not mistake a dated snapshot for current information.

Specify who can settle a disagreement between sources and how the agent should proceed while it remains unresolved. Choosing whichever document is newest can be a mistake: an unreviewed comment may correctly identify a problem without having authority to change the policy. Even an approved source needs to be checked for changes that could make it out of date.

A reference is not an instruction

Retrieved evidence can contain instructions addressed to someone else, examples of malicious text, or an actual attempt to redirect the agent. Keep its origin visible. A customer message that says to ignore the policy is evidence of what the customer wrote, not a change to the policy.

In the workbench, moving an untrusted source into the initial context produces a review flag. That flag is deliberately narrow. Moving the same source to retrieval does not sanitize it or solve prompt injection. It simply makes the design distinction visible so that the retrieval, prompting, authorization, and evaluation layers can be reviewed together.

Make the brief testable

Before expanding the brief, try three cases: the normal task, a missing governing source, and a conflict between an instruction and retrieved text. Record what you expect the system to do. If it cannot explain its uncertainty in the second case, adding more background may only conceal the defect.

Anthropic’s context-engineering article describes selective retrieval, compact context, and persistent notes. Those are the source principles. The three-place map and the design checks here are my practical adaptation, not a claim that this tool has tested or improved a model.

Use the workbench to export a brief, then implement and evaluate it in your own system. For the wider delivery method, see AI SDLC. If you want guided practice building the underlying skills, start with LockedIn Labs Training.