Gaurav Sen · Gaurav Sen · Transcript & summary by WhipScribe
In four minutes it gives a crisp, interview-ready answer to the RAG versus agents question using one concrete travel-booking example.
Tap a chapter to open that moment in the transcript; the link to it is copied for you.
“Here it's more like answer compiler. Here it's a decision maker.” Gaurav Sen · at 2:33 — open in the transcript →
In a mock AI interview, Gaurav Sen is asked whether a travel app that books flights and hotels and plans trips should be built with retrieval-augmented generation (RAG) or with an agent. Sen picks agents. RAG, as he describes it, embeds a query, finds similar chunks in a vector database and hands them to the model as context, so the model only compiles an answer from a fixed, predefined path over data you own.
Agents differ on three counts in Sen's telling: they loop until they judge they have enough context, they call tools that change the real world such as making a booking or logging in, and they reach live data like fares and room availability that you neither own nor may be allowed to store. Adding a retry loop to RAG does not fix the static-data problem. Asked about agentic RAG, Sen calls it a combination that is barely distinct from agents and a confusing label. The clip ends on a joke about an AI whiteboard.
Gaurav Sen says a travel app that books flights and hotels is a use case for agents, not RAG. The assistant has to pull from several sources, loop until it has enough context, and take real actions such as making a booking or logging the user into a system. RAG can only read context from a store you own, so it cannot do the booking itself.
Gaurav Sen describes RAG as fetching context from a data store, usually a vector database, by matching the query's embedding to similar chunks and adding them to the prompt along a predefined path. An agent instead runs a loop, makes tool calls that act in the real world, and decides for itself when it has enough context. In RAG the LLM compiles an answer; in an agent it is the decision maker.
When the interviewer suggests letting the LLM ask for retrieval again until it has enough context, Gaurav Sen says the real problem is that RAG works on static data you own. Flight and hotel data is dynamic and belongs to other companies, so you cannot store it yourself and may not be allowed to. An agent goes out and fetches that live data while the LLM makes decisions along the way.
Gaurav Sen says agentic RAG is a combination: an agent sits in the middle, fetches real-time context through tool calls, and can treat a vector database as just another tool, choosing what context to fetch each time instead of following a predefined path. He finds it extremely similar to plain agents, calls the term confusing and useless, and jokes that it is mainly useful for a LinkedIn post.
Our own transcript of the public episode, with a timestamp about every 90 seconds. Tap a timestamp or the link button on a paragraph to copy a link that opens this page there.
0:00Hi. Hi Gaurav. Hi. Let's start this interview with a question itself. We have this problem of you know booking we are trying to build an application. While you know booking a flight, booking a hotel, giving a travel plan we want to use AI. Can you describe should we go for RAG or should we go for agent if I am trying to build an AI application? Yes, I got the AI application part. What are you trying to build? Because RAG, okay, I can describe the differences on the whiteboard that will help. What if you wanted to make a RAG application for the same use case? Is it possible? And if it's not, then why not? Let's see the primary difference between RAG and AHN. When we are saying retrieval augmented generation,
0:41what we mean by that is when passing context to the LLM to answer a user query we actually fetch it from a data store usually this is a vector database which tells us that this query after its embedding has been formed has high similarity with some other embedding in the vector database so pick up that chunk add that as context to the query agents are slightly different the use case we have picked up is correct for agents which is hotel booking and flight booking the thing is when the user is asking for some information your llm does not have the context in one shot then it needs a loop of context it needs to perform multiple actions by itself decide at some point that okay i have enough context now to respond to the user there are also sometimes
1:17actions which are making changes to the real world like for example it might go ahead and make a booking more simply it might actually log you into a system so it's an actual action that is happening it might change your last scene in some cases in this case the lm of course can't do all this but the agent does this agent can make tool calls and these tool calls are equivalent to performing actions all you can do is read here you can do more and also there is a loop in our use case this makes more sense because you are fetching from multiple sources and you are also taking actions. So what if I introduce a loop here? Like if the context is not like enough, my LLM will tell me to, you know, do this retrieval again and I'll perform the retrieval again.
1:55Then what? The problem here is that it is static data. It is data that you own. Outside you have dynamic data. Like you don't own the flight data. You don't own the hotel's data. You cannot store it yourself. Also, you may not be allowed to. In that case case you are actually going and you need to fetch this and a decision is being made by the llm so let's say that the number of flights that i have are very few and so the cost of the flights is very high and llm can make the decision that okay instead of going to booking.com i can go to airbnb also cheaper places maybe i can find as for rag this flow is usually predefined like these are the set of places you can query. This is how you will query.
2:28This is the response that you'll get. While here the LLM is, that's the reason why it's considered the brain here. Here it's more like answer compiler. Here it's a decision maker. Okay, okay. So basically the difference is here I have in the agents, I have the ability to extract real-time information. Yes. Right, I'm extracting real-time information and that in the case of RAG, the information is basically static or stored somewhere and I am able to extract only the information which is stored. Yes. Right? Yeah. So, you know, these days people are also talking about agentic RAG as a terminology also. What do you think about that? Is it like combination of both these techniques or is it like introducing something into RAG?
3:04What it is exactly? It's a combination. Agentic rag basically means that you have an agent in between which is fetching real-time context using tool calls. It can also fetch from a vector database that will become a tool call then. It makes a decision that hey, what kind of context do I want to fetch this time? So instead of fetching static context having a predefined path, you get rid of this predefined dynamic flow for fetching the context honestly speaking it is i feel it is extremely similar to agents i don't know why they call it agentic rag because you're using an lm to make decisions and compile the answer so yeah it's kind of confusing and i think it is useless also but rag and agents definitely have
3:36some difference yeah i agree i agree it's it's it's useless because retrieval and like knowledge retrieval is a concept basically yeah yeah that it's useful for a LinkedIn post sorry do I get the job now okay you can use AI whiteboard this is a whiteboard it's just a plain whiteboard no no it's a it's AI we have included AI you know AI whiteboard so this is literally your whiteboard. Okay, fine, sure. It's an AI whiteboard. Cool. You can start with the explanation. I'll just start with this AI marker. What should I say on this? I can't say anything.