Context engineering
Decide which context construction strategy supports the task and its authority boundaries
When agent answers vary with how evidence is assembled, this area becomes relevant. For the AI application engineer, the concern is specific: useful evidence is omitted while irrelevant or untrusted text dominates the prompt. The engineering design starts from that consequence and follows the relevant evidence through the customer workflow. Treat context as a constructed input with a purpose and an owner. The proposed design should explain why each source is included, what it may influence, and how the agent should behave when required evidence is unavailable.
The engineering decisions relationship
- Context sources
Establish the basis for source selection.
- Instruction boundary
Keep lower-trust content from overriding authority.
- Context assembly specification
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around source selection
Questions and the evidence they need
- Source selection
- Inspect context sources for the relevant constraint or observation.
- Instruction boundary
- Inspect prompt assembly rules for the relevant constraint or observation.
- Assembly version
- Inspect representative task evidence for the relevant constraint or observation.
For the AI application engineer, this becomes relevant when agent answers vary with how evidence is assembled. The immediate decision is which context construction strategy supports the task and its authority boundaries. The scope should be narrow enough that the engineering team can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that useful evidence is omitted while irrelevant or untrusted text dominates the prompt. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Context assembly should preserve source and precedence
Relationships within engineering decisions
- Source selection
- Choose relevant authorised evidence for the task.
- Instruction boundary
- Keep lower-trust content from overriding authority.
- Assembly version
- Record ordering and context-building assumptions.
Source relevance
For this scope, source relevance should be examined alongside context sources. Inventory context sources by purpose, relevance, trust, and freshness. Include only material needed for the task or a defined control. The proposed design should let reviewers explain why a source was supplied and how removing or replacing it changes the expected behaviour.
Instruction precedence
For this scope, instruction precedence should be examined alongside prompt assembly rules. Define which material may instruct the agent and which is information to interpret. Customer text, retrieved documents, and tool outputs can require different treatment. The assembly rules should preserve those distinctions instead of flattening every source into apparently equivalent authority.
Context version and ordering
For this scope, context version and ordering should be examined alongside representative task evidence. Preserve the context construction configuration and source versions needed to explain a result. Changes to ordering, truncation, retrieval, or compression can affect behaviour. The design should support targeted comparisons that distinguish missing evidence from failure to use evidence that was actually supplied.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for source selection
Illustrative working format
- Context sources
- Establish permitted access, provenance, and which task conditions it represents.
- Prompt assembly rules
- Confirm the applicable revision and who resolves disputed interpretation.
- Representative task evidence
- Name the custodian and the conditions requiring a refreshed version.
The starting material is context sources, prompt assembly rules, and representative task evidence. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a workflow owner, an implementation lead, an eventual maintainer, and qualified control reviewers where needed. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry source selection through to an accountable finding
From the scoped material to a decision record
- Context sources
Make the component and operating boundary explicit.
- Instruction boundary
Apply the scoped check to assembly version.
- Context assembly specification
Record the evidence, open dependencies, and the owner’s next decision.
Create a context inventory that records source, purpose, trust, freshness, and allowed influence. Then inspect a representative assembled prompt against that inventory. The proposed design should make it possible to remove an unnecessary source, prioritise a required fact, or change an assembly rule without losing track of which task evidence changed.
A practical first slice would focus on source relevance and then follow its consequences into instruction precedence. Keep context version and ordering visible as a separate review question rather than assuming it is satisfied by the first result. The engineering team should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the context assembly specification usable by its owner
Context assembly specification
Illustrative working format
- Context assembly specification
- Identify the assessed workflow, revision, and decision boundary.
- Source precedence map
- Link supporting and contrary observations to inspectable evidence.
- Context evaluation cases
- Name the unresolved condition, next action, and accountable owner.
Indicative outputs include context assembly specification, source precedence map, and context evaluation cases. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine assembly version through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Source selection
An agent combines a request, account history, internal policy, and tool output.
- Instruction boundary
Track source precedence and context ordering through the assembled request.
- Assembly version
Change assembly rules when lower-trust content displaces required authority.
Consider an illustrative situation in which a service agent combines a customer request, account history, internal guidance, and tool outputs. This is a constructed example, not a client engagement or an observed Softlander outcome.
For the service example, internal guidance and customer-supplied text would enter through different trust paths. An illustrative comparison could remove each source in turn and inspect task behaviour. The aim is to discover useful contribution and missing dependencies, while preserving a clear distinction between information to consider and instructions the system may follow.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves context version and ordering unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the defined workflow and configuration
Confirm fit before the next commitment
- Source selection
- This review is limited to the defined workflow and configuration.
- Context sources
- The relevant owner must confirm access and the intended operating conditions.
- Context assembly specification
- Production acceptance needs separate scoped evidence.
The method described here is proposed engineering work. Scope, staffing, implementation access, acceptance, and commercial terms require a readiness review. A design or lab result does not establish production suitability, guaranteed reliability, or security certification.
Ways to engage
Related engagement scopes
AI Fractional Agentic AI Office
Create a regular place for agentic AI decisions. Connect initiative priorities, architecture questions, risk ownership and evidence reviews.
AI Fractional Agentic Transformation Office
Coordinate the operating changes behind agent adoption. Align workflow redesign, ownership, dependencies and adoption measures.
AI Harness Engineering Pod
Engineer a bounded AI execution harness with tool adapters, context handling, orchestration, recovery and observable traces.
Continue exploring
Related insights and resources
Engineer the harness, not just the prompt
Define the contracts around an agent's decisions: what state it trusts, which actions can execute, how interrupted work resumes, and what evidence an operator needs to recover safely.
Governing agent decisions
Governance becomes useful when it changes a decision. Connect each agent workflow to an accountable owner, explicit operating conditions, proportionate evidence and a practical route for exceptions and withdrawal.
Do you need an agent centre of excellence?
A centre can concentrate scarce expertise and reusable controls, or become an approval queue detached from real work. Choose the mandate before the structure.