Review update · 17 October 2026. Qualified the reliability claims, made the probability assumptions explicit and added evaluation sources. The original publication date is retained.
An agent demonstration can show a system browsing, writing code and correcting errors in one convincing run. It does not, on its own, establish how often that system succeeds, how much intervention it needs, or what a failure costs. Those are the questions that matter when someone else has to operate it.
Production tells a different story.
This is not a dismissal of agents as a category. It is an attempt to describe where they actually work today, what causes them to fail, and what you need in place before deploying them in anything that matters.
What the Demos Optimise For
When assessing a demonstration, ask whether the tasks were selected in advance, how many attempts were made, what tools were permitted and whether unsuccessful runs were included. These are questions to ask about evidence, not allegations about every vendor demonstration.
A successful example demonstrates that a result is possible. A representative evaluation estimates how dependable it is under stated conditions. Confusing those two claims is where a useful demo becomes a poor deployment plan.
Multi-step systems can propagate mistakes from one action into later actions. But task length alone does not determine success: verification, retries, tool feedback and human intervention can change the outcome. Measure the complete system rather than infer its reliability from a model leaderboard.
Where Agents Actually Work
Our recommendation is to begin with tasks whose outcomes you can assess and whose failure you can contain. Anthropic’s engineering guidance also distinguishes predictable workflows from more flexible agents and recommends starting with the simplest adequate solution.
Bounded, well-defined tasks. Extracting date–entity pairs into a schema gives you something concrete to test. It still needs checks for missed entities, wrong dates and unsupported values: valid JSON is not evidence of correct extraction.
Reversible actions with limited consequences. Read-only access reduces the damage an agent can do directly. It does not make its conclusions more accurate, and a read-only tool can still expose information to an inappropriate destination. Keep access and data handling within the task’s needs.
Longer tasks need intermediate checks. In an illustrative calculation, independent steps that each succeed with probability 0.95 produce 0.95³ ≈ 85.7% success over three steps and 0.95¹⁰ ≈ 59.9% over ten, if every step must succeed. These are mathematical assumptions, not measured agent accuracy. Real errors can be correlated, and recovery can change the result.
The Reliability Problem
Reliability is one deployment constraint alongside capability, latency, cost, privacy and operational fit. Which constraint dominates depends on the job and the consequences of getting it wrong.
At a hypothetical 10,000 tasks a day, a measured 5% task-failure rate would mean 500 failures to handle. A deployment plan must explain whether those failures are caught, how they are escalated and whether the remaining workload still saves effort.
A plausible but incorrect result can escape a superficial review. Conventional software can also fail silently; this is not unique to agents. For either system, test actual outcomes and downstream effects rather than relying on a confident success message.
Untrusted content must stay untrusted. A page, email or document can contain instructions unrelated to the user’s task. Our recommendation is to constrain tools and permissions, check sensitive destinations and require approval for consequential actions rather than treat retrieved instructions as authority.
What You Need Before Deploying
If the task justifies the engineering cost, agents can be made production-worthy. The minimum viable set of infrastructure:
- Structured observability. Record tool actions and outcomes with enough context to diagnose failures, while redacting secrets and personal data and setting access and retention limits. Without it you cannot diagnose failures or improve the system.
- Interrupt and override mechanisms. Human-in-the-loop is not an admission of defeat. For high-stakes or irreversible actions, requiring human approval is sound engineering.
- Idempotent, reversible tool design. Where actions cannot be made reversible, they should at minimum be clearly flagged and require explicit confirmation. Never give an agent capabilities it does not need for the task.
- Failure budget and escalation paths. Decide in advance what happens when the agent is uncertain or reaches an unexpected state. Without a defined stopping rule, an agent may continue despite uncertainty. Test that it actually stops or escalates when required.
The Honest Assessment
Agents are useful. They are not magic. The current round of products and frameworks is moving fast and improving, but a demonstration is insufficient evidence for a particular production workload.
A practical release gate is a representative task set, explicit pass criteria and an escalation path. Anthropic’s agent-evaluation guidance discusses evaluating both the resulting state and the steps an agent took. We recommend tracking success, intervention, latency and cost together, then repeating the evaluation after model or tool changes.
That is less exciting than the demos. It is also how useful systems get built.
Related reading: RAG in Production: Lessons from Real Deployments.