A document assistant that answers questions accurately, with citations, over a well-maintained library is a genuinely useful thing. It is also, for a lot of business problems, an incomplete one — because the answer is not what anybody wanted. The answer was a step towards something.
Consider the difference between these two outputs.
Both start from the same retrieved clause. In the first case, a bid coordinator now knows something, writes it on a list, and has to remember to act on it. In the second, the checking, the flagging and the drafting have already happened, and what arrives is a decision to approve rather than a task to start.
The gap between those two rows is the gap between retrieval and agency, and it is worth being precise about what actually changes.
What an agent adds
An agent is a system that can take a goal, decide on a sequence of steps, use tools to carry them out, look at what came back, and adjust. Four capabilities distinguish it from retrieval.
It can act. It has access to tools — read a database, create a record, draft a message, call an internal API — rather than only producing text. This is the substantive difference, and it is also where nearly all of the risk lives, which is why tool design gets its own article in this series.
It can plan across steps. Retrieval answers one question. An agent can work out that answering this question requires first looking up the client record, then checking the expiry date, then comparing it against the deadline.
It can react to what it finds. If the certificate is valid, do nothing. If it expires before the submission date, draft the renewal request. Branching on the result is what separates an agent from a fixed automation, and it is the reason agents cope with variation that rule-based automation cannot.
It can stop and ask. A well-designed agent escalates when confidence is low or the consequence is high, rather than proceeding. This is a feature, not a limitation.
When retrieval is enough
The upgrade to an agent is not free. It brings tool permissions, approval design, loop control, cost variability and a considerably larger surface for things to go wrong. Plenty of valuable use cases do not need any of that.
Stay with retrieval when the user is a knowledgeable person who wants information faster and will take the action themselves; when the output is advisory rather than consequential; when the underlying process changes often enough that encoding it would be wasted effort; or when the volume is low enough that the human step is not the bottleneck.
A policy assistant for a legal team, a "what does our standard contract say about X" tool, a research aid for analysts — these are retrieval problems. Adding agency to them increases risk without removing work, because the expensive part of those jobs is the thinking, not the doing.
When you need an agent
Reach for an agent when the sequence of steps is well understood and repetitive; when the volume is high enough that the manual version is a genuine cost; when the steps span systems that do not talk to each other; and when the failure mode of a mistake is recoverable or catchable by a human before it lands.
Document intake and classification, first-line request triage, compliance checklisting, follow-up drafting, reconciliation between two systems — these are agent problems. The judgement in them is real but bounded, the volume is high, and a person reviewing output is much faster than a person producing it.
The test that cuts through most debates: if you removed the AI entirely, would this job be a person following a documented procedure, or a person exercising expertise? The first is a candidate for agency. The second is a candidate for better retrieval.
What changes in how you build it
Moving from retrieval to agency changes the engineering questions.
With retrieval, the hard questions are about data — extraction quality, chunking, permissions, freshness. With agents, those questions remain, and a second set joins them: what is this thing allowed to do, what does it do when a tool fails, how many steps before it gives up, what does it cost when it goes badly, and who approves the output before it leaves the building.
That second set is not AI expertise. It is ordinary production system design — permissions, error handling, timeouts, budgets, audit trails — applied to a component that is non-deterministic. Teams that have run production systems before tend to find agents less mysterious than they expected and more demanding than they were told, and the demands are in exactly the places their instincts already point.
The realistic middle ground
In practice the most successful early deployments sit between the two. The agent does the mechanical work and stops short of the consequential act.
It reads the incoming document, extracts the fields, checks them against the rules, identifies what is missing, drafts the response — and then places all of it in front of a person, with its reasoning and sources visible, for a decision that takes ninety seconds instead of forty minutes.
This is not a compromise on the way to full automation. For a great many business processes it is the correct end state, because the accountability genuinely cannot be delegated. A person is answerable for the bid, the payment, the citizen response or the clinical decision. What AI removes is the preparation, not the responsibility.
Organisations that understand this early build systems people adopt. Organisations that pitch full automation tend to spend the pilot arguing about trust, and then quietly rebuild the approval step anyway.
How to start small
Start with a workflow you already documented. Build the retrieval layer first and confirm it answers accurately — an agent built on unreliable retrieval fails in ways that are much harder to diagnose, because you cannot tell whether it acted wrongly or was informed wrongly.
Then add exactly one tool. A read-only one, ideally: look up a record, check a status. Run it in shadow mode, where it produces its recommendation and a human does the work independently, and compare the two for a few weeks. When it agrees with the human reliably, give it a tool that writes something reversible — a draft, a flag, a comment. Keep the send, the submit and the approve with a person.
The next article follows what happens inside the agent while it does all this — the loop it runs, and why it needs limits.
How CloudNala can help
We help organisations make this call honestly — which processes justify an agent, which are better served by good retrieval, and where the human decision point has to stay regardless of what the technology could do. Then we build the version that starts read-only and earns its permissions, rather than the one that demos well and never passes a risk review.
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