Agentic RAG: The Loop Is Easy, the Blast Radius Is Not

A retrieval assistant that gives a wrong answer is a mild embarrassment. Somebody reads it, notices it is wrong, and the cost is a few minutes.

The same system with a create ticket tool attached and a bad plan behind it opens 40 tickets before anyone looks. The same system with an email tool sends a message to a customer that cannot be recalled. The same system with write access to a CRM changes a field on 200 records and nobody knows which 200.

That is the whole subject. Agentic RAG is a small change to the architecture and a large change to the consequences, and the engineering that matters is not the planning loop that every tutorial draws. It is what the loop is allowed to touch, on whose authority, and how you get back.

What agentic actually adds

Plain retrieval is a single pass. A question comes in, the system searches, the model writes an answer from what it found. One retrieval, one response, done.

Agentic adds three things.

Multiple retrievals, chosen by the model. The first search returns something that raises a new question, so the system searches again with a better query. This alone fixes a real weakness. Ask a plain retrieval system which of our contracts expire before the new policy takes effect and it does one search and fails, because that is two lookups and a comparison.

Tools beyond search. A calculator, a database query, a calendar, a ticketing API. The model chooses which to call and with what arguments.

A loop with a stop condition. It keeps going until it decides the task is done or something stops it.

The first two are genuinely useful and mostly safe. The third is where the interesting failures live.

Worth saying plainly, because a lot of budget is spent on this: most tasks people describe as agentic need only the first item on that list. Multi step retrieval with no write tools solves a large share of real requests and carries almost none of the risk. Build that, see what remains, and add tools to the remainder.

Read is forgiving, write is not

Sort every tool into two piles before designing anything else.

Read tools search, fetch, query, calculate, summarise. A wrong call returns wrong information into the context, the model usually notices, and the worst case is a bad answer with a citation the user can check. Cheap to get wrong.

Write tools create, update, delete, send, schedule, pay. A wrong call has already happened by the time anyone reads the output. The model cannot notice, because the observation it gets back is a success response.

That asymmetry deserves to be visible in the code. Read tools and write tools should not be registered through the same path, should not share a permission model, and should not look alike in the trace. Teams that treat them uniformly end up with a configuration file where search_documents and send_email sit adjacent, and somebody eventually enables the wrong row.

A useful discipline: a write tool must be requested by name in a design review, with a named owner and an answer to what happens when it fires wrongly. Read tools can be added freely.

Authorisation is per tool, per user, per object

Here is the failure we find most often in agentic systems that already ship.

The retrieval side has been done properly. The user's identity resolves to a document set, search is filtered, and the assistant only sees what the person may read. Somebody thought about it, and it works.

Then the tools were added and they run under a service account.

So the assistant will refuse to show a user a contract they cannot read, and will happily update a record they have no business touching, because the tool authenticates as the application rather than as the person. The retrieval permission model and the tool permission model were built at different times by different people, and only one of them was treated as a security question.

Three checks belong on every write call. Is this user permitted to perform this action at all. Are they permitted on this specific object. And is the agent, acting for them, permitted to do it without asking, or does this one need confirmation.

The third is not the same as the first two, and it is the one that has no analogue in ordinary software. A user may be fully entitled to delete a record by hand and you may still not want an autonomous loop doing it on their behalf at three in the morning.

If you have read our piece on choosing between retrieval and fine tuning, this is the same argument extended. Permissions decide the architecture, and they decide it earlier than people expect.

Three tiers of action, sorted by how hard they are to undo

Reversibility is the property to design around, and it sorts cleanly into three tiers.

Tier one, reversible without trace. Draft a document, stage a change, add an internal note, run a query. If it was wrong, delete it and nothing happened. Let the agent do these freely. Most of the value people want from agentic systems lives here and it is often overlooked because it feels unambitious.

Tier two, reversible with effort. Create a ticket, update a record, book a meeting room, apply a label. Undoable, but somebody has to notice and do it, and there may be a downstream effect already in motion. These need an iteration cap, a rate limit and a compensating action written before the tool ships. If your create ticket tool has no close ticket path defined, it is not ready.

Tier three, irreversible. Send an external email, issue a payment, delete data, submit a filing, publish. No undo exists. These require explicit human confirmation on every call, and the confirmation has to show what will happen rather than that something will happen. A dialogue saying the assistant would like to send an email is useless. One showing the recipient, subject and body is a control.

The sorting exercise takes an afternoon and changes the architecture more than any framework choice. It also tends to reveal that two thirds of the requested tools are tier one, which makes the project cheaper and faster than the original scope suggested.

Loops need budgets, and not only token ones

A planning loop that can call tools can call them repeatedly. Three limits, all of them necessary.

An iteration cap. Hard stop after a set number of cycles, typically six to ten for enterprise tasks. Past that, hand to a human with the trace. Loops that exhaust a token budget instead of an iteration budget fail in a worse way, because they stop mid task with side effects already applied.

A per tool call cap within a run. Create ticket, maximum one. Send email, maximum one. Search, maximum eight. This is the limit that turns the 40 tickets story into a 1 ticket story, and it costs about an hour to implement.

A wall clock timeout. Because a tool that hangs will otherwise hold a loop open indefinitely, and the user has long since navigated away.

There is a fourth constraint that is less obvious and matters as much: idempotency on write calls within a run. If the loop retries a step after a timeout, and the first attempt actually succeeded, you get two of whatever it was. Every write tool should accept an idempotency key derived from the run id and the step, and the receiving system should honour it. Where the receiving system cannot, the agent layer has to remember what it already did in this run and refuse the duplicate itself.

Traces, because somebody will ask what happened

At some point a director will ask why the assistant did a specific thing on a specific date. The answer needs to be a record, not a reconstruction.

A usable trace holds, for every run: the user, the question, every retrieval with the passages returned, every tool call with its arguments and its response, every model decision between them, and the final output. Keyed so one run can be pulled up in seconds.

Three payoffs, and they arrive in this order.

Debugging. When an answer is wrong, the trace shows immediately whether retrieval missed the document or the model mishandled it. Those look identical from outside and need different fixes.

Evaluation. Real traces are the only honest source of test cases, because they contain the tasks users actually attempt rather than the ones the team anticipated.

Accountability. The one that eventually matters most. An action taken in a user's name with no record of why is a problem no amount of accuracy fixes.

Fifty to 100 hours, and every team that skipped it has rebuilt it within a year.

Evaluating a task is harder than evaluating an answer

One more thing changes when a system starts acting, and it catches teams who evaluated their retrieval system properly.

For plain retrieval you grade an answer. Was it right, was it grounded in the cited passage, did it refuse when it should have. One question, one output, one judgement.

For an agentic run there is no single output to grade. There is a trajectory. The system might reach the correct answer through six sensible steps, or through eleven steps including two wrong turns it recovered from, or through a lucky guess that happened to land. All three look identical if you only score the final response, and only the first one will hold up when the task changes slightly.

So the evaluation set has to hold tasks rather than questions, and grade three things separately.

Did it finish. A surprisingly large share of agentic failures are not wrong answers but runs that hit the iteration cap and stopped. Measure completion rate before accuracy, because a system that completes 60 per cent of tasks has a different problem from one that completes 95 per cent and gets a fifth of them wrong.

Were the steps sound. Grade the trajectory, not just the destination. A run that called the right tools in a sensible order with correct arguments is repeatable. One that stumbled into the answer is not, and it will fail on the next variant.

What did it touch. For any run involving write tools, the evaluation has to assert on side effects. Exactly one ticket created, no emails sent, the record updated with these fields and no others. This is the assertion that catches the forty tickets case in testing rather than in production, and it is the reason multi step evaluation sits at 60 to 120 hours rather than the 20 an answer grader would take.

Build the set from real traces once you have them. Thirty to fifty genuine tasks beat two hundred invented ones, because invented tasks are written by people who already know how the system works.

What agentic RAG costs, with the hours shown

The rate is $40 to $100 per hour by role. Tool definitions and tracing sit near the floor, authorisation and reversibility near the ceiling, and mixed teams blend to around $65.

This assumes a working retrieval system already exists. If it does not, that build comes first and lands around 320 to 670 hours on its own.

Module	Hours	What it covers
Tool definitions and schemas	50 to 110	Read and write registered separately, arguments validated, failure shapes defined
Planning loop and budgets	60 to 130	Iteration cap, per tool caps, wall clock timeout, stop conditions
Authorisation layer	70 to 150	Per tool, per user, per object, plus the autonomy question
Reversibility and compensating actions	60 to 130	Tier sorting, undo paths, idempotency keys on every write
Trace logging and replay	50 to 100	Full run capture, retrievable by run id, replayable
Multi step evaluation	60 to 120	Tasks rather than questions, graded on the whole trajectory

Worked example. Tools 80 plus loop 95 plus authorisation 110 plus reversibility 95 plus traces 75 plus evaluation 90 equals 545 hours. That is $21,800 at $40, $54,500 at $100, and about $35,425 at a $65 blend.

The full span across the six modules runs 350 hours at every minimum to 740 at every maximum.

Deliberately excluded: inference spend, and the cost of the systems being written to. Both are usage rather than build.

Look at the distribution. Authorisation and reversibility together are 205 of the 545 hours, and the planning loop that every tutorial covers is 95. That ratio is the point of this article.

Where to draw the human line

Autonomy is a dial, not a switch, and most teams set it too high on day one because a demo with a confirmation step feels less impressive.

A defensible starting position: tier one autonomous, tier two autonomous with caps and a notification, tier three always confirmed. Then move the line based on evidence from traces rather than on confidence.

Two signals tell you when a tool has earned more autonomy. The confirmation has been approved without modification for a meaningful run of consecutive calls, several hundred rather than several dozen. And the trace shows the agent's arguments matching what a human would have entered, rather than being corrected at the confirmation step.

One signal tells you to move the line back: any single incident that required a compensating action. Move it back immediately, investigate, and re earn the autonomy. Teams that debate whether an incident was serious enough usually have a second one while debating.

There is a version of this that fails quietly, worth naming. Confirmation fatigue. If the assistant asks for approval forty times a day, people stop reading and start clicking, and you now have the risk profile of an autonomous system with the latency of a supervised one. Fewer, better confirmations beat more of them, which is another argument for keeping tier three genuinely small.

A sequence that ships something safe

Weeks 1 to 2. Sort every requested tool into the three tiers, with an owner and an undo path per tier two and three item. Expect a third of the list to be dropped once somebody has to write the undo path.

Weeks 2 to 4. Multi step retrieval with no write tools at all. Ship it. A meaningful share of the requested value arrives here, at almost no risk, and it tells you which write tools are actually needed.

Weeks 4 to 7. Authorisation layer, before the first write tool rather than after it. Tools added to a system with no authorisation layer are never retrofitted cleanly.

Weeks 7 to 9. Traces and replay.

Weeks 9 to 12. First tier two tools, with caps, idempotency and notifications.

Weeks 12 to 15. Tier three, confirmed, with the confirmation showing the full payload.

Fifteen weeks, roughly 545 hours, and something genuinely useful in production by week four with nothing that can act on its own.

The failure mode to avoid is the reverse order: a loop with every tool wired in during week two, a demo that impresses everyone, and six months of trying to add safety to a system whose users have already learned to trust it.