BRANDBUSTERS SIGNAL / 07 · AI AND PRODUCTIVITY
The prompt is only the beginning. How to design context so that AI works better and costs less
A weak result does not always mean a weak model or a badly written instruction. More often, the system did not receive the right data, rules, examples, tools or information about the current state of the task. Context engineering means providing the smallest set of information that allows AI to perform specific work correctly, consistently and at a sensible cost.
- 14 MIN READ
- AI · CONTEXT · EFFICIENCY
- UPDATED: OCTOBER 2026
Businesses try to fix the output with an ever longer prompt.
The first response is too generic, so the user adds a role, further instructions, more constraints and the full history of the problem. Then come a presentation, meeting notes, a report, CRM data and a few examples.
The prompt grows, but the result does not necessarily improve.
The model receives more information, yet still does not know:
- —which source takes priority;
- —which data is current;
- —how to resolve contradictions;
- —what standard defines a good output;
- —which information it must not use;
- —which format to return;
- —when to escalate a decision to a human.
This is no longer just a prompt problem. It is a problem of context architecture.
Context engineering covers not only the user’s instruction, but the full set of information available to the system when it performs a task: rules, data, examples, history, memory, tools, outputs from earlier steps and the required response format.
A long prompt can contain a great deal of text and still provide very little useful context.
MORE ≠ BETTER
A longer context does not guarantee a better answer. Excess information can distract the model’s attention and make the relevant signal harder to find.
Source: Anthropic, Effective Context Engineering for AI Agents ↗UP TO 95%
In supported scenarios, reusing the same prefix through prompt caching can substantially reduce input-token costs. The actual saving depends on the model and configuration.
Source: OpenAI, Prompt Caching ↗QUALITY / COST / TIME
Efficient AI applications should optimise not only answer quality, but also the cost and latency of the entire process.
Source: Microsoft Research, Efficient AI Applications ↗Prompt engineering tells the model what to do. Context engineering decides what it can draw on.
PROMPT ENGINEERING
- —Frames the task.
- —Defines the role and instruction.
- —Sets the response format.
- —Adds constraints.
- —Helps complete an individual task.
CONTEXT ENGINEERING
- —Selects the right data and sources.
- —Establishes their priority and currency.
- —Provides examples of good outputs.
- —Manages history, memory and working state.
- —Makes the right tools available.
- —Limits unnecessary information.
- —Supports repeatable delivery of an entire process.
A good prompt still matters. It should not try to replace a knowledge base, permissions system, customer history, operational data, process logic and quality-control mechanism.
07 / CONTEXT ENGINEERING
Seven layers of good context
- 01
GOAL
What business outcome and decision should emerge?
- 02
RULES
Which instructions, constraints and priorities remain stable?
- 03
KNOWLEDGE
Which data and documents are needed right now?
- 04
EXAMPLES
What does a good output look like, and which errors are unacceptable?
- 05
TOOLS
What can the system check, calculate or execute?
- 06
STATE AND MEMORY
What happened earlier, and what remains current?
- 07
OUTPUT AND EVALUATION
What format should the response take, and how will we assess its quality?
Context should not be as large as possible. It should be as small as is sufficient.
Seven layers — from the goal to evaluation
- 01
Goal: start with the outcome, not the model’s capabilities.
“Analyse sales” does not specify whether the system should find the cause of a decline, prepare a board commentary, forecast performance or recommend action.
These are different tasks. They require different data, methods and levels of responsibility.
Context should specify:
- —who will use the output;
- —the decision it should support;
- —the time horizon;
- —the most important measure;
- —the boundaries of the system’s responsibility.
Question
Which specific decision will become easier because of this answer?
- 02
Rules: separate what stays stable from what changes with every task.
Stable instructions may cover KPI definitions, brand tone, privacy policy, approval rules, source hierarchy and escalation criteria. Customer data, the period under review, the question and the current working state are dynamic context.
Mixing everything into one long prompt makes maintenance, testing and reuse harder.
In API-based systems, a stable opening prefix can also support prompt caching, provided the model and configuration offer it.
Question
Which instructions should be shared across a hundred tasks, and which belong to just one case?
- 03
Knowledge: do not paste in the whole library when you need three relevant pages.
A large context window does not mean it should be filled with everything that might conceivably help.
A better approach is just-in-time retrieval: bringing in the information needed for the current step, whether a relevant document excerpt, the correct price-list version, a particular customer’s history or data for a chosen period.
Context should retain:
- —the source;
- —the date;
- —the version;
- —the information owner;
- —the level of trust;
- —any restrictions.
Question
What is the smallest amount of knowledge the system needs to complete this step correctly?
- 04
Examples: one good reference can replace a page of instructions.
Models learn the expected behaviour well from concrete examples. Show both a good output and a case that should be rejected or escalated to a human.
Examples must be representative. Dozens of similar cases add tokens without necessarily teaching the system a wider range of behaviours.
The strongest set covers varied, important situations: a standard case, a difficult one, a borderline case and one in which the system should refuse or escalate.
Question
Does this example show the model the expected standard, or merely another version of the same case?
- 05
Tools: the system need not remember data it can check safely.
A well-designed tool can retrieve the current order status, check availability, perform a calculation, find a document or save an output in the right system.
The tool list should not be unlimited. Tools with overlapping purposes make selection harder, raise costs and can lead to incorrect actions.
Each tool should have:
- —an unambiguous name;
- —a precise description of its purpose;
- —a minimal set of parameters;
- —a predictable output format;
- —restricted tool permissions;
- —error handling and escalation.
Question
Can a person clearly explain when each tool should be used?
- 06
State and memory: conversation history is not yet business memory.
A long conversation can contain decisions, drafts, errors and outdated information. Passing it in full to every subsequent step increases cost and the risk of relying on the wrong passage.
The system should distinguish between:
- —the current working state;
- —approved decisions;
- —lasting preferences held in long-term memory;
- —working notes;
- —information that has expired;
- —source material.
Memory should be selective, updateable and linked to its source.
Question
Which information should survive into the next task, and which should be forgotten?
- 07
Output and evaluation: without a quality criterion, an answer is only a proposal.
The system must know the required output format: a table, a recommendation, a draft message, a risk list, a CRM record or a decision for approval.
It also needs evaluation criteria. These may include factual accuracy, completeness, style compliance, use of sources, cost, time, safety and the number of corrections needed before use.
Any change to a prompt, model, tool or data source should be tested against the same evaluation dataset of real cases.
Question
How will an independent person recognise that the output is acceptable?
The difference is not prompt length. It is the quality of decisions about context.
BEFORE
Task
“Analyse sales performance and write recommendations.”
Attached material
- —the entire annual report;
- —a CRM export;
- —a marketing presentation;
- —notes from several meetings;
- —no measure definitions;
- —no named audience;
- —no output format.
Typical result
A generic summary, many observations and no decision.
AFTER
Goal
Explain the decline in contribution margin over the last eight weeks and identify three decisions for the commercial director.
Context
- —the definition of contribution margin;
- —sales data by channel, category and promotion;
- —a comparable period;
- —price and cost changes;
- —a list of known disruptions;
- —three examples of sound analysis;
- —a requirement to cite a source for every claim.
Format
- —the main cause;
- —evidence;
- —alternative explanations;
- —recommended decisions;
- —risks;
- —missing data.
Typical result
Material that can be verified and used in a decision-making discussion.
The improvement did not come from more impressive language. It came from a better choice of information and criteria.
Treat context as a budget, not a free warehouse.
Every additional passage may help, but it may also increase cost, response time, contradictions and the difficulty of finding the right signal. Treat the model’s attention budget as a resource to allocate deliberately.
| # | Element | Keep in context when | Move or retrieve later when |
|---|---|---|---|
| 01 | Instruction | Keep in context whenIt is needed for every task. | Move or retrieve later whenIt concerns a rare exception. |
| 02 | Document | Keep in context whenThe whole document is essential for comparison. | Move or retrieve later whenOnly one chapter or passage is needed. |
| 03 | History | Keep in context whenIt contains a current decision or working state. | Move or retrieve later whenIt is a working trail without lasting value. |
| 04 | Example | Keep in context whenIt demonstrates a distinct, important pattern. | Move or retrieve later whenIt repeats behaviour already illustrated. |
| 05 | Data | Keep in context whenIt is needed for the current calculation. | Move or retrieve later whenIt can be retrieved at the point of use. |
| 06 | Tool | Keep in context whenIt has an unambiguous role in the process. | Move or retrieve later whenIt duplicates another tool’s function. |
Good architecture more often retrieves the right context on demand than carries all available knowledge into every call.
Nine ways to improve the output while using fewer tokens
- 01Separate stable instructions from the dynamic task.
- 02Place shared, unchanging context in a stable prefix where the technology supports caching.
- 03Retrieve only the source passages you need, rather than whole documents.
- 04Replace a long history with an approved working state and a brief summary of decisions.
- 05Use a few varied examples rather than a list of similar cases.
- 06Limit the number of tools and remove overlapping functions.
- 07Route simple, well-defined tasks to a model with suitable capabilities and cost.
- 08Stop agents once they have achieved the outcome or exceeded the cost, time or step limit.
- 09Measure cost per accepted output, not only the cost of an individual call.
Do not shorten context by removing information needed for correct or safe execution. The goal is not the fewest tokens. It is the greatest value from every token used.
Eight context-engineering failure modes
- 01One gigantic prompt attempts to contain the business’s entire logic.
- 02The system receives every available document without selection or hierarchy.
- 03Conflicting sources are treated as equally credible.
- 04Conversation history serves simultaneously as instructions, memory and a knowledge base.
- 05The team adds exceptions but never removes outdated rules.
- 06The agent receives too many similar tools and excessively broad permissions.
- 07Quality is judged on one impressive example.
- 08The business changes the model or prompt without rerunning tests on real cases.
Context that nobody maintains gradually becomes a collection of contradictory instructions.
The context-engineering scorecard
| # | Measure | What it shows |
|---|---|---|
| 01 | Accepted-output rate | What it showsThe share of responses that can be used without substantial correction. |
| 02 | Factual accuracy | What it showsWhether the output matches sources and current data. |
| 03 | Completeness | What it showsWhether the system includes every required element. |
| 04 | Number of corrections | What it showsHow much human work the output needs before use. |
| 05 | Tokens per accepted output | What it showsHow much context and generation are needed to produce a useful result. |
| 06 | Cost per accepted output | What it showsThe full cost of the model, tools and retries. |
| 07 | Time to output | What it showsHow long the whole process takes, not just the first response. |
| 08 | Number of escalations | What it showsWhether the system recognises cases that require a human. |
| 09 | Cache hit rate | What it showsHow much stable context is reused in supported scenarios. |
The cheapest answer is not the most efficient if a person has to rewrite it from scratch. Nor is the most expensive model the best if it receives poorly designed context.
From prompts to a system in 30 days
WEEK 1
Choose one repeatable process.
- Select a regularly performed task with a measurable outcome.
- Collect 20 to 30 real cases.
- Record the current time, cost, quality and number of corrections.
- Identify cases that should trigger escalation to a human.
WEEK 2
Separate the layers of context.
- Define the goal and output format.
- Separate stable rules from case-specific data.
- Establish the source hierarchy.
- Select a few representative examples.
- Restrict the tool set.
WEEK 3
Run a controlled test.
- Test the same evaluation dataset.
- Measure quality, cost, tokens, time and corrections.
- Record the most common failure modes.
- Add context only in response to an observed problem.
WEEK 4
Set the operating standard.
- Approve the sources, instructions and examples.
- Assign a context owner.
- Introduce versioning and a review date.
- Define limits for cost, time and autonomy.
- Decide: scale, improve or stop.
Ten questions before scaling an AI solution
- 01Which process and business outcome does the solution improve?
- 02Which information is truly needed for every task?
- 03Which data should be retrieved only at the point of use?
- 04How does the system resolve conflicting sources?
- 05Who owns the currency of instructions and knowledge?
- 06Which examples define a good output?
- 07Which tools and permissions are genuinely necessary?
- 08How does the system recognise when to ask a human?
- 09What is the cost per accepted output, rather than per individual answer?
- 10How will we check that the next change improves quality rather than harms it?
The best AI system does not know everything. It knows what it needs right now.
Context engineering shifts the conversation from impressive prompts to the design of a real way of working.
Rather than expecting the model to infer definitions, priorities, current data and quality standards, the business creates an environment in which the right information reaches the right task at the right moment.
This improves more than answer quality. It makes costs easier to control, knowledge easier to update, risks easier to manage and the solution easier to scale beyond the most advanced users.
Do not ask how to write the perfect prompt. Design a system that supplies the right context.
WANT TO MOVE FROM EXPERIMENTS TO A REPEATABLE AI SYSTEM?
Let us design the process, context, measures and controls before scaling it.
We can select the right use case, build the context architecture, prepare an evaluation set and test both the quality and economics of the solution.