Context engineering: the discipline of what the model sees before it answers

A model can be highly capable and still give a poor answer. The failure often starts before generation. It starts with the information placed in front of the model.

The answer is only as good as the context the model was given. Context engineering is the discipline of getting that context right, before the model reasons, not after.

What is context engineering?

Context engineering is the discipline of assembling the right information, entities, relationships, permissions, and history into a model’s context before it reasons. It focuses on what the model sees, not only on how a user phrases an instruction.

The term has been described in complementary ways by several technology leaders. Shopify CEO Tobi Lütke called it the art of providing all the context for the task to be plausibly solvable by the LLM. Andrej Karpathy described it as the delicate art and science of filling the context window with just the right information for the next step.

For enterprise AI, this distinction matters. A support agent may need to connect a customer, product, contract, open ticket, past resolution, and recent product change. If those facts arrive as disconnected text fragments, the model has to guess how they fit together.

TLDR: the answer is only as good as the context

• Context engineering focuses on what the model sees, not only on how users ask questions.
• Retrieval soup happens when many relevant fragments arrive without clear relationships.
• Good context preserves entity identity, permissions, evidence, and business history.
• The challenge is an architecture problem, not a prompting trick. DevRev’s Enterprise-Bench reports 94.3% task accuracy versus 63.6% for the same model with different context assembly, with 4.4 times fewer tokens per correct answer.
• Computer Memory provides the context layer, connecting business data so AI agents can reason over structured, permission-aware context.

What is the difference between context engineering and prompt engineering?

Context engineering needs more than matching words; it needs a connected view of the situation. This is where AI knowledge management becomes relevant. It structures organizational knowledge so agents can retrieve and reason over it accurately, quickly, and within permission boundaries.

Prompt engineering optimizes the instruction given to a model. A prompt might say, “Find the customer’s open issue and recommend the next step,” but without the customer, issue history, product version, account permissions, recent fix, or approved action policy, the model still has to search, interpret, connect, and prioritize the information on its own.

Key takeaway: Context engineering addresses the deeper problem. It assembles the customer, product, ticket, account, resolution, and permissions into a coherent context before the model begins its work.

A knowledge graph can help connect these entities and their relationships, allowing the system to retrieve not just relevant information but also the business context linking it together. This gives the model a clearer foundation for reasoning and taking action.

Why did AI move from prompt engineering to context engineering?

Prompt engineering became popular when model behavior was the main source of uncertainty. Teams experimented with role descriptions, examples, instructions, output formats, and constraints. Those techniques remain valuable, but the center of gravity has shifted.

Models have become more capable and widely available. GPT, Claude, Gemini, and other frontier systems can follow complex instructions, summarize documents, write code, use tools, and plan multistep tasks.

As model capability becomes easier to access, the differentiator increasingly moves to the data and context surrounding the model.

The first response to this shift was retrieval-augmented generation, or RAG. A RAG system searches a collection of documents, retrieves relevant passages, and places those passages into the model’s context.

This approach helps ground answers in company information instead of general training data.

RAG remains useful. It’s often a practical way to search unstructured content such as policies, help articles, product documentation, meeting notes, and email. The distinction between knowledge graph vs RAG is important because retrieval and reasoning solve different parts of the problem.

The natural next step was to retrieve more. Teams added more documents, larger top results, reranking, query expansion, conversation history, tool outputs, and longer context windows.

Modern AI context windows can hold far more information than earlier systems could.

That sounds like progress. For simple questions, it often is. But enterprise-grade questions are not only search questions. They’re relationship questions. Consider a request such as:

Which customers are affected by the authentication issue introduced in the latest release, and which accounts can we contact today?

Answering safely may require the model to:

1. Identify the correct engineering issue.
2. Find the release connected to that issue.
3. Determine which product version each customer uses.
4. Connect affected accounts to support tickets.
5. Separate open tickets from resolved tickets.
6. Check account ownership and communication preferences.
7. Respect data access permissions.
8. Recommend or perform an approved action.

Key takeaway: A collection of similar text passages may contain every fact. Yet the model can still assemble the facts incorrectly. That’s why the conversation is moving from prompt engineering to context engineering.

The question is no longer only how to ask the model. It’s how to prepare the world the model needs to understand.

Why isn’t more context always better?

More context isn’t automatically better because relevance doesn’t equal relationship. A passage can be relevant to a question while still being irrelevant to the exact entity, time period, permission level, or workflow state involved.

A large context window is like a larger room. It gives you more space, but it doesn’t organize the furniture. If every document, message, ticket, and tool output is placed inside without structure, the model has to infer what belongs together.

That creates three common problems:

• Important facts are buried under low-value material.
• Similar entities are confused.
• Relationships are inferred from proximity instead of represented explicitly.

The result is often a confident answer built from individually plausible fragments.

What is the retrieval soup problem?

Retrieval soup describes a context full of relevant fragments that lack clear structure, identity, chronology, or relationships. The model receives many possible clues and tries to reconstruct the situation from them.

Imagine retrieving 10,000 chunks for an enterprise question. Some mention the customer. Others mention the product. Several describe similar tickets. A few include old decisions.

The model must decide which records refer to the same entity, which facts are current, and which relationship is causal.

That’s a difficult reasoning task even when every chunk is technically relevant.

One customer may appear under a legal name, account name, email domain, and CRM ID. Without entity resolution, the model may treat one customer as several customers.

One issue may appear in a support ticket, engineering bug, release note, and internal chat. Without relationship modeling, the model may fail to connect the records.

Time creates another problem. A resolved ticket may sit beside a new ticket about the same symptom. An old workaround may appear more frequently than the current fix.

If the context doesn’t make time and state explicit, the model may recommend a retired solution.

Permissions create an even higher risk. A model can’t safely answer from information the user shouldn’t see. Filtering after retrieval may be too late if restricted data has already entered the model’s working context.

These failures often look like hallucinations. Sometimes they are. But many enterprise failures begin earlier. The model was given context that was relevant in isolation but wrong in combination.

Research on agent systems shows why this matters economically. LangChain, reporting Anthropic’s findings, notes that multi-agent systems can use up to 15 times more tokens than a standard chat interaction.

More tokens can increase the chance of finding a useful fact. They can also increase cost, latency, and confusion. The goal isn’t to give the model everything. The goal is to give it the right context for the task.

The problem isn’t always the model. Often, it’s what the model was given.

Why is context engineering an architecture problem?

Context engineering is an architecture problem because reliable context depends on multiple layers working together. Retrieval alone can’t guarantee identity. A larger window can’t guarantee permissions. A prompt can’t guarantee live data. A model can’t create an evidence trail unless the system supplies one.

A production context layer needs to answer several questions:

• Which entities are relevant?
• How are those entities connected?
• What changed recently?
• Which facts are authoritative?
• Who can access each fact?
• What action is allowed?
• Can the answer be traced back to evidence?
• Can the system keep context current across sessions?

These requirements span data integration, schemas, ontologies, retrieval, permissions, memory, workflow orchestration, and evaluation. That’s why context engineering can’t be reduced to writing a better system prompt.

What does a bigger context window actually solve?

A bigger context window solves a capacity problem. It lets the model process more tokens in one request. It doesn’t solve an organization problem.

A bigger window is a bigger room. Context engineering is what you put in the room and how you organize it.

A 128,000-token context filled with duplicated documents, stale tickets, and unconnected fragments may be less useful than a 4,000-token context containing the correct customer, current product version, related issue, approved resolution, and evidence.

Longer windows can still be valuable. They help with large documents, long conversations, complex research, and multistep work. But capacity should support context quality, not replace it.

This distinction becomes more important as AI agents move from answering questions to taking actions. Gartner predicted that 40% of enterprise applications would include task-specific AI agents by the end of 2026, up from less than 5% in 2025. Gartner’s 2025 forecast shows why organizations need dependable context and governance, not only capable models.

An agent that summarizes a stale ticket is inconvenient. An agent that updates the wrong account, exposes restricted information, or closes the wrong issue creates operational risk.

What should good context engineering guarantee?

Good context engineering should guarantee that the model receives enough accurate, connected, current, and governed information to complete its task. It should reduce guesswork before generation and make the resulting answer or action easier to verify.

The key is not to treat a graph as a label or a trend. The key is to ensure that the model receives context that preserves meaning.

How does structured memory become a context layer?

Structured memory turns disconnected business activity into context an agent can use. It captures entities, attributes, relationships, history, permissions, and evidence in a form that supports reasoning across systems.

Computer Memory serves as this context layer. It connects structured and unstructured data, including records, conversations, files, relationships, and historical context. The goal is to give agents a connected understanding of the organization before they answer or act.

A typical context-assembly flow can look like this:

1. The user or system creates a task. The request may involve a customer, product, ticket, order, account, or operational event.
2. The system resolves entities. It identifies the exact customer, issue, release, team, or account involved.
3. The system follows relationships. It finds connected tickets, products, decisions, contracts, changes, and prior resolutions.
4. The system applies permissions. It removes information the user or agent isn’t authorized to access.
5. The system checks the current state. It prioritizes live status over stale snapshots.
6. The system assembles focused context. It sends the model the smallest useful set of facts, relationships, and evidence.
7. The agent reasons and acts. The response or workflow follows the available evidence and governance rules.
8. The result enriches future context. New decisions, actions, and outcomes become part of the organization’s usable memory.

This approach is different from asking an agent to search every system from scratch for every question. It creates a durable understanding of how the records connect.

Schemas and ontologies define what entities mean and how they relate. A schema might distinguish a customer from a contact, a product from a feature, or an incident from a support ticket. An ontology adds meaning to those concepts and their connections.

At its core is a permission-aware knowledge graph that represents those entities and relationships. It can connect a customer to a contract, product, ticket, engineering issue, release, and resolution. The model doesn’t need to infer every relationship from text proximity.

Computer AirSync keeps this context live. It connects enterprise systems and syncs changes so agents don't rely on stale snapshots – and because Computer reads from and writes back to those systems, it works with your systems of record instead of sitting as a disconnected, read-only layer.

This matters because the enterprise context changes constantly. Customers change plans. Tickets move from open to resolved. Products receive new releases. Account permissions change. Teams make decisions in conversations that may never become formal documents.

A context layer that only indexes yesterday’s data will eventually produce yesterday’s answer.

That doesn’t mean every task needs every piece of company data. Good context engineering is selective. It assembles the right context for the specific task, user, and moment.

How can teams implement context engineering?

Teams can implement context engineering by treating context as a governed product rather than an incidental prompt payload. The work should begin with high-value business tasks and known failure modes, not with a decision to add a larger model or retrieve more documents.

1. Start with workflows where incorrect context creates visible cost or risk

Support escalation, customer-impact analysis, incident response, account research, refund or credit decisions, product-to-engineering feedback, compliance and policy questions, and cross-system operational reporting.

For each task, document what the model needs to know: the entities, relationships, permissions, current state, evidence, and allowed actions.

2. Model the business objects that matter

Preserve time and state by distinguishing current from historical information and open from resolved work, using fields like created/updated/effective dates, status, owner, source system, confidence, and superseded information.

Without this, the model may treat a previous workaround as the current solution or an old customer record as the active account.

3. Enforce permissions before reasoning

Access controls must apply before restricted information enters the model’s context, accounting for user identity, role, account access, field-level restrictions, team boundaries, and action permissions.

This is not only a security feature; it affects answer quality. If the system gives the model incomplete information without explaining why, the model may fill the gap with an assumption. A governed context layer should make access constraints explicit and preserve an evidence path for what was included.

4. Measure outcomes

Compare the same model and task under different context strategies using metrics like task accuracy, correct entity resolution, citation validity, permission violations, action success rate, stale-context errors, tokens per correct answer, latency, human escalation rate, and repeated-question rate.

DevRev’s Enterprise-Bench is the AI industry's first open, vendor-neutral benchmark. Under Enterprise-Bench conditions, Computer by DevRev, reports 94.3% task accuracy versus 63.6% for the same model under different context conditions, along with 4.4× fewer tokens per correct answer.

Interpret these results within the benchmark’s specific tasks and dataset conditions, but note the central point: context assembly can materially affect outcomes even when the underlying model remains unchanged.

What changes when teams trust the context?

When teams trust the context, they spend less time compensating for fragmented information. They don’t need to hand-tune a prompt for every variation of a customer, product, or ticket question. They can focus on the workflow and the outcome.

The shift is from retrieving information to assembling the context an AI system needs to reason and act safely:

• From searching for documents to understanding connected entities.
• From copying more text into the prompt to assembling focused context.
• From guessing relationships to modeling them explicitly.
• From checking permissions after retrieval to governing context before reasoning.
• From treating memory as a feature to building it as an operational layer.
• From asking AI to suggest an action to giving it the context needed to take one safely.

People don’t have to repeat the same background in every interaction. Agents don’t have to rediscover the organization from scratch. Decisions, relationships, and outcomes become available where the work happens.

The same architecture can support support, sales, product, engineering, operations, and leadership; each team sees the context relevant to its role, while the underlying business relationships remain connected. 

That’s also why context engineering matters beyond chat. A chat answer can be useful even when it’s incomplete. An action requires more: the correct entity, current state, permission to proceed, evidence for the decision, and a safe path to update the relevant system.

You can see how Computer assembles structured, permission-aware context by requesting a demo.