Why does an AI without context stay mediocre? You ask a business question, the AI answers fast, well phrased but often off the mark. A raw AI model often stays disappointing in a business setting.
The problem is not the model, it is the lack of context.
An AI model without internal data does not know your processes, has never seen your documents, does not understand your business rules and improvises as soon as the question moves beyond a general scope.
The result: generic answers, sometimes correct, often unusable in production.
And even worse, answers that are wrong but convincing.
Yet, as soon as you share context with an AI agent, everything changes, and that is what I wanted to show you in this edition.
And there is not just one way to feed data to an AI. Some are simple, others more advanced like RAG.
I will explain everything step by step.
4 concrete approaches to share context with AI
Before talking about advanced techniques like RAG, there are other ways to give an AI agent access to data.
Some are very simple, others more powerful, and above all each approach has its right use.
1️⃣ Classic filters: simple, fast, reliable
This is the most underrated approach. And yet, it is often the best one to start with.
The principle is simple: the AI agent does not reason over an entire database but applies precise filters such as date, status, category, ID, client…
Example:
“How many orders were confirmed yesterday for client X?”
→ The agent filters the relevant rows, does the calculation and answers.
It is fast, cheap and unambiguous.
Simple rule 👉 if a human would use filters in a spreadsheet, then use filters.
Here is an example with an agent on n8n to retrieve sales data:
2️⃣ SQL queries generated by AI
When you start wanting to aggregate, rank, compute averages or compare periods, filters reach their limits.
Here, you let the AI agent generate the relevant SQL query based on the database structure.
Example:
“What are our 3 most profitable products this quarter?”
The agent writes the SQL query, queries the database, retrieves a structured result and then explains it.
It is very handy if you have structured data, far more reliable than going through filters and then doing calculations, and well suited to business databases (CRM, sales, finance).
Simple rule 👉 If a human would use a pivot table or formulas → SQL.
Here is an example with an AI agent connected to a SQL database:
3️⃣ Sharing the whole document
Another classic approach you can take is to give the whole document to the AI to read (such as contracts, procedures, transcripts, reports…)
But there is a key limit = the context window. A model cannot ingest an infinite amount of text. Beyond a certain volume, performance drops, all the way to saturation.
With recent models, you can go up to 1M tokens (GPT 4.1 via API), otherwise 400k tokens for GPT-5.2.
The big upside is having no technical complexity, the full context, and it is very relevant for overall analysis or a summary.
Of course, it comes with limits (document length), processing cost on a part of the document that is useless. Not ideal when you have dozens or hundreds of documents.
Simple rule 👉 It is a good solution when the volume is under control and the need stays occasional.
In all other cases, you will want to be more selective, and that is precisely where RAG becomes interesting.
4️⃣ Semantic search: understanding meaning, not just words
This is where RAG comes into play. Instead of filtering, or sending everything to the model, you split the documents, turn the texts into vectors, and search for the passages closest in meaning to the question.
Example:
“How do I handle a customer dispute related to a late delivery?”
Even if the document never contains that exact phrase, the agent finds the right passages.
It is powerful because it works even if the words are not identical, it scales to thousands of documents and it is ideal for documentation, support, legal, and knowledge management.
I will explain RAG in more detail, but at this stage, keep in mind that you should share context with the model simply, then add intelligence when it is needed.
RAG explained, simply (no jargon)
The RAG (Retrieval Augmented Generation) is a fairly simple thing: retrieving information before answering. Exactly like a human who looks up the relevant documentation in a knowledge management space (Notion, sharepoint, google drive, ..).
Concretely, a RAG always follows the same logic:
- The question is asked
- The AI looks for the most relevant passages in your documents
- It uses only these extracts to generate the answer
Schematically, it looks like this:
👉 Important: the model does not answer with its “memory”, it relies on your data.
And that changes everything in a business when there is domain knowledge to hold and very specific logic to follow.
Splitting the documents
To search across your documents, you need to split them beforehand. That is the little subtlety. You do not give whole documents to the RAG.
They are split into small pieces (chunks), turned into vectors (embedding), stored in a dedicated database (aka vector database).
We do this because searching within 3 relevant paragraphs is more efficient than reading 200 pages for every question.
That is the classic RAG, but as you can see, it is linear, passive, and lacks the intelligence for the model to choose between a classic filter, a SQL query, a web search or RAG.
This approach has its limits: retrieval of passages that are “roughly” relevant, missing key information, insufficient context. And above all the model answers anyway, even if the data is bad.
We get well written answers that are sometimes incorrect. A big problem in production.
To go further, you need to give more control, more logic and a better decision-making capacity. That is exactly where the next step comes in: the agentic RAG.
Agentic RAG, when AI starts to reason
Agentic RAG is the next step. We are no longer talking about a simple pipeline, but about an autonomous AI agent.
A RAG agent no longer settles for “I search → I answer”
It becomes able to choose which tool to use (vectors, SQL, full document), check whether the context is sufficient, run a new search if needed, and combine several sources before answering.
Example with this diagram where the agent has 3 tools at its disposal (vector search, SQL search, web search):
It is this iterative loop, running until the goal is reached, that is interesting.
A user question may require, at the same time, an internal rule (doc), a numeric figure (SQL) and a client history (CRM).
A classic RAG would make a single call. Here, with agentic RAG, the agent orchestrates. We move from a linear logic to a logic of tool-assisted reasoning.
To go further, I will quickly zoom in on 2 essential elements to improve vector search.
Reranking: sorting after the search
The principle is simple, instead of retrieving only 3 or 4 passages,
we retrieve 10, 20, sometimes more… Then, a second model re-ranks the results, assigns a relevance score and keeps only the best ones.
For this, we use the reranking model from Cohere.
Here is an example on an n8n scenario with Cohere's reranker stepping in once the document passages have been retrieved.
Metadata: restoring lost context
When you split a document, you often lose the source, the date, the category, the client, …
Metadata serve to keep all the context. It lets the agent filter on specific chunks before the search, group related pieces and answer more global questions.
For this, we add metadata during vectorization, then we let the agent filter on this metadata during vector search. An example with “doc_date” :
A concrete case: a RAG agent that is useful in business
To move a little beyond theory, let's take a real case.
Context: a hotel group, several properties in France, has thousands of customer reviews spread across Google, Booking, TripAdvisor, …
The teams face several problems: too many reviews to read them all, recurring customer pain points… but poorly identified, and review replies that are sometimes inconsistent across hotels.
The goal with RAG: build an AI agent able to analyze customer reviews for the management team, detect friction points per property, help craft suitable replies, and produce a clear view for the field teams.
On the data side, customer reviews are scraped, stored in a SQL database, with internal rules in a vector database that carries business categorization metadata (welcome, cleanliness, breakfast, location…).
Concretely, we will have several scenarios:
1/ Vectorizing the customer reviews
The workflow vectorizes the customer reviews and enriches each review with metadata (property, rating, category). Here we use supabase to create the vector database.
2/ The RAG AI agent
The agent able to semantically search the relevant reviews, group weak signals and generate actionable summaries.
Examples of possible queries:
- “Summarize the negative reviews of the Annecy hotel”
- “What are the main pain points this month in Toulouse?”
- “How do I reply to a 4-star review mentioning breakfast?”
Here, this is just a concrete example to show the range of possibilities, but this kind of agent can be replicated across many other functions, including customer support to automate incoming tickets.
