What AI Agents Can And Cannot Do

An AI agent can look up a customer's order, verify a shipping complaint against a database, and issue a refund in one uninterrupted sequence, each step checked against a real tool result. The same architecture, given a vaguer instruction like "handle this customer's complaint appropriately," can misjudge the right action with no internal signal that anything went wrong. Both outcomes trace back to the same design: a language model wrapped in a loop that reads, decides, calls a tool, and reads again. This piece maps where that loop is genuinely reliable, where it predictably breaks, and why the difference has almost nothing to do with how "smart" the underlying model is.

What an "agent" actually is, mechanically

An AI agent is not a separate kind of model. It is a language model, the same kind of system used for chat, embedded inside a control loop that gives it the ability to observe a state, choose an action, execute that action through a tool, and observe the result before choosing again. The model itself never touches a database or an API directly. It generates text describing which function to call and with what parameters; a separate execution layer, written by a developer, actually makes the call and returns the result as text the model reads back into its context window.

This pattern was formalized under the name ReAct (short for Reasoning and Acting) in a 2022 Google Research paper, which showed that interleaving explicit reasoning steps with tool calls, rather than asking a model to reason through an entire task in one unaided pass, produced more reliable and more inspectable behavior on multi-step tasks (Yao et al., 2022). Most production agent frameworks built on Claude or GPT models today still follow a close variant of this loop: observe, reason, act, observe again.

Anthropic's own published engineering guidance draws a sharper line than most marketing material does, distinguishing a workflow, where a developer's code defines every branch and the model fills in individual steps, from an agent, where the model itself decides the sequence of steps and when the task is complete (Anthropic, "Building Effective Agents," 2024). The guidance recommends starting with the simplest workflow that can pass evaluation and only reaching for full agent autonomy when the task genuinely cannot be hardcoded in advance, precisely because autonomy trades predictability for flexibility, and that trade only pays off when flexibility is actually needed.

That distinction matters for anyone evaluating an "agentic" product: a lot of what gets marketed as an autonomous agent is closer to a fixed workflow with a language model filling in a few parameters, which is a meaningfully more reliable and more testable system than one where the model is choosing its own multi-step plan at runtime.

The capability vs. limitation matrix

Not every task category responds the same way to agent automation. The table below groups task types by what actually determines reliability: whether each step produces a result the system can check.

Task category	Example	Why it works or fails	Typical reliability
Single structured tool call	Look up a stock price via an API, convert currency	One input, one deterministic output, directly verifiable	High
Short chained tool use with verification	Check order status, confirm a policy flag, issue a refund	Each step's output is a concrete, checkable value that feeds the next	High
Long multi-step chains, no checkpoints	Research a topic across 15+ sources and synthesize a report unattended	Small per-step error rates compound across many sequential decisions	Medium to low
Ambiguous, open-ended goals	"Handle this customer's complaint appropriately"	No single correct output exists, so there's nothing to verify against	Low
Tasks requiring persistent memory across sessions	Remembering a user's stated preference from a conversation three weeks ago	No memory exists by default unless a developer built external storage and retrieval	Low, without added scaffolding
Physical-world grounding	Judging whether a shipped item actually arrived damaged from a text description alone	The model has no sensory access to the real-world state it's reasoning about	Low

Reliability tracks whether a step produces a checkable result, not how advanced the underlying model is.

Every row that lands in the "high" tier shares a structural property: a tool returns a value that the system, not just the model's own unverified reasoning, can confirm against the real state of the world. Every row that lands in the "low" tier lacks that property, either because there's no single correct answer, no persistent record to check against, or no way for a text-based system to observe physical reality directly.

What agents genuinely do well

Agents are reliable on tasks with a clear success condition and a tool result at each step that can be checked, rather than trusted on faith. Looking up a fact through a search API, running a calculation, filling a form with data retrieved from a database, or executing an API call sequence where each output cleanly feeds the next input all fall into this category. Because the model isn't reasoning through the entire problem unaided in a single response, it's checking its work against real tool outputs at every step, well-scoped agent tasks tend to outperform asking the same model to solve the whole multi-step problem in one shot.

This is also where the industry's actual benchmarking effort has concentrated. τ-bench, a benchmark developed by Sierra to evaluate agents on realistic multi-turn customer-service tasks in airline and retail domains, scores success strictly by whether the agent's actions leave the underlying database in the correct final state, not by whether its response merely sounds right (Yao et al., 2024). That evaluation design reflects the same underlying truth as the capability matrix above: agent tasks are gradeable, and therefore genuinely automatable, exactly to the degree that they resolve to a checkable end state.

Anthropic's own guidance on building agents recommends starting with the simplest possible workflow, a single well-defined tool call, and only adding autonomy and multi-step planning once that simple version is proven reliable, because compounding errors across many autonomous steps is the dominant failure mode observed in practice (Anthropic, "Building Effective Agents," 2024).

The practical implication is that "agent capability" isn't a single number that goes up as models get smarter. It's a property of the task's structure. A frontier model given an ambiguous, unverifiable goal will still struggle in ways that a much smaller model given a narrow, checkable goal will not.

Why verification, not raw intelligence, is the deciding factor

A model that can check its own output against a concrete tool result, an API response, a database query, a test suite passing, catches its own mistakes before they compound. A model reasoning through an ambiguous multi-step plan with no external check has nothing to correct against except its own prior output, which is precisely the condition under which small errors propagate uninterrupted.

Where agents reliably break down

Long-horizon planning without drift is the clearest documented weak point. METR, an organization that benchmarks frontier AI models on realistic software and research tasks, measures agent capability by the length of task (in estimated human-expert time) that a model can complete autonomously with 50% reliability, and found this metric has grown exponentially over the past six years, with the doubling period compressing from roughly seven months to roughly four months during 2024 and 2025 (METR, "Measuring AI Ability to Complete Long Tasks," March 2025). The trend line itself is real progress, but the framing matters just as much as the number: even the frontier of agent capability is still described in terms of a reliability ceiling that degrades as task length grows, not a threshold that's simply been crossed.

Ambiguous goals are a separate failure mode from long-horizon drift, and arguably a harder one to engineer around. When a task has multiple plausible correct interpretations, refund, discount, apology email, or escalation, are all reasonable responses to "handle this complaint", an agent has no mechanism to detect that it picked the wrong one, because there was never a single right answer for it to check its output against in the first place. This isn't a knowledge gap the model can be trained out of. It's a structural absence of ground truth.

Persistent memory — the ability to retain and recall information across separate sessions without a developer explicitly engineering that storage. Most agents do not have this by default; each new session typically starts from a blank context unless a memory or retrieval system has been built on top of the base model specifically to store and reinject relevant history. An agent that seemed to "remember" a user's preference from last week is, in nearly every production system today, actually reading that preference back out of an external database a developer built for exactly that purpose, not recalling it the way a person would.

Physical-world grounding is the limitation least addressed by better prompting or bigger models. A text-based or even multimodal agent reasoning about whether a package "actually" arrived damaged, whether a sensor reading reflects a real fault versus noise, or whether a robot's gripper actually secured an object, is working from whatever description or image was fed into its context, not from direct physical interaction with the world. Where robotics and multimodal perception systems do close this gap, they do so by adding entirely separate sensing and control infrastructure, not by making the underlying language model more capable at text prediction.

A concrete example of the capability gap

Consider a customer-support agent connected to a refund API and ask it to "refund the last order if the customer complained about shipping." It can reliably parse the request, look up the order, check a shipping-complaint flag, and call the refund function, a narrow task where every step produces a result the system can verify before moving on. Reliability here comes from structure, not from the model being unusually capable at this specific request.

Now ask the same agent, with the same underlying model and the same tools, to "handle this customer's complaint appropriately." Reliability drops sharply, and not because the model got weaker between the two requests. The second instruction has several plausible resolutions and no single checkable outcome, so there's nothing for the agent, or a developer reviewing its behavior afterward, to verify the choice against. The gap between these two prompts is the single clearest illustration of where agent capability actually lives: in task structure, not model capability.

Why adding more tools doesn't fix long-horizon reliability

A common assumption is that giving an agent more tools, broader API access, a calculator, a file system, a web browser, makes it more capable of handling complex, ambiguous work. Tools expand what an agent can technically reach, but they add no judgment about which tool to use, when to stop, or when a plan should be abandoned partway through and re-planned. Anthropic's guidance explicitly frames tool design as something requiring the same rigor as any other software interface: clear, unambiguous parameter definitions and specific error messages, because a model handed a vague failure response tends to retry with equally malformed parameters rather than correcting course, whereas a specific error lets it self-correct on the next attempt (Anthropic, "Building Effective Agents," 2024).

In practice, expanding a tool inventory without adding proportional verification steps tends to increase the number of places a compounding error can enter a chain undetected, since every additional call is another point where a misread instruction or misparsed result can slip past unnoticed. This is why the tau-bench evaluation approach, and Anthropic's own internal recommendation, both converge on the same design principle from different directions: measure and build for checkable outcomes at each step, not for raw tool count or model size.

The compounding-error problem in numbers, conceptually

If a single tool call succeeds correctly 95% of the time in isolation, and five such calls are chained with no verification between them, the chance that all five succeed cleanly falls below 80%, purely from independent per-step error accumulating (a general property of any multi-step process with per-step failure rates, not a claim about a specific model or benchmark). Longer, unverified chains make this arithmetic worse, which is exactly the pattern METR's task-length reliability curve documents at the frontier.

Does adding more agents help, or just add more places to fail?

A separate design question from "more tools" is "more agents": splitting a task across multiple agent instances instead of scaling up a single one. Anthropic's own engineering team published a detailed account of building a multi-agent research system, an orchestrator model that spawns several subagent models to search different angles of a question in parallel, and reported that the multi-agent version outperformed a single-agent baseline by roughly 90% on internal research-evaluation tasks, largely because parallel subagents could each hold a narrower context window and explore independently before the orchestrator synthesized their results (Anthropic, "How We Built Our Multi-Agent Research System," June 2025).

That same writeup is unusually candid about the cost side of that gain. Multi-agent systems, in Anthropic's own accounting, use roughly 15 times more tokens than a single chat interaction, which makes the architecture worth the expense only for tasks valuable enough to justify it, open-ended research and broad parallel search being the clearest cases, not for tasks a single well-scoped agent already handles reliably (Anthropic, June 2025). The team also flagged coordination itself as a new failure surface: subagents can duplicate each other's work, miscommunicate through the imprecise natural-language instructions the orchestrator hands them, or spawn far more parallel calls than a task actually needs, all failure modes that simply don't exist in a single-agent loop.

The pattern that emerges is consistent with the capability matrix earlier in this piece: splitting work across agents doesn't remove the verification problem, it relocates it. A multi-agent system still needs the orchestrator's synthesis step to be checkable against something real, and it adds a coordination layer that itself needs monitoring. Anthropic's engineering post describes building dedicated tracing and evaluation tooling specifically because standard debugging approaches don't surface where a multi-agent chain went wrong, an observability cost that scales with the number of agents in play, not just with task complexity.

When multi-agent orchestration is worth the added cost

Parallel multi-agent search earns its overhead on breadth-first tasks, ones where a problem can be genuinely decomposed into independent sub-questions with no shared dependency between them, such as researching several unrelated aspects of a topic at once. It's a poor fit for tasks with tight sequential dependencies, where step three can't start until step two's specific output is known, since that structure gives the orchestrator nothing to parallelize and just adds coordination overhead on top of a chain that was already sequential.

Common confusions about agent autonomy

A frequent misconception treats "agent" and "smarter model" as roughly synonymous, assuming that swapping in a more capable underlying LLM meaningfully raises the ceiling on ambiguous, long-horizon tasks. What actually raises the ceiling on narrow, checkable tasks is often not a smarter model at all but better task decomposition: breaking a long chain into shorter, independently verifiable segments with a checkpoint between each.

A second common confusion conflates a model's own stated confidence with the presence of a verification mechanism. Nothing about a fluent, confident-sounding tool call means the underlying reasoning was checked against anything real, which is a related but distinct failure mode from the compounding-error problem covered above (see the SciHub101 explainer on why AI hallucinates facts for the mechanism behind confident, ungrounded output specifically).

A third confusion treats "the agent decided to do X" and "the agent was able to do X" as the same question, when they're answered by two entirely separate systems. What an agent's reasoning decides to attempt and what its execution layer, governed by whatever API permissions and scopes a developer configured in advance, is actually authorized to do are independent layers. For the mechanics of how that permission layer works in real business integrations, see how AI agents connect to business apps, which covers OAuth scopes, webhooks, and the execution runtime that sits underneath any agent's apparent autonomy.

The takeaway

AI agents are reliable exactly where a task resolves into short, checkable steps: structured API calls, database lookups, and tool chains where each result can be verified before the next action fires. They become unreliable exactly where marketing language tends to promise the most, long-horizon plans without checkpoints, goals with no single correct answer, and anything that requires grounding in physical reality the model can't directly observe. The strongest current agent deployments treat this as an engineering constraint rather than a temporary gap to be closed by a bigger model, pairing autonomy with human confirmation at any consequential or hard-to-reverse step and decomposing long tasks into segments short enough that compounding errors stay rare.

---

Read next:

• How AI agents connect to business apps
• Why AI hallucinates facts
• How AI models learn from feedback

FAQ

Q: What is the ReAct framework in AI agents?

ReAct, short for Reasoning and Acting, is a pattern formalized in a 2022 Google Research paper where a model alternates between reasoning about its next step and calling an external tool, using the tool's result to inform the next reasoning step, repeated in a loop until the task completes (Yao et al., 2022).

Q: Do AI agents remember previous conversations?

Not by default. Most agents start each session without memory of prior interactions unless a developer has built a separate memory or retrieval system that stores relevant history and reinjects it into the model's context window at the start of a new session.

Q: Why do agents fail more often on longer tasks?

Errors compound across steps. If an agent misreads an early step, that mistake carries into every subsequent action, and even a high per-step success rate compounds into meaningfully lower end-to-end reliability across a long, unverified chain, a pattern METR's task-length benchmarking documents even at the frontier of current models.

Q: What tasks are AI agents genuinely good at right now?

Tasks with a clear, checkable success condition at each step: structured API lookups, form filling from retrieved data, and short multi-step tool chains where each output can be verified before the next call fires. Reliability tracks task structure more than it tracks how advanced the underlying model is.

Q: Are AI agents safe to use for irreversible actions, like sending money or deleting data?

Best practice, as recommended in Anthropic's published agent-building guidance, is to require human confirmation before any agent executes a destructive or hard-to-reverse action, since agents can misinterpret ambiguous instructions with no automatic internal mechanism to flag uncertainty before acting.

Q: Can adding more tools make an AI agent more reliable on complex tasks?

Not on its own. More tools expand what an agent can technically reach, but they add no judgment about which tool to use or when to stop, and without proportional verification steps, more tools tend to create more places for an undetected error to enter a chain.

Q: Does using multiple AI agents together work better than one agent?

For breadth-first tasks that split cleanly into independent sub-questions, yes: Anthropic reported roughly a 90% improvement over a single-agent baseline on internal research evaluations using an orchestrator-subagent architecture. That gain came at roughly 15 times the token cost of a single chat interaction, and multi-agent systems add their own failure modes, like duplicated work and miscommunication between agents, so the approach only pays off on tasks valuable and parallelizable enough to justify it (Anthropic, "How We Built Our Multi-Agent Research System," June 2025).

Q: Why do multi-agent AI systems cost so much more to run?

Each subagent maintains its own context window and makes its own model calls, and an orchestrator has to synthesize all of their outputs afterward, so the total token consumption scales with the number of agents involved rather than staying flat. Anthropic's own published engineering account puts this at approximately 15 times the token usage of a single-agent interaction for its research-agent system (Anthropic, June 2025).