Ask an AI assistant to rewrite a paragraph and it does well. Ask it which of your ad campaigns to cut this month and it produces something fluent, confident, and untethered from your actual spend. The gap between those two results is not intelligence. It is context.
What is context engineering?
Context engineering is the practice of deciding what information, instructions, tools and state an AI system receives for a task, and how that material is selected, ordered, scoped and kept current.
The term treats the model's context as something you design rather than something that accumulates. Anthropic, whose engineering team helped popularise the phrase, describes it as "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" and frames it as the natural progression of prompt engineering. The term is recent and its edges are still moving, so treat any single definition — including this one — as a working consensus rather than a settled standard.
What does "context" actually mean here?
Context is everything the model can see when it produces a response. In an agent system that typically includes:
- System instructions — the standing rules about role, tone, and constraints.
- Tool definitions — what the model is able to call, and what each call expects.
- Examples — demonstrations of the shape of a good answer.
- Message history — the conversation so far.
- Retrieved data — passages pulled in at question time from documents or a search index.
- External knowledge — anything reached through a connected system, including over the Model Context Protocol.
To that list, work in a business setting adds four things general AI writing rarely mentions:
- Live business state — today's orders, this week's spend, the campaigns currently running.
- Identity and permissions — which user, which workspace, which brand, and what they are allowed to see or change.
- Task state — what has already been done, decided, or rejected in this piece of work.
- Provenance and freshness — where each figure came from and when it was last true.
Everything in that list competes for the same finite space, which is the constraint that makes this a design problem rather than a collection problem.
Why context engineering became important
Three things changed at roughly the same time.
AI moved from answering to acting. A model that drafts an email needs the email. An assistant that decides which page to fix, which campaign to pause, or which customer segment to email needs the operating reality of the business.
More context stopped being automatically better. Context windows grew to a million tokens, and it became clear that filling them degrades results. Anthropic documents this directly: as token count grows, accuracy and recall degrade, an effect they call context rot. Curation beats accumulation.
The connection layer standardised. Once assistants could reach outside systems through a common protocol, the bottleneck stopped being "can this model see my data" and became "which data, from where, how fresh, and who says it is allowed" — all context engineering questions.
Context engineering vs prompt engineering
Prompt engineering is about wording. Context engineering is about supply.
A well-engineered prompt asks the right question in a way the model can act on. Well-engineered context means the material needed to answer it is present, current, and trustworthy. You can write a flawless prompt about last quarter's margins and still get a fabricated answer, because no amount of phrasing conjures a number the model was never given.
The two are complementary, and prompt engineering did not stop mattering. It stopped being sufficient the moment the interesting questions started depending on facts that live outside the conversation.
Context engineering vs RAG
Retrieval-augmented generation searches an external corpus at question time and places the retrieved passages into the model's context before it answers. It is a technique for filling part of the context, and a good one for written material at volume.
Context engineering is the wider decision that includes whether to use retrieval at all. Retrieval answers "which passages are relevant to this question". It does not answer "what is currently true", "who is asking", "what may this user change", or "how old is this number". A business assistant frequently needs all four, and none of them come out of a vector search.
The honest framing is that RAG is a component, not a competitor. Plenty of good context architectures contain retrieval. Very few consist only of retrieval. The full RAG comparison works through where retrieval sits in a context stack, and where it runs out.
Context engineering vs AI memory
AI memory is the general term for information an AI system retains beyond a single turn — the conversation window it can currently see, stored facts and preferences about a user, and knowledge it can retrieve later.
Memory is therefore one possible source of context, aimed mostly at continuity for an individual. It answers "what has this person told me before". Context engineering also governs instructions, tools, permissions, live state, and freshness — most of which no memory feature addresses. An assistant that remembers you prefer short summaries has memory. An assistant that knows this week's revenue has context.
AI memory for business separates those layers in more detail.
Context engineering vs a knowledge base
An AI knowledge base is a curated collection of documents and written answers, indexed so an AI system can retrieve relevant passages when responding.
A knowledge base is excellent context for anything that is written down and changes slowly: policies, product descriptions, positioning, support answers, brand rules. Its weakness is structural rather than technical — it is only as current as the last human edit, and the things that most often decide a business question (revenue, spend, stock, rankings) are exactly the things nobody keeps updating in a document.
Good context architecture usually keeps a knowledge base for stable written knowledge and gets volatile figures from the systems that own them. The knowledge base comparison sets out where that line falls.
An eight-property test for business context
This is a Zylx framework, not an industry standard. It is offered as a checklist that has been useful for judging whether an AI system is actually equipped to answer a question, and it is deliberately simple enough to apply in a meeting.
For any piece of context you intend to supply, ask:
| Property | The question it answers | Failure looks like |
|---|---|---|
| Relevance | Does this bear on the task at hand? | A 60-page handbook loaded to answer a pricing question |
| Freshness | When was this last true? | Confident advice built on last quarter's numbers |
| Structure | Can the model tell entities and relationships apart? | A wall of text where products, orders and customers blur together |
| Provenance | Can the answer be traced to a source? | A number nobody can find again |
| Permissions | Should this requester see this? | One brand's figures surfacing in another brand's workspace |
| Persistence | Does this survive the end of the conversation? | Re-explaining the business every Monday |
| Portability | Can a second assistant use the same context? | Rebuilding everything to try a different AI product |
| Actionability | Can the system do something, and under what control? | Read-only insight nobody has time to implement |
The point of the table is not to score highly on all eight. Most contexts should not be actionable, and plenty of good context is deliberately not persistent. The point is that these properties are usually decided by accident, and deciding them on purpose is most of what context engineering is.
Two of them cause the majority of real-world disappointment. Freshness fails silently — a stale answer looks exactly like a current one. Permissions fail expensively — the failure is not a bad answer but a disclosure.
Why business context fragments
Business context is rarely missing. It is scattered, which produces the same result.
A mid-sized ecommerce operation typically holds its catalogue in one system, its traffic in another, its search performance in a third, its spend in a fourth, its payments in a fifth, and its email history in a sixth. Positioning and strategy live in documents, or in a founder's head. Each system is individually well-run and none of them can answer a question that spans two of them.
Then the AI arrives, and the fastest way to give it any context at all is to paste. Pasting produces a snapshot that is correct for about a day, belongs to one conversation, and has to be recreated every time. That is not a failure of discipline; it is the path of least resistance when no other path exists.
The four failure modes
Most bad AI output in a business setting traces to one of these.
Missing context. The material needed was never supplied. The model fills the gap with something plausible, which is the worst possible failure because it is indistinguishable from an answer.
Stale context. The material was supplied once and has drifted. Nothing in the output indicates its age.
Unstructured context. The material is present but shapeless — a transcript dump where the model cannot reliably tell which figure belongs to which product.
Over-stuffed context. Everything was supplied on the theory that more is safer, and the signal drowned. This is the failure mode that grows as context windows get larger, which is why capacity increases have not eliminated the discipline.
What good context architecture looks like
Working backwards from the questions you want answered gives a more useful architecture than starting from the data you happen to have.
- Name the recurring questions. Not "give AI our data" but "which pages lost traffic and did that cost us revenue".
- List what each answer requires. Usually a mix: some written knowledge, some current figures, some company-specific judgement.
- Assign each requirement to a home. Stable prose belongs in instructions or documents. Volatile figures belong in the system that owns them. Company judgement belongs somewhere durable rather than in one person's memory.
- Decide freshness per source. A brand guideline can be a year old. An inventory count cannot be a week old.
- Decide scope before access. Which workspace, which brand, which user. Retrofitting permissions is significantly harder than starting with them.
- Separate reading from acting. Most value comes from reading. Where acting is genuinely useful, put a human decision between the proposal and the effect.
- Keep provenance. An answer that cannot be traced cannot be trusted, and an untrusted answer gets re-checked by hand, which removes the saving.
How much architecture do you actually need?
Escalate only when the previous step stops working.
- Written instructions are enough when the context is stable prose and one person is asking. Positioning, tone, standing constraints.
- Uploaded documents are enough when the knowledge is written, bounded, and changes on a human timescale.
- A knowledge base or retrieval is worth it when the written material is too large to supply wholesale and questions hit different parts of it.
- Connected systems become necessary the moment the answer depends on a number that changes — revenue, spend, stock, rankings, orders.
- A protocol like MCP matters when more than one assistant, or more than one person, needs the same governed access. It turns context into something you build once rather than once per tool. MCP for business covers what that governance involves.
- A maintained context layer earns its keep when context spans several systems, has to stay current without anyone maintaining it, and needs to serve whichever assistant the business happens to use.
There is no prize for arriving at the last row. Most businesses are best served two or three steps up from where they are, and the practical guide to giving AI context about your business walks the ladder with the trade-offs at each rung.
Where a Business Brain fits
A Business Brain is persistent, structured business context — assembled from the systems a company already runs and kept current — that authorized AI assistants can query through a governed interface. It is Zylx's name for the last row of that ladder, and we would rather say plainly that it is our category framing than imply an industry consensus that does not exist.
In terms of the eight properties, it is an attempt to decide all of them deliberately: context assembled from source systems rather than documents (freshness), organised as entities rather than text (structure), returned with the record behind it (provenance), scoped per workspace and revocable (permissions), maintained outside any conversation (persistence), reachable by any authorized client over MCP (portability), and able to propose changes that a human approves (actionability, with a brake).
That is a design position, not a universal answer. A business whose context is genuinely three documents does not need it, and should not be sold it.
What to take away
Context engineering is not a new technology. It is the recognition that the useful question stopped being "which model is smartest" and became "what does this system actually know, how current is it, and who said it could look".
If your AI output is fluent but wrong, add context before you change models. If it is right but stale, fix freshness before you add volume. And if you cannot say where a number came from, that is the first thing to fix, because everything else is guesswork built on top of it.
Sources
- Anthropic: Effective context engineering for AI agents — definition, context components, and the "smallest set of high-signal tokens" principle.
- Anthropic: Context windows — how the context window works, and context rot as token count grows.
- Model Context Protocol documentation — the open standard for connecting assistants to external tools and data.
- The eight-property test is original Zylx synthesis, offered as a practical checklist rather than a standard.