Part 4 of the series The 10 Commandments of AI in Business: Choosing the right intelligence for the right problem.

1.0 Where we left off

Commandment 2 spent a lot of words and one experiment telling you what not to build. We proved that for a known, repeatable process, an agent costs up to 7.4× more, forever, for identical output. We ended on a promise,

“You don’t have an agent problem. You have a workflow which, conveniently, is the subject of the next commandment.”

So here we are. If most business processes are known roads that don’t need an agent behind the wheel, the obvious question is: what should we be driving instead?

The answer is deeply unglamorous, and that’s exactly why it gets overlooked. It’s the single well crafted prompt and the fixed chain of prompts ,the boring, cheap, reliable workhorse that quietly solves the majority of real GenAI problems in business. This commandment is a defence of the humble. Because in the rush to look cuttingedge, teams skip straight past the tool that would have worked.

1.1. The two humble workhorses

Recall the decision lens and hierarchy ladder from Commandment 2. The current commandment lives entirely on the bottom two rungs, the ones everyone is embarrassed to build or state publicly, because they don’t sound impressive in a stand-up.

The critical distinction from an agent is that, in a workflow, the developer owns the path. You decide step 1 >> step 2 >> step 3. The LLM never asks “what should I do next?”. It only fills in the blank you hand it. No reasoning loop, no growing context, no runaway tokens, no unpredictability. Just a dependable pipeline.

The mindset shift for leaders: stop asking “how do we make this AI impressive?” and start asking “what’s the simplest thing that reliably works?” The measure of a good AI implementation is not its sophistication. It’s the ratio of business value to complexity and the humble workflow wins that ratio far more often than anyone admits.

1.2. The six highest-ROI, lowest-risk patterns

Here’s the good news that the hype obscures. A huge share of everyday business processes collapses into just six patterns, and every one of them is a single prompt or short chain job. Learn to recognise these, and you’ll spot the “why don’t we build an agent?” over reach immediately.

Notice the common thread in the final column. In all six cases, verifying the output is both cheap and fast. That low verification cost is precisely what minimizes risk. While AI evangelists in your company might rush to “agentise” these patterns, using an agent here is almost always overkill. You aren’t asking the model to make high stakes, autonomous decisions. You’re simply asking it to transform text that a human or automated validator can instantly double check. That makes these tasks the natural domain of simple, humble workflows, which already account for a massive chunk of real business operations.

2.0. Three business processes, and where the humble workflow fits

Let’s honour the recurring principle of this series i.e. Look at the actual process, step by step, and place the tool where the nature of the work belongs.

Example A : Contract summarisation (a single prompt, then a small chain)

The process:

Receive contract >> Read & understand >> Identify key terms >> Summarise obligations & risks >> Flag anything unusual >> Route to the right reviewer

The naive instinct is “build a contract analysis agent.” But look at the path, it never changes. Every contract goes through the same steps in the same order. You can draw the flowchart. So it’s a fixed chain, not an agent:

Three fixed prompts and a routing rule. No agent. Cheaper, faster, predictable and every step’s output is verifiable against the source contract. The human lawyer stays the accountable reviewer (a nod back to Commandment 1‘s HR-grievance lesson: keep judgement human).

Example B : Ticket triage (you’ve already seen this one win)

This is the exact task we benchmarked in Commandment 2 and it’s the poster child for the humble workflow:

Classify >> look up >> draft >> route.

We proved a fixed 3-call chain did it at 1/7th the cost of the multi-agent version, for identical output. I won’t re-litigate it. I’ll just point at it as Exhibit A. When a process is this predictable, the humble chain isn’t the compromise. It’s the correct answer.

Example C : Meeting-note extraction (a single prompt does most of it)

The process:

Record meeting >> Transcribe >> Extract decisions & action items >> Assign owners & due dates >> Format as minutes >> Distribute

The entire “intelligent” part is one well designed extraction prompt. No chain, no agent. This is the kind of task where a team spends three weeks architecting an “agentic meeting assistant” when a single prompt with a good schema would have shipped on day one and worked more reliably.

2.1. The catch: “simple” is not the same as “reliable”

Here’s the honest part, and the reason this commandment isn’t just “use fewer tokens.” A humble workflow is only valuable if it’s trustworthy in production, and a lasily written prompt is not. The gap between a demo prompt and a production workflow is exactly where most simple GenAI projects quietly fail.

The difference comes down to three engineering disciplines. None of them are glamorous, and all of them matter more than the model choice:

1. Structured outputs. Don’t let the model reply in free prose and then try to parse it with fragile string matching. Force it to return a defined schema (JSON with named fields), using the model’s structured-output / function-calling feature. Now the output is machine-usable and “validatable” by design.

2. Templates. Don’t hand-write a fresh prompt each time. Build a prompt template with slots for the variable parts (the contract, the email, the transcript) and a fixed, tested instruction around them. This is what makes the workflow repeatable the same instruction runs on every input.

3. Validation (and retry). After the model responds, check it before trusting it: did it return valid JSON? Are all required fields present? Are dates real dates, amounts real numbers? If validation fails, retry once with the error fed back. This one cheap loop turns a flaky prompt into a dependable component.

The principle: an agent gets its reliability from the model reasoning its way out of trouble (expensively, unpredictably). A humble workflow gets its reliability from you engineering the trouble out in advance, cheaply, and deterministically. That’s not a downgrade. It’s often the more professional choice.

3.0. A small experiment on reliability, not cost

In Commandment 2 we measured cost. It would be lasy to run the same experiment again. But there’s a different axis worth measuring here and it directly answers the  “is simple actually trustworthy?”.

The setup:

An extraction task (pull order_id, account_email, and issue_type from support messages), run many times, two ways:

• Design A : Naive prompt: “Extract the order id, email and issue from this message.” This is a Free-text reply.
• Design B : Engineered workflow: the same task, but with a forced JSON schema + validation + one retry on failure.

We measure not dollars, but parse success rate (did we get valid, complete, machine-usable output?) and consistency(same input >> same output across runs).

Batch of 4 messages × 5 run(s) each.

The full runnable script is available on request; I’d encourage running it on your own data, as the naive failure rate depends heavily on your inputs.

The lesson is the mirror-image of Commandment 2. There, the agent’s unpredictability (the ± spread) was the villain. Here, the villain is a lasily-built simple prompt and the hero is a well-engineered one. The humble workflow is not automatically reliable; it becomes reliable when you add structure and validation. And crucially that reliability costs you nothing extra in tokens. It’s pure engineering discipline, not more compute.

This reframes the whole commandment: the choice isn’t “cheap-but-flaky simple workflow” vs. “expensive-but-smart agent.” Done right, it’s “cheap and reliable workflow” vs. “expensive, unpredictable agent.”

For the six patterns above, the humble option wins on both axes.

4.0. Guardrails and lightweight evaluations

One more discipline separates a workflow you can trust from one you merely hope works. Leaders should insist on it before any GenAI goes into a real process:

• A small “eval set.”: Take 20-30 real examples with known-correct answers. Every time you change the prompt or the model, run it against this set and measure accuracy. This is the single cheapest insurance policy in AI, and astonishingly few teams do it.

Example : Support ticket classification

A SaaS company routes inbound tickets into five categories: Billing, Bug, Feature Request, Account Access, Other. They, pull 80 historical tickets that a senior support lead has already labelled correctly. This becomes the frozen eval set. Each entry is simply:

When someone tweaks the classification prompt, they run all 80 and get a number: “91% match, up from 87%.” That’s a decision they can defend one which is validated by a proper eval set

• Guardrails on the output. Simple checks the workflow enforces automatically: is the classification one of the allowed labels? Is the summary within length? Does the extraction contain no invented fields? Reject and retry if not.

Example: Allowed-label check (classification)

allowed = {"Billing", "Bug", "Feature Request", "Account Access", "Other"}

if model_output not in allowed:

    retry()          # e.g. the model returned "Payment Issue"

The model occasionally invents a label like “Refund”. The guardrail rejects anything outside the five permitted values and forces a retry, so a rogue category can never reach the routing system.

• A human checkpoint sized to the stakes. Low-stakes, easily-reversed output (e.g. spot check a draft email). High-stakes or irreversible (e.g. human sign-off, always  for a contract clause sent to a client) . This scales the human-in-the-loop idea from Commandment 1.

None of this requires a data-science team or a fancy platform. It requires the discipline to treat a “simple” workflow as a real production component because it is one.

5.0. The decision lens: is this a humble workflow job?

When a GenAI proposal lands on your desk, run it through this before approving anything more complex:

Rule of thumb: Before anyone builds an agent, prove that a single prompt and a fixed chain can’t do it. In the majority of business tasks, they can and they’ll be cheaper, faster, and more reliable.

5.1. The business leader’s checklist

The next time a team pitches a GenAI build, ask:

• ☐ “Which of the six patterns is this really?” : Most business tasks are one of them.
• ☐ “Can we do this with a single prompt or a fixed chain first?” : Make the simpler option the default, and the complex one justify itself.
• ☐ “Is the output structured and validated or are we parsing free text and hoping?” : Desired for production reliability.
• ☐ “Where’s the eval set?” : If they can’t show you 30 examples with known answers, it isn’t production-ready.
• ☐ “What happens when it’s wrong, and who checks?” : Making human judgement a supreme gate.
• ☐ “What does this cost per transaction versus the fancier alternative?” : Tie it back to Commandment 2. Simple usually wins on cost and reliability.

If the honest answers are “it’s an extraction task, one prompt with a schema does it, here’s our eval set, and legal signs off on red-flags” :

Congratulations!!!

You have a humble workflow. Ship it, and put the engineering effort into reliability, not sophistication.

6.0 Conclusion

There is a quiet bias in every organisation right now. Complexity is mistaken for competence. Building an agent feels like real AI work. Writing one excellent, structured, validated prompt feels like… not much. So teams routinely over-build and end up with something more expensive, slower, and less reliable than the humble alternative would have been.

This commandment is a plea to resist that bias. The single prompt and the fixed chain are not the consolation prize you settle for when you can’t afford an agent. For the vast majority of business language tasks, summarising, extracting, classifying, drafting, translating, reformatting: they are the right answer, and done with a little engineering discipline (structure, validation, evals), they are both the cheapest and the most trustworthy thing you can put into production.

Honour the humble LLM workflow. It does more of the real work than anything with a fancier name.

Next up : Commandment 4: “Honour Predictive AI and Automation as Thy Elders.”

We’ve now defended the simple generative workflow. But there’s an even more overlooked truth. A great many problems people throw generative AI at aren’t language problems at all. They’re prediction problems, or plain automation. In the next post we rehabilitate the unfashionable elders : machine learning, forecasting, and old-fashioned rules and show how to spot a “predictive problem wearing a generative costume.”

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:

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:

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:

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:

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:

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:

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.

(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:

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:

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.

(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:

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:

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

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:

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:

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.