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.”