Before You Build an AI Agent, Do This Math First

Most of what gets called an "AI agent" in production today is a script with an LLM node and a few if-statements bolted on. That's not an insult, and it's usually the right architecture for the job. The trouble starts when a team pitches a board on autonomous agents, builds a fixed workflow instead, and nobody notices the mismatch until the system fails in a way the roadmap never accounted for.

Agent or workflow? The distinction that decides your failure modes

An LLM workflow follows a graph you already know: retrieve, summarize, classify, route, respond. The steps and their order are fixed at design time; the model fills in content, not structure. An agent, by contrast, decides its own next step — it plans, calls tools, observes the result, and re-plans, with the model choosing the path rather than following one you drew.

Most systems marketed as "agents" are the first thing. That's fine — a well-branched workflow is easier to test, cheaper to run, and fails in predictable places. The problem is treating the two as interchangeable when you scope a project, because they fail differently: a workflow breaks at a branch you didn't anticipate; an agent breaks by confidently taking a coherent-looking path to the wrong outcome. Know which one you're building before you estimate the timeline.

The reliability math nobody puts in the pitch deck

Autonomous, multi-step agents have a compounding-error problem that a single well-tested workflow step doesn't. If each step in a chain succeeds independently 95% of the time, the chance the whole ten-step chain succeeds is 0.95^10 — about 60%, not 95%. Stretch the same chain to twenty steps and it drops to roughly 36%.

This is why "our agent nails the demo" and "our agent runs unattended in production" are different claims. A demo is usually three or four steps under ideal conditions. A production agent doing real multi-step work needs either a much higher per-step success rate than most teams measure, or a design that keeps the chain short and adds checkpoints — a rule-based validation, a cheaper model as a sanity check, or a human approval gate — before the errors compound past the point of usefulness.

Tool calling is where the plan actually breaks

The step that fails first is rarely the reasoning — it's the tool call. Whether the model emits a syntactically valid call with the right arguments depends heavily on the specific model and the specific schema you gave it; "our agent calls tools reliably" is meaningless without naming both. A schema with ambiguous parameter names, optional fields the model treats as required, or ten tools that overlap in purpose will degrade call accuracy regardless of how capable the underlying model is.

In practice this means: keep the tool surface small and the argument schemas unambiguous, test tool-calling accuracy as its own metric before evaluating the agent end to end, and validate every tool call's output structurally before acting on it — don't assume a well-formed call implies a correct one.

Multi-agent systems: coordination tax versus redundancy gain

Splitting work across multiple specialized agents sounds like it should help — more focused prompts, cleaner separation of concerns. It often doesn't. Coordinating agents costs tokens, latency, and a whole new failure surface: agents misreading each other's outputs, looping, or converging on a plan none of them would have chosen alone. A single agent with a better tool, a tighter prompt, or a bigger context window frequently outperforms a multi-agent setup built to solve the same problem.

Multi-agent architectures earn their cost in narrower cases: genuinely independent subtasks that parallelize, distinct tool-access boundaries you want isolated for security reasons, or long-running specialists that need separate context windows to avoid polluting each other's state. If none of those apply, the multi-agent version is probably a coordination tax with no matching benefit — measure a well-tooled single agent first, and only add agents if it falls short.

MCP is plumbing, not an agent

The Model Context Protocol gets described in vendor decks as if adopting it gives you agentic behavior. It doesn't. MCP is a protocol for exposing tools and resources to a model in a standard way — the equivalent of a well-documented API, not an orchestration layer or a runtime that plans and executes. Wiring up MCP servers still leaves you responsible for the planning loop, the retry logic, the error handling, and the evaluation harness. It's a good idea for interoperability; it is not, on its own, an agent.

What we tell clients before they build one

Start with the workflow if you can draw the task graph today — most business processes can be. Reserve genuine agent autonomy for the parts where the next step really can't be predetermined, and keep those chains as short as the task allows, because every additional step multiplies your failure rate rather than adding to it. Instrument every step individually, not just the end-to-end outcome, so you know which link in the chain is actually weak. Name a human-approval point for any action with real consequences — sending money, deleting data, contacting a customer — rather than trusting the compounding math to stay in your favor. And before reaching for a multi-agent architecture, measure what one well-tooled agent can do; the coordination cost is real and the payoff usually isn't.

If you can draw the flowchart today, you don't need an agent — you need a good workflow and a model that's honest about its tool calls. Save the autonomy budget for the part of the problem where the flowchart is the thing you actually don't know yet.