Context Engineering > Prompt Engineering

Prompt engineering still matters. Clear instructions, constraints, and output contracts improve behaviour. But in serious workflows, the larger source of quality is usually context: the information the model receives, the authority of that information, and the moment it becomes available.

The practical question has shifted from “What is the cleverest way to phrase this?” to “What does the system need to know to do this job, and what must it deliberately ignore?”

Context is more than a long prompt

Context includes every signal available during a run:

• stable operating rules;
• the current request;
• project and customer facts;
• retrieved documents;
• prior decisions;
• examples of acceptable output;
• tool results and external state;
• review comments from earlier runs.

Putting all of this into one system prompt is not context engineering. It is context accumulation. Good context design separates layers by purpose, owner, freshness, and authority.

| Layer | Example | Change rate | Typical owner | | --- | --- | --- | --- | | Operating contract | Role, boundaries, quality standard | Slow | Workflow owner | | Method | Steps, rubric, output schema | Medium | Domain lead | | Project knowledge | Brand rules, product facts, policies | Medium | Project team | | Task input | Current brief, ticket, transcript | Every run | Requester | | Retrieved evidence | Relevant documents or records | Every run | System with source controls | | Run state | Tool results, decisions, validation | During run | Orchestrator |

This model makes change safer. Updating a customer fact should not require rewriting the operator role. Changing the output structure should not silently alter source permissions.

Decide what deserves to be fixed

Stable context belongs in a controlled, reusable layer. Examples include prohibited claims, tone boundaries, escalation rules, definitions, and quality criteria.

Do not fix information merely because it was true when the prompt was written. Pricing, product availability, staff names, and campaign status may expire quickly. Store them in a source that can be updated and retrieved, or require them in the current request.

A useful test is: who should be able to change this, and how soon must the change affect new runs? The answer tells you where the context should live.

Retrieval is an evidence-selection problem

Retrieval is often described as giving a model access to documents. Access is the easy part. The difficult part is selecting the right evidence without adding misleading material.

For each retrieval path, define:

1. The approved source set.
2. The query or selection strategy.
3. Freshness requirements.
4. The maximum amount of returned context.
5. How sources are cited in the output.
6. What happens when evidence conflicts or is absent.

Imagine a support-draft workflow with access to a help centre, account record, and internal incident log. The account record should outrank a generic help article for the customer’s plan. A current incident notice should override the normal troubleshooting path. If the records conflict, the workflow should surface the conflict rather than average the claims.

That prioritisation is part of the product. It cannot be solved by adding “use the most relevant context” to a prompt.

More context can reduce quality

Large context windows make it possible to provide more information, not wise to provide everything. Irrelevant material can distract from the task, introduce conflicting instructions, increase cost, and make important constraints harder to find.

Use the smallest context package that supports the decision. Prefer a focused product brief and three current evidence excerpts over an entire drive folder. Summaries can help, but preserve links or identifiers back to source material so important claims remain inspectable.

Watch for three failure modes:

• Context dilution: the required rule is buried among low-value text.
• Context collision: two sources make incompatible claims with no authority order.
• Context staleness: a plausible old fact is treated as current.

Treat examples as behavioural context

Few-shot examples do more than demonstrate format. They imply which details matter, how ambiguity is handled, and what tradeoffs are acceptable.

Select examples for coverage, not decoration. Include a normal case, a boundary case, and a case where the correct behaviour is to ask or abstain. Label why each example is good. Otherwise the model may reproduce superficial phrasing while missing the underlying decision rule.

Examples also expire. If the product, policy, or audience changes, review them as carefully as written instructions.

Memory should preserve decisions, not every conversation

Raw chat history is a poor default memory system. It contains abandoned ideas, repeated discussion, stale facts, and instructions that may no longer apply.

Persist the outputs that should affect future work: approved terminology, customer preferences, decisions, open questions, final artifacts, and review outcomes. Give each item an owner, timestamp, and scope.

For example, “Use a more confident tone” in one draft review should not automatically become a global brand rule. Save it against the campaign or customer unless somebody deliberately promotes it.

Make context visible in the run

Users should be able to answer: what sources shaped this output? Which rules were active? What information was missing? Which assumptions were introduced?

A run record does not need to expose internal chain-of-thought. It needs operational provenance: source names, versions or timestamps, selected excerpts, validation status, and reviewer decisions.

This visibility is essential for debugging. When an output is wrong, the team can distinguish a model failure from a retrieval failure, stale knowledge, ambiguous input, or an incorrect operating rule.

A context design walkthrough

Consider a landing-page audit workflow. The task input is a screenshot and URL. The operating contract defines the reviewer’s stance and prohibits invented performance claims. The method contains the audit sequence and severity rubric. Project knowledge contains the offer, audience, brand constraints, and current conversion goal. Retrieval supplies relevant analytics or research when available. The run state records findings, evidence, confidence, and the final prioritised list.

If the audit lacks audience information, it should flag that gap. If analytics are unavailable, it can still assess hierarchy and usability but must not claim a conversion problem is proven. Clean context boundaries make that behaviour possible.

The practical checklist

Before revising prompt wording, ask:

• What stable rules govern this job?
• What changes per project and per run?
• Which facts need retrieval, and from where?
• Which source wins when information conflicts?
• What is the freshness requirement?
• Which examples teach meaningful decisions?
• What should persist as memory?
• What context must be visible during review?
• What should the system do when evidence is missing?

Prompt engineering defines the instruction. Context engineering designs the information environment in which that instruction operates. Once AI work becomes repeated, shared, or consequential, the environment usually determines whether the result can be trusted.