What AI Agents Cannot Do Yet: An Honest Take (2026)

AI agent limitations are easiest to manage when you name them before you delegate, not after something breaks. Four failure classes cover the incidents an owner needs to test for: irreversible external actions, work whose correctness cannot be checked without redoing it, context that lives only in someone’s head, and judgement calls where being wrong costs more than being slow. Naming that boundary is what makes delegation safe.

Underneath the four classes sit the technical limits buyers usually ask about. Agents still state wrong facts and pass wrong arguments to tools with full confidence. They lose track of early details in long chains, give different answers to the same input, add cost and latency with every step, and can be steered by instructions hidden in the content they read. None of them can carry accountability for a compliance decision. Each of these shows up in practice as one of the four classes below.

Why naming AI agent limitations is what makes delegation safe

This page diagnoses. It does not prescribe a scoring rubric, an approval setup or a correction routine; those have their own posts, linked where they belong. The job here is narrower: give a P&L owner a short list of failure classes, each testable with a real business scenario, so the decision about what to hand over is made on purpose.

Limits belong at the front, not in a closing hedge paragraph, because they decide the shape of the work you can delegate.

One definition keeps the rest honest. A large language model is the engine underneath both chatbots and agents. A chatbot answers a question and stops. An agent wraps the model in a loop: it plans a sequence of steps, keeps some memory between them, calls tools on your behalf and produces a result that lands in a real system: a sent email, an updated record, a deployed change. Every advantage of the second kind comes from that reach into real systems, and so does every failure class below.

Start with up to $100 in free credits, no card →

Irreversible external actions

The scenario. An operations lead asks for a cleanup of duplicate contacts in the CRM. The agent merges 400 records, overwriting owner fields and deal stages on half of them, and the audit trail shows a merge, not the values that existed before. The same shape appears elsewhere: an email sent to a client list, a payment released to a vendor, a deploy pushed to production on a Friday afternoon. The action was inside the agent’s permissions. The pause was missing.

The test. Ask of any step: can this be undone inside the same system in under a minute, by someone who did not do it? Drafting, reading, reconciling and summarising all pass. Sending, paying, merging, deleting and deploying fail, and a failed test means the step needs an approval gate, not a better prompt.

What a human still holds. The decision to let the action leave the building. Not the drafting, not the lookup, the release. This is a design choice a vendor either makes visibly or does not make at all. Viktor’s security page states it in one line: “Money moves, code pushes, and customer emails wait for your explicit approval in Slack.” Admins can put further high-risk tools behind the same gate. The mechanics of that gate, and why ask-first should be the default, are covered in Don’t let your AI agent act without asking.

Tasks whose correctness cannot be checked without redoing the work

The scenario. A finance manager hands over the month-end reconciliation between Stripe payouts and the bank feed. The agent returns a clean sheet with a matched total. The manager cannot tell whether the match is right without rebuilding the reconciliation line by line, which is the work she was trying to hand off. The same trap appears in an analysis with no sources or a migration checked only by row counts.

Why multi-step chains make this worse. A single prompt produces one output you can read. A chain of twelve steps produces an output shaped by eleven earlier decisions you never saw: which records were filtered out, which duplicate was treated as the original, which exchange rate was applied. An error in step three is invisible by step twelve because every later step treated it as true. The arithmetic is unforgiving: if each step is right 95% of the time, a 10-step chain is fully right only about 60% of the time (0.95 to the tenth power), and at 99% per step about 90%. Those inputs are illustrative, but the published evidence points the same way: on Sierra’s τ-bench, an agent that succeeded on more than 60% of tasks in one attempt fell below 25% when the same task had to succeed eight times in a row.

The test. Can a reviewer verify the result in a fraction of the time it took to produce? A draft email passes: reading it is faster than writing it. A reconciliation with no working shown fails.

What a human still holds. The definition of what correct means, and the shape of the evidence that proves it: sources in the analysis, a line-level log in the reconciliation, a before-and-after sample in the migration. If the work cannot be delivered with that evidence attached, it has not been delegated. It has been hidden.

Context that lives only in someone’s head

The scenario. An agency account manager asks for a renewal proposal for a client. The agent pulls last year’s scope and rates and drafts a clean document. It does not know that the client’s CFO said on a call in March that any increase above five percent goes to procurement review, that the founder verbally agreed to hold rates for a year, or that the client dislikes the word retainer. None of that is written anywhere. The proposal is technically correct and commercially wrong.

Why memory does not fix it. Agent memory stores what was written to it, not a commitment made in a hallway. The problem is not window size; the context was never captured anywhere the agent can read.

The test. Before delegating, ask the person who normally does the task: what do you know about this that is not written down? If the answer is long, the task is not ready. If the answer fits in ten minutes of typing, type it, and the task becomes delegable.

What a human still holds. The relationship and its unrecorded history, until that history is recorded. Owners who want to delegate more spend their effort here: moving tribal knowledge into documents, CRM notes and written preferences that a tool can reach.

Judgement calls where being wrong costs more than being slow

The scenario. A support request arrives from a long-standing customer whose last three tickets were about the same bug, asking for a refund in a tone that reads as resigned rather than angry. The right move is a call from someone senior, not a policy-compliant refund reply. A refund processed in two minutes is fast and wrong. An agent optimises for finishing the task; the value here was in noticing that it should not be finished the usual way.

The same class covers requests that ought to be refused (a bulk follow-up to every quiet customer, including the two in an open escalation), pricing exceptions that set a precedent, and any decision whose blast radius includes people who did not ask for it.

The test. If this is done wrong, is the cost mostly time, meaning redo it, or mostly trust, meaning a customer, a regulator or a team member? Time costs are delegable. Trust costs are held.

What a human still holds. The call itself, and the standing to answer for it. Work that needs someone accountable should be done by someone who can be.

The cost, latency and quota limit

Two further limits cut across all four classes, and cost is the first. Each step is another model call, and each call usually re-sends the growing context, so token use and wall-clock time grow faster than the step count, and every retry repeats the bill. Anthropic’s pricing page, checked October 2026, lists Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens. Run illustrative numbers: a 20-step chain that re-sends a 30,000-token context at every step reads 600,000 input tokens, about $1.20 before output and retries, against 30,000 tokens for a single prompt. Latency stacks the same way, one model call after another. Platforms also cap the context window (1M tokens on current Claude models, per Anthropic’s models overview), session length and tools per agent; past the window, early instructions fall out of view. Prices and limits change often, so size a workflow against the vendor’s current documentation.

The security limit: agents read instructions they should not obey

Giving an agent tool access adds three risks that cut across the classes. Prompt injection: untrusted text in an email, a web page or a ticket is read as a command. Data exfiltration: a hijacked step copies records to a destination the owner never approved. Unauthorized tool execution: an action with no approval gate turns a wrong step into a completed one. Models do not reliably tell content from instruction, so the defence is architectural. Grant the narrowest scopes, keep credentials out of the model’s view and gate every outbound action. Viktor’s security page describes a tool gateway that injects API keys at execution time so the model never sees them.

The counterargument: can guardrails close these gaps?

The steel-man is strong. Scoped tools contain class one, step budgets limit how far an early error spreads in class two, runbooks and memory shrink class three, and approval gates catch much of class four. Two things stay true anyway. First, every control has a cost. A gate on every outbound email means someone approves every outbound email, and approval fatigue follows: the reviewer clicks approve without reading, and the gate becomes decoration. Narrow scopes and step budgets mean more tasks handed back half-done.

Second, controls narrow the blast radius; they do not move the boundary. A gated deploy still needs a human who understands it, and a runbook still cannot contain the commitment nobody wrote down. Guardrails decide how expensive a mistake is, not whether judgement is required. Choosing which actions can skip the gate without turning it into decoration is its own decision, and When to let your AI employee act without review works through it.

What this means when you delegate work

Match each class to a control, and price the control in.

A decision rule in three questions, asked of every task before it is handed over:

1. Irreversibility. Can the system undo the final step in a minute? If not, gate it.
2. Auditability. Can a reviewer check the result faster than redoing it? If not, require evidence or keep the task.
3. Blast radius. If it goes wrong, who is affected besides the person who asked? If the answer includes customers, money or production, a human holds the call.

Tasks that pass all three are the ones to delegate first: the daily pipeline summary, the weekly ad spend variance, the draft reply that a person still sends, the dashboard that refreshes itself. Tasks that fail one question get the matching control. Tasks that fail all three stay with people.

The vendor rubric is in Evaluating AI agents: a checklist. What to do on the day something comes back wrong, and how to make the correction stick, is in How to correct your AI employee when he gets something wrong.

Where this goes from here

The boundary moves. Better models, tooling and memory shift individual tasks from hold, to delegate with a control, to delegate. None removes a class. An irreversible action will still need someone willing to own it, and a judgement call about a person will still need a person.

What changes is how vendors design around the limits; the useful signal is whether a design makes the boundary visible or hides it behind the word autonomous. Viktor’s product page draws the line in two sentences: “A chatbot answers. An AI employee finishes.” He lives in Slack and Microsoft Teams and connects to 9,800+ tools, most through one-click OAuth. His pricing is usage-based credits per workspace with no per-seat fee, and a new workspace starts with up to $100 in free credits and no credit card. That is one vendor’s answer to the four classes: do the reversible, checkable, documented work unprompted, and ask before the rest. Pricing checked October 2026.

Start free with up to $100 in credits, no card required →

FAQ

Why do multi-step workflows fail more often than single prompts?

Each step treats the previous step’s output as true, so an early error shapes everything after it while the final output looks finished, and per-step error rates compound. A single prompt exposes its one output; a chain hides its intermediate decisions unless the tooling logs them.

Which tasks should never be automated today?

Anything that fails all three tests at once: irreversible, unverifiable faster than redoing it, and reaching customers, money or production. Signing contracts, ungated payments, unreviewed bulk customer email and personnel decisions sit there.

What security risks come with giving an agent tool and API access?

Over-broad scopes, prompt injection that exposes credentials or exfiltrates data, and tool calls with no approval gate, as covered in the security section above. Security checklist for AI tool access lists what to check before you connect any tool.

What are the 7 types of AI agents?

The textbook taxonomy (Russell and Norvig) names five: simple reflex, model-based reflex, goal-based, utility-based and learning agents; lists of seven add hierarchical and multi-agent systems. No type removes the four failure classes, which depend on the task, not the design.

What is the 30% rule in AI?

It is a loose rule of thumb, not a standard: hand roughly the routine, low-risk 30% of a workflow to AI and keep people accountable for the judgement-heavy rest, though some sources flip the proportions. The number matters less than the principle, which maps onto the four classes: the share a person keeps is the irreversible, unverifiable, undocumented and high-stakes part.

How do you test a vendor against these four classes before rollout?

Give it one task from each class in a sandbox. Ask it to merge two test records and see whether it asks first. Ask for a reconciliation and see whether it shows its working. Hand it a task with a known unwritten constraint and see whether it asks for the context. Ask it to answer a test ticket that should be escalated and see what it does.