Context Engineering: The Discipline That Decides Whether Your AI Works

When an AI system fails in production, the instinct is to blame the model. Usually it isn't the model.

It's that the model was asked to make a decision without the information required to make it — the policy it should have applied, the record it should have checked, the three previous turns of the conversation that explained what the user actually meant. The model answered confidently anyway, because that is what models do.

Context engineering is the discipline of making sure that doesn't happen: designing the system that selects, formats and delivers the right information to a model at the moment it runs. As models have improved, the share of failures caused by model limitations has fallen and the share caused by context problems has risen. That shift is why the term exists.

Context engineering versus prompt engineering

Prompt engineering is about the wording of an instruction. Context engineering is about everything that instruction arrives with.

The clearest way to see the difference is to look at what each one treats as the unit of work.

A prompt-engineering approach to a scheduling assistant produces an instruction like "Book a flight from SF to Tokyo on Aug 20, include baggage and refund rules." Everything the model needs is in the sentence, because a human put it there.

A context-engineering approach produces a system that, on receiving "sort out my Tokyo trip," retrieves the user's travel policy, their seat preferences, the calendar entries that bound the dates, the approved booking tools, and the format the output has to take — then assembles those into the model's input automatically.

Prompt engineering doesn't disappear. It becomes a component of the larger practice: the system still has to phrase the instruction well, but phrasing is now one input among many. Context engineering subsumes it rather than replacing it.

How context engineering works

At runtime, a context-engineered system assembles an input package from several sources. The exact composition varies, but the components are consistent:

System instructions- behavioural rules, constraints, tone, what the model must never do.

The user's request- the immediate question or objective.

Conversation history- previous turns, usually compressed rather than included whole.

Retrieved knowledge- documents, records and passages pulled from your systems. This is where RAG, semantic search, embeddings and a vector database do their work.

Live system state- the account, ticket, deal or record the request concerns, fetched through connectors.

Tool definitions- which tools exist and when to use them. See function calling.

Memory- durable facts about the user, the team or the company that outlive one session. See persistent company memory.

Output format- the structure the response must conform to. See structured output.

A useful analogy: if the model is a processor, context engineering is the operating system — deciding what to load into memory, when, and what to evict. The context window is finite, so every decision to include something is also a decision to exclude something else.

The central constraint is this: a bigger context window does not remove the problem. Model performance degrades well before the window is full, because irrelevant material competes with relevant material for the model's attention. Filling the window is not the goal. Filling it correctly is.

The four core patterns

Practitioners have converged on four operations. Most real systems use all of them.

Common context failures

These have recognisable signatures. Learning to spot them is most of the practical skill.

Context poisoning. An error, a hallucination, a stale fact, a bad extraction enters the context early and is then referenced repeatedly downstream. The system develops a persistent false belief and reasons confidently from it. Characteristic sign: the same wrong detail recurring across many outputs.

Context distraction. The window grows large and the model anchors on accumulated history rather than the current task. It keeps doing what it was doing. Characteristic sign: quality degrading as a conversation lengthens, even well short of the window limit.

Context confusion. Too much irrelevant material — extra documents, too many tool definitions, unnecessary user data. Accuracy drops even when the window isn't full, and tool selection accuracy is especially sensitive to this. Characteristic sign: the model picking the wrong tool when many are available.

Context clash. Contradictory information is present simultaneously — two versions of a policy, a superseded decision alongside its replacement. The model has no principled way to adjudicate. Characteristic sign: inconsistent answers to the same question. This is a direct consequence of information silos, where the same fact exists in several places in several states.

Context starvation. The opposite failure, and the most common in practice: the model simply wasn't given what it needed. Characteristic sign: plausible, generic answers that would be right for some other company.

Note that three of these five are caused by including too much. The instinct to "just give it everything" is wrong.

Where it's applied

Retrieval-augmented generation

The canonical application. Rather than relying on training data, the system retrieves relevant material at inference time and includes it in the context. Quality here is almost entirely a context-engineering problem — chunking strategy, embedding choice, ranking, how many passages to include, how to handle conflicts between them. See Enterprise Search vs RAG vs AI Agents vs Company Brain.

AI agents

Agents are the hardest case, because context has to persist and evolve across many steps. An AI agent must track workflow progress, tool results, what it already tried and what failed — without accumulating so much history that it loses the thread. Multi-step reliability is substantially a context problem. See Agentic AI Architecture and Agentic AI Platforms.

Coding assistants

The most visible proof the discipline works. A coding assistant useful on a large codebase isn't running a better model than one that isn't — it's selecting the right files, symbols, types and recent changes to put in front of the model.

Enterprise assistants

Where context engineering meets a constraint the other three don't have: permissions. Retrieval must respect who is asking. An enterprise assistant that retrieves the right document for the wrong person has failed worse than one that retrieved nothing. This is permissions-aware AI, and it makes selection a security operation rather than purely a relevance one.

Context engineering as an enterprise competency

For a company deploying AI across many use cases, context engineering stops being a technique and becomes infrastructure. The reason is economic.

Every AI use case needs the same substrate: a way to find relevant company information, respect permissions, maintain memory, and call tools. Build that per use case and you build it fifty times, inconsistently, and get fifty different answers to the same question. Build it once as a shared context layer and every subsequent use case gets cheaper.

This is the practical argument for a context graph over per-application plugins, and it's the same argument behind the company brain idea: the valuable asset is not any individual agent, it's the layer underneath them all.

Three organisational consequences follow:

Someone has to own the context layer. The emerging role — context engineer, AI platform engineer, whatever it ends up being called — sits between domain experts who know what information matters and the engineers who build retrieval. The work is as much knowledge of architecture as software.

Documentation quality becomes an AI input. Stale documentation was previously a human inconvenience. In a context-engineered system it is training data for every answer the company gives. This is why the tribal knowledge problem gets sharper, not softer, with AI.

Context quality needs measurement. Not just answer quality. Teams that do this well log what was retrieved, what was selected and what was compressed away, so that a bad answer can be traced to a bad context rather than blamed on the model. See evaluation.

Practical implementation

A workable sequence for a team starting out.

1. Instrument before optimising. Log the full assembled context for every request. You cannot debug what you cannot see, and almost no one does this at the start.

2. Diagnose failures as context problems first. When an answer is wrong, check what the model was given before you change the prompt or the model. In mature systems this is usually where the fault is.

3. Fix retrieval before fixing generation. Precision beats recall. Returning three correct passages beats twenty mostly-relevant ones, and a ranking improvement typically outperforms a model upgrade.

4. Set an explicit context budget. Decide how much goes to history, retrieval, tools and instructions. Without a budget, history silently crowds out retrieval as conversations lengthen.

5. Compress deliberately. Summarise older turns before you're forced to. Emergency truncation at the window limit drops whatever happens to be at the boundary.

6. Isolate by concern. Separate contexts for separate tasks. Resist the single accumulating thread.

7. Resolve clashes upstream. If two systems hold contradictory versions of a policy, fix the source. No amount of ranking cleanly resolves a genuine contradiction.

8. Enforce permissions at retrieval. Filter at the point of selection, not afterwards. Anything that reaches the context window has effectively been disclosed.

9. Version your context assembly. Treat it like code, so a quality regression can be attributed to a specific change.

10. Evaluate on real cases, on a schedule. Context quality drifts as your documents, systems and people change — even when nothing in your code does.

When it's worth the effort

Not always. A single-turn, single-source, low-stakes task doesn't need this discipline. It repays effort when you have multi-turn interactions, several information sources, work that must respect permissions, multi-step tasks, or a requirement to explain why an answer was given.

How Libra approaches this

Libra WorkBase is built around a shared context layer rather than per-application retrieval. One context graph across company systems via Integrations, with permission inheritance so selection respects who is asking, and Knowledge Base, Meeting Assistant, Email Assistant, Business Intelligence, Agents and Workflows drawing on it.

The practical effect is that context engineering happens once, centrally, rather than being re-solved by every team that wants to build something. It deploys to cloud, VPC or self-hosted.