Context Engineering

Definition. Context Engineering is the work of selecting, organising and maintaining the information an AI agent uses for a particular decision.

A capable model can still give the wrong answer when it sees an outdated price, misses an exception or applies a rule to the wrong customer. Context Engineering addresses what the agent can see and how that information is maintained. It is more than writing a long prompt.

Three kinds of context

Facts describe the current state of the business: products, prices, availability, customer status or service terms. Each fact should have an authoritative source. Information that changes during the day may need a live lookup; a static document may be enough for something stable. The agent should know when a source was last updated and what to do when the answer is missing.

Rules explain how to handle recurring situations: who is eligible for an offer, when to escalate a request and which actions require approval. The process owner should be able to resolve conflicts between rules and approve changes. For a rule that must never be broken, such as a permission or spending limit, put a check in the system that executes the action. A prompt alone cannot enforce it.

Examples show how people applied those rules in real cases. A useful example includes the situation, the decision, the reason and any known outcome. The Decision Log can supply candidates, but raw logs should not flow straight back into the agent's instructions. Someone needs to check that the decision was sound, the outcome is understood and any personal information is handled appropriately.

The three kinds of context have different sources and different update needs. They should not be bundled into one document that nobody owns.

Start with one decision

Pick a decision the team makes repeatedly. Ask the process owner what information a person checks, which rules govern the choice and which cases are difficult. Gather a small set of approved facts, rules and examples from the systems the team actually uses. Record the source and owner for each item.

Then test the agent against ordinary cases and exceptions. Include a changed fact, conflicting rules and a case where the answer is unknown. Check whether it retrieves the right material, cites or records its basis where appropriate, and escalates when it cannot decide. The Rulebook should state who resolves a conflict and what happens when a required source is unavailable.

The first version need not cover every edge case. It does need a clear update process: who updates a fact, who approves a rule, who reviews new examples and how changes reach the agent. Review these update arrangements whenever the business process or its sources change.

What context does not solve

More material does not always help. Irrelevant documents can bury the rule the agent needs. Contradictory instructions can make its response unpredictable. Stale information can look authoritative. Test retrieval and decisions against actual cases, then remove or repair the material that causes mistakes.

Good context may support a case for more autonomy, but it is only part of that case. The process owner still needs evidence of decision quality, clear operating boundaries and a way to detect and stop failures. Autonomy levels describe that separate permission decision.