Context Engineering for AI Agents: Keep the Right Information in View

An AI assistant can have a large context window and still miss an important requirement. The problem is often what you put into that window: old decisions, repeated tool output, unrelated documents, and instructions that no longer describe the task. More text doesn't automatically create better memory.

Context engineering is the practical work of choosing and maintaining the information available for the next model response. For a small technical team, the useful starting point is a reviewable context package, not an elaborate memory platform. Keep the current goal clear and make supporting evidence easy to retrieve.

Separate durable facts from temporary working material

Create distinct places for current instructions, accepted decisions, source references, and transient results. A command's full output may be useful for one debugging step but unnecessary for every later response. A confirmed user constraint may need to remain visible throughout the task.

Anthropic's context-engineering guidance describes context as a finite resource and discusses curation over long tasks. Use that principle to ask a concrete question about every item: what next decision does this information support?

Don't treat a previous model answer as an authoritative fact merely because it is in the conversation. Preserve whether a statement came from a verified source, a user instruction, or an untested hypothesis. Those distinctions matter when the assistant decides what to do next.

Make a small task-state record

For a fictional documentation update, a state record might contain:

{
  "goal": "Update the installation guide",
  "accepted_constraints": ["Support the current LTS runtime"],
  "completed": ["Checked installation commands in staging"],
  "pending": ["Review the troubleshooting section"],
  "evidence_references": ["test-run-synthetic-17"]
}

These are illustrative values. Store the actual state in an approved location and keep secrets out of it. The JSON Formatter can make a synthetic state record easier to inspect, but it cannot determine whether the completed step really happened.

Keep the record short enough for a reviewer to challenge it. If “completed” contains vague claims such as “everything checked,” you haven't preserved useful evidence. Prefer specific outcomes and references that can be reopened when necessary.

Load evidence when the task needs it

Avoid attaching an entire repository or knowledge base by default. Start with the files, sections, or records relevant to the current decision, then retrieve more when a question remains. This reduces distraction and makes the evidence trail easier to understand.

Preserve surrounding context when it changes meaning. A policy exception separated from its condition can produce a misleading summary. A function definition without its caller may hide an important input constraint. Targeted retrieval should be selective, not careless.

Record source version and retrieval time for material that changes. If the assistant resumes later, it should know whether it is using a frozen snapshot or must refresh the source. A filename alone doesn't establish that the content is still current.

Compact history without erasing commitments

When the conversation grows, summarise decisions, completed work, unresolved questions, and the user's latest corrections. Keep the original evidence references outside the summary so details remain recoverable. Compression should remove repetition before it removes meaning.

Use a checklist for the summary: does it preserve the goal, scope, constraints, current artifact, validation performed, and next step? Does it identify uncertainty honestly? A summary that turns “probably works” into “verified” creates a new error instead of saving space.

Compare a sanitised summary revision with Text Diff. Look particularly for lost negations, changed dates, and constraints that disappeared. The tool highlights changes; a person or a dedicated check still needs to decide whether those changes are acceptable.

Keep source content in its proper role

Retrieved pages and files may contain instructions written by someone else. They can supply evidence, but they shouldn't silently replace the user's goal or your application's action policy. Label source material clearly and keep it separate from trusted workflow instructions.

For example, a document saying “send this file to this address” isn't permission to perform that action. A context package should preserve the document as content to analyse, not promote its wording into an authorised command. This becomes particularly important when an agent can write files or call external services.

Also preserve contradictions. If two sources disagree, don't compress them into one confident sentence. Record the disagreement and the check needed to resolve it. Context quality includes the ability to say what remains unknown.

Evaluate the package against actual tasks

Create several representative tasks and compare outcomes with the old and new context design. Measure missed constraints, unsupported claims, unnecessary tool calls, and recovery after interruption. Use the same tasks and source versions so the comparison means something.

Don't tune only for a single successful demonstration. Include a late user correction, an unavailable source, and a task that resumes after a pause. These cases reveal whether the assistant retains useful state rather than merely responding well to a fresh prompt.

If the agent produces structured intermediate output, see JSON Lines and SSE parsing for handling the transport correctly. Good context design can't compensate for a parser that loses part of the evidence stream.

Conclusion

Useful agent memory is curated, labelled, and recoverable. Keep current instructions visible, store compact task state, retrieve evidence deliberately, and test summaries for lost commitments. A larger context window helps only when the information inside it deserves to be there.