Context Engineering: The foundation for reliable enterprise AI agents

An AI assistant can start a conversation with all the right instructions and still lose track of them as the conversation progresses.

You ask it to keep answers short, use your product names, and avoid jargon. Forty messages later, it starts writing long explanations, inventing product names, and explaining what an API is.

The same problem occurs with enterprise AI agents. A customer shares an order number at the start of a support conversation, only to be asked for it again ten turns later.

This doesn't necessarily mean the model has failed. The information may still be there, but it has become harder to find and use as the conversation grows.

Context engineering helps address this problem by keeping the right information available to an AI agent when it needs it. For enterprises, this goes beyond writing better prompts. It involves managing what information an agent can access, when to make it available, how it is governed, and what needs to be retained as the task progresses.

Context engineering in brief

• Context engineering determines what an AI agent sees at each step of a task, including instructions, tools, knowledge, memory, and conversation history.
• More context is not always better. Research shows that model accuracy can decline as input grows, even when the context window is not full.
• Progressive disclosure keeps the initial context small and adds information when a condition makes it relevant.
• Enterprise agents need both autonomy and control. They should reason freely where appropriate and follow deterministic workflows when the work requires repeatability or auditability.
• Context must be operated as infrastructure. Teams need clear ownership, access controls, versioning, and traces that show what the agent saw when it acted.

What is context engineering?

Context engineering is the practice of deciding what information an AI agent receives at each step of a task, and when it receives it. The objective is to provide the smallest set of relevant information that enables the agent to act correctly.

Context includes everything the model reads before it makes a decision:

• System instructions and business policies
• Tool definitions and tool results
• Knowledge retrieved from documents and help articles
• Conversation history and customer information
• Memory retained from earlier interactions
• Notes or summaries created during a longer task

Anthropic describes context engineering as the natural next step after prompt engineering. The central idea is simple: give the model the smallest set of high-signal information that makes the desired outcome more likely.

That distinction matters because an enterprise agent does not make one isolated response. It may retrieve information, call tools, interpret results, update state, and make several decisions before completing a task. The context that supports one step may be irrelevant or even harmful at the next.

Context engineering vs. prompt engineering

Prompt engineering focuses on how an instruction is written. Context engineering covers the full set of information available to the model, including how that information changes throughout a task.

This distinction is becoming increasingly important for enterprises.  Forrester describes context engineering as the design and delivery of structured, relevant, and timely context that helps AI outputs remain accurate, grounded, and compliant. Gartner projects that by 2029, 80% of AI agent platforms using reasoning models will have context layers in place, up from fewer than 10% today.

Key context engineering terms

Why does more context make AI agents worse?

More context can reduce accuracy because every additional token competes for the model’s attention. Relevant information becomes harder to distinguish from everything around it. Researchers call this context rot.

Research from Chroma tested 18 frontier models and found that all of them lost accuracy as input length increased. The decline appeared even on simple tasks and well below the models’ maximum context windows. The study also found that irrelevant text made performance worse.

Stanford’s Lost in the Middle study found a related pattern: models often recall information near the beginning and end of a long input more reliably than facts buried in the middle.

For a single chatbot question, the problem may be manageable. But enterprise AI agents often handle longer, more complex tasks. Each turn adds tool outputs, retrieved information, customer details, and conversation history. By the twentieth turn, a critical policy may be buried under thousands of tokens of less relevant information.

There is also a direct cost. Carrying unnecessary context across multiple model calls can increase token usage, latency, and cost without improving accuracy.

The solution is not simply to use a larger context window. It is to manage what enters the context in the first place.

Do AI agents still need workflows?

Yes. Some enterprise work requires fixed steps, even when an agent can reason autonomously.

Customer service automation has evolved from IVR menus and scripted flows to goal-driven agents that can handle conversations more independently. But that doesn't mean workflows are no longer needed.

Goal-driven agents are better suited to open conversations. Customers can explain problems in their own words, change direction, and still receive help. Scripted flows struggle with that flexibility, and every new branch makes them harder to maintain.

But some tasks must follow a defined sequence. Identity verification, regulated insurance claims, and refunds above a threshold may require specific checks in a specific order. An auditor needs evidence that the required steps were followed. “The model decided” is not enough.

Context engineering determines when a workflow applies. A deterministic workflow can become part of the agent’s context when a condition is met, while the agent reasons freely elsewhere.

Kore.ai {Artemis} supports this approach by combining autonomous reasoning with deterministic, auditable workflows within a single agent definition. This allows agents to handle open-ended conversations while following defined steps when the task requires them.

What are the best practices for context engineering?

Effective context engineering starts with five practices: keep the initial context small, load information by condition, give each context component a type and owner, retain useful memory instead of raw history, and isolate complex work across sub-agents.

1. Start small and add context as the task evolves

Begin with the essentials: core instructions, brand voice, and a small set of general tools. Add more information as the conversation makes it relevant. This is progressive disclosure.

Consider a telecom agent handling a question about roaming charges. It does not need tariff rules for 200 countries at the beginning of the conversation. It needs the rules for the customer’s destination once the customer identifies it. Until then, the other 199 sets of rules add noise.

The principle is straightforward: load context when the task requires it, not simply because it might be useful later.

2. Use conditions to determine what loads

Progressive disclosure works by using conditions to determine when additional context is needed. 

Some conditions come from state, such as whether a customer has been verified or whether an account lookup has returned a result. Others come from the conversation, such as a customer mentioning cancellation, a particular product, or a billing dispute.

When a condition is met, the agent can load the matching policies, tools, and knowledge. Verification may unlock account tools. A billing dispute may activate the dispute process.

In Agent Blueprint Language (ABL), a business rule on a knowledge tool can prevent archived documents from reaching the agent:

 search_kb_policies(query: string) -> object
  description: "Search the policy knowledge base"
  type: searchai
  business_rules: |
    [{"id":"hide_archived","when":{"kind":"always"},   

 "Then":{"hide":[{"field":"status","operator":"eq","value":"archived"}]}}]

The same approach can apply to query text, known customer attributes, or detected intent. Rules can filter, hide, boost, or lower search results. Different agents can apply different rules to the same knowledge base.

This goes beyond retrieval tuning. These rules also control which information reaches the agent and can influence its decisions. 

3. Give every context component a type and an owner

A single instruction block is difficult to test, maintain, and govern. Context is easier to manage when each component has a clear purpose.

Each component should also have an owner. Legal may own policies, support may own knowledge, and engineering may own tools. When a policy changes, the responsible team can update and validate that component without rewriting the entire agent.

Tools need the same discipline. If two tools overlap, the agent has to decide which one to use. Anthropic offers a useful test: if an engineer cannot clearly explain when a tool applies, the agent is unlikely to make that choice reliably.

4. Compact old history and preserve useful memory

Long conversations accumulate raw tool output, resolved issues, and details that no longer matter. Keeping all of it in the context makes the next decision harder.

Instead, summarize what has happened, preserve what remains unresolved, and remove raw results once they have served their purpose. Durable facts, such as a case number or a stated preference, should be stored in memory that the agent can retrieve later.

This is how an agent can maintain continuity without carrying the entire conversation forward. It also prevents familiar failures, such as asking a customer for an order number they already provided.

5. Split complex work across sub-agents

A lead agent can delegate a narrow task to a specialist with its own clean context, then receive a concise summary of the result.

The specialist’s working details stay separate from the lead agent’s context. This reduces the amount of information the lead must process while allowing each specialist to focus on a defined job.

Anthropic has described systems in which sub-agents work through tens of thousands of tokens and return summaries of roughly 1,000 to 2,000 tokens. The broader lesson is to separate detailed work from the context needed to coordinate the overall task.

How does context fail in production?

Context failures take several forms. Each creates a different kind of risk.

Missing information is just one reason context fails. Problems can also arise when the information an agent receives is irrelevant, outdated, contradictory, or beyond the user's access permissions. 

Better retrieval alone will not solve them. Enterprise context needs clear ownership, versioned policies, and permission checks before information reaches the model.

What changes at enterprise scale?

As enterprises deploy AI agents across more workflows and systems, context engineering requires a more structured approach to governance, cost management, debugging, and model upgrades.

An agent handling one task with two tools may work with loosely managed context. An agent supporting dozens of use cases across multiple systems, regions, and customer tiers needs a more deliberate design.

• Governance: When context is typed and loaded by condition, teams can answer a critical audit question: what did the agent know when it made that decision?
  
  
• Cost: Fewer unnecessary tokens reduce the cost of each model call and can lower the cost per resolution. A password reset should not carry the full returns policy.
  
  
• Debugging: When an agent gets something wrong, teams need to know what it saw. Traces should show which context loaded at each turn and why.
  
  
• Model upgrades: Hard-coded flows limit an agent to predefined paths. Well-engineered context allows agents to take advantage of improvements in model reasoning without requiring every workflow to be rebuilt.

Running context as a platform

Forrester uses the term ContextOps for the operating side of context engineering: managing, governing, monitoring, and improving context throughout its lifecycle.

The shift is from building context separately for every agent to managing it as shared infrastructure. Otherwise, teams end up recreating the same policies, memory structures, and integrations across projects.

A shared context platform can establish common standards for ownership, access, versioning, evaluation, and observability. Individual agents can then apply those standards to their specific tasks.

How does {Artemis} support context engineering?

Kore.ai {Artemis} enables teams to define and manage the context available to enterprise AI agents, control how that information is used, and trace what an agent saw during execution.

Beyond policies and retrieved knowledge, agents may also need context about past decisions. A document can explain what a policy says, but may not show how it was applied in an earlier exception. Context graphs can capture that decision history, helping agents use relevant precedents when handling similar cases.

The bottom line

As AI models become more capable, the quality of context they receive becomes increasingly important. Even the most advanced models need relevant information, clear permissions, and a record of what they accessed to perform reliably.

For enterprises, context engineering helps put these controls in place. By managing what agents know and when they can access it, teams can build AI agents that make better decisions, handle complex tasks, and remain accountable for their actions.

‍

What is context engineering?

Context engineering is the practice of deciding what information an AI model or agent sees at each step of a task. It includes instructions, tools, retrieved knowledge, memory, and conversation history. The goal is to provide the smallest set of relevant information that enables the agent to act correctly.

What is the difference between prompt engineering and context engineering?

Prompt engineering focuses on how a single instruction is written. Context engineering covers everything the model sees, including tools, knowledge, memory, and history, and determines how that information changes before each model call. Prompt engineering is one part of context engineering.

Is RAG the same as context engineering?

No. Retrieval-augmented generation (RAG) is one technique within context engineering. RAG retrieves relevant documents and adds them to the model’s context. Context engineering also manages tools, policies, memory, conversation history, and when each component becomes available.

Why do AI agents lose accuracy in long conversations?

This is known as context rot. As input grows, relevant information becomes harder for the model to use reliably. Research across 18 frontier models found that accuracy declined as context grew, even well below the context window limit. Agents face additional pressure because every turn can add tool output, retrieved content, and history.

What is progressive disclosure in AI agents?

Progressive disclosure means giving an agent only the context it needs at each stage of a task. The agent starts with a small base of instructions and tools. Additional policies, knowledge, or tools load when a condition is met, such as customer verification or a billing question.

What is ContextOps?

ContextOps is the operating discipline for managing, governing, monitoring, and improving the context AI agents use. It helps enterprises move context engineering from individual projects to a shared, governed platform.

‍