Why AI agent failures are context failures

When an agent produces the wrong thing, the cause is almost never that the model could not do the work. The model was working from an incomplete picture of what the work was. Something was missing: a constraint nobody wrote down, a convention everyone on the team knows, or a definition of done that said "fix the bug" and stopped there. The industry spent two years upgrading models. It has now largely concluded that the bottleneck was somewhere else.

What does the evidence say?

Redis's 2026 context engineering survey asked practitioners directly. It found 73% saying agents fail more often from broken context than from broken models. It also found 83% saying fresh context matters more for enterprise reliability than adding model parameters.

The more interesting part is the gap that comes next. What people believe has changed, but what they do has not. The same survey describes most organisations still assembling context by hand. They have no shared infrastructure, no freshness guarantees and little governance. People have spotted the problem, and most are still solving it with copy and paste.

Why does a capable model still get it wrong?

Because when something is unclear, it guesses instead of asking.

Give a vague task to a competent colleague and you get a question, or at worst a guess they tell you about. Give the same task to a model and you get a confident, complete-looking answer built on an assumption it never mentioned. The model is working as designed. It produces plausible continuations, and an ambiguous instruction has more than one.

So the failure looks different. A person who has not understood usually shows it. An agent that has not understood looks the same as one that has. That is why review by eye stops working at volume. Verification has to be built into the process instead of depending on someone paying close attention.

Is this the same as prompt engineering?

No. The difference is why the term changed.

Prompt engineering was about phrasing: the wording, the examples, the role instruction. It treats the model as the variable. Context engineering treats the information as the variable. It asks what this worker needs to know, where that comes from, how it stays current, and who decided it was allowed to see it.

That shift makes it an infrastructure problem instead of a writing problem. Phrasing cannot promise that information is fresh. A retrieval path can, and so can a scope. So can a definition of done written before the work. That definition can also be version-controlled, which a clever prompt in somebody's history cannot.

Where does the missing context usually live?

Four places, roughly in order of how often they cause trouble:

• In the acceptance criteria that were never written. The task says what to build but not how anyone will decide it worked.
• In the team's head. Conventions, the reason a thing is done the odd way, the module you do not touch before the migration lands.
• In an adjacent system the agent cannot see. The ticket points to a design that lives in another tool, and the agent cannot open it.
• In the run itself, then lost. Long sessions degrade. Information that was there early on stops being usable later, and a multi-step task slowly drifts away from what it was asked to do.

The first is the biggest and the easiest to fix. It is also the one nobody wants to do. Writing a checkable done-test is slower than writing a task title, and it is the most useful thing you can do.

Does more context fix it?

Not reliably. This is where teams overcorrect.

After a context failure, the instinct is to send more: the whole repository, the full history, every related document. It helps less than you would expect and sometimes hurts. Relevance falls as volume rises, and long sessions get worse over time instead of better. Adding volume does not solve the problem.

What works is narrower and duller. Send what the task needs, from a current source, with the acceptance criteria written so that something can check them. The goal is a picture that includes the part that decides the outcome. A bigger picture does not guarantee that.

What does this change about how you run agents?

It moves the effort earlier and it makes the effort visible.

DORA's 2025 report found AI adoption improving throughput while delivery stability declined. It also named what teams keep finding out on their own: time saved writing gets re-spent auditing. If the specification was thin, you pay for it in the audit. That usually comes at the worst moment, and it costs a person's attention.

So the useful measurements watch the start of the process, not the end. First-pass verification rate measures the quality of the specification. Cycle time split by phase shows whether time in the spec phase is investment or rework. Both are boring numbers. They make context debt visible before it turns into an incident.

Cognibl is built on the same idea. A task carries its definition of done, its scope and its evidence together. The context that decides whether the work counts travels with the work. It does not live in somebody's memory of the stand-up.