What Agents Are Still Bad At

Some agent limitations shrink with each model generation. Others are structural, and no amount of capability removes them. Telling the two apart is the difference between planning around a limitation and waiting for it to go away.

The structural ones

These follow from how agents work, not from how good the model is.

For a vendor-side perspective, Monitask also has a page on productivity vs efficiency.

Long chains of steps

Error rates compound. An agent that succeeds 95% of the time per step succeeds roughly 60% of the time across ten steps, and 36% across twenty.

This is arithmetic, and it does not improve much when per-step reliability rises — 99% per step is still only 82% across twenty.

What follows: short chains, checkpoints, and human review at the points where a wrong turn is expensive. Long autonomous sequences are where demonstrations succeed and deployments fail. See where agent projects fail.

Knowing when it is wrong

An agent that took a wrong turn usually proceeds confidently. It has no independent way to check its conclusion against reality unless you gave it one.

Verification has to be external — a test, a second source, a rule, a person. Asking the agent whether it is sure produces an answer of very limited value.

Knowing what it does not know

Missing context does not announce itself. The agent works with what it has, and it cannot tell that the crucial document was not in the folder it searched.

This is why data quality dominates outcomes more than model choice.

Finite context

Everything the agent considers has to fit in its working view. Long tasks accumulate history, and something must be dropped or summarised.

Summarising loses things, and what it loses is not chosen by relevance to the problem you actually have.

Context windows have grown enormously and the constraint is structural rather than a fixed number.

Acting on untrusted input

An agent reads content and then acts. If that content contains instructions, the agent may follow them, because it has no reliable way to separate data from instruction.

This is a design property, not a bug being fixed. See prompt injection.

Cost that scales with attempts

A loop that struggles makes more calls. Difficult tasks cost disproportionately more, and a stuck agent can consume a great deal before anyone notices. See what agents cost to run.

The ones that are genuinely improving

Worth separating, because planning around them differently is rational.

Tool use reliability. Choosing the right tool with the right arguments and interpreting results. This improved substantially and is the reason agents became viable at all.

Instruction following over complex, conditional requirements.

Handling ambiguity in a request without either guessing wildly or refusing.

Multi-step planning within a bounded task.

Cost per token, which has fallen consistently — though total spend rises because usage rises faster.

Where agents are bad in practice

Different from the structural list: things that fail for practical reasons.

Anything requiring information the agent cannot reach. The most common disappointment, and it is an integration problem wearing a capability costume. See integration is the hard part.

Work with no clear definition of done. "Improve this" gives the agent no stopping condition.

Tasks where the right answer depends on unwritten context — how your organisation actually works, what the client meant, which rule is being applied loosely this quarter.

Judgement calls with real consequences. Not because the agent cannot produce an answer, but because accountability for the answer has nowhere to sit.

Anything requiring a stable long-term memory of your specific situation, unless you built that.

Physical world tasks, obviously, and worth stating because "agent" implies more agency than software has.

And work where being wrong occasionally is unacceptable. An agent that is right 97% of the time is excellent and is not suitable for something where the 3% is catastrophic and undetectable.

The multi-agent question

Several specialised agents coordinating is heavily discussed and much less often working in production.

Why it is harder than it sounds: every handoff is a place to lose context, error compounding applies across agents as well as steps, and debugging a failure across several agents is substantially harder than in one.

It is not useless — separation of concerns is real. It is currently more architecture diagram than deployment. For broader independent background, see NIST AI Risk Management Framework.

Treat claims about multi-agent systems with the same scepticism as any other capability claim, and ask what is running in production.

What this means for planning

Assume short chains. Design the task so the agent does a few steps, not thirty.

Build verification in. External checks, not self-assessment.

Put the human where the mistake is expensive, not everywhere. See human oversight.

Fix the data before blaming the model. Most disappointments are reach and quality problems.

Define done. Explicitly, in a way the agent can evaluate.

And budget for the failures. A task that succeeds 80% of the time still needs a path for the other 20%, and that path is part of the design rather than an exception.

The honest note on this article

This list will date. Some of it will be wrong within a year, and the structural section should age much better than the practical one.

The compounding-error arithmetic will not change. Nor will the fact that an agent acting on content it reads is exposed to what that content says.

Check the date at the top. In this subject, an undated list of limitations is worse than none.

The short version

Error compounding is arithmetic — 95% per step is 60% across ten. It dictates how long a chain can be.

Agents cannot reliably tell when they are wrong. Verification has to be external.

Missing context does not announce itself, which is why data quality beats model choice.

Acting on untrusted input is a design property, not a bug awaiting a fix.

And most practical disappointments are integration and data, not capability.