In this insight
Context engineering means deciding what information an AI system receives for a particular task. More information is not automatically better. The aim is enough relevant, current evidence to do the work, without burying the important facts in repetition or unrelated history.
Think of briefing a new colleague. Handing them every message the company has ever sent is not a helpful introduction to one decision. They need the goal, the current rules, the relevant records, the open questions and a way to check where those facts came from.
Separate instructions from evidence
A request such as add a cancellation step is an instruction. A current workflow diagram is evidence about how the process works. An old discussion suggesting a different policy is historical context. These items should not all carry the same authority.
Before collecting material, identify the task and the decision boundary. Is the assistant explaining existing behaviour, proposing a change or implementing an approved decision? Each task needs a different selection of context.
Keep source material labelled. A quoted document can contain instructions intended for its original reader; that does not make it an instruction to the assistant. Treating all retrieved text as authority can turn an information source into an unintended control channel.
Select a useful slice of the project
In a fictional appointment application, a cancellation change may require the current booking rules, relevant screen, service handling cancellations, notification behaviour and tests. It probably does not require every invoice template or a year's worth of unrelated meeting notes.
Selection should follow dependencies, not only matching words. A function with cancellation in its name may call a shared permission check or schedule an email elsewhere. Leaving out those connections can make a short context incomplete even when every included file looks relevant.
Start with an index or summary that points to the necessary evidence, then retrieve the actual details needed for the decision. A summary helps navigation; it should not substitute for checking the current source when correctness depends on a specific rule.
Make conflicts and missing facts visible
Suppose an old note says appointments can be cancelled at any time, while the current approved rule requires review after work begins. Do not ask the model to quietly reconcile the conflict. Identify which source is authoritative and what still needs a person's decision.
Freshness is not the only signal. A recent informal message may not override an older approved policy. Record the role of the source, its version and the reason it applies. This gives the reviewer a way to challenge the answer.
If the necessary rule is missing, say so. A question such as who may cancel after work starts is better than an invented assumption buried in code. Useful context includes known uncertainty, not just statements that make the task appear ready.
Preserve lineage without repeating everything
Lineage is the connection between a decision and the information behind it. In plain language: why did we choose this, and where can someone check? Keep references to approved rules, relevant discussions and tests alongside the task.
That does not mean copying the full history into every prompt. Store the history where it belongs and bring forward the parts that matter. A short decision note can explain the choice and point back to detailed evidence when needed.
When a new person or tool takes over, they should be able to recover the current state without reconstructing every conversation. This is one way a shared operating model helps: it preserves important decisions outside any one person's memory or any one model's input window.
Test the selection, not just the answer
Try the same task with an intentionally outdated note included. Does the process identify the conflict? Remove a critical permission rule. Does it ask for the missing evidence? Add a large irrelevant document. Does the useful context remain available?
Check the result against the original task and its sources. A concise answer may still be wrong; a long answer may only conceal uncertainty. Compare correctness, omissions, review effort and resource use rather than assuming shorter input always wins.
Context selection is a boundary for access as well. Retrieve only what the task and current user are allowed to use. Helpful information from another project is not automatically permitted information. Relevance never overrides authorization.
Model conversion exercise
Use this exercise with a real workflow and the people accountable for its outcome. Record disagreements as modeling questions instead of silently choosing an answer.
Choose a small fictional change and assemble a brief containing its goal, current rules, relevant components, evidence links and open questions. Ask another person which item they would remove and which dependency is missing. Then add one conflicting historical note and decide how it should be labelled. Your output is a reviewable context pack, not a longer prompt for its own sake.