Part 3 of the series The 10 Commandments of AI in Business: Choosing the Right Intelligence for the Right Problem.

1.0 First, a quick recap

In Commandment 1, we established that the process is sovereign . You start with the process, find the constraint, and let the nature of the work at the constraint choose the tool. We had a six-row decision lens, and we noticed that AI Agents were just one row in it reserved for the specific job of coordinating multiple systems.This post zooms into that one row, because it is the single most abused word in business AI today.

Somewhere in your organisation, right now, someone is proposing to solve a problem with “an agent.” Maybe a “multi-agent system.” It sounds sophisticated. It sounds like the future. And in perhaps one case out of five, it’s the right call.

This commandment is about identifying that one case from the other four

2.0 The scene (you’ve lived this one too)

A process is running slowly. Someone has read that agentic systems are the frontier of AI. They propose:

“Let’s build an agent for it. Actually a multi-agent system. One agent to read the request, one to look up the data, one to draft the reply, one to check it.”

It sounds like a well-organised team of digital workers. What it actually is, in most cases, is a slow, expensive, unpredictable way to do something a fifty-line script could have done reliably for a fraction of the cost.

To understand why, we first have to be honest about what an agent actually is because the word is doing a lot of marketing work that the technology doesn’t always earn.

3.0 The same brain, with a different packaging

Here is the most important thing a business leader can understand about agents, and almost nobody says it plainly:

An agent is not a smarter AI. It is the same LLM — the same “brain” — wrapped in scaffolding that lets it act on its own.

The large language model at the centre of an agent (Claude, GPT, Gemini) is exactly the same model you use when you type a single question into a chat window. It is not more intelligent because you called it an “agent.” It has the same knowledge, the same reasoning ability, and the same tendency to make mistakes.

What changes is the harness built around it. An agent is an LLM plus:

• Tools — the ability to call external functions (search a database, send an email, query an API).
• A loop — permission to run itself repeatedly until it decides the job is done.
• State & memory — a scratchpad of what it has done so far and what it has learned.
• Autonomy over the path — and this is the crucial one.

That last point is the whole distinction. Let me make it concrete.

In a simple prompt or a workflow, you decide the steps. You write: “First classify the email -> then extract the fields -> then draft a reply.” The LLM fills in each blank, but the path is fixed, predictable, and controlled by you.

In an agent, the LLM decides the steps. You give it a goal, “resolve this customer’s issue” and a set of tools, and it decides what to do first, what to do next, when to use a tool, and when it’s finished. You have handed the steering wheel to the model.

That is the trade at the heart of this commandment:

	Workflow	Agent
Who controls the path?	You (fixed)	The LLM (dynamic)
Predictable?	Yes	No
Cheap & fast?	Yes	No
Good when the steps are…	Known in advance	Unknown in advance

You hand over the steering wheel only when you genuinely don’t know the road in advance. Most business processes are known roads. That is why most business processes do not need an agent.

4.0. The Anatomy of an agent — how it actually works ?

Before we look at applications of an agent or even cost an agent out, we need to demolish the biggest myth about it: that the agent magically knows how to look things up, send emails, or issue refunds. It doesn’t. Every one of those abilities is a tool that a developer built, described, and handed to the LLM in advance. And the “memory” that lets it string steps together isn’t memory at all, it’s scaffolding re-reading a transcript to a model that forgets everything between calls. Let’s take these one at a time.

4.1 What exactly is a “tool”?

A tool is simply a capability you give the LLM so it can act on the outside world instead of just talking about it. On its own, an LLM can only produce text.It cannot look up your billing records or send an email. A tool is the bridge. In practice, a tool is almost always one of these:

• A function you write — a small piece of code that calculates a shipping cost or formats a date.
• A database query — “fetch this customer’s last 10 transactions.”
• An API call to another system — your payment gateway, your CRM, a weather service, a Slack message.
• A search — over the web, or over your internal documents.

The critical point to note here is that none of these appear by magic. Someone in the team has to build each one, connect it securely to the underlying system, and maintain it. Ten tools means ten integrations to build, test, secure, and keep working when the underlying systems change. That is real, recurring engineering cost — and it’s part of the price tag of “just building an agent.”

4.2 How a tool is defined and how the LLM knows what it does ?

Here’s the part that removes the mystery. When you give a tool to an LLM, you don’t just hand it the code. You register it with a plain-language description and a defined set of inputs. Conceptually, each tool is declared like this:

Field	Definition
Tool name	get_billing_history
Description	“Retrieves all charges for a given customer in the last 90 days. Use this when you need to see what a customer was actually billed.”
Inputs	customer_id a number (required)
Returns	A list of charges, each with a date, amount, and status

You define, up front a toolbox, the complete set of tools, the agent is allowed to use for this job. For a billing-dispute agent, that toolbox might be:

Tool	What its description tells the LLM	Underlying reality
get_billing_history	“Use to see a customer’s charges”	A database query
get_gateway_logs	“Use to check if a payment was retried or failed”	An API call to the payment provider
issue_refund	“Use to refund a specific charge”	An API call that moves real money
send_email	“Use to message the customer”	An API call to your email system

4.3 So how does the LLM decide which tool to use?

This is the question everyone should ask, and the answer is refreshingly un-magical:

The LLM uses the tool descriptions, names, parameter schemas, and surrounding context to determine which tool is most appropriate. It’s matching intent to tool metadata the same way you’d scan a toolbox and reach for the screwdriver because you need to turn a screw.

That’s why the quality of the tool metadata matters enormously. If get_gateway_logs is described vaguely as “gets logs,” the LLM may not realise it’s the right tool for checking a retried payment and will either pick the wrong tool or give up. The engineer’s skill is partly in writing tool metadata so clear that the LLM reliably reaches for the right one.

Two consequences follow, and both matter:

• The LLM is only as capable as the toolbox you give it. It cannot check a refund status if you never built and registered a get_refund_status tool. The agent cannot perform external actions beyond the toolbox it has been given, although it can still generate plans, analyses, and reasoning using the model itself.
• The LLM can still choose wrongly. Because the choice is a judgement based on descriptions, the same non-determinism that makes agents flexible also means they can pick the wrong tool, in the wrong order, or call one they didn’t need the unpredictability we’ll cost out shortly.

4.4 Watching a single agent run

Let us now take a genuinely open-ended task and do a walkthrough on how the agent will process it.

Query :  “A customer says they were double-charged last month — investigate and resolve it.“

Notice we cannot pre-write the steps. The cause could be a billing bug, a duplicate subscription, a refund that never processed, or a customer misunderstanding. The path depends on what the agent finds. This is why it’s a legitimate agent candidate. Here’s the mechanism and watch how, at each reasoning step, the LLM scans that pre-defined toolbox and chooses:

1. User goal received → “Investigate the double-charge for customer #4471.”
2. Reasoning (LLM call #1) → “I don’t know the cause yet. First I should see what this customer was actually charged.” It scans the toolbox, matches that need to the description of get_billing_history, and selects that tool.
3. Tool call → get_billing_history(customer_id=4471) , the underlying database query runs and returns two charges on the same date.
4. Observation & state update → the result is recorded: “Confirmed: two charges, $2,000 each, 12 July.”
5. Reasoning (LLM call #2) → “Two charges confirmed. Now I need to know whether one was a failed-then-retried payment or a genuine duplicate.” It scans the toolbox again, matches this to get_gateway_logs, and selects it.
6. Tool call → get_gateway_logs(...) → the API call returns: one payment succeeded, one was a retry that also succeeded (a bug).
7. Reasoning (LLM call #3) → “This is a genuine duplicate caused by a retry bug. The right action is to refund one charge.” It selects issue_refund.
8. Tool call → issue_refund(...) → the API call moves real money; refund succeeds.
9. Reasoning (LLM call #4) → “Refund done. Now I should tell the customer.” It selects send_email and generates the message.
10. Termination → the agent decides the goal is met and stops.

Four separate LLM “reasoning” calls, and each one did the same thing: read the current state, scan the toolbox, and decide which tool fits next. The intelligence isn’t in the tools. The intelligence is in the LLM matching its intent to the right tool, one step at a time. But how does it “read the current state” if the model forgets everything between calls? That’s the machinery we look at next.

4.5 What the agent actually “remembers” — context, memory, and state

It’s tempting to imagine the agent as a colleague who remembers what they just did. It isn’t. Here’s the fact that surprises almost everyone:

The underlying LLM is stateless between API calls. In plain English, this means the model has no memory of previous interactions. Every time it is asked to do something, it starts with a blank mind. Any apparent memory comes from external systems that retrieve and re-insert information into the model’s context.

So how does the billing agent “recall” that it already found two charges? Because the harness re-feeds it the entire history on every single call. The intelligence has no memory; the scaffolding around it does. Let’s name the pieces:

• Context (the context window) — the LLM’s entire field of vision in every call: the system instructions, the descriptions of every tool in the toolbox, the original goal, and the running transcript of everything done so far. Because the model is stateless, anything you want it to “know” must be placed into the context on every call.
• Working memory (short-term) — the running scratchpad for this task: each thought, action, and observation, accumulated as the loop runs. In a simple agent, the working memory is the growing transcript that gets stuffed back into the context each loop. It exists only for the life of the task, then vanishes.
• Long-term memory — information kept beyond this task, in an external store (a database, a vector store, a file) — e.g. “customer #4471 raised a similar issue in March.” It is not automatically in context; the agent must deliberately retrieve it (via a tool) and inject it, and write to it if it wants to remember something for next time.
• State — the harness’s structured record of where we are: which steps are done, the latest tool outputs, and whether the goal is met. The state is what the loop checks to decide “reason again” or “stop.”

The key dynamic: after every reasoning step and every tool call, the harness updates the working memory and state by appending the newest thought, action, or observation and then the next reasoning call re-sends the whole enlarged context. Long-term memory only changes if the agent explicitly writes to it.

Watch it happen across our billing example. Notice how the context grows at every step — this is the engine of the token bill:

Step	What the LLM is sent (context window, cumulative)	Working memory / state after the step	Long-term memory
Start	System prompt + all tool descriptions + goal	(empty)	(could retrieve: “#4471 — no prior disputes”)
Reason #1	…the above	+ Thought: pull billing history Action: get_billing_history(4471)	—
Tool #1	(no LLM call — tool runs)	+ Obs: 2 charges, ₹2,000, 12 Jul	—
Reason #2	System + tools + goal + Thought1 + Action1 + Obs1	+ Thought: check for retry Action: get_gateway_logs(...)	—
Tool #2	(tool runs)	+ Obs: one payment retried — bug	—
Reason #3	…all of the above + Thought2 + Action2 + Obs2	+ Thought: genuine duplicate → refundAction: issue_refund(...)	—
Tool #3	(tool runs)	+ Obs: refund success	—
Reason #4	…everything above + Obs3	+ Thought: notify customer → drafts email → terminate	Writes: “Resolved double-charge for #4471; cause = retry bug”

Read the middle column top-to-bottom: the context the model must process grows on every loop. By Reason #4, the LLM is re-reading the goal, the full toolbox descriptions, and every thought, action and observation from the entire run, just to decide one final step.

This is the counter-intuitive cost engine of every agent. The model’s “memory” is really the harness re-reading the whole transcript aloud before each decision. In naive agent implementations, token costs compound because the full history is repeatedly reprocessed. More advanced systems reduce this through summarisation, pruning, retrieval, and memory compression. And it’s why context management (trimming, summarising, offloading to long-term memory) is one of the hardest parts of building a reliable agent, a cost that never appears in the demo, only in the bill.

4.6 From one agent to many — what a multi-agent system actually is

A multi-agent system is a team of AI agents, where each agent is responsible for a specific task. They communicate with one another, and a manager agent coordinates their work and combines their results to solve a larger problem.

It is not one brain with many skills. It is many separate reasoning loops each incurring its own LLM calls, each re-sending its own growing context (the exact engine we just saw in 4.5), and now also spending calls on talking to each other. Every metaphorical “meeting between colleagues” is, under the hood, more LLM calls and more tokens.

The typical parts:

• Orchestrator / Manager agent — receives the overall goal, breaks it into sub-tasks, delegates each to a worker, and assembles the results. It coordinates; it doesn’t do the detailed work.
• Worker / Specialist agents — each has a narrow job and its own toolbox.
• Delegation — the manager deciding which worker gets which sub-task (itself an LLM reasoning step).
• Inter-agent communication — workers reporting back, and sometimes talking to each other. Every conversation between agents comes at a cost. One agent creates the message, and another must read and interpret it, consuming tokens at both ends.
• Shared vs. isolated memory — do the agents share one memory, or does each keep its own and pass summaries? This choice massively affects both cost and reliability.

Each “obvious” multi-agent example is defeated by a different disguise, until we reach one that genuinely qualifies.

4.6.1 First disguise: “It’s parallel, so it’s multi-agent”

Here’s the trap most “multi-agent” demos fall into. Suppose the task is: “Research our three rivals — Acme, Globex, and Initech.” The obvious design spins up three research agents, one per company. It looks impressive. But ask the sceptical question a literate leader should ask:

“Couldn’t a single agent just research all three, one after another, in a loop? The output would be identical.”

It absolutely could. So what does splitting into three agents actually buy? Only two things and, crucially, not the thing that justifies a true multi-agent system:

• Parallelism → lower latency. Three workers run simultaneously, cutting wall-clock time to roughly a third. But the trap, it is not cheaper. You still pay for every call and token. Parallelism buys speed, never cost.
• Context isolation → reliability. A single agent doing all three sequentially would pile all three companies’ research into one ballooning context (per 4.5), risking degraded attention and facts about Acme bleeding into the Globex summary. Three isolated workers each keep a clean, focused context.
• Specialisation → none. The three tasks are identical: same skill, same toolbox, three times over.

Verdict: three-identical-companies is not a true multi-agent case it’s a “parallel fan-out” pattern, justified only by latency and context hygiene. A single looping agent is a perfectly respectable alternative. Showcasing it as “multi-agent” is quietly overselling the pattern.

The disguise it wore: parallelism. We saw through it. But there’s a second, subtler disguise.

4.6.2 Second disguise: “It’s specialised, so it’s multi-agent”

Let’s fix the flaw in 4.6.1 by choosing a task that is genuinely specialised. Take acquisition due-diligence: “Assess TargetCo as an acquisition.” This clearly splits into three experts, each with a different toolbox and different domain reasoning:

Worker	Its toolbox (genuinely different)	Its expertise
Financial analyst	financial-data API, calculator	valuation, ratios, cash-flow health
Legal & risk analyst	litigation database, contract search	lawsuits, liabilities, compliance flags
Market analyst	web search, news API	market position, competitive threats

This feels like the textbook multi-agent case real division of labour, three distinct specialties. Surely now we need agents?

No. And this is the most important lesson in the whole commandment 2. Watch what happens when we try to break the task with plain, fixed LLM calls:

Step	Action	Type	What produces it
1	Pull financial data for the target	Tool call	call_financial_api(target)
2	Summarise financial health	LLM call	fed the data from step 1
3	Pull litigation records	Tool call	query_litigation_db(target)
4	Summarise legal risk	LLM call	fed the cases from step 3
5	Search market & news	Tool call	web_search(target)
6	Summarise market position	LLM call	fed the news from step 5
7	Combine into a final assessment	LLM call	fed all three summaries above

Four LLM calls, three tool calls, in a fixed sequence I drew in advance. No agent decided anything. This is a specialised parallel workflow not an agentic system at all.

So where did the intuition go wrong? It made the single most common error in this entire field:

It confused specialisation with agency. They are not the same thing.

• Specialisation (different toolboxes, prompts, expertise) justifies different branches ,which a workflow gives you for free. You do not need agents to have specialised steps.
• Agency is justified only by a dynamic, discovery driven path where the next step genuinely cannot be known until the previous step reveals what it found.

Due-diligence is a checklist. You know in advance that you’ll pull financials, litigation, and market data so the path is pre-drawable, so it’s a workflow. Specialisation was a real property, but it was never the property that matters.

When would due-diligence actually become agentic? Only if it must branch on its findings: the financial analyst spots an odd related-party transaction → decides on its own to pull a subsidiary’s filings → forms a hypothesis of inflated revenue → chases three more documents to test it → follows the trail into an entity nobody put on the checklist. That path can’t be pre-drawn. But the ordinary “produce a due-diligence report” task never needs it. Most corporate due-diligence is checklist-driven i.e., a workflow.

Verdict: due-diligence is a specialised workflow, not a multi-agent system. It cleared the specialisation bar but failed the one that counts — agency.

The disguise it wore: specialisation. We saw through that too. So what does a genuine multi-agent system look like?

4.6.3 The real thing: parallel + specialised + discovery-driven

To genuinely need a team of agents, a task must clear all three hurdles at once: it must be parallel (not just fan-out), specialised (not repetition), and agentic (a discovery-driven path in each strand). Here is a task that finally does and it builds on an idea any leader will recognise: an analytics agent that builds answers on the fly.

The single-agent version first. Consider one exploratory question: 

“Why did our Q3 margins drop in APAC?” 

An analytics agent with tools (run_query, transform_data, make_chart) would:

1. Decide which data to pull → write a query → run it → see “margins fell 4pts,”
2. Based on that, drill into product mix → write a new query → see “one product line drove it,”
3. Based on that, drill into a specific SKU → discover a cost spike,
4. Decide a waterfall chart best communicates the finding → generate it.

Can you pre-draw this flowchart? No. Query 2 depends on the result of query 1; the chart type depends on the finding; the number of drill-downs isn’t known until the data reveals where the anomaly hides. The path is discovered, not designed. This is a genuine agent but for one question, it is a single agent (the steps are sequential and dependent; there’s nothing to parallelise).

Now scale it into a true multi-agent system. Change the request to an open-ended, multi-domain one:

“Give me a full quarterly business review, what’s happening across Sales, Operations, Finance, and Supply Chain?”

Here’s the important nuance, because it’s where magic-thinking creeps in: the analyst agents and their toolboxes are defined upfront. Someone engineered a Sales analyst wired to the sales DB and CRM, a Finance analyst wired to the GL, and so on. You decide your domains and build their tools in advance. What the lead agent does dynamically is decide, for this query, which of those analysts to invoke, write each a specific brief, and in more advanced setups decide how many parallel investigations to spawn within a domain (say, three sales sub-investigations for three anomalous regions it wants explored at once).

So “spinning up agents on the fly” is real, but bounded: the lead agent varies the orchestration, who works on what, and how many within a fixed, pre-engineered envelope of tools and data access. It never invents a new capability. Ask it a question in a domain you never built tools for, and it is simply blind to it. The intelligence is dynamic; the capability envelope is not.

Analyst agent	Its tools	Why it’s genuinely agentic
Sales analyst	sales DB, CRM query, charting	explores revenue, follows leads into whichever regions/segments look anomalous
Operations analyst	ops-metrics DB, charting	investigates throughput/quality, drills wherever the data looks off
Finance analyst	ledger/GL API, charting	explores margins/cash, chases the drivers it discovers
Supply-chain analyst	logistics DB, supplier API	investigates delays/costs, digs where the trail leads

(These four analysts and their tools are defined by your engineering team upfront; the lead agent chooses which to deploy and how many parallel instances per query)

Now every box is genuinely ticked:

• Parallel — the four domains are independent and don’t need to talk mid-flight.
• Specialised — different data sources, different domain reasoning.
• Agentic — each analyst runs a real, unbounded discovery loop; none of the four paths can be pre-drawn. (This is the exact property due-diligence lacked.)
• Too large for one context — four deep explorations won’t fit cleanly in one agent’s memory without context rot.
• Coordination worth it — parallelism gives a materially faster review; isolation keeps each investigation clean.

The decisive contrast with 4.6.2: in due-diligence, each worker ran a fixed two-step chain (pull → summarise) workflow. Here, each analyst runs a genuine, open–ended discovery loop (agent). 

Four parallel agents doing genuine discovery = a real multi-agent system.

The other classic clean example, if you prefer a non-analytics one: agentic deep research — a lead agent spawns parallel researcher sub-agents, each doing open-ended web investigation that revises its own search strategy based on what it finds. Same fingerprints: parallel + specialised + discovery-driven.

4.6.4 How the machinery runs : the blackboard flow

The critical structural difference from a single agent is that there is no shared brain. Each analyst has its own isolated context and working memory, and can only learn about the others through messages passed via the lead agent. The lead agent holds the one global state / shared memory (often called a blackboard). Here’s the flow, tracking every piece of machinery, for our business review:

#	Event	Lead agent’s blackboard (shared state)	What each analyst holds (isolated)
1	Goal received	Goal: quarterly review; strands:[sales,ops,fin,supply]; dispatched:0; returned:0}	—
2	Lead reasons → plans the four investigations (1 LLM call)	plan written to blackboard	—
3	Delegation → lead generates 4 briefs, sends as messages	dispatched:4, returned:0	Each analyst’s context is created: only its own brief + its own tools
4	Sales analyst runs its own discovery loop(query→observe→drill→chart→…)	lead waits — no visibility inside the analyst	Sales memory: only sales queries/findings
5	Ops analyst runs its own discovery loop(parallel)	no visibility	Ops memory: only ops findings – never sees sales context
6	Finance & Supply analysts run their own loops (parallel)	no visibility	Each: only its own domain findings
7	Analysts report back → each generates a summary + charts message	lead appends all 4 reports → returned:4	analyst contexts now discarded
8	Lead reasons over the combined blackboard (now a large context)	synthesises the 4 strands into one review	—
9	Terminate → returns the assembled business review	final result on blackboard	—

Three dynamics you should take away:

1. Memory is isolated, not shared. The sales analyst literally cannot see what the finance analyst found. This is a feature (clean, focused contexts) and a liability (the lead agent is the only place the full picture exists a single point of failure, and the place where one analyst’s hallucinated number gets baked into the final review as fact).
2. Every arrow between agents is tokens. Each brief (step 3) and each report (step 7) is text, one agent generates and another reads, pure coordination overhead producing no direct output. And it sits on top of each analyst’s own discovery loop, which carries the very same growing-context cost engine from 4.5, now running four times in parallel, plus the lead’s.
3. The lead’s synthesis context is huge. Step 8 pulls all four full reports into one context often the single most expensive call in the entire run.

4.6.5 The three-strike summary

We defeated two disguises before finding the real thing:

Example	Looks like…	Actually is…	Fails on…
4.6.1 Three identical companies	multi-agent	parallel fan-out (a single looping agent works)	no specialisation
4.6.2  Due-diligence report	multi-agent	specialised workflow (fixed, pre-drawable path)	no agency
4.6.3  Multi-domain business review	multi-agent	genuinely multi-agent	nothing; it passes

The lesson compounds beautifully: to justify a multi–agent system, “it’s parallel” isn’t enough and “it’s specialised” isn’t enough. You need the one property that actually matters everywhere in this commandment — an unpredictable, discovery-driven path happening in parallel, specialised strands. That is a genuinely high bar, which is exactly why real multi-agent systems are far rarer than the word’s popularity suggests.

5.0 The experiment: what over-engineering actually costs

Now you might be thinking:

“Fine. You’ve shown me three architecture’s — a workflow, a single agent, a multi-agent system. Big deal. What if I just run multi-agent for everything? It sounds sophisticated. It’ll make us look cutting-edge. Where’s the harm?”

Wait a minute. It’s not about looking cool or cutting-edge. There is always a cost — and it is a perpetual one. This is the crucial word most people miss. Building the fancy system is a one-time cost you can rationalise away. But an agent doesn’t cost you once; it costs you on every single transaction, forever. Every email, every query, every invoice — for the entire life of the system.

That perpetual cost comes in two forms:

1. Token generation cost — the actual dollars you pay the model provider for every input and output token, on every run.
2. Time (latency) — how long each transaction takes, which becomes its own cost when a customer is waiting or a queue is backing up.

So rather than argue about it, we ran a real experiment. Here’s what we found.

5.1 The experiment: one simple task, three designs

We took a deliberately simple, deterministic, predictable task, the kind that occurs millions of times in real businesses:

Inbound customer-email triage:

Receive email → Classify intent (billing/technical/sales) → Look up the order → Draft a reply → Route to the right queue

The path never changes. Every email follows the same steps in the same order. We know the road which, per this whole commandment, means a fixed workflow is the correct design. But to measure the cost of over-engineering, we built it three ways and compared the results:

• Design A — Workflow (correct): three fixed LLM calls : classify → extract → draft. I decide the sequence; the model just fills in each blank.
• Design B — Single agent (over-engineered): one ReAct agent given the goal “triage this email” plus tools, left to discover the sequence itself on every email.
• Design C — Multi-agent (absurdly over-engineered): a manager agent delegating to a classifier, an investigator (with its own tool-using loop), and a drafter all sharing one Gemini model, passing messages back and forth.

5.2 The results (real runs, Gemini 2.5 Flash, averaged with spread)

Before reading the numbers, here’s exactly what was measured — so you can trust the table rather than take it on faith.

• One fixed task, three architectures. Every design was handed the identical input — a single customer support email (“I think I was charged twice for order #A-5592”) and asked to produce the same outcome: a classified, investigated, drafted, and routed reply. The only thing that changed between runs was the architecture (fixed workflow → single agent → multi-agent), never the task. This is what makes it a fair, apples-to-apples comparison: any difference in cost is caused purely by how we built it, not what we asked.
• Real calls to a real model. These are not simulated numbers. Each design made live calls to Gemini 2.5 Flash via Vertex AI, using LangChain/LangGraph to orchestrate the single-agent and multi-agent versions. The workflow used direct, fixed model calls.
• Measured directly from the model’s own metering. For every LLM call we captured the input tokens and output tokens straight from the model’s usage_metadata (not estimated), counted the number of LLM calls, and timed the wall-clock latency end-to-end. Cost is computed from those real token counts.
• Repeated runs, with the spread reported. Crucially, we didn’t run each design once and quote a lucky number. Each architecture was run multiple times, and we report the mean ± standard deviation for every metric. That ± is deliberate: it lets us see not just how much each design costs, but how predictable that cost is run-to-run which, as you’ll see, turns out to be one of the most revealing findings of all.

With that established, here are the results.

Design	LLM calls	Input tokens	Output tokens	Time (s)	Cost ($)	× vs. workflow
A. Workflow (fixed)	3 ± 0	228 ± 0	95 ± 0	6.6 ± 0.3	0.0001 ± 0.0000	1.0×
B. Single agent	3 ± 0	929 ± 0	240 ± 0	5.1 ± 0.4	0.0003 ± 0.0000	3.1×
C. Multi-agent	6 ± 0	866 ± 21	802 ± 123	20.3 ± 0.7	0.0006 ± 0.0001	6.7×

(Cost $ above uses the script’s default illustrative pricing . We recompute with real Gemini 2.5 Flash rates later )

The ± values come from running each design multiple times. These values carry one of the most important findings in this whole post. Let us look at the insights hiding in the table

1. Same task. Same output. Wildly different cost. All three designs produced the same triaged email. Yet moving from workflow to multi-agent multiplied the token bill several times over. You paid more a lot more for identical business value.

2. The single agent made the same number of calls (3) but burned ~4× the input tokens. This is the subtle one. The agent didn’t take extra steps here; the task was simple enough to solve in three reasoning turns. So why 929 input tokens versus the workflow’s 228? Because every one of the agent’s turns re-sends the growing context plus the full tool descriptions the “stateless model re-read the whole transcript” from Section 3.5. Even when an agent takes no extra steps, the harness itself is a drain. You pay 4× just for the scaffolding, before the agent does anything clever.

3. The multi-agent output tokens exploded — 802 vs. 95, more than 8×. This is the message-passing “tax” made visible. Each agent generates a verbose brief or report that another agent then reads. All that inter-agent chatter is output token’s pure coordination overhead that produced zero additional business value.

4. Predictability collapses as you move right — look at the ± column. The workflow is perfectly deterministic: ± 0 on everything. The single agent: still ± 0 on tokens (it happened to find the same path each run). But the multi-agent swung by ± 123 output tokens run-to-run. When you hand the LLM the steering wheel, you don’t just lose money and speed you lose predictability itself, the one thing a production process needs most. A cost you can’t forecast is a cost you can’t budget.

5. The latency story is honest and still damning. Notice the single agent (5.1s) was actually slightly faster than the workflow (6.6s). At this tiny scale, the difference between A and B is within network noise don’t over-read it. But the multi-agent at 20.3s is ~3–4× slower, unambiguously, and outside all noise. Every hand-off is another sequential round-trip. When a customer is waiting on a reply, that 20 seconds is a real, felt cost.

5.3 Now the real money: cost per email, at real Gemini prices

The table above used the script’s placeholder prices. Let’s use the real ones. Gemini 2.5 Flash charges $0.30 per million input tokens and $2.50 per million output tokens note that output is 8.3× more expensive than input, which matters enormously in a moment.

Recomputing each design’s cost for one single email:

Design	Input tokens	Output tokens	Input $	Output $	Cost / email	×
A. Workflow	228	95	$0.0000684	$0.0002375	$0.000306	1.0
B. Single agent	929	240	$0.0002787	$0.0006000	$0.000879	2.9
C. Multi-agent	866	802	$0.0002598	$0.0020050	$0.002265	7.4

Here’s a beautiful, sobering detail: under real Gemini pricing the multi-agent penalty gets worse 7.4×, not 6.7×. Why? Because output tokens cost 8.3× more than input, and the multi-agent design is output-heavy (all that inter-agent chatter). The cost multiplier isn’t fixed it depends on your model’s input/output price ratio, and the fashionable architecture is precisely the one that leans on the expensive side of that ratio. Choose a model with pricier output, and over-engineering punishes you even harder.

Fractions of a cent per email sound trivial. That’s the trap. Watch what “perpetual” does to a trivial number.

5.4 Scale it up: the perpetual token guzzler

These are not one-time costs. They fire on every message, every month, forever.

And here’s the key reframe before we scale: email triage is just our illustrative example. The classify → investigate → draft → route pattern is completely channel-agnostic the identical architecture runs on every inbound support contact, whether it arrives as an email, a live-chat message, a web ticket, or an in-app query. So when we scale up, we’re not imagining a company drowning in ten million emails; we’re counting the total inbound support messages a large consumer business genuinely handles across all its channels a number that comfortably reaches into the millions per month.

Scaling the real per-contact figures to realistic business volumes:

Monthly volume (all channels)	A. Workflow	B. Single agent	C. Multi-agent
100,000 contacts/mo	$31	$88	$226
1 million contacts/mo	$306	$879	$2,265
10 million contacts/mo	$3,059	$8,787	$22,648

And annually, at large-consumer scale (10M/month):

	A. Workflow	B. Single agent	C. Multi-agent
Per year	$36,708	$105,444	$271,776

Look at that final row. For a task where the workflow was the correct design, choosing “multi-agent because it’s cool” costs you an extra ~$235,000 every single year, forever to produce the exact same triaged replies. That is not an investment. That is a perpetual token guzzler bolted onto your P&L, quietly draining margin on every transaction until someone finally asks why the inference bill is so high.

This is the difference between a build cost and a run cost. You can absorb a bad build once. A bad architecture bleeds you every day it runs.

And support triage is just one process. Most enterprises run dozens of these high-volume, repetitive, perfectly-predictable AI tasks — document classification, invoice extraction, content moderation, KYC checks, log triage, review summarisation. Each one is a candidate to be quietly over-engineered into an agent, and the 7.4× penalty compounds across every one you get wrong. The quarter-million-dollar line above isn’t a ceiling reserved for tech giants it’s the cost of a single mis-architected process. Multiply it by the dozen such processes a typical operation runs, and “let’s just use agents for everything” stops looking cool and starts looking like a structural margin leak. And yet, for the first two years of this wave, high token consumption wasn’t treated as a leak at all it was treated as a trophy. The industry had a name for it: token maxing.

5.5 The rise and fall of “token maxing”

Token maxing was the mindset that more tokens consumed was itself the mark of a sophisticated AI operation as if there were an industry leaderboard for who could burn the most. Longer reasoning traces, fatter contexts, more tool calls, more agents: consumption became a proxy for capability, and teams effectively competed on it. What the leaderboard conveniently ignored were the only two things that actually matter the cost of all those tokens, and whether they produced any better outcome.

Then the invoices arrived.

Companies that industrialised agentic systems without discipline discovered that token consumption doesn’t scale linearly with value it scales with architecture. A team could 10× its inference bill and see no improvement in business outcomes, because it had bought reasoning overhead, not results. The very “sophistication” they were proud of was the thing draining the budget.

In 2026, Uber reportedly burned through its entire annual AI budget within the first quarter exhausting a full year’s allocation by roughly March. Not a build overrun. Not a one-off migration. A run-rate so far above forecast that twelve months of budget evaporated in three because that’s what perpetual, per-transaction token consumption does when it’s left unconstrained. The invoice doesn’t arrive once; it arrives on every call, every day, and it compounds silently until the annual number is gone.

Uber isn’t alone, and it isn’t incompetent it’s an early, visible example of a pattern now playing out across the industry: teams that optimised for capability (“more agents, more reasoning, more tokens”) without a matching discipline on cost-per-outcome discovered that the two are not the same thing. The reasoning overhead they were proud of was the line item quietly draining the budget.

The lesson isn’t “don’t use AI.” It’s the one this entire experiment has been building toward: the flashy architecture and the frugal one often produce the identical result, but only one of them empties your budget by March

The correction is now well underway. Mature teams have swung hard toward token prudence: default to the simplest architecture that works, reserve agents for genuinely discovery-driven paths (Section 3), cache aggressively, trim context, use smaller models where they suffice (a preview of Commandment 9), and above all measure cost-per-successful-outcome, not cost-per-clever-demo. The status symbol is no longer “we run a multi-agent swarm.” It’s “we deliver the outcome at a fraction of the token cost.”

Our little experiment is that lesson in miniature: the cheapest design (A) and the flashiest design (C) produced the identical result. One of them cost 7.4× more, forever.

5.6 And the token bill isn’t even the whole bill

Everything above is just tokens and time. There’s a second, harder-to-price cost that compounds the first: reliability.

The cost compounds, it doesn’t add. With multi-agent you pay for every worker’s own reasoning loop (each re-sending its growing context and tool descriptions), plus the manager’s coordination calls, plus the tokens agents spend talking to each other. Three multiplying sources, not three additive ones.

And the failure modes multiply too. With a fixed workflow, if something breaks, you know exactly which of the three steps failed. With a single agent, a wrong tool choice is one bug in one loop. But with a team of agents:

• a manager can mis-delegate — send the wrong sub-task to the wrong worker;
• a worker can misunderstand its brief — it only has the summary the manager chose to pass, not the full context;
• errors propagate — one worker’s hallucinated “fact” gets synthesised into the final output as truth;
• and when the output is wrong, you must debug which agent, in which loop, on which call went astray dramatically harder than tracing a single agent, and worlds away from a fixed workflow where the path is nailed down.

That debugging difficulty, that unpredictability (remember the ± 123), and that wider blast radius are all real operational costs that never appear on the model provider’s invoice but land squarely on your engineering team, every week.

The rule that follows: every additional agent multiplies cost and fragility. A multi-agent system must therefore clear a higher bar than a single agent not a lower one. Splitting a task across four agents does not make it four times smarter. It makes it several times more expensive, several times slower, and several times harder to trust.

5.7 The takeaway

We ran the experiment so you don’t have to learn this from your own invoice. On a task that genuinely needed a workflow:

• The workflow and the multi-agent system produced identical output.
• The multi-agent version cost 7.4× more per transaction a gap that only widens with pricier output models.
• It ran ~4× slower, was less predictable run-to-run, and was far harder to debug.
• And every one of those penalties is perpetual, paid on every transaction, for the life of the system.

So when someone says “let’s just run multi-agent for everything, it’ll make us look cool” this is the number to put on the table. Cool is a one-time feeling. The token bill is forever.

Match the architecture to the road. Where the road is known, build the workflow. Reserve agents for the roads that genuinely have no map and reserve multi-agent for the rare roads that fork into parallel, specialised, genuinely-unmapped territory at once. Everywhere else, do not take the agent’s name in vain.

6.0 When you genuinely DO need an agent

The experiment might read like an anti-agent polemic. It isn’t. Agents are not the villain — misapplied agents are. The whole point of paying the agent tax is that, for the right problem, it buys you something a workflow simply cannot: the ability to navigate a road that has no map.

Reach for an agent only when the problem shows these fingerprints:

• The path is unknown in advance. You genuinely cannot pre-draw the flowchart, because the next step depends on what the previous step discovers. (Our billing-dispute investigation in 4.4: yes. The email triage we just benchmarked: no.)
• It’s genuinely multi-step and adaptive. The task requires forming a hypothesis, testing it, and changing course based on the result.
• It requires dynamic tool use. Which tools, and in what order, depends on the situation as it unfolds.
• Uncertainty is inherent, and exploration has value. The messy, branching nature of the problem is the whole point where an agent would add value

7. The decision lens: agent or not?

Put your process step usually the constraint you identified in Commandment 1 through these questions:

Ask this	If YES →	If NO →
Can I draw the exact steps in advance?	Workflow	Consider agent
Does every run follow the same path?	Workflow	Consider agent
Does the next step depend on what the last step discovered?	Consider agent	Workflow
Does it need to adapt, form hypotheses, and change course?	Consider agent	Workflow
Is unpredictability acceptable here?	Agent viable	Workflow / human
Would a wrong autonomous action be costly or irreversible?	Add human checkpoints	Agent viable

Rule of thumb: If you can draw the flowchart, build the flowchart. Only when you genuinely can’t draw it, does an agent earn its existence.

7.1 The second lens: single agent or multi-agent?

The first lens gets you to “yes, this genuinely needs an agent.” But that’s only half the decision. The fashionable and expensive mistake is to leap straight from “we need an agent” to “let’s build a multi-agent system.” As our experiment showed, that leap can multiply your perpetual cost several times over for no added value.

So once the first lens says “agent,” run the candidate through this second lens before allowing more than one:

Ask this	If YES	If NO
Do the sub-tasks run genuinely in parallel (independent, no need to talk mid-flight)?	Consider multi-agent	Single agent
Do they need genuinely different toolboxes or expertise (not the same skill repeated)?	Consider multi-agent	Single agent
Is each strand itself discovery-driven (an unmapped path, not a fixed pull-and-summarise)?	Consider multi-agent	Single agent (it’s a workflow of specialists)
Is the combined work too large for one agent’s context to hold cleanly?	Consider multi-agent	Single agent
Does the value of parallelism/isolation exceed the extra tokens, coordination, and debugging pain?	Multi-agent viable	Single agent

You need all five to point toward multi-agent. Miss even one, and a single agent is the right and far cheaper answer. This is deliberately a high bar, because the default gravity of the industry pulls the other way.

8. The business leader’s checklist

The next time someone says “let’s put an agent on it,” ask these before nodding:

• ☐ “Can you draw me the flowchart of steps?” — If they can, you want a workflow, not an agent.
• ☐ “Does the path change based on what the process discovers along the way?” — If not, an agent is overkill.
• ☐ “How many tools does it need and who builds and maintains each one?” — Every tool is a real, recurring integration. Tool count is a proxy for true cost and fragility (Section 4.1).
• ☐ “What will this cost per transaction, at our volume, versus a fixed workflow?” — Make them run the numbers. Remember these are perpetual costs (Section 5).
• ☐ “How much slower will each transaction be?” — Latency is a real cost when a customer or a line is waiting.
• ☐ “When it misbehaves, how will we know why and which step or agent failed?” — Probe their debugging and observability story.
• ☐ “What can this agent do in the real world, and what happens if it does the wrong thing?” — Establish the blast radius and the human checkpoints (previewing Commandment 8).
• ☐ “Why not a single prompt or a simple chain first?” — Put the burden of proof on the more complex option, not the simpler one.
• ☐ “If it’s multi-agent can you tick all four boxes (parallel, specialised, too-large-for-one-context, coordination-worth-it), or is this org-chart cosplay?” — Force a hard justification for every agent beyond the first.

If the honest answers point to a known, repeatable path, you don’t have an agent problem. You have a workflow which, conveniently, is the subject of the next commandment.

9.0 Conclusion

An agent is not a magic upgrade. It is the same LLM you already use, wrapped in a harness that lets it choose its own path and act on its own and you pay for that autonomy in tokens, time, unpredictability, and operational pain. We didn’t assert this; we measured it: on a task that genuinely needed a workflow, the multi-agent version produced identical output at 7.4× the perpetual cost, ran ~4× slower, and was far harder to trust.

That price is worth it when the road is genuinely unknown and the task must adapt as it goes. It is wasted as our experiment showed, up to ~7× over, forever when the road is known, which describes the majority of business processes.

The literate leader doesn’t ask “can we make this an agent?” They ask “can I draw the flowchart?”  and reserve the steering wheel for the roads that genuinely have no map.

Invoke agents where they belong. Everywhere else, do not take their name in vain.

Next up — Commandment 3: “Honour the Humble LLM Workflow.”

If most processes don’t need an agent, what do they need? We’ll make the case for the unglamorous, reliable, cheap workhorse of business AI — the single well-crafted prompt and the fixed chain — and show how far a “boring” workflow can actually take you.