AI agents for the enterprise: reliability multiplies, it doesn't add

On 25 June 2025, Gartner published its prediction that more than 40% of agentic AI projects will be cancelled before the end of 2027, naming three causes: escalating costs, unclear business value, and inadequate risk controls. Notably, none of the three is a model-capability problem.

If you've tried putting an agent into production and watched it perform well in the demo then degrade against real data, this post explains the mechanism behind that — and how to compute it before committing budget.

Multiplication, not addition

A chatbot handles one turn: take a question, answer it. An agent handles a chain: read the request, call a tool, read the result, decide the next step, call another tool, and so on until done. That difference isn't about complexity — it's a difference in **how error accumulates**.

Suppose each step of the agent is reliable with probability p. The chance that an n-step chain is entirely correct, assuming the steps are independent, is p to the power of n:

• **p = 99%** — 5 steps: 95.1% · 10 steps: 90.4% · 20 steps: 81.8% · 30 steps: 74.0%
• **p = 95%** — 5 steps: 77.4% · 10 steps: 59.9% · 20 steps: 35.8% · 30 steps: 21.5%
• **p = 90%** — 5 steps: 59.0% · 10 steps: 34.9% · 20 steps: 12.2% · 30 steps: 4.2%
• **p = 80%** — 5 steps: 32.8% · 10 steps: 10.7% · 20 steps: 1.2%

Read the second line again. An agent that is **correct 95% of the time at every step** — a number that sounds fine — completes a 20-step process end-to-end in only 35.8% of runs. This is the mechanism behind a familiar pattern: the agent works in a three-step demo, then "gets worse for no reason" once it's wired into a real twenty-step process.

The research community has named the problem. Sierra's τ²-bench introduces a `pass^k` metric — "all k attempts succeeded" — to distinguish it from the familiar `pass@k` ("at least one of k attempts succeeded"). For an end user, `pass@k` is close to meaningless: customers don't re-run a process eight times and keep the best result.

One technical caveat worth stating: the table above assumes the steps are **independent**. In practice failures correlate — the same ambiguity in a prompt tends to break the same step across many runs. That means empirical numbers can differ from the theoretical ones in either direction, which is exactly why you have to **measure on your own task** rather than infer from a model's benchmark score.

Why the chatbot shipped and the agent didn't

The second difference matters more than the multiplication, and gets discussed less: **an error is not the same kind of thing**.

When a chatbot is wrong, it produces a wrong answer. The user reads it, sees it's off, asks again. The damage stays inside the conversation.

When an agent is wrong, it **has already taken an action**. It emailed the customer, updated a record in the ERP, issued the refund, deleted the file. The error has left the conversation and entered your data and the real world. And because the agent chooses its next step from the previous result, one wrong action at step 3 shapes every remaining step — in a way that still looks coherent from the inside.

That's why the right question when designing an agent isn't "is the model smart enough" but **"if this tool is invoked wrongly at the worst possible moment, what is the maximum damage"**.

Three walls pilots don't see coming

• **Cost scales with steps, not with requests.** Every agent step is a model call, and every call has to carry the whole accumulated context. Cost therefore grows closer to quadratically in the number of steps than linearly. With a generation of models that have adaptive reasoning on by default, price per million tokens is no longer sufficient for forecasting — what you need to measure is tokens actually consumed across a complete trajectory.
• **Latency adds up and can't be hidden.** A 2-second chatbot is fine. A 12-step agent at 2 seconds per step is 24 seconds of the user watching a screen. Streaming makes the wait feel better but doesn't change the total, and for batch-run internal processes latency becomes a throughput ceiling.
• **Grading on final-answer accuracy measures the wrong thing.** An agent can answer correctly because two wrong steps cancelled out — and you won't know until the data shifts slightly and they stop cancelling. You need **trajectory-level** measurement: the sequence of tool calls, the arguments passed, the intermediate results. This is the same class of work as evaluating retrieval quality in a RAG pipeline, only harder because the state space is much larger.

Security: when prompt injection becomes privilege escalation

In the 2025 edition of the OWASP Top 10 for LLM Applications, prompt injection holds LLM01 — first place, for the second consecutive edition. LLM03 is *Excessive Agency*, and it is the most substantially expanded entry versus the previous edition. That pairing isn't a coincidence: the two risks multiply each other.

Against a chatbot, a successful injection produces an unwanted answer. Against an agent with tool access, a successful injection lets the attacker **borrow the agent's permissions**. If the agent can read a mailbox, an email with instructions buried in its body can become a command. If the agent looks up internal documents through RAG, one poisoned document goes straight into context — this is indirect injection, and it doesn't require the attacker to reach the chat interface at all.

OWASP also published a separate list for agentic applications at Black Hat Europe 2025, including *Agent Goal Hijack*: the attacker doesn't break the agent, they **change its objective** with malicious content. The agent keeps running normally, keeps logging normally — it's just working for someone else.

A practical rule: every piece of content an agent reads from outside — email, documents, web pages, API responses — must be treated as **untrusted**, exactly the way you'd treat user input in a web app. This is the same zero-trust principle applied to a new surface. The difference is that "validate the input" isn't enough here, because following natural-language instructions is what the model fundamentally does — so the real defence has to live in **tool permissions**, not in text filtering.

The part that has been standardised: MCP

There's good news in this picture. In December 2025 Anthropic transferred the Model Context Protocol (MCP) to the Agentic AI Foundation under the Linux Foundation, making it a vendor-neutral open standard; MCP now has native support from Anthropic, OpenAI, Google DeepMind and Microsoft. According to a July 2026 round-up of deployment data, 78% of surveyed enterprise AI teams have MCP-backed agents in production and 28% of Fortune 500 companies run MCP servers. Read the survey figures with an error bar, but the direction is clear.

What this means in practice: **the tool-connection layer is no longer a place to invent your own**. Before MCP, each model–system pair needed its own integration, and changing models meant rewriting them. With MCP you build one server per data source and every compliant client can use it — which makes the model choice reversible, matching the no-lock-in principle we apply to the AI Orchestrator layer.

When to use an agent, and when to use a deterministic workflow

This is the section that decides whether a project ships or gets cancelled, and the answer usually runs against expectation: **most business processes don't need an agent**.

If you know the steps in advance, know their order, and know the branching conditions — that's a workflow. Write it in ordinary code: cheaper, faster, testable, with readable logs, and 100% reliable on every step that needs no reasoning. Use the model for **exactly the places that need language judgement** — classifying an email, extracting fields from a free-form document, drafting a reply — and leave orchestration to code.

An agent that chooses its own action sequence is only genuinely worth it when all three of these hold:

• **The steps can't be enumerated in advance.** Inputs vary so widely that any hand-written decision tree misses branches — investigating an incident without knowing in advance which table to query, for instance.
• **The chain is short enough, or each step is verifiable.** If the trajectory is long and there's no way to confirm each step, the multiplication at the top of this post decides the outcome.
• **The cost of one wrong action is low enough, or there's a confirmation step.** Reading and summarising can afford to be wrong. Moving money cannot.

None of this is new — it's the "right tool for the job" principle we wrote about in AI is not a universal tool, applied to the agentic class of problems.

How to start when the business is already running

• **Pick a process with clear boundaries.** Don't start with "an AI assistant for the whole company". Pick one job with defined inputs, checkable outputs, and enough volume that the saving shows up as a number.
• **Run deterministic first, add judgement after.** Build the skeleton as coded workflow, and insert model calls only at the steps that genuinely need language understanding. You'll usually find the "needs an agent" portion is far smaller than it first appeared.
• **Log full trajectories from day one.** Not to debug incidents, but to have an evaluation dataset. Without trajectory logs, every later improvement is just a feeling.
• **Define the stop threshold before you start.** "If end-to-end completion is below X% after four weeks, we switch to the deterministic approach" — write that number down while you're still calm. This is what separates a pilot that reaches a conclusion from a pilot that runs forever and is quietly cancelled, contributing to Gartner's 40%.

Conclusion

An agent is not a smarter chatbot. It's a multi-step system whose reliability **multiplies down** rather than adding up, and where each step can produce a real consequence instead of a wrong sentence. Those two properties explain most of what Gartner calls escalating costs and inadequate risk controls.

The good news is that both are computable in advance. Count the steps, multiply the reliabilities, ask every tool what the worst-case damage is if it's called wrongly, and move everything deterministic back into code. That arithmetic takes an afternoon, and it's the difference between a project that reaches a conclusion and one that sits in the other 40%. See KonexForge's AI & ML capability, or get in touch if you want a specific process assessed before you commit budget to it.