Context engineering means choosing and maintaining the information an AI system receives while doing a task. A useful brief includes the goal, relevant evidence, constraints, examples and a way to check the result. More text is not automatically better context.
Explain the job and the audience
Start with who will use the output and what they need to accomplish. Include the current problem and the decision or action the output should support. Specify the required format only after the purpose is clear.
For example: “Prepare a comparison for an IT manager choosing where to host an internal document assistant. Use the attached requirements. Separate confirmed constraints from open questions. Do not assume a public model API is permitted.” This gives the assistant a task boundary and a reason for the comparison.
Supply evidence with labels
Identify the source, date and status of each document. Separate approved policy from working notes. If two sources disagree, say who resolves the conflict. Ask the assistant to cite the evidence behind important claims and flag missing information.
For a website brief, label a customer result as approved only when it is publishable. For an application brief, distinguish current behaviour from proposed behaviour. These simple distinctions prevent many plausible but incorrect assumptions.
A reusable brief
- Goal: the change or decision we need.
- Audience: who uses the result and what they already know.
- Inputs: approved sources, examples and relevant existing work.
- Constraints: data boundaries, tools, budget, deadlines and prohibited actions.
- Output: the required structure and level of detail.
- Acceptance: concrete examples of a correct result and checks to run.
- Unknowns: what must be clarified or explicitly left unresolved.
Use the brief builder in this knowledge base to draft these fields. It creates a text file locally in your browser; it does not need to send your project information to a model.
Improve through specific feedback
If the output is wrong, identify the failure precisely. “This paragraph uses the old policy; use the version dated X and show its source” is more actionable than “make it better.” Keep a record of the correction in the approved brief when it affects future work.
Ask for small, reviewable increments on complex tasks. Check the first example before requesting dozens of variations. This catches misunderstandings while they are still inexpensive to fix.
Keep context current
Remove superseded instructions, preserve decisions and keep unresolved questions visible. Long conversations can contain contradictions. A concise current brief is often more useful than repeatedly attaching everything the organisation has ever produced.
Sources & further reading
Primary references for the technical background and regional statements in this guide. Planning examples and checklists are Novacom’s practical guidance; examples are illustrative unless explicitly identified as project experience.