RAG, or how to give an AI the power of a business tool

A RAG is what lets an artificial intelligence become a business tool, specific and relevant to our work. The word is technical, the principle is not, and Laurent Alexandre recently declared that a company head who does not know what it is should be replaced. The provocation is excessive, but it touches on what I call the professional use of artificial intelligence. Understanding RAG means understanding how we add the power of an AI to our work tools, from a simple conversation in a chatbot to business tools that are partly automated.

An AI that is relevant in general, but beside our situation

For a long time we said that an AI answered through statistics, that it gave back whatever came out on average from everything it had read. That is no longer true at all, at least if we choose otherwise. We can stop there, at a surface use, but today we can go much further. Recent models reason, even when little is asked of them. They produce a line of thought, they articulate, and their answer can be relevant.

The problem lies elsewhere. That reasoning does not draw on our data. When the question is about a profession, the AI may have a great deal to say, because it has read enormously about professions and knows their general outlines. But when the question is about our organisation, our current case, the internal procedure of a specific team, it has none of the information that would make its answer fit. It knows neither our collective agreement, nor a client’s history, nor the latest version of a regulation, and its answer, lacking that anchoring, stays on the surface.

Handing your data to an AI immediately raises the question of its security and confidentiality. An organisation cannot pour its sensitive information into just any tool without knowing where it is processed, who can access it, and what remains of it afterwards. This is why the subject is not simple, and why it calls for real work. But it is also on this condition that the AI brings genuine business power. There is a tension here that is better stated from the outset. We only draw a specific usefulness from an AI by entrusting it with our data, and doing so requires having seriously given ourselves the means. RAG is precisely what makes it possible to hold both ends, because it keeps the base under the organisation’s control.

An AI only becomes useful to our situation if we feed it that situation. RAG is the technical way of automating this feeding across all our documents.

Retrieval, then generation

RAG stands for Retrieval Augmented Generation. The setup links a language model to a document base that we build for it, and it works in two stages.

• Retrieval. When a question arrives, the system does not pass it straight to the model. It first searches the base for the passages that relate to the question. This search works by closeness of meaning, which makes it possible to find a relevant passage even when it does not use the same words as the question.
• Generation. The retrieved passages are slipped into the model’s context, just before it forms its answer. The model then answers by drawing on those documents, the ones from our organisation, up to date, rather than on its general knowledge. The answer stays within the scope of what was provided, and we can trace back to the sources that produced it.

This technique differs from another with which it is often confused. Training or retraining a model on your data, what is called fine-tuning, means modifying the model itself, a heavy and costly operation that must be redone whenever the data changes. RAG does not touch the model. It leaves the model intact and gives it access to a base that we update whenever we like, by adding or removing documents. Lighter, more flexible, keeping the data under the organisation’s control, this is the approach that has established itself in companies for putting AI at the service of their internal data.

From chatbot to business tool

We first meet RAG in a simple form, that of an assistant we have given a few documents to as attachments in a conversation, and that we question by chatting. But its reach goes much further. RAG can be mobilised automatically, inside a database management system and a business tool whose large parts are automated.

I measure this against an experience I lived more than twenty years ago, without AI. I was directing the Pocket Films festival at the Forum des images, and I had built with FileMaker Pro a business tool that managed the whole festival. I am not advertising FileMaker Pro, but it is a system that lets you create complete business tools very quickly, and it has been used in very large companies for forty years. The one I built evolved over the festival’s six years, as my team’s needs arose. It first managed the people we lent phones to, then the lent phones, then the films made, then their posting on a local network even before YouTube existed, where anyone could click on a film and give their opinion, with statistics that helped me make my choices. It then took on the preparation of screenings, the programme grid, the writing of the catalogue texts, the management of guests and hotels, and finally what we called outreach, that is, all the screenings elsewhere. Everything fit within a single tool, which grew each year.

Each week, I asked my teams what magic function they would have needed to gain time and efficiency, and I added to the tool what I could. Directing the festival also meant this, listening to what came from them, to their concrete needs, and helping them in their work rather than deciding in their place. It is a stance as much as a technique.

Today, in a system of this kind, you can build a RAG as you go, and deposit the relevant context data in it as it appears. Taking the same example, the structured content of the base, the film summaries, the documents about people, the directors’ biographies, the articles written about the festival, would feed the RAG. And the tool could then, for an outreach screening request received by email, analyse that request and prepare on its own a suitable programme proposal. We can even imagine it collecting the emails directly, processing them, and preparing the proposal without being asked, before a human validates it. Proposals gain in relevance, the number of possible partnerships grows, and the festival’s outreach is strengthened by it. If the answers sometimes lack depth, we enrich the RAG ourselves, with articles on the history of cinema, or the books of Gilles Deleuze, and the answers become informed by them.

I know that it is thanks to this tool that we were able to receive a huge number of films and build demanding programmes from experimental audiovisual objects, some of them improbable. By automating the mechanical tasks, it let us work on the substance, on the meaning of these films in the history of cinema. That is where the festival drew its quality and its impact. And the key is not only the tool’s existence, it is that it evolved with our needs. Between its first version in 2005, when the festival was created, and its last, it had gained in functions, in simplicity, in ease of use. It had taken shape at the same time as our way of working.

This is where Laurent Alexandre’s formula shows its limit. Reducing the matter to the efficiency of a leader who would or would not know is to fall short. What counts is the business tool, and RAG is what lets an AI become its heart. It is the story of the tool in the human adventure, except that here the tool is digital. We measure poorly, I think, how much a tool matters. We go too fast, we want it to work for us right away, when it is the attention we give it that ends up changing our way of working. There is, for this reason, no opposition between tools, even those of artificial intelligence, and our humanity. A tool remains a tool, and it is the use we make of it that gives it its value.

For those who run an organisation

It is for those who run an organisation that the stakes are highest, and this is even where we should begin. An organisation that wants to make use of AI on its own data quickly discovers that the quality of the result does not depend on the model it chooses, but on the quality of the base it gives it. A poorly ordered base, with redundant, outdated, unstructured documents, produces mediocre answers, whatever the tool. This is the blind spot of many corporate AI projects, where the solution is installed before the data has been organised, and where people are then surprised by the results.

This observation brings new occupations into view, and it calls for real professional skills. Two families are intertwined in it, which are too often confused. The first are purely technical in the computing sense, database management, the administration of cloud services, security, cost control. The others fall under an expertise on the business subject itself, which consists in knowing which documents matter, in shaping them so a machine can find its way in them, in choosing what goes into a RAG, in checking that retrieval brings back the right thing, in keeping the base up to date. That expertise is not technical in the computing sense, it is technical in the sense of the profession. It is exactly what I had done for the Pocket Films festival, without being a computer specialist, by knowing my subject and knowing how to organise it. A leader can be that person, the one who holds the expertise of the profession and shapes it, on condition of not seeing this work as beneath them.

The most sought-after skill in 2026, in organisations that are seriously deploying AI, is not after all the mastery of models, but that of the data and of the infrastructures that run them. This foundation lets an AI work at the scale of an organisation, and it is the one most lacking today. A leader does not need to know how to build a RAG, any more than they need to know how to configure a server. What they need to understand is that the work of structuring the data conditions everything else, that it takes time, that it stays invisible, and that it cannot be fully delegated to a contractor. Whoever decides without knowing this buys a solution without having prepared the ground that would make it useful.

For those who want to stay employable

At the scale of one person, the same mechanism opens an accessible path, provided one develops one’s own documentation abilities and methods. Understanding RAG means grasping why a well-titled document, written in a machine-readable format such as Markdown, filed in a coherent folder, is worth far more than a rich but shapeless document. It means grasping why the person who organises a team’s internal base holds a more strategic position than it seems. Structuring documents, moreover, also means knowing how to get the AI’s help to structure them, so they are useful and indexed in the best way. Building a structured set of notes and documents, what is sometimes called a second brain, is already preparing the material for a personal RAG.

One might object that AI is intelligent, that it learns everything, and that it is therefore pointless to tidy up so much beforehand. That is partly true, but learning everything each time consumes enormous resources. When we give it well-structured data, when we have organised our thinking ahead of it, we raise the AI to a higher level of competence while consuming far less energy on each query. The care we put into organising our documents is not a preliminary chore, it is what makes the tool both better and more frugal.

The same curiosity quickly leads to the question of the business tool. With a system like FileMaker Pro, you create business tools of great richness, which you can evolve yourself at the pace of your needs. With a note manager like Obsidian, you build a structured personal base that you can, with the right modules, turn into a RAG. The skill is not to program the setup, it is to understand what it does, in order to give it what it needs, and to take one’s own tools seriously.

Setting up a RAG without being a technician

You can start right now, without writing a line of code. The main consumer tools already offer a RAG, in the form of small dedicated spaces. In ChatGPT, these are the custom GPTs and the Projects. In Gemini, these are the Gems. In Claude, these are the Projects, where you drop files into the knowledge base and where RAG activates by itself as soon as that base becomes too large to fit all at once. In every case, the principle is the same, you create a space, you deposit documents in it, and the tool cuts them up, indexes them, and goes to find the useful passages for each question. It is a RAG, in a lightened form, a kind of individual mini-RAG.

This way of doing things is better than a widespread habit, which consists in loading everything into a conversation and continuing to chat. A conversation has a limited memory. When it grows long, it ends up exceeding what the tool can store in its working memory, and it then starts to compact it, that is, to summarise the older exchanges to make room. Through that summary, detail is lost. The documents pasted at the start become blurred, then disappear. A RAG does not work that way. The base stays available at all times, it is not summarised, you can modify it, and the tool returns to it for each question, in the same state. That is what makes it a stable memory, where the conversation is a memory that wears away.

An interesting case is that of Claude Cowork, which works on a folder on the computer. Cowork indexes that folder, separates storage from reasoning, and consults that index rather than loading everything into memory, which brings it close to a RAG. The difference from a Project is that it deposits on the disk, by itself, what it produces, and reindexes as it goes, so that its base grows without the limit of a conversation. It is an agent that feeds its own RAG as it works.

Moving from individual use to the organisation

A Project or a Cowork is an individual use, tied to an account. As soon as we enter an organisation, the question changes in nature. We can no longer think of these tools each on their own, we have to think of them collectively, which requires becoming more professional. The right question becomes that of a shared, connected RAG, that each person accesses while chatting with the AI.

It is possible, and we can stay within Claude. On the Team and Enterprise plans, a Project can be shared with the whole organisation, and its RAG activates automatically when the base grows. An administrator deposits the reference documents, makes the project accessible to the team, and each person who asks a question queries the same base. This is the simplest path, with no infrastructure to build.

To go further, when the sources change constantly, emails, shared spaces, business tools, we connect them through connectors, following the open standard called MCP. Claude then queries a set of internal sources chosen by the organisation, and the administrator decides what is exposed and to whom. We keep control of the perimeter and the access. And for a very large volume of documents, or a requirement of sovereignty over where the data is hosted, we set up a dedicated document base, linked to the AI, which can be hosted on our own servers. This is the most demanding case, but it is necessary only for organisations that have needs of that scale.

The path therefore amounts to a progression. We start with an individual space to understand, we move to a shared project for a team, we connect connectors when the sources are live, and we build a dedicated infrastructure only if scale or confidentiality require it. From one stage to the next, the decisive factor does not change. It is the care given to the documents we hand to the machine that makes the quality of what it gives us back.

Forging your tools, a choice older than AI

The method I used for Pocket Films is nothing new. Many people work this way, and it is even the core business of a large company like Salesforce. These systems are called CRMs, there are festival management tools, and business tools for almost every sector. Using a business tool is therefore common. What is less common is to build your own, or to evolve it yourself to fit it as closely as possible to your practice. The people who take this trouble gain a far greater efficiency, and above all a specific one. They can dig into their singularity, deepen what sets them apart, and differentiate themselves by that very means.

And this has nothing to do, at the start, with artificial intelligence or with RAGs. Choosing to forge your own tools with digital technology, or relying on ready-made tools, is a way of approaching work that long predates AI. RAG merely extends this choice, by adding the power of an AI to those tools. Those who already had the culture of the custom-built tool will find familiar ground in it. For the others, it is a good occasion to discover what changes when you take your tools seriously.

A snapshot of June 2026

I am writing all this in June 2026, and these things will evolve fast. The product names, the functions, the ways of doing that I describe will probably be outdated within a few months. This article could become obsolete fairly quickly, and I hope so, because that will mean these uses have spread and the tools have become simpler. What will not age is the principle beneath it. An AI becomes useful to our work when we give it, with care, the material of our work.