There's a huge race in AI right now to define the next generation of RAG. While you've probably heard claims that RAG is dead way too many times by now, those are often overhyped and solutions are generally too simplistic. Many players in the industry are converging on the idea of a knowledge or context layer between your agent and its underlying data sources as a much better alternative to conventional RAG. But there's not a lot of agreement about what those solutions actually look like and they're generally not one size fits all. And now Redis, one of the real pioneers in high speed data retrieval has just announced Iris with an architecture that's really worth taking seriously
if you're building AI agents that rely on large scale fast changing data spread across many different data sources because these are serious weaknesses of most AI retrieval systems. And by the way, we have no affiliation with Redis whatsoever.
We've in fact never done a sponsored video on this channel, but we can all take inspiration from Redis' architecture here without even having to use their stack directly. Let's start with some context. Back a few months ago, the CEO of Redis was quoted saying, I've seen fewer examples of real successful production agents than I would have imagined in terms of anything outside of engineering. And to be fair, AI agents have often under delivered in production systems across the board, and there's a huge gap between a flashy demo and one that survives real world data and real use cases. He also wrote in this blog post, the hardest problems in production AI are no longer solved by model choice. They show up at runtime, stale state, slow retrieval, fragmented memory, disconnected tools, and sessions that fail to compound. And the example he uses here is a customer support bot. A customer might ask, why is my order late? Think about everything the agent needs to actually answer that question, especially in bigger organizations,
such as the customer database, the order system, the shipping provider, the ticketing tool, and the policy docs. Naive rag is almost never going to work in these kind of use cases, and it can still be quite a challenge for a lot of agentic rag configurations.
We've covered similar solutions to this on our channel before, such as giving your AI agent locked down access to a read only view on your database. And we go very deep into agentic retrieval strategies within our AI architects course linked in the description. But let's look through exactly what Redis are offering here. Before we dig into it here, they have a good list here of requirements for agents to function at scale. Of course, everything mentioned here is a focus of their product offering, but it is still a good list to give some context upfront.
First off, the agent should be able to navigate throughout a large amount of data. It should be able to traverse relationships,
understand entities, discover relevant context and so on. Secondly,
context should be retrievable quickly,
which in most cases is a very true requirement.
Agent to grad systems can often be very slow if they have quality retrieval strategies behind the hood and they may work through many loops to retrieve the correct information. Third, context that is always up to date. Agent retrieval pipelines are often too slow for anything near real time, and the day that your agent retrieved ten minutes ago might already be stale and out of date. And the fourth is the self improvement aspect
that most AI agents don't really remember interactions,
information, and context as they should. So what exactly is Redis Iris and how are they looking to solve those challenges and meet those requirements? First off, Iris is a stack of Redis services and not all of them are new. Iris has just been announced at the time of recording this video, so this is definitely not a hands on tutorial or review of their service, but rather an explainer of the retrieval architecture they're using, which is quite different to many other AI context layer solutions in the industry. At a very high level, you have the data in the source systems,
Oracle, Postgres, MongoDB,
and you have this Redis data integration
that continually captures,
changes, and syncs them into Redis data structures. So now you've got an operational copy of the data within Redis. Your agent can then interact with this data using the Redis context retriever, which makes a CLI and MCP tools available to the agent. We'll talk about that in a minute. Redis agent memory then tries to persist what it learns across sessions using a combination of both short term and long term memory. And then Redis LAN cache caches responses
and then tries to short circuit anything that's been answered before. So your agent never actually touches the operational data directly. It interacts with the data in the Redis DB that's been synced by the Redis data integration
via MCP or CLI that's made available by the Redis context retriever. So let's dig into those components because you probably have more questions than answers at this point. Let's start from the start with this Redis data integration, which is currently in public preview. RDI implements a change data capture pattern to sync data from a source database such as Postgres or Oracle, Snowflake, or Mongo,
and tracks that and updates the data into the Redis data structures. This is how Iris is covering the requirements that we mentioned earlier of being always up to date. RDI mirrors a fresh copy of your data for the agents to hit at high speed, and Redis are the experts at lightning fast retrieval, so I wouldn't doubt them that much in that regard. And since they're making a copy of the data from the operational systems
means that the agent is not going to bombard the transactional systems with requests because hitting operational data directly could be quite an issue for busy agentic systems where agents could be making thousands of times more requests than a human would. It also means that the data can be modeled in a manner that's more efficient from both the speed and indexing perspective
and also in a more flattened denormalized
structure that will make it a lot easier for your agents to interact with via tools. Of course, this idea of copying operational data to a different source is not exactly new. That approach is often used for analytics and cash in, for example. Next, the Redis context retriever is the one that aims to deliver on the requirement for the agents to be able to navigate through your knowledge base. The idea here is that you define models of your business data, the entities, the fields, the relationships,
and these can then be executed via MCP or CLI via your agent.
You can then define the data you want to give your agent access to along with role level access control. So your entities could be product or customer or order, for example, and then you have tools. So these are the tools that your agent will then be able to call based on that data. For example, find product by range, get customer by ID, search customers by text, filter by tags, filter product in stock. So you have a bunch of different operations such as filtering,
finding, getting, searching. So it's giving the agent tools to more easily access your data as it needs without trying to get your agents to join data across lots of different tables or across different data sources, which can be incredibly unreliable in agentic rag. The Redis agent memory includes both short term and long term memory features. For short term memory, you can set a custom TTL,
which will be very important for systems where the source data might change very, very frequently. And then they have long term memory, which stores extracted past sessions, user preferences, learned patterns, and other relevant data. And this is one of many memory solutions across the industry. For example, you have MEM0,
Honsho, DEP, Graffiti.
We have dreaming style features within clawed managed agents and OpenClaw, which I went through in a previous video, and much more. But for how the Redis memory works, first off, we have the short term memory, which is a session memory, and that's very important to maintain the current conversation state and session history. So the short term memory will be stored temporarily,
and certain elements, user preferences,
patterns, and other relevant data may be promoted to the long term memory. Otherwise, it's just deleted as per the TTL policy. Then you have the LAN cache service. So instead of calling your LLM for every single request,
you can use LAN cache to check if a similar response has already been made previously,
and if so, returns it instantly from the cache to save time and money. It sounds great. Semantic caching could be very useful for your projects, but it's also a potential minefield
where you can get similar past responses that are actually out of context. When searching the cache, you can search by similarity thresholds
and also search strategies
either using exact search or semantic search. These can be pretty blunt instruments, so you really need to thoroughly evaluate systems that are using response caching like this. The data is queried within the system using Redis search, and that can search vector, structured, and unstructured data all within one index. Here, you can see some Redis search queries similar to SQL, but with its own syntax. There are lots of different types of queries from exact match, range, full text, geospatial,
vector,
combined, and aggregation.
Redis also claimed that you can easily scale to 1,000,000,000 vectors using their indexes, which is pretty huge. And then they also have Redis Flex, which is a new SSD based storage tier that they're offering. So you're not paying for every single thing to run-in memory, which could really make a difference in terms of pricing. So here, Redis are very much acknowledging that you cannot just magically solve retrieval
with a very simple layer. It requires a modular stack. You need multiple services together and you need to be very cognizant of how you're using them. And it's very important to look past the market in here. Retrieval here is certainly not just a solved problem by signing up for a Redis account. This is not plug and play, and it will require maintenance to make sure that the shape of your retrieval layer is up to date with the source operational data, and you need to model your source data along with relationships. Recently on our channel, Daniel covered Pinecone Nexus, which is another knowledge layer approach to your AI agents,
but it's quite a different architecture.
Pinecone's new product offering here goes to build time. It precompiles
types knowledge artifacts like related to sales, finance, support, marketing, so the agent queries a preshaved answer instead of rederiving it at every single call. Whereas Redis here goes to runtime. It doesn't try to precompute anything into a compiled knowledge layer. It makes the data structures fast and navigable so the agent pulls fresh context on demand as it's quickly changing. And the two options here split pretty cleanly on where they're strong. Pinecones
is more likely to be strong where you have a large stable knowledge base with recurring known questions,
contracts, compliance, manuals, and things like that where a precompiled artifact
is exactly right. When using Pinecone's knowledge engine or anything like Andrea Kapathi's wiki idea, anytime the source data changes, you need to recompile what's in the knowledge layer, whereas Redis' architecture here will be far more suitable to very fast changing data environments.
Because in those cases, a precompiled artifact in a knowledge layer could be stale five minutes after it's created. When we're evaluating data retrieval solutions, we often have a use case in our mind from past experience or specific projects we've worked on, and there's certainly a segment of software professionals that are rolling their eyes when they see the Carpathi Wiki idea or Pinecone Nexus idea of a compiled knowledge layer. They're likely to be thinking of use cases where the underlying data is changing very regularly.
And even though this kind of architecture can be pretty complex,
it may be what's required to make a reliable working AI agent in production. When you take a step back, there really is no one size fits all solution to retrieval. Conventional rag and simpler agentic rag solutions were often touted as the magic solution. But in reality, flashy demos often don't translate to reliable production systems. Digging deep into retrieval strategies has been our main focus on this channel and community for quite a long time. And if you want to design a context and retrieval layer that will actually work in production, that's exactly what we cover in our agentic retrieval module inside the AI architects course in our community. Link in the description below. And I'd also highly recommend you check out our recent video covering pinecone nexus, which Daniel went through on our channel, which uses quite a different architecture for their knowledge layer than the Redis Iris architecture covered in this video. Thanks for watching.