Everything in this series has been building towards a single argument: agentic AI is not a feature you add to a system. It is a delivery discipline, and organisations that treat it as one get to production faster than those that treat it as a technology evaluation.
This article sets out the lifecycle we use, and what each step is actually protecting against.
Design — before any code
1. Use-case selection. Choose a workflow with high mechanical content, meaningful volume, a recoverable failure mode and a clear owner. Most failed AI projects were mis-selected at this step, not badly built. The instinct to start with the most impressive use case is the instinct to fight.
2. Workflow mapping. Draw the current process on one page, with every step, every system it touches and every decision point marked. This almost always surfaces steps nobody had documented and disagreements about how the process actually runs — both of which are worth discovering now.
3. Data and source review. Which documents and systems will this depend on? Who owns them? Are they current? Are they machine-readable? What do the permissions actually allow? A great many AI projects are really data projects wearing a costume, and this is where you find out.
4. Agent role definition. Write, in a paragraph, what this agent is for and what it must never do. If that paragraph is hard to write, the scope is too broad. Narrow agents outperform general ones, as covered in the article on tools.
5. Tool design. What can it read, what can it write, what can it send. Read-write-send classification, scoped identities, argument validation, and an approval gate in front of anything irreversible.
6. Memory design. What may be retained, from what source, for how long, visible to whom, deletable how. Default to nothing and add deliberately.
7. Guardrail design. Step limits, cost ceilings, topics it must refuse, actions requiring approval, escalation triggers — all enforced in code rather than requested in a prompt.
8. Evaluation design. The golden set, the checks, and specifically what counts as confidently wrong. Written before the system exists, because writing it afterwards means writing tests the system already passes.
Prove it works
9. Prototype. Now build. With steps one to eight done, this is often the fastest part of the project — days or weeks, not months.
10. Human review. Put it in front of the people who do this work today. They will find things no test set anticipated, and their assessment of whether the output is genuinely useful is the one that matters.
11. Pilot. Run it against real cases, in parallel with the existing process, with everything logged. Produce evidence: accuracy, override rate, cost per case, time saved. This is the stage that converts an opinion into a business case.
Run it
12. Monitor. Traces, cost per case, escalation rate, human-edit rate — reviewed by a named person on a schedule, not collected and ignored.
13. Optimise. Feed real failures back into the evaluation set. Route easy cases to cheaper models. Fix the specific weaknesses the human-edit data has identified.
14. Scale. Extend to adjacent workflows, or widen the current one, with the same discipline applied again.
Then it loops. What you learn running the thing changes the design, which is why the last arrow in the diagram points back to the beginning.
The checklist
Before an agent goes live:
- Is the business workflow clearly defined and documented?
- Is there a named, accountable owner with a budget?
- Are the source documents and data approved, owned and current?
- Are tool permissions scoped to the minimum the task needs?
- Are human approval points defined for every irreversible action?
- Do test cases exist, with a recorded baseline?
- Are traces captured, with redaction decided?
- Is cost per task ceilinged and alerted on?
- Is there a rollback path and a working manual fallback?
- Has security review been completed?
- Has privacy and POPIA review been completed?
- Is business value measurable, with a pre-deployment baseline?
If more than two of those are unanswered, the project is not ready — and the remedy is almost always to narrow the scope rather than to work harder on the current one.
Why eight steps before code
The ratio is the point, and it is worth defending, because it looks like bureaucracy to teams who can produce a working prototype in an afternoon.
The counter-argument is empirical. Look at where AI projects actually fail in South African organisations: they fail on data that was not usable, on permissions that could not be honoured, on outputs nobody would take accountability for, on costs that were not predicted, and on an inability to demonstrate that the thing works. Every one of those is a design failure, and every one is discovered late and fixed expensively.
The prototype is not the risky part. The prototype is the cheap part. What is expensive is discovering in month five that the document library has no owner, or that the workflow you automated is one the business is about to change, or that legal will not approve the output without an audit trail you did not build.
Eight steps of design is perhaps two weeks of work for a well-scoped agent. It is the cheapest insurance available on the whole programme.
Where to begin
If your organisation is at the start of this, the first useful action is not a technology evaluation or a vendor process. It is steps one and two: pick the workflow and map it on one page.
That exercise will tell you more about your AI readiness than any maturity assessment, because it forces the questions that actually determine the outcome — is this process stable enough to encode, do we know where the data is, and who would own the result.
Most organisations that do this discover they have a shorter path to value than they expected, in a less glamorous place than they hoped. The tender checklist rather than the executive assistant. The intake step rather than the citizen chatbot. That is a good outcome, and it is the one that ships.
The idea worth keeping
Across fifteen articles, one principle has recurred in different forms, and it is the one worth carrying out of the series:
The future is not people chatting with AI. It is organisations designing safe, useful, measurable AI systems around real workflows — with trusted knowledge behind them, bounded tools in front of them, human accountability where the consequences land, and evidence that they work.
The model is one layer. Everything that determines whether the thing is valuable sits around it, and all of it is ordinary, tractable engineering and delivery discipline. That should be encouraging: it means the hard part of AI is the part your organisation already knows how to do.
How CloudNala can help
We run this lifecycle with organisations end to end — selecting the workflow, mapping it, assessing the data, designing the tools, memory, guardrails and evaluation, then building, piloting and instrumenting the result. Most engagements start with the two-week design phase, because that is where the expensive decisions get made and where a stalled AI programme usually turns out to be stuck.
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 Readiness Workshop or write to us at consult@cloudnala.co.za