The most important decision a forward deployed team makes is not which model to use. It is where probabilistic intelligence belongs in the process, and where it does not.
"Use an agent" is not a design. A real workflow is a sequence of steps with different characteristics: some follow exact rules, some route work between people, some interpret messy documents, some carry legal or financial accountability. Each step deserves the execution mode that suits it. The result is almost always a mixture, and the AI part is usually smaller than the first slide suggested.
Five execution modes
| Execution mode | Best suited to | Example |
|---|---|---|
| Deterministic code | Stable rules and exact calculations | VAT calculation, schema validation |
| Workflow automation | Predictable sequences and routing | Create a task once a request is approved |
| Machine learning | Pattern prediction from structured evidence | A fraud propensity score |
| Generative AI | Language, unstructured content and bounded judgement | Draft a case summary from documents |
| Human decision | Accountability, ambiguity and high-impact exceptions | Approve an exceptional payment |
The right architecture often uses all five. The mistake is to reach for the fourth row because it is new, when the first row would be cheaper, faster, exact and explainable.
A plain-language decision test
For every proposed AI step, ask:
- Can ordinary rules solve this reliably?
- Does the task need language, images or ambiguous context to be interpreted?
- Can the output be checked before it causes harm?
- What happens when the model is uncertain or wrong?
- Does a person have to remain legally or operationally accountable?
- Is there enough evidence to evaluate performance?
- Does the benefit justify the cost and the new failure modes?
The first three questions do most of the sorting:
Sandveld, step by step
Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative.
With the operating map from Part 2 in hand, Ironbark's pod worked through Sandveld's invoice workflow one step at a time with the AP manager and the senior clerk.
- Reading the invoice. Invoices arrive as PDFs, scans and phone photos in dozens of layouts. That is interpretation of unstructured content, so it is a job for AI, but the output is checked deterministically before anything else uses it: the supplier must exist, totals must add up, VAT must reconcile, dates must be plausible.
- Matching the invoice to the order and the delivery. The three-way match between invoice, purchase order and goods-received note is an exact rule. Deterministic code.
- The fresh-produce weight tolerance. Once written down, the clerks' 2% rule became an ordinary rule with an owner. Deterministic code. It did not need AI at all; it needed someone to notice it.
- Explaining an exception. When an invoice does not match, a clerk needs to know why and what to do. Drafting that explanation from the invoice, the order, the delivery and the supplier's history is a good use of generative AI, because a clerk checks it before acting.
- Releasing payment. Always a person. Accountability for paying suppliers sits with named staff under Sandveld's financial controls.
- A change to a supplier's bank details. Never AI. This is the classic route for invoice fraud. The agent's only job here is to stop and hand over to the existing verification process, where a person phones the supplier on a number already on record.
- Informal approvals on WhatsApp. Neither AI nor automation. That was a process problem, and the fix was a proper approval step in the workbench.
The final design used AI in two places. The original vendor's design had used it everywhere, which is part of why it failed.
The autonomy ladder
Autonomy should grow with evidence, not with enthusiasm.
| Level | Agent responsibility | Human responsibility | Suitable stage |
|---|---|---|---|
| 0. Observe | Analyse historical work without affecting it | Perform the normal process | Discovery |
| 1. Assist | Retrieve, summarise or draft | Decide and act | Early pilot |
| 2. Recommend | Propose a decision with evidence | Approve or reject | Controlled production |
| 3. Act with confirmation | Prepare an action and request approval | Confirm material actions | Mature workflow |
| 4. Act within policy | Execute bounded, reversible actions | Review exceptions and samples | Proven low-risk scope |
| 5. Autonomous domain | Coordinate several steps within strict controls | Own policy and incident response | Rare, well-evidenced cases |
The critical point is that different steps in the same workflow sit at different levels.
At Sandveld, intake classification and the posting of clean matches reached Level 4 once the evidence from Part 4 supported it. Exception recommendations stay at Level 2: the agent proposes, a clerk decides. On supplier bank details, the agent is not even at Level 1. It does nothing except stop. Asking "how autonomous is the agent?" is the wrong question; ask how autonomous each step is.
Human in the loop needs design
An "approve" button does not create meaningful control. The reviewer needs:
- the proposed decision or action;
- the evidence used;
- missing or conflicting evidence;
- the policy and threshold applied;
- model confidence, but only where it is calibrated;
- alternatives and consequences;
- a way to correct the record;
- enough time and skill to review.
If reviewers approve hundreds of low-value cases a day, they will rubber-stamp the queue. Automation bias and review fatigue become system risks. Sandveld's design addressed this directly: clean matches no longer reach a clerk at all, so the clerks' queue holds only the cases that genuinely need judgement, each with an evidence pack showing the invoice, the order, the delivery note, the variance and the agent's draft explanation. Our article on human oversight that shows its work goes further into what makes review meaningful.
Architecture by responsibility
The architecture follows the same split. A workflow orchestrator routes each step to the service that owns it: rules and deterministic services, an AI reasoning service, or a human decision workbench. All three write to the systems of record, and all three emit evidence into one evidence and evaluation layer.
The system of record stays authoritative. The AI service must not quietly create a second truth inside prompts, memory or a vector store. At Sandveld, the ERP remains the record of what was invoiced, matched, approved and paid; the AI never holds an approval the ERP does not know about. Part 5 covers how that was achieved with an ERP that had no API for posting invoices.
Model choice follows task design
An FDE may start with one ecosystem to build depth, but the architecture should stay able to evaluate alternatives. Choose models on:
- task quality on representative data;
- latency and throughput;
- input and output cost;
- context, tool and modality requirements;
- regional availability and where data is processed;
- security, contractual and regulatory constraints;
- operational maturity and support;
- portability and switching cost.
At Sandveld, the extraction step needed strong handling of phone photos of handwritten and printed invoices; the explanation step needed concise, grounded writing. Those were evaluated separately, on Sandveld's own invoices, and did not have to be the same model.
Model agnosticism is not achieved by putting a generic interface in front of prompts, tool schemas and behaviour that are tightly coupled to one provider. Portability needs evaluation assets, abstraction at sensible boundaries and a tested migration path.
The design record
For every AI-enabled decision, record:
decision:
business_purpose: "Explain why an invoice did not match, and recommend an action"
current_owner: "AP clerks"
proposed_execution: hybrid
source_evidence: [invoice, purchase_order, goods_received_note, supplier_history]
permitted_actions: [draft_explanation, recommend_action]
prohibited_actions: [approve_exception, release_payment, change_supplier_details]
evaluation_method: "Golden set from six-week sample; clerk agreement rate"
human_checkpoint: "Clerk accepts, edits or rejects every recommendation"
failure_path: "No draft; case shown to clerk with raw documents"
rollback_or_correction: "Clerk correction recorded against the case"
accountable_owner: "AP manager"
This makes the architecture reviewable. It also stops "use an agent" from standing in for an actual design decision. For the broader question of how much authority an AI system should hold, see AI may assist, but not inherit authority.
The short version
Assign every step an execution mode. Deterministic code first; AI where interpretation is genuinely needed; people where accountability lives.
Test before you reach for AI. Exact rule? Interpretation needed? Checkable before harm?
Set autonomy per step. One workflow can run Level 4 in one place and Level 0 in another.
Design the review, not the button. Give reviewers evidence, time and authority, and keep trivial cases out of their queue.
Keep one truth. The system of record stays authoritative.
Previous: Part 2, the process map is usually fiction. Next: Part 4, the demo is the beginning. See every part on the series page.
How CloudNala can help
We help teams decide where AI belongs in a workflow before anyone builds an agent: working step by step through the operating map with the people who own the work, assigning each step to rules, automation, AI or a person, setting autonomy per step, designing review queues that people can actually use, and writing design records your risk and audit teams can follow.
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 AI Opportunity Sprint or write to us at consult@cloudnala.co.za