Prompt and Context Engineering
Prompt and context engineering treated as software rather than folklore: versioned, tested, measured, and owned by a process instead of by whoever last edited the string.
In most organisations the prompt that decides the quality of a customer-facing feature lives in a string literal, has no version history, has never been tested against anything, and was last changed by someone who has since moved teams. Prompt and context engineering is the work of removing that sentence from your architecture.
Prompt and context engineering is the discipline of designing, versioning and testing everything that goes into a language model's context window: the instructions, the retrieved evidence, the examples, the tool definitions and the output contract, optimised against a measured evaluation set rather than adjusted by intuition.
Why prompt engineering is now context engineering
The phrase people search for is prompt engineering, but the work has moved. Modern models follow clear instructions well; what separates a good system from a mediocre one is what else is in the window and how it is arranged. Relevance, ordering, compression and what to leave out matter more than clever phrasing.
The context window is a budget. Every token of retrieved text, conversation history, tool schema and example competes for the same space, and adding more is not free: it raises cost, raises latency, and past a point reduces accuracy as the salient detail is buried in the middle of a long document. Managing that budget deliberately is the core of the engagement.
More context is not better context
We routinely improve accuracy by removing material from the window: pruning retrieved passages after reranking, summarising conversation history rather than replaying it, and cutting few-shot examples that duplicate what the instruction already says. Shorter prompts are also cheaper and faster, which makes this one of the rare optimisations with no trade-off.
What we do in a prompt engineering engagement
Audit what exists
We collect every prompt in the system, including the ones nobody remembers writing, and map which requests use which. In a typical audit we find duplicated instructions that have drifted apart, contradictory rules stacked over months of patching, and examples that no longer reflect the desired output.
Build the evaluation set
Real inputs, agreed correct outputs, and the failure cases that matter most. Without this there is no way to distinguish a genuine improvement from a change that helped the three examples someone happened to try. Where a team wants this capability independently, it is the substance of LLM evaluation and benchmarking.
Restructure the context
Instructions separated from evidence and from the output contract. Retrieved material ordered by relevance with the strongest passages placed where models actually attend to them. History compressed. Tool definitions trimmed to what the request could plausibly need. Output constrained to a schema that can be validated rather than parsed hopefully.
Harden against injection
Any prompt that includes user input or retrieved documents is exposed to instruction injection. We test with adversarial inputs, separate trusted instructions from untrusted content, and constrain what the untrusted portion is permitted to influence. This matters most where the model can call tools, because that is where an injected instruction stops being embarrassing and starts being expensive.
Put prompts under version control
Prompts move out of code into versioned, reviewable configuration with the evaluation suite running on every change. A prompt edit becomes a pull request with a test result attached, and rolling back a bad one takes seconds rather than a redeploy.
What the engagement typically finds
| Finding | Frequency in our audits | Usual fix |
|---|---|---|
| No evaluation set of any kind | Very common | Build one from real traffic before touching anything |
| Contradictory stacked instructions | Very common | Rewrite as a single ordered instruction with explicit precedence |
| Oversized context, low relevance | Common | Rerank and prune; compress history |
| Unvalidated output parsing | Common | Constrained decoding or schema validation with a retry path |
| No injection separation | Common | Trusted and untrusted content separated, tool scope reduced |
| No version history on prompts | Near universal | Prompts as versioned configuration with tests |
The improvement from this work is usually larger than teams expect, because it compounds: a better structured, smaller context is more accurate, cheaper and faster at the same time.
How the engagement runs
Short, measured and self-contained. You keep the evaluation set whatever you decide to do next.
Prompt audit
Every prompt inventoried and mapped to the requests that use it, with current failure modes collected from real traffic and support tickets.
Evaluation set
A scored set of real inputs and agreed correct outputs, including the edge cases that matter, plus a baseline score for the system as it stands today.
Restructure and test
Context redesigned, instructions rewritten, output contracts constrained and injection resistance tested, with every change scored against the baseline.
Handover and process
Prompts moved into versioned configuration, the test suite wired into your pipeline, and a working session on how to keep it that way.
What you receive
A measurably better system and, more importantly, the practice that keeps it improving.
Prompt audit
Every prompt in the system, what it is used for, and what is wrong with it, ranked by impact.
Evaluation set and baseline
Real inputs with agreed outputs, a scoring harness, and the score of the current system.
Rewritten prompt library
Versioned prompts with an explicit output contract, documented so a new engineer can change them safely.
Context budget design
What goes into the window, in what order, at what token cost, and what is deliberately excluded.
Injection resistance report
Adversarial test results, the separations put in place and the residual risk that remains.
CI integration
The regression suite running on every change, with a gate that stops a quality drop reaching production.
Is this the right engagement?
Worth being direct. Prompt and Context Engineering is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- An LLM feature is live and quality is inconsistent in ways nobody can quantify.
- Prompts live in code, have no tests, and changing them makes the team nervous.
- Token spend or latency is high and the context window is suspected to be the reason.
- The system takes untrusted user input or retrieved content and injection has never been tested.
- You are considering fine-tuning and want to know whether prompting has genuinely been exhausted first.
Choose something else if
- The underlying problem is retrieval quality. Fix that first with RAG development.
- There is no working system yet. Prompt engineering optimises something that exists.
- The requirement is a full evaluation capability rather than a prompt overhaul. That is LLM evaluation.
- You want a one-off list of prompt tips. This engagement changes how prompts are owned, which is a bigger commitment.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Is prompt engineering still a real discipline?
The naive version, hunting for magic phrasing, is largely obsolete. The engineering version is more relevant than ever: deciding what enters the context window, in what order and at what token cost, enforcing an output contract, resisting injection, and proving each change against an evaluation set. That work is not going away, it has just stopped being about wording.
How much improvement should we expect?
It depends entirely on the starting point, and we will not quote a percentage before seeing yours. What we can commit to is that improvement will be measured against a baseline you can inspect, so you can judge the value rather than take our word for it.
Will this reduce our token costs?
Usually, and often materially, because most production prompts carry context that adds cost and latency without adding accuracy. Reduced spend is a side effect of the same work that improves quality, not a separate optimisation.
Can our own engineers do this instead?
Yes, and that is the intended end state. The engagement exists to install the practice: the evaluation set, the versioning, the test gate and the review habit. We would rather hand that over than be called back for every prompt change.
Do we need this before fine-tuning?
Almost always. Fine-tuning is expensive to own and only sensible once a well-engineered prompt has been measured and found insufficient. Doing this first either solves the problem outright or produces the baseline that makes the tuning decision defensible. See LLM fine-tuning.
Often paired with this
Most clients combine two or three engagements from the Generative AI & LLM Engineering pillar. These are the ones that most often run immediately before or after.
LLM Evaluation and Benchmarking
Golden sets, calibrated judges and a regression suite in CI, so quality is a number that moves rather than an opinion.
Read more →LLM Fine-Tuning and Customisation
Fine-tuning when prompting and retrieval have genuinely run out, with curated data, a measured baseline and a clear verdict.
Read more →RAG System Development
Retrieval augmented generation built as a measured retrieval problem, with chunking, hybrid search, reranking and evaluation.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.