Don't watch the AI type. Watch the structure around it.

Almost everyone in a technology role has now watched a language model produce a page of code in seconds. The first time, it is impressive. By the tenth time, it raises a harder question: so what?

Most teams do not struggle to generate code. They struggle with everything around the code. Who decided what to build? Did anyone check that decision before the build started? What is the agent allowed to change on its own? How does a reviewer keep up when agents open more pull requests than people can read? And how do you prove, before anything reaches production, that it works?

We recently took one product, one real customer problem and one feature, and walked it from customer feedback to a live deployment, with AI agents doing the work at every stage. The lesson we kept returning to was simple. Do not make it about watching AI generate things. Make it about how an idea moves through real roles, real decisions and real checks, all the way to production.

This article is the architect's view of that journey, and what it means for South African teams adopting agentic AI in their delivery work.

One product, one problem

The product was a working hotel-booking app. It was live in the cloud, and guests could search, compare and book.

Guest feedback told a different story. People knew exactly what they wanted, but they could not say it to the search box. A typical guest wanted "somewhere quiet near the beach, with a pool for the kids". The search only understood a city name. So guests opened ten tabs, compared hotels by hand, and gave up.

That one sentence became the whole brief: let guests describe their stay in their own words, and show the best matches first.

A single testable sentence from a real user is a better starting point than a feature list. It tells product what success looks like, tells architecture what the AI must understand, and later becomes the first test case in the evaluation set.

A relay, not a solo act

The most important design decision was not technical. It was to run the work as a relay between roles, each with its own agent, each with a written handover:

1. Product turned guest feedback into a requirements document.
2. UX turned the requirements into how the search should look and behave.
3. Architecture turned the design into a blueprint the agents could build from.
4. The build agents built it inside that blueprint.
5. Review and deploy proved it worked and took it live.

Each role used an AI agent for its stage, and each role still owned its decisions. The output of one role became the input of the next. Nothing lived only in someone's head, which is also what makes the work auditable later.

We used the open-source BMAD Method for this: a set of AI agents with a role and a skill for each stage, from product to architecture to build. If you are new to it, what BMAD actually is covers the method itself. The tooling matters less than the principle, though: the AI suggests, a person decides, and every decision is written down. You can apply the same relay with other spec-driven tools, or with a well-run team and a set of templates.

Two conditions before any design

Before any architecture was drawn, two conditions were set.

First: if the AI is unavailable, today's search must still work. No guest should get an error page because a model provider or a network is having a bad day. The AI has to be something you can unplug.

Second: the must-haves stay must-haves. If a guest's budget is fixed, or they are travelling with a dog, or they need a pool, the system never shows them something that breaks that rule just because it sounds like a good match. The AI helps the system understand the guest. It does not get to bend the rules.

Those two conditions shaped every decision that followed. This is where architecture earns its place in AI work. Not by picking the model, but by deciding where the model is not in charge. For teams in South Africa, the first condition carries extra weight: most frontier models are served from outside the country, priced in dollars and reached over links that are not always predictable. A feature that fails open to the old behaviour is a feature you can switch on with confidence.

RAG in plain words: look it up first, then answer

The technique behind the feature is retrieval-augmented generation, or RAG. In plain words: look it up first, then answer.

On its own, a language model answers from what it learned during training. Ask it about your hotels, your products or your policies, and it will sound very sure, and it can be wrong. RAG fixes that in three steps:

• Retrieve the facts that matter from your own data: descriptions, facilities, house rules, reviews.
• Augment the guest's question with only those facts.
• Generate an answer from those facts, and check the answer against them.

For enterprise teams, this is the difference between an AI that sounds helpful and one you can put in front of a customer. Our earlier guide, RAG explained simply, goes further into where these projects succeed and fail.

Draft first, then ask

The part that surprised people most was how the architecture agent behaved.

With product and UX, the agent asked questions as it went. With architecture, it worked differently. It drafted the whole architecture on its own first, from the requirements, the UX spec and the existing system design. Only then did it list what it could not settle by itself, and ask all of those questions in one round.

Some of those questions were not really questions. They were requests for permission. The project's rules said that changing the database or bringing in new outside software were "ask first" actions. So the agent stopped, waited for a person to say yes, and offered an alternative that would not need approval.

The remaining questions were the kind only a person can answer:

• Is the cloud setup the design assumes really in place?
• Whose account pays for the AI, and what caps the spend?
• If a guest types "this weekend" on a Sunday, what do they mean?

The last one is the best of the three. It is exactly the kind of edge case that slips through a design review, and exactly the kind of thing you want an agent to surface rather than guess. An agent that drafts first and then asks one well-formed round of questions respects people's time. An agent that asks permission at the right boundaries earns their trust.

The reviewers who said "not ready to build"

Next, AI reviewers checked the plan before anyone built anything. Think of them as building inspectors who visit before the foundations are poured.

The toughest reviewer came back with a blunt verdict: not build-ready. Its method is worth borrowing for any design review, with or without AI. It imagines two builders, each following the plan exactly, and looks for the places where their work still would not fit together.

It found real problems:

• Two fallback modes shared a name but behaved differently, so two builders would have implemented two different things.
• The test runner and the app would have run different code paths, which means the tests could pass while the app was broken.
• A routine database reset would have quietly wiped out the search index. That one was caught by a person double-checking the reviewer's work, which is a reminder that AI review adds to human review rather than replacing it.

All of it was fixed on paper, before a single line of the feature was written. A mistake fixed on paper is the cheapest mistake you will ever fix.

The blueprint: where the AI is, and where it is not

The final architecture was one pipeline in five steps:

Two things make this trustworthy. First, the AI steps and the deterministic code are clearly separated, so you always know which part to test and which part to watch. The must-haves and the ordering are ordinary code with ordinary unit tests. The AI steps are monitored and evaluated. This is the same split we argue for in AI-native does not mean AI everywhere: most of a well-built AI feature is still plain code.

Second, the AI sits behind a single connection point, like an appliance plugged into a wall socket. Unplug it, and the app works exactly as it did before. That is the first condition, kept.

It also pays to be honest about where a feature like this stands at any point in time. In this case, understanding the sentence and the must-have checks were built first, with simple keyword matching standing in for the meaning-based search until it was ready. Saying that out loud builds more trust with stakeholders than pretending everything is finished.

Harness engineering: fast does not have to mean fragile

If there is one idea every technology leader should take from this, it is:

Structure tells the agents what to build. The harness tells you whether they built it right.

A harness is everything around the agent that checks its work:

• Agent rules: a plain file that says what the agent must always do, what it must ask about first, and what it must never do.
• Automated gates on every change: is the code tidy, does it fit together, do the tests pass, does it build, does it work in a real browser the way a customer uses it?
• Evaluations: a fixed set of test searches, starting with the guest's own sentence, run against the feature to prove it still returns the right answers after every change.
• AI review of every pull request, before a person looks at it.
• Safe deployment: infrastructure written as code, and deployments that use short-lived identity instead of stored passwords.

The harness is what lets you move at agent speed without crossing your fingers. It is also where most of the engineering effort should go before you scale the number of agents. For a deeper treatment, see harness engineering: the workshop around the agent.

What this changes for people

AI-native delivery does not remove roles. It changes what each role spends its time on.

• Product owners spend less time writing and more time deciding. The agent asks, the product owner chooses, and says no when it matters.
• Architects spend less time drawing boxes and more time setting the conditions, the boundaries and the rules the agents work inside.
• Reviewers get pull requests written for them, with screenshots, a diagram of the change, a suggested reading order and exact steps to verify it.
• Release managers stop reading hundreds of code changes and start reading the harness results. Did the gates pass? Did the test searches still hold? Did the right person approve the risky changes? Their job moves from checking the work to checking the proof.

That last shift matters most in regulated South African sectors such as banking, insurance and the public service, where someone has to sign off a release and stand behind it. A release decision backed by recorded evidence is far easier to defend to an auditor than one backed by "the agent said it was fine".

Five lessons for teams starting out

1. Start with a real customer problem, not a model. One testable sentence from a real user beats a feature list, and it becomes your first evaluation case.
2. Put architecture in the room early. Set the non-negotiables, such as fallbacks, hard rules, data boundaries and spend limits, before anyone designs a screen.
3. Make "ask first" explicit. Write down what an agent may change on its own and what needs a person. Schema changes and new dependencies are good places to start.
4. Review the plan, not just the code. Have reviewers try to break the design on paper. It is the cheapest place to find a problem.
5. Build the harness before you scale the agents. Gates, evaluations, AI review and safe deployment are what make speed safe.

Is this real, or is it a demo?

That is the question executives ask most. The honest answer: the generation part is real and getting better every month. But the part that makes it enterprise-ready is not the model. It is the structure, the decisions and the harness around it.

The teams that get value from agents will not be the ones with the cleverest prompts. They will be the ones that decided, in writing, where the AI is in charge and where it is not, and built the checks that prove it.

How CloudNala can help

We help delivery teams bring AI agents into their work with the structure in place first. That means mapping your current flow from idea to production, defining the roles and handovers an agent-assisted relay needs, writing the agent rules and ask-first boundaries with your engineers, and designing the harness: the gates, evaluations, review steps and deployment controls that let you scale agents without losing control of what reaches production.

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.

Talk to us about guardrails for AI agents or write to us at consult@cloudnala.co.za