Context engineering: what deserves to enter, leave and survive the session

Giving “all the context” to an agent seems safe. In practice, excess can hide instructions, mix old state, increase cost and make irrelevant information compete with what decides the task.

Context engineering is the discipline of assembling the smallest set of signals capable of guiding an execution and preserving what needs to survive outside the window.

Executive summary

Context is not total memory. It is a temporary selection.

Chat helps you work. The registration system helps you continue.

Prompt is just part of the context

An agent's behavior may depend on:

• system instructions;
• objective and criteria of the task;
• selected files and documents;
• message history;
• tools and descriptions;
• intermediate results;
• state of the environment;
• recovered memory;
• policies and capabilities;
• feedback from verifiers.

Changing any of these parts can change the output, even with the same model and the same seed phrase.

The attention budget

Larger windows do not transform every token into a signal. Three problems remain:

Pollution

Obsolete instruction or irrelevant example gains weight by being present.

Competition

Critical facts are distant or diluted in similar material.

Ambiguity of authority

The agent does not distinguish canonical rule, hypothesis, comment and history.

The goal is not to minimize tokens for aesthetics. It's about maximizing useful signal and leaving explicit authority.

A layered context package

Assemble the task in the following order:

1. intention: problem, recipient and result;
2. authority: who decides and what actions are permitted;
3. contracts: requirements, interfaces, risks and non-objectives;
4. current status: branch, version, issues and evidence;
5. sources: necessary files or references;
6. criterion: how to check and when to stop;
7. exit: delivery and handoff format.

This structure reduces the chance of historical context passing through current instruction.

Recover at the right time

Not every source needs to come in before the first action. On long tasks, keep tags light and retrieve content when the step requires it.

Example:

índice de ADRs -> selecionar ADR relevante -> ler integralmente -> executar -> registrar decisão

That's better than dumping a hundred ADRs out the window. Recovery, however, needs:

• reliable source;
• reproducible search;
• version or date;
• record of what was used;
• fallback when the source is not available.

Public agent systems differentiate between history, session, workspace and tools; these implementations reinforce that context and environment are layers, not a single prompt. [HARNESS31-C2]

What should survive the session

If information is needed to resume, audit or correct, it should not depend solely on chat.

Externalize:

• decision and motivation;
• work status;
• created artifacts;
• relevant commands or tests;
• faults still open;
• evidence collected;
• next steps and conditions;
• limits of conclusion.

Use versioned files, issue, ADR, manifest, checkpoint or other appropriate record. The format depends on the product; The principle is that durable consequence deserves durable address.

Compress without rewriting history

A good handoff summary separates:

Avoid “all right” or “almost done”. These labels erase the scan path.

Context also expires

Price, model availability, benchmark, law and operational status get old. Register:

• observed in;
• valid for;
• review after;
• source;
• decision that depends on the fact.

When the validity expires, the system must search again or block the claim. Do not allow an old text to continue to dictate a current decision due to inertia.

Subagents as context isolation

Subagents may maintain separate research or specialties. This reduces detail competition at the main agent, but creates a new contract:

• delimited task;
• permitted sources;
• structured output;
• preserved uncertainties;
• no out-of-scope effects;
• final synthesis with attribution.

Parallelism doesn't fix bad questions. It just produces competing responses faster.

A context quality test

Before running, ask:

1. Does the objective fit into one sentence?
2. Are rules and examples distinguished?
3. Is there a source of truth for each material fact?
4. Did any sensitive information enter unnecessarily?
5. Does the agent know what not to do?
6. Is the ready criterion verifiable?
7. Can the state be resumed without this conversation?

Then, ablate: remove a block and see if quality, cost, or risk change. Public research from harness shows that additional layers can increase capacity and also cost or latency depending on the task; the result is not universal. [HARNESS31-C3]

What this article proves — and what it doesn't prove

Vendor sources describe context selection, retrieval, compression, and isolation techniques. They are empirical guidance, not an independent standard or guarantee of performance for every application.

This article proposes a context contract for FORGE. The ideal set needs to be tested by task, model, risk and horizon.

Conclusion

Context engineering is not about stacking knowledge. It's deciding what the agent needs to perceive now, what they can look for later and what the organization needs to preserve outside the session.

The best context is not the biggest. It's what makes intent, authority, state, and verification difficult to confuse.

Previous reading: Long-lasting agents. Next suggested reading: The right queue for AI.