The first three parts of this series each argued a piece. Citizen builders bring knowledge nobody else has. Agents execute faster than the surrounding process can absorb. Experts hold the judgement that decides whether software can be depended on. Put together, they describe an operating model — and the interesting thing about that model is that the order matters more than the components.
Most organisations already have all three ingredients. Business users are building things. Agents are writing code, whether or not anyone has approved that. Senior engineers are making judgement calls. What is usually missing is any sequencing, which is why the same three groups can produce either a functioning delivery system or a slow-motion argument.
The top band is the whole model
Read that diagram from the top and the sequencing becomes obvious. The experts do their work first, and it is a different kind of work from reviewing what other people built.
Before anyone builds anything, somebody decides what the approved starting points are, where different classes of data may live, which actions require a human, what the review path looks like for each risk level, and what the automated gates catch. That work is upfront, it is reusable, and it is what makes everything below it fast.
Run the identical five steps in the other order — citizens build, agents accelerate, and experts are called in afterwards to assess the result — and you have the anti-pattern that part six is about. Same people, same tools, same enthusiasm, an entirely different outcome, because the controls arrived as a judgement on completed work rather than as a shape the work could take.
This is the single most useful thing in this series and it fits in a sentence: experts design the environment, they do not inspect the output.
Triage is what makes it humane
The second necessary piece is a routing decision, made early and made honestly.
Without it, an organisation has only two responses to a prototype: wave it through, or bury it in enterprise controls. The first creates the risk. The second is worse in a subtle way — it teaches people that mentioning what they have built results in weeks of process, so the next thing gets built quietly and nobody finds out until something goes wrong.
Note that most things land in the first two columns and should stay there. A triage process that keeps escalating everything is not being careful; it is failing at its actual job, which is to identify the small number of tools that have become load-bearing and leave the rest alone.
The question that drives the classification is deliberately not technical. It is not how complex is this or what did they build it with. It is: who is harmed if this is wrong, and how badly? A twenty-line script that emails customers is a higher tier than a sophisticated internal dashboard, because the blast radius is what matters.
The seven-step version
Written out as a process, for the organisations that need it in that form:
- A business user identifies a workflow that hurts. They are the ones who can, and this is the cheapest reliable source of automation candidates you have.
- A prototype gets built — by them, with AI, roughly. This is discovery, not delivery. Its value is the requirement it makes concrete.
- Triage classifies it. Personal tool, team workflow, department tool, enterprise system. Honest classification, based on consequence.
- The platform supplies the starting point appropriate to that tier — template, environment, access pattern, data rules.
- Agents do the execution inside that approved path, at whatever speed they manage.
- Experts review at the risk points, not at every point. Data movement, identity, money, anything customer-facing.
- The thing is monitored, and what it teaches goes back into the guardrails.
Step seven is the one that gets dropped, and dropping it is what makes governance calcify. Guardrails written once and never revised become the rules people work around. Guardrails that change because production taught you something stay credible.
What each group has to give up
Operating models fail on the concessions, not the diagram. Each of the three groups has to surrender something they are currently attached to.
Citizens give up the right to make something official on their own. Building freely is encouraged. Deciding unilaterally that the finance team now depends on your tool is not. This is a real constraint and it should be named as one.
Engineers give up gatekeeping as the primary mechanism. If the answer to every non-standard request is a queue, people route around the queue, and you get less visibility than before. The job becomes making the safe path the easy path — which is considerably more work than saying no.
Leadership gives up the idea that governance is free. Someone has to build the templates, maintain the pipeline, staff the review capacity and keep the register current. If that is nobody's actual job, it will not happen, and the operating model will exist only as a slide.
Where this tends to break
Three failure modes we see repeatedly.
The register is theatre. An intake form exists, nobody fills it in, and the organisation believes it has visibility. The test is simple: pick three tools you know people use daily and check whether they are in the register.
Review capacity is assumed rather than staffed. The model requires expert attention at the risk points. If the two people qualified to give it are already fully committed, the model degrades to rubber-stamping within a quarter.
Triage escalates everything. Usually because the person triaging is judged on incidents and not on friction. Escalating is always the personally safe choice, which is why the incentive has to be corrected deliberately.
The point of all of it
The organisations that get value out of this are not the ones where everyone can build anything. They are also not the ones where a central team controls all software creation — that model was already failing before AI, because it could never keep up with demand.
They are the ones where a large number of people can build things quickly, inside an environment where the dangerous mistakes are difficult to make, and where a small number of experienced people spend their time on the environment rather than on inspection.
That is a genuinely different way of organising delivery, and the technology is the least difficult part of it.
How CloudNala can help
We help organisations put the sequence in the right order — usually starting with the triage and register, because that is the cheapest step and it immediately tells you how big the actual problem is. From there the work is designing the approved paths for each tier, deciding where expert review genuinely earns its cost, and building the feedback loop that keeps the guardrails honest. It is deliberately incremental: the first version of this should take weeks, not a transformation programme.
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