Why Context, Not Prompts, Decides Whether AI Pilots Work

Pilots now stall on context, not on models

Ask why an AI agent pilot disappointed, and the answer you hear has changed. According to Redis's 2026 survey of IT and AI infrastructure leaders, leaders have stopped blaming models and started blaming context, meaning the data, records, memory and live state an agent needs for real work, and they now rank fresh, navigable context above bigger models as the path forward. Redis sells context infrastructure, so it has a stake in that conclusion, but the technical sources below point the same way. If you want the practical part first, the checklist and the review signals are in the last two sections.

Drew Breunig's The State of Context Engineering, based on his AGNTCon talk, traces how the field got here. In 2023, choosing the right words and examples for a single model call was prompt engineering. By 2025 the job had become context engineering, where the system fills the model's context window dynamically instead of a person typing a crafted prompt. In 2026, as more of that logic moved out of the context and into code, he calls it harness engineering.

Elastic offers the cleanest one-line distinction: prompt engineering asks 'How should I phrase this?' while context engineering asks 'What information does the model need access to right now?' The first concerns one query. The second concerns how information flows through a whole system, across every step an agent takes.

DataHub treats prompt engineering as a subset of context engineering: the larger discipline decides what gets retrieved, what gets compressed, what carries over between turns and what gets dropped. It cites its own 2026 report, in which 82% of IT and data leaders say prompt engineering alone is no longer enough and 95% call context engineering important for running agents at scale. DataHub is also a vendor in this space, so treat the figures as a signal of sentiment rather than neutral measurement.

What the AI actually sees, and who decides

The context window is everything the model can see when it produces an answer. For agents that work over many steps, Anthropic lists the pieces that need managing: system instructions, tools, the Model Context Protocol (MCP), external data and message history. A useful mental model for non-engineers is the briefing pack you hand a contractor before each task. The difference is that this contractor forgets everything between tasks unless the pack carries it forward.

Anthropic advises aiming for the minimal set of information that fully describes the expected behavior, and stresses that minimal does not have to mean short. It also says system prompts should sit at the 'right altitude', avoiding hardcoded, brittle logic on one side and vague high-level guidance that assumes the model shares your background knowledge on the other. For example, a line like 'follow our refund policy' means nothing if the policy itself never reaches the model.

LangChain groups the techniques into four buckets: write, select, compress and isolate, and gives splitting work across sub-agents, each with its own tools, instructions and context window, as one way to isolate. The rest is our plain-language gloss. In practice, write means saving information somewhere outside the window for later, select means pulling in only what this step needs, compress means shrinking what you keep, and isolate means stopping one task's clutter from spilling into another.

Four ways context goes wrong, and two newer ones

Breunig's earlier article, How Long Contexts Fail, names four failure modes. Each bullet below pairs his definition with a business example of our own. Learn them by name: once a team has the vocabulary, complaints about 'the AI being weird' turn into specific, fixable reports.

Longer-running agents have exposed two more problems, according to a daily.dev summary of Breunig's talk. 'Fighting the weights' is when the model falls back on what it learned in training rather than following your context. 'Context inertia' is when the agent fixates on one idea and won't let go.

The same summary says Anthropic's Memento harness reportedly handles inertia by clearing the context every 90 minutes while keeping the work environment intact. That detail comes second-hand, from a summary of a talk describing another company's system, so take it as an illustration rather than a recipe. The underlying point holds either way: sometimes the right amount of accumulated context is less.

• Context poisoning: a hallucination enters the context and keeps being referenced. Example: an agent misreads a delivery date early in a task and keeps citing the wrong date for the rest of the session.
• Context distraction: the context overwhelms what the model learned in training. Example: after a long back-and-forth on a support case, the agent leans on the transcript instead of the general judgment it would otherwise apply.
• Context confusion: unnecessary context influences the answer. Example: an agent handed twenty tool descriptions when the task needs two calls the wrong one.
• Context clash: parts of the context disagree with each other. Example: the knowledge base holds both the 2023 and 2025 travel policies, so the model has to guess which one applies.

Why a bigger context window does not solve this

It is tempting to treat very large context windows as permission to stop curating. According to a daily.dev summary of Breunig's talk, he argues the opposite: windows of a million tokens and more do not make AI reliable, they simply let in more errors through the four failure modes above.

Independent testing points the same way. Chroma's July 2025 Context Rot report tested 18 leading models, and on the LongMemEval benchmark they did consistently worse when given the full conversation history than when given only the most relevant excerpts. The researchers concluded that the results point to the importance of context engineering.

In our view, 'just connect it to the whole shared drive' is the wrong instinct for any agent that works across systems. If your use case is a person uploading one file and asking for a summary, you are already doing context selection by hand, and much of this article matters less to you. It matters a great deal once an agent starts pulling from many sources on its own.

The fixes teams use, and which failure each one targets

According to the daily.dev summary of Breunig's talk, teams apply six fixes: augmentation, tool loadout, quarantine, pruning, offloading and summarization. None of them is exotic. Each is a way of deciding, step by step, what the model should and should not see.

The descriptions here are our plain-language gloss, not the talk's definitions. In practice, augmentation means retrieving relevant documents and adding them for this step; tool loadout means giving the agent only the tools the task needs; quarantine means running sub-tasks separately so their clutter stays contained. Pruning means removing outdated or irrelevant material, offloading means keeping notes and plans outside the window until needed, and summarization means compressing long histories before carrying them forward.

The list below maps failures to fixes. This mapping is our editorial interpretation, not Breunig's, and some entries (archiving, memory review, resets) go beyond the six named fixes. It is meant as a starting point when you triage a bad answer.

Memory deserves special care, because whatever an agent writes down becomes future context. A ZenML case-study summary describes how Anthropic's Applied AI team began with simple markdown files loaded at the start of each session, which grew into file-system-based memory with versioning, concurrency controls and permissions, plus a 'dreaming' process in which agents review past transcripts and propose memory improvements. The lesson for everyone else: a plain notes file is a legitimate first version, but govern it from day one, because a poisoned fact saved to memory spreads to every later session until someone removes it.

• Confusion → tool loadout and pruning
• Clash → pruning and archiving superseded documents
• Distraction → quarantine and summarization
• Poisoning → pruning and regular memory review
• Context inertia → periodic context resets
• Fighting the weights → state the rule explicitly in the context and check answers against the source

Context is an organizational problem, not just an engineering one

Redis's survey also shows how far most organizations are from supplying good context. Among the most mature organizations, 69% still feed critical decisions with stale data. Across all respondents, 60% say they are ineffective at governing access to context and only 58% are confident it is well governed. As with DataHub, Redis sells context infrastructure, so read its framing accordingly: useful as a picture of what leaders report, not as an independent audit.

Atlan makes a point every operations leader should take seriously: business rules written into prompts go stale and cannot be audited, versioned or shared across agents. Its alternative is persistent, governed infrastructure (metadata, definitions, lineage, governance policies) that serves every agent in the organization. Put simply, your discount rules should live in one maintained place, not in five slightly different prompts.

This is where most of the real work sits, and none of it is glamorous. Someone has to archive old policy versions. Someone has to make sure an agent acting for a user cannot read what that user is not allowed to read. And someone has to own each body of knowledge, so that when the AI gives a wrong answer there is a person who can fix the source rather than patch the prompt.

A checklist for operations and product leaders

You do not need to write code to use this list. Most items are decisions about information and ownership that engineers cannot make on your behalf, and that pilots tend to skip.

Run through it before approving a pilot's move to production, and again whenever the agent gets access to a new system.

• Name the task precisely. 'Answer supplier questions about delivery terms' can be scoped; 'help procurement' cannot.
• List the sources the agent needs for that task, and the ones it should never touch.
• For each source, name an owner who keeps it current and can correct it.
• Remove or clearly archive superseded documents so old and new versions never compete.
• Check that agent access follows the same permissions as the human it acts for.
• Write business rules once, in a maintained, versioned place, instead of inside prompts.
• Limit the tools the agent can call to the ones this task actually needs.
• Decide what the agent may remember between sessions, and who reviews that memory.
• Ask how long sessions are handled: is history summarized, pruned or reset?
• Require answers to cite their sources so reviewers can see what context was used.
• Agree on a small set of review checks before launch, not after the first incident.

Simple signals that your AI is getting the right context

None of the sources above offers a standard metric set, so treat the following as practical suggestions rather than an industry benchmark. The goal is to catch context problems early, with checks a domain expert can run without a data science team.

The simplest method is a regular sample review. Pull a handful of real queries each week, have the knowledge owner check the answers and cited sources, and log which failure mode each bad answer showed. Over time the log tells you whether to fix documents, permissions, tools or session handling. If the AI is a low-stakes drafting aid that a person always edits, this level of tracking is probably overkill.

• Source accuracy: in sampled answers, was the cited document the correct and current one?
• Stale-source hits: how often did the agent rely on archived or outdated material?
• Honest gaps: when the answer was not in the sources, did the agent say so rather than guess?
• Conflict rate: how often did reviewers find two sources giving different answers to the same question?
• Tool relevance: did the agent call tools that had nothing to do with the task?
• Long-session drift: do answers late in a session stay as accurate as those at the start?
• Permission breaches: any case of the agent surfacing data the user could not see should be treated as zero-tolerance.