A look back, written in 2026. By 2024 the question clients asked had changed from “can AI write this” to “can it answer from our own documents, and can it do the next step for us”. Those are retrieval and agents, and both turned out to be easier to demo than to trust.
Retrieval: answers with a source
Retrieval-augmented generation, RAG, is a plain idea. Before the model answers, find the passages in your own material that are relevant — policies, past letters, product sheets — and give it those to work from. The answer is grounded in something you can point at.
Most of the work is not the model. It is the documents: out of date versions sitting next to current ones, scanned PDFs with no text, the same policy in three places with three different figures. Retrieval faithfully finds whichever one matches best, including the wrong one.
Before building anything, ask who owns each document and how you would know it had changed. If nobody can answer, the system will quote stale information with total confidence.
Agents: doing, not just answering
An agent is a model allowed to take steps — look something up, fill in a form, draft a reply, update a record — and decide the next step from the result. That is where the value is, and also where the risk is, because a wrong answer on screen is a mistake and a wrong action in a system is an incident.
The agents that held up were narrow. A defined job, a short list of tools, and a clear point where they stop and hand over. The ones that tried to be a general assistant for the whole business were impressive for a week and quietly switched off.
The approval step is the product
Every working system I have built or seen has a person approving what goes out. Not as a formality: because the business carries the consequences, and a regulated firm in particular cannot say the software decided.
Yet the approval step is usually an afterthought — a list of drafts with an approve button. That is not enough to review anything properly. The reviewer needs to see what the system was asked, which sources it used, what it proposes, and what it is unsure about, all in one place.
Design that screen first. If a reviewer can check a proposal in thirty seconds and trust it, the system gets used. If checking takes as long as doing the job by hand, it will be abandoned, however good the model is.
What I would tell a small firm now
Pick one workflow with a clear input and a checkable output — an enquiry to triage, a document to summarise, a reply to draft. Get the source documents in order. Build the review screen. Measure how often reviewers change the output, and why.
That last number is the honest measure of whether it works. When it falls, widen the job. When it does not, the fix is usually the documents, not the model.
