You would not ask a colleague to solve a customer problem by handing them the entire company drive and saying, “Good luck.” You would explain the question, introduce the people involved, bring the current records, and point out the policy that matters. Context engineering is that same act of preparation for an agent.

Build a short, useful brief

Begin with the task and its current state: what was asked, what has already happened, and what still needs doing. Add the identity and permissions that apply. Bring the smallest useful set of evidence, including the source and date, then include tool results, failures, and pending actions. Finally, say what a good answer must look like and when the agent should ask for help.

A support agent rarely needs the whole company knowledge base. It may need the customer’s current case, the relevant policy, a recent order, and a clear way to say that the evidence is incomplete. Smaller, better context is often more useful than a larger prompt.

Rank evidence like a person would

Relevance is only one consideration. A current policy from the authoritative system should beat an old forum post that happens to contain the same phrase. Apply permission checks before retrieval results are shown, and keep record IDs or citations so the answer can be checked later.

Documents can be persuasive and still be untrusted

An email, webpage, ticket, or uploaded file may contain a sentence telling the agent to ignore its instructions or reveal a secret. Treat that sentence as content to discuss, not as a new rule. Keep policy and permissions outside retrieved material, where a document cannot rewrite them.

Leave a trail for the next person

Record which sources were selected, which versions were used, and why they made the cut. Test stale policies, conflicting records, irrelevant high-similarity results, and important evidence pushed out by truncation. When an answer is wrong, an understandable context trail gives the team somewhere concrete to start.