What AI agents can't do yet, and how to design around it
There's a version of the AI agent pitch that implies you can describe a goal in plain language and the agent will figure out the rest: plan the steps, use the right tools, recover from errors, and get you a correct result. That version is true for a narrowing set of well-scoped tasks and not true for a much larger set of tasks that still get pitched that way. Knowing where the line currently sits is the difference between an agent that's genuinely useful and one that's an expensive, unreliable version of a task a script could do better.
Where agents are genuinely reliable
Agents do well on tasks with a clear goal, a bounded set of tools, and a way to verify success within the same session: look up an order and answer a question about it, draft a document from a template and known inputs, classify and route a request based on its content. The common thread is that each step is checkable, and a wrong step doesn't compound silently into a wrong final answer three steps later.
It's worth noticing what these reliable cases have in common structurally: they're short, they touch a small number of tools, and there's usually an objective way to check whether the output is right. As any one of those three properties weakens, longer chains, more tools, fuzzier success criteria, reliability drops off faster than intuition suggests. It's not a gentle slope, it's closer to a cliff, and a lot of failed agent projects are the result of pushing one property past its limit while assuming the others would compensate.
Where they still struggle
- Long-horizon tasks with many steps: small errors early in a chain compound, and the agent often can't tell it went wrong until much later, if at all.
- Ambiguous success criteria: if a human would disagree about whether the task was done well, an agent's self-assessment is unreliable too.
- Tasks needing real-world judgment under incomplete information: an agent will proceed confidently on a guess where a person would pause and ask.
- Recovery from novel failures: agents handle the errors they've been designed around, and improvise poorly outside that set.
The compounding error problem, concretely
It's worth walking through why long chains fail more than people expect. If each step in a five-step task is ninety-five percent reliable on its own, which sounds close to reliable, the chance all five succeed together is under seventy-eight percent. Add a sixth and seventh step and it drops further. This is pure arithmetic, not a knock on any particular model, and it's the single biggest reason agent demos with three steps look far more trustworthy than agent systems with fifteen. The fix isn't a smarter model, it's decomposing the task into shorter chains with verification checkpoints in between, so an error at step three gets caught at step three instead of silently propagating to step twelve.
Design around the gap instead of hoping it closes
The practical answer isn't to wait for a more capable model, it's to design the system so the agent operates inside a scope where it's genuinely reliable, and hands off cleanly at the edge of that scope. That means narrow, well-defined tool sets rather than open-ended access, checkpoints where a human confirms before an irreversible action, and a default of asking rather than guessing when confidence is low. An agent that knows what it doesn't know is more useful in production than one that's marginally smarter but doesn't.
Breaking a long task into shorter, independently verifiable stages, each with its own clear success check, is the single most reliable way to get agent-shaped work done in production today. It's less impressive in a demo, because it looks less like magic and more like a well-structured pipeline with a model doing the parts that need judgment. That's exactly the point. The systems that actually run in production for months without babysitting tend to look boring on a whiteboard and remarkable in the results they produce quietly, week after week.
The best agents in production today aren't the most autonomous ones. They're the ones with the clearest sense of when to stop and ask.
Scope the task, not just the model
When a client asks for 'an agent that handles X,' the useful next question is what percentage of X actually needs full autonomy versus what percentage just needs assistance: drafting, flagging, or summarizing for a human to finish. Scoping the autonomy level honestly, task by task, produces systems that ship and hold up. Scoping for full autonomy everywhere produces demos that don't survive the first genuinely weird input, and a client who now trusts AI agents less than before the project started, which is the worst outcome of all, worse than never having tried.