The accounts-payable team at Gamtoos Valley Municipality, a fictional Eastern Cape municipality, processes a few thousand supplier invoices a month. A vendor demonstration showed an agent reading each invoice, deciding what to check, looking up the purchase order and posting the payment, end to end. It was impressive, and the team's first question was the right one: which part of this process do we not already know how to do?
The answer was almost none of it. Supplier registration, quantity against the purchase order and VAT reconciliation are rules the finance office can already write down. One step was different. Suppliers describe the same item in their own words, so "uPVC pipe 110 x 6000" on an invoice may or may not be the "110mm uPVC pressure pipe, 6m" on the order. That comparison needs judgement. The rest of the process does not.
This article argues for a simple discipline: use a workflow until a genuinely unknown step forces you to use an agent, and when it does, give the agent that step and nothing more. It builds on part 2 of Agent Claims Decoded, which classifies the patterns. Here the focus is on building and testing the one that most organisations actually need.
Three patterns, one question
Anthropic's widely cited guide, Building effective agents (December 2024), draws the line clearly. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths". Agents are "systems where LLMs dynamically direct their own processes and tool usage". It also gives the advice this series is built on: "we recommend finding the simplest solution possible, and only increasing complexity when needed".
Part 2 of Agent Claims Decoded noted that many organisations mix the two, with a workflow handling the common case and a bounded agent called only for exceptions. This article treats that mixture as a pattern in its own right: a workflow that contains one bounded agent step. The code still owns the path. At one point it hands a narrow question to a model, lets it explore within strict limits, and takes back a typed answer.
The test is the same one used throughout The agent loop in plain English: who chooses the next step? In a workflow the code does. In agent-led orchestration the model does, every time. In the middle pattern the code chooses every transition, and the model's choices are confined to the inside of one step.
Find the unknown before you choose the pattern
Teams usually start from the pattern ("we need an agent for this") and work backwards. Start instead from where the uncertainty sits. Four questions locate it quickly.
- Can you list the steps in advance? If a competent person could write the process as a checklist, the path is known even when individual steps are hard.
- Is the uncertainty in a step or in the path? Judging whether two item descriptions match is uncertainty inside a step. Not knowing which system to look at next, because the answer depends on what the last check showed, is uncertainty in the path.
- Who has to explain the outcome, and to whom? A municipal payment is explained to an auditor, a supplier and sometimes a council committee. The more an outcome must be explained, the more the path should be fixed and recorded.
- Can you test it with fixed cases? If you can write the expected result for a set of known inputs, a workflow or a bounded step will be easier to prove than an open loop.
For the Gamtoos invoices, every answer pointed the same way: a known path with one uncertain step.
The middle pattern most teams actually need
The redesigned process runs four deterministic checks first: supplier on the register, supplier matches the purchase order, quantity within the order, VAT reconciles. Duplicates are caught by invoice number. None of that needs a model, and running it through one would only add cost, latency and a new way to be wrong.
Only when an invoice passes those checks and its description still differs from the order does the workflow call the bounded step.
The step's contract is deliberately small:
- One question. Is this the same item as the order line, or not?
- Named, read-only tools. It may read the purchase order, the supplier catalogue and the delivery note. It has no tool that writes anything.
- A budget. At most three tool calls. If it has not reached an answer by then, it stops.
- A typed output. A finding (
same-item,different-itemorunclear), the evidence it relied on, and a confidence level. This follows the approach in From prompt to structured contract. - Validation on return. The workflow checks the output against the schema. A malformed answer is treated as
unclear, never guessed at. - No authority. The step recommends. The workflow applies a fixed rule to that recommendation, and a finance officer decides every exception.
That last point is where the pattern earns its keep. As Agent capability is not agent authority puts it, what a system can do and what it is permitted to do are separate design decisions. Here the agent can investigate, and only the workflow and the officer can act.
What the lab showed
To make this concrete, we built a small public-safe lab for this series (open source, MIT licence) with 61 synthetic invoices, including a duplicate, an over-billed quantity, seven invoices in the supplier's own wording and three vague descriptions. The model inside the bounded step is simulated, so the numbers show how the process behaves, not how any real model performs.
| Outcome | Invoices |
|---|---|
| Posted by the deterministic checks alone | 49 |
| Sent to the bounded agent step | 10 |
| Posted after a valid, high-confidence same-item finding | 7 |
| Bounded-step output that failed schema validation (sent to an officer) | 1 |
| Sent to the finance officer in total | 5 |
| Most tool calls used by any bounded step | 3 |
The useful number is the second one. The agent touched 10 of 61 invoices. Everything else was handled by rules that an auditor can read, that cost almost nothing per run and that behave the same way every time. The officer's queue holds the cases a person should see: two deterministic exceptions and three cases the bounded step could not settle, each arriving with the reason attached.
There is a second lesson in the lab. Every mismatch that was posted was settled by a catalogue alias, which is a sign that this part of the step could itself become a rule. That is the move the decision table below recommends: let the model show you which judgements are really rules waiting to be written down.
Test each pattern on its own terms
A common mistake is to test all three patterns with the same instrument, usually a handful of demo prompts. Each pattern fails differently, so each needs different evidence.
| Pattern | Test with | Evidence that it works |
|---|---|---|
| Workflow | Unit and scenario tests with fixed inputs and expected outputs | Every rule has a test, and the tests fail when a rule is broken |
| Bounded agent step | A labelled set of cases for that step alone, plus schema, budget and refusal tests | Accuracy on the labelled set, zero invalid outputs reaching an action, no budget overruns |
| Agent-led orchestration | Scenario runs with recorded traces, failure injection and evaluation of the whole path | Acceptable outcomes across repeated runs, traces a reviewer can follow, clean stops on failure |
The middle pattern is the easiest to evaluate because the step's question is narrow. You can label fifty invoice pairs as same or different and measure the step directly, which is the evaluation discipline described in Evals that gate real work. An open-ended agent rarely offers a target that clean.
When the unknown really is the path
There are processes where the path itself is unknown. When the municipality's billing system slows down at month-end, the next diagnostic depends on what the last one showed: the database, then the integration queue, then a certificate that expired overnight. No checklist can anticipate every branch, so an agent that chooses its next read-only diagnostic, within a turn and tool budget, can do useful work.
Even there, the same discipline applies at a larger scale:
- Keep the agent's tools read-only until there is evidence that its recommendations are reliable. Preventing expensive and destructive tool calls covers the controls.
- Make stopping explicit: a budget, a confidence threshold and a hand-over to the on-call engineer.
- Record the trace, because the path is the evidence.
- Resist splitting the work across several agents until responsibilities genuinely separate, as argued in Multi-agent is an organisational choice.
The cost of agent-led orchestration is not only tokens. It is variance, harder testing, longer reviews and a wider authority boundary. Pay it when the uncertainty is in the path, and not before.
A decision table
| Question | Workflow | Workflow with a bounded step | Agent-led orchestration |
|---|---|---|---|
| Can the steps be listed in advance? | Yes | Yes | No |
| Where is the uncertainty? | Nowhere material | Inside one or two steps | In the choice of next step |
| How repeatable are the cases? | Highly | Mostly, with messy inputs | Each case differs |
| Who explains the outcome? | The rules | The rules, plus the step's recorded finding | The trace and a reviewer |
| How is it tested? | Fixed cases | Fixed cases plus a labelled set for the step | Scenarios, traces and evaluation |
| Typical cost and latency | Lowest | Low, only where the step runs | Highest and most variable |
If a row pushes you rightwards, ask whether you can change the process instead. Often an unclear step becomes a rule once someone writes the rule down. For example, the supplier catalogue could carry approved aliases, so that most description mismatches never reach a model at all.
What this means for South African organisations
Public-sector finance in South Africa is audited: municipal financial statements are audited by the Auditor-General, and council oversight committees examine the findings. A process whose path is fixed and recorded is far easier to defend than one whose path was chosen by a model at run time. That does not rule out agents. It means the burden of proof rises with autonomy, and the middle pattern keeps that burden manageable.
Budget matters too. Every invoice that a rule can handle is an invoice that does not consume model capacity, does not wait on a provider and does not need evaluation. In organisations where skills for operating AI systems are scarce, a design that confines the model to one well-tested step is also a design that the existing team can run.
Key points
- Locate the uncertainty before choosing the pattern. Most processes have an uncertain step, not an uncertain path.
- A workflow with one bounded agent step keeps the code in charge of every transition and confines the model to a narrow question.
- Give the bounded step one question, read-only tools, a call budget, a typed output, validation on return and no authority to act.
- Test each pattern on its own terms: fixed cases for workflows, a labelled set for the bounded step, traced scenarios for orchestration.
- Reserve agent-led orchestration for work where the next step genuinely depends on what the last one found, and keep it read-only until the evidence supports more.
This is part 1 of Not Every Workflow Needs an Agent. For the vocabulary behind it, start with Everyone says they have agents.
How CloudNala can help
CloudNala runs agent design reviews for teams that are about to build or buy an agent for an existing process. We map the process, locate where the uncertainty actually sits, recommend the least autonomous pattern that can handle it, and specify the bounded step's contract, test set and stop conditions, so that you build what the process needs rather than what the demonstration showed.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agent Design Review or write to us at consult@cloudnala.co.za