On November 4, Redis announced the next chapter of Redis Iris, its real-time context engine for AI agents. Iris is now six pieces — Intent Router, Agent Playbooks, Agent Memory, Context Gateway, Lens, and Agent Mesh — four of them generally available, two in beta. The press release is worth reading, but the sentence I want to start with is this one, about the memory component: it “can also forget what it should not keep, such as personally identifiable information.”
A database vendor is now shipping forgetting as a feature. To see why that is strange and why it matters, it helps to know what Redis spent the last fifteen years being.
What Redis used to be
Redis has been around since 2009. For most of that time, if you asked an engineer what it was for, the answer was one word: caching. Keep the hot data in RAM, where reading it takes microseconds instead of the milliseconds a disk costs, and keep the expensive stuff — the full database, the search index, the model — somewhere slower and safer behind it.
The classic setup looks like this:
The cache’s job was speed, and its whole design assumed something comforting: anything it lost could be rebuilt from the source of truth behind it. A cache miss was an inconvenience, not a memory problem. Nothing in that architecture ever had to be right, only fast. If the data in it was wrong, you flushed it and moved on.
What agents changed
Agents broke that assumption. An agent’s context — what it did last time, what a user told it three sessions ago, what document it ingested — does not come from a source of truth you can rebuild against. The agent is what it remembers. Its memory is built from the user’s own actions and the documents it was fed, and every later session inherits whatever got written down.
That is the transformation the new release represents. The same vendor, the same fast runtime, has added a product whose job is the opposite of a cache’s: not “hold the repeated question” but “decide what the agent keeps.” Agent Memory builds memories from user actions and documents through something called MemoryETL, organizes them into hierarchies so a team can control them at whatever grain they need, and — the part that caught my eye — provides inspection, audit, and provenance for every memory.
The six pieces
For readers who want the whole release: Intent Router (GA) sends a request to the right destination by matching its meaning, not its wording. Agent Playbooks (GA) define which answers are stable enough to reuse and which need a fresh run of a known procedure. Agent Memory (GA) is the memory pipeline described above. Context Gateway (GA) is a single governed entry point to an agent’s data sources and tools. Lens (beta) traces every outcome back to the skill, route, or memory that produced it. Agent Mesh (beta) lets agents hand work to each other over connections that survive interruptions.
Notice what the six have in common. None of them is about making a model smarter. They are all about what reaches the model — what it is reminded of, what it is allowed to see, and what it can be traced back to afterward.
The parts that are actually new
I have written three posts in a row about agent memory (whoever writes the memory owns the agent, who checks the notebook, and nobody sells memory integrity), and the reason is that the memory layer is where the control lives. Whoever writes an agent’s memory writes the agent’s sense of what is true.
So it is worth pausing on what a vendor is now selling: memory with provenance — every memory traceable to the session or document it came from — memory with audit, so a team can inspect what the agent learned instead of trusting it, and memory that can be made to forget things like personal data it has no business keeping.
These are the exact controls I keep asking for in this series. For three posts I have been able to say “nobody ships this.” Now somebody ships it, or at least says they do — the proof will be in what the audit actually surfaces and whether provenance holds up under tampering. But the direction is real, and it is new: the controls are a marketing bullet now, not a wishlist item.
Why the transformation matters
It would be easy to file this under “database company jumps on the agent trend.” I think it is the more interesting story. Redis did not need to exist differently fifteen years ago, and the pressure that remade it did not come from a competitor. It came from customers whose requirements inverted the product’s original promise. A cache was allowed to be wrong because it was disposable. Agent memory is not disposable, because the agent does not exist without it.
Watch what happens when that inversion is complete somewhere else. The book’s argument is that agreement — being told what you want to hear — got cheap enough to become infrastructure, and the interesting failures moved from the chat window into the systems nobody inspects (chapter 5 and chapter 8 live there). Memory was the obvious next silo. An infrastructure vendor putting inspection, audit, provenance, and erasure on the same slide as latency numbers is one of those failures becoming legible to the mainstream — the controls our registry keeps asking for are now something a sales team leads with.
That is the transformation worth noticing. Not that Redis grew six new products. That the fast, dumb, disposable layer — the one whose whole culture was “flush it and move on” — has been rebuilt around deciding what an agent is allowed to remember, and being able to show its work. The cache learned to forget. Everything downstream of it should take notes.