Agentic AI sits on a stack. It does not erase the layers below it.

The board of Rooibos Agri Finance, a fictional South African provider of seasonal input finance to small and medium-sized farmers, asked its executive team for "an agentic AI strategy" last year. The request was sincere. Competitors were announcing agents, a supplier had demonstrated one, and the board did not want to be left behind.

The head of credit took the request apart in the next meeting. Rooibos already used explicit rules to decide who was eligible to apply. It used a statistical model to estimate the risk that a loan would not be repaid. It was piloting image analysis to read scanned title deeds and to check crop photographs submitted with applications. It wanted a generative assistant to explain decisions to farmers in plain language, in English or Afrikaans. And it had a genuine use for a bounded agent: chasing the documents applicants forget to send. "That is five different kinds of AI," she said. "Which one does the board want a strategy for?"

She was right, and the confusion is common. "AI" names a family of techniques that solve different problems, carry different risks and fail in different ways. This series sets out the family in plain language, for non-specialists and for technical leaders who have to explain it. This first part maps the layers and gives a way to choose between them. Part 2 shows how they combine in one service, and Part 3 explains why each must be evaluated differently.

What counts as AI, briefly

Definitions matter less than people think, but one is useful. The OECD's revised definition (November 2023) describes an AI system as a machine-based system that infers, from the input it receives, how to generate outputs "such as predictions, content, recommendations, or decisions" that can influence physical or virtual environments.

That list of outputs is a good map in itself. Predictions, content, recommendations and decisions are different things, and the techniques that produce them are different too. A purely rule-based system does not infer in this sense, which is why some definitions exclude it. We include explicit rules in the stack anyway, because in practice they sit alongside every other layer and are often the right answer.

Six capabilities, not one technology

The stack is easiest to understand as six capabilities, each answering a different kind of question.

Explicit rules. Encoded logic written by people: if the applicant has farmed for less than two seasons, they are not eligible for this product. Classical expert systems belong here. Rules are exact, auditable and brittle: they do only what was written.
Statistical prediction. Models learned from historical data that estimate a probability or a value: the likelihood that a loan will be repaid, given what is known. Most classical machine learning sits here. Predictions are useful and uncertain, and they are only as good as the history they learned from.
Perception. Neural networks, usually deep learning, that read unstructured input: text in a scanned document, the condition of a crop in a photograph, speech in a voice note. Perception turns messy input into structured facts, with some error rate.
Generation. Large generative models that produce new content: an explanation of a decision, a summary, a draft letter. Generation is fluent and flexible, and it can produce plausible statements that are wrong.
Workflows. Coded processes that orchestrate the other capabilities in a fixed order. A workflow may call a model, but the code decides what happens next.
Agents. Systems in which a model chooses the next step and the tool to use, within limits. Anthropic's guide Building effective agents (December 2024) describes agents as "systems where LLMs dynamically direct their own processes and tool usage", and contrasts them with workflows orchestrated "through predefined code paths".

The layers overlap; they do not replace each other

The popular picture is a staircase: rules, then machine learning, then deep learning, then generative AI, then agents, each newer step superseding the last. That picture is wrong in two ways that matter for decisions.

Deep learning is a kind of machine learning, and perception and generation are usually both deep-learning capabilities, often in the same model. Explicit rules sit outside machine learning but alongside it in almost every real service. The bounded agent is highlighted because it is not a new kind of model: it is an arrangement inside a workflow in which a generative model chooses some steps and relies on the other capabilities.

First, the categories nest and overlap. Deep learning is a kind of machine learning. Generative models are deep-learning models. Perception and generation often use the same model: a multimodal model can read a crop photograph and write a description of it. An agent is not a new kind of model at all; it is an arrangement in which a generative model, tools, rules and code work together, with the model choosing some of the steps.

Second, newer does not mean better for the job. An agent that decides eligibility is worse than a rule that decides eligibility, because the rule is exact, cheap, testable and explainable, and eligibility criteria are written down. A generative model that estimates repayment risk is worse than a statistical model trained and validated for that purpose. The newer layers add capabilities. They do not remove the reasons for using the older ones.

This is the central argument of the series: agentic AI sits on a stack, it does not erase it. Rooibos's bounded agent relies on rules to know what counts as complete, on perception to read what arrives, on generation to write the request, and on a workflow to decide what happens when the documents are in.

The Rooibos service, layer by layer

Here is how the five capabilities map onto Rooibos's input-finance service. Each has a different owner, a different way of failing and a different route of appeal.

Capability	Job at Rooibos	Owner	Typical failure	How a farmer challenges it
Explicit rules	Eligibility for the product	Credit policy owner	Rule coded wrongly, or policy unclear	Ask which rule applied and dispute the fact behind it
Statistical prediction	Repayment-risk estimate	Credit risk modelling team	Model learned from a population unlike today's applicants	Ask for review by a credit officer
Perception	Read title deeds, check crop photographs	Operations, with the engineering team	Misread a field, or misjudge a poor photograph	Correct the extracted fact
Generation	Explain the decision in plain language	Customer communications owner	Explanation that does not match the actual reasons	Ask for the reasons in writing from a person
Bounded agent	Chase missing documents	Operations	Asks for the wrong document, or asks too often	Contact the branch; the agent cannot decline an application

The last column is the one boards rarely ask about and regulators eventually do. For a credit decision, the question of how a person can challenge it is not optional. POPIA's section 71 restricts decisions with legal or substantial effects that are based solely on automated processing intended to profile a person, and creditworthiness is one of the examples the Act gives. Whether it applies to a particular design is fact-specific and a question for legal advice; A person needs a route to challenge the outcome covers the design side. Rooibos's answer is that a credit officer makes every adverse credit decision, with the rule outcomes, the risk estimate and the extracted facts in front of them. That includes ineligibility: when the rules find an applicant ineligible, a credit officer confirms the outcome, checking the facts behind the rule but not overriding the policy itself.

From problem to capability

The practical question is not "should we use AI?" but "which capability does this problem need?" CloudNala uses a short decision map.

Ask the questions in order for each job in the service. A yes points to a capability; most real services answer yes to several questions and combine the results. Explicit rules are highlighted because they come first: where policy can be written down, the most auditable capability is also the cheapest.

Ask, in order:

Can the answer be written down as a rule that the organisation owns? If yes, use explicit rules. Eligibility, thresholds, regulatory limits and document requirements usually belong here. The model should not be the law sets out why.
Is the question an estimate from historical patterns, with a measurable outcome? If yes, use statistical prediction, and validate it on data that resembles the population you will serve.
Is the input unstructured (images, scans, speech, free text) and the output a structured fact? If yes, use perception, and design for confirmation of the facts that matter.
Is the output new language or content for a person to read? If yes, use generation, grounded in the actual facts and reasons, and never as the source of those reasons.
Is the path of steps known in advance? If yes, a workflow orchestrates the capabilities above.
Does the next step genuinely depend on what the last step found? Only then consider a bounded agent, with limited tools and no authority over the decision. Use a workflow until the unknown forces you to use an agent develops this test.

Most real services answer yes to several questions, which is why they combine layers. That is Part 2's subject.

Common misreadings

"Generative AI replaces machine learning." It does not. A repayment-risk model and a language model answer different questions. Using one for the other's job is a design error, not progress.
"Rules are old-fashioned." Rules are the most auditable capability in the stack. In regulated decisions they are usually the backbone.
"An agent is the most advanced option, so it is the target." An agent is the most flexible option, and therefore the hardest to test and explain. It is the right choice when the path is unknown, not when the board wants to sound current. Agentic AI: what it actually is gives the plain-language background.
"A chatbot is our AI strategy." A chat window is an interface over one capability, usually generation. Why a chatbot is not an AI system explains what it leaves out.
"The taxonomy is settled science." It is not. The six capabilities are an architectural abstraction for making decisions, not a scientific classification, and real systems blur the lines.

What Rooibos told its board

The executive team went back with a one-page answer. Rooibos would not have an "agentic AI strategy". It would have a service design in which each capability did the job it was best suited to: rules for eligibility, a validated model for risk, perception for documents, generation for explanations, and one bounded agent for document collection. Each would have a named owner, an evaluation method and an appeal route. The board approved it, and asked for one thing in return: a quarterly view of how each layer was performing. Part 3 explains what that view should contain.

Key points

"AI" covers at least six capabilities: explicit rules, statistical prediction, perception, generation, workflows and agents.
The categories overlap and nest; newer capabilities add options without making older ones obsolete.
Agents sit on the stack: they depend on rules, perception, generation and workflows rather than replacing them.
Choose the simplest adequate capability by asking what kind of answer the problem needs, in a fixed order.
Each capability needs its own owner, failure analysis and route of challenge, especially in credit and other decisions about people.

Next: Part 2, Rules, prediction, generation and agency: when the layers combine. All parts are on the series page.

How CloudNala can help

CloudNala runs AI decision reviews for organisations that have been asked for an "AI strategy" and need a design instead. We take one service, map each step to the simplest adequate capability, name the owner, evaluation method and appeal route for each, and give your executive team a one-page answer it can take to the board.

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 Decision Review or write to us at consult@cloudnala.co.za