Redis CEO Rowan Trollope on building the context engine for the agent era

Speaker 1: Let's do that.

Speaker 2: Okay. Well, let's bring in Rowan from Redis because he's waiting in the waiting room. Rowan, welcome to the show. How are you doing?

Speaker 4: I'm doing great.

Speaker 2: Thanks for being here. Since it's your first time in the show, I've I've actually Are been you

Speaker 1: getting an act is this an active sauna session for you?

Speaker 2: It does look like a sauna background. No.

Speaker 4: I'm in Tenerife today actually. So

Speaker 1: Oh, amazing. Yeah.

Speaker 2: The wood paneling behind you really does look like a

Speaker 1: I like it. I like it. Well, yeah. We'll see in in in a few minutes if you start sweating.

Speaker 4: I'll be doing the cold plunge next.

Speaker 2: We'll see how

Speaker 1: that goes. Well, some people in tech do combine cold plunges with

Speaker 2: That's happening.

Speaker 1: Talking about their companies. Yeah. Yeah. Yeah.

Speaker 2: For sure.

Speaker 1: That's great to great to meet you.

Speaker 2: Great to meet you. I've I've used Redis a ton about a decade ago. I'm a big fan of the product. But if you could introduce yourself and the company a little bit before we go into the news today, that'd be great.

Speaker 4: Yeah. Absolutely. Thanks, guys, for having me on. It's an honor to be on. I loved your show. Amazing. Big fan and watch all the time.

Speaker 2: Great.

Speaker 4: Yeah. So I'm the I I head up Redis, and we're one of the sort of core infrastructure components that, you know, has been around. We're one of the one of the bigger open source projects Yeah. Over the last fifteen years and sort of helped build out a lot of the Internet infrastructure and got a great team. We have just about we're three 1,500 people now, and we're starting to see a lot of there you go.

Speaker 2: That's great.

Speaker 4: We're starting to see a lot of traction in the AI world as people are starting to really build out agents.

Speaker 2: So as you

Speaker 4: guys were just talking about, you know, lots of opportunity there and and Is sort of being pulled in on agent data.

Speaker 2: Yeah. I wanna get to that. Is is is the is the correct framing for Redis for people who might not have actually used the product in memory key value storage, like nonrelational databases, think like MySQL, but less structured and also held in memory, therefore faster?

Speaker 4: Totally. You nailed it. It it the history of of it, it's a it's an in memory data structure server. It's not really a database. Yeah. But it's been treated as a database, and the killer app that kinda took off and made Redis a part of kinda got the tendrils into all the applications on the whole Internet was was key value Yep. Used being used for caching. Yep. So it originally started as an in memory database. The big thing that's changed, though, and this is just coming live now is over the last few years, we've re architected Redis and launched a new product

Speaker 2: Mhmm.

Speaker 4: That uses Flash as the back end storage. And so now we have the fastest, the world's fastest Flash object store. And and so that's that's a new thing. And that was really driven by AI because we were seeing huge demand for way bigger way way more data. And just and also RAM prices have gotten crazy.

Speaker 2: Sure.

Speaker 4: And NVMe cost performance has improved dramatically.

Speaker 2: Sure. Okay. So then take me through some of the history of the business. I know you joined as CEO like in the modern era. But in terms of that transition, what is the shape of the business? Because a lot of people are building open source software. And I'm always fascinated by that transition and that interaction between the product, which sometimes has like incredible developer pull, incredible ecosystem and then also an incredible opportunity to build a real business around it. But what is the shape of that? Because I think people go to Red Hat, they go to consulting shops, they go to hosting providers, enterprise software wrapped around it. But what how would you describe it, shape of the business around the product right now?

Speaker 4: Yeah. So we're it's a great question. We're still a open core company. So we have an open source base, which is Redis. Anyone can download it and use it for free. It's used all over the place for free. And then we have a paid version. So for example, the the recent innovation I mentioned, the rewrite using Flash Sure. Story, that's that's not for free. That's something that you would pay for. We have a lot of performance advantages in the paid version. We have a hosted version. It runs on all three of the the major clouds. So if you get Redis on Amazon or Google or or Microsoft Azure, right, we we provide we we have our own version essentially that runs on those clouds. Mhmm. And so that's that's that's the that's the heart of the business. Most of our usage on the Internet is free Redis because the free product is amazing. Yeah. The paid version is even better.

Speaker 2: I like it. That's a good that's a good salesmanship. So the the relationship with the hyperscalers, is that, like, consumption revenue that's coming to you? I set up an an AWS instance. I pull Redis off the shelf from the dashboard of a million different tools. And then Yeah. As I'm using it every month, stuffing more and more data into it, that money is flowing to you from the hyperscalers?

Speaker 4: Exactly. So Yeah. It's a little different depending on which hyperscaler you're talking about. For Microsoft, they're hosted red if you buy the first party service from Microsoft. Right? So on on the on the hyperscalers, you have first party services that are offered by Mhmm. The hyperscaler themselves, then there's third party that you buy through the marketplace. In Microsoft's case, when you buy Redis, first party, it's actually our software. And and exactly you're exactly right. We get a revenue share of that. So that's called Azure Cash for Redis. And then there's and then Amazon and Google no longer offer us first party services, Redis. They have their own products that were once built based on Redis, but we did a license shift Mhmm. To kinda get them off of our tail, frankly. So Amazon and Google now have their own code bases that they have to maintain that that that that have really diverged from what is now core Redis. We offer on Amazon and Google through the marketplace Redis, you know, as the Redis cloud product essentially. And then increasingly, we're offering that through new cloud vendors, either their NeoClouds or, like, Vercel, for example. So if you ask an agent, you're building on Vercel and you say, hey. Please deploy Redis cloud. Boom. You'll get our product, And it it seamlessly is integrated into their platform as well.

Speaker 2: Yeah. That makes a lot of sense. So, I mean, I remember when I was using Redis, was using it a lot for, actually, like, business intelligence and, like, data analysis. It was just nice to clean up some data, have it all available in memory much faster to sort of query and do like MapReduce over. But obviously, the bread and butter's caching, but I'm interested in the shape of the agent business, like Yeah. What data is being stored, when because a lot of this stuff can be loaded in context. It can live on the chip. We talked to the Cerebrus founder last week. Like, there's an incredible amount of work being done really, really deep in the in in the in the AI supply chain. And then there's everything out to the hard drives and tape storage on the other side. Yeah. And so what is the sweet spot that Redis is filling right now?

Speaker 4: Yeah. So if if in the past, as you just talked about, sort of the the the kill use case in the cloud mobile era was caching your your database Mhmm. Basically. Yeah. Okay. You could use it for a lot of other stuff as you talked about. And in the new world, we sit in a similar place, and that is essentially providing all the context, you know, like, coalescing all the context for the agent and then delivering that to the agent. Yeah. And we've we had to actually build a new product to do that. So what what developers have been using Redis for in the agent this, like, called the next era that we're heading into is storing agent data Mhmm. And hosting agent context. And one of the reasons for that is that you're going to see multiple orders of magnitude more agents than human beings in a company. Mhmm. And what that has a direct consequence to the load you're putting on your back end data systems. So just like in the cloud mobile era, you saw, you know, kinda you went from, like, guys that were sitting at at green screens, like like bank tellers, for example. And and the load factor on your back end DB two might have been, like, 10,000 to one or something. Okay? Then you added mobile, and you added a million customers or 10,000,000 customers. So so two, three, four orders of magnitude more load, and Redis came in there as a scaling layer.

Speaker 2: Yeah.

Speaker 4: Okay? And you didn't you didn't have to go and scale d p two or your mainframe or whatever. It doesn't make any sense. You oracle that back end. Similarly, in the agent era, a similar transition is happening. So as that load increases, you can't have like, my company has a thousand employees. I can't have a 100,000 or a million agents

Speaker 2: Mhmm.

Speaker 4: And we're going crazy with agents right now internally

Speaker 2: Yeah.

Speaker 4: Hitting my back end data systems because I'm gonna be paying a hell of a lot more to all of my underlying providers. So we use Redis in the middle as the context engine

Speaker 2: Yeah.

Speaker 4: And we cache and hold all the context from the underlying databases in Redis, and that's what the agents interact with. So we launched a brand new product that's on our website right now called Iris.

Speaker 2: Yeah.

Speaker 4: And this is its exact intention is that what you do is you you have we have a data integration piece that sucks the data out of your underlying databases, stores it in our new Redis flash database, and then serves it through CLI and MCP through Pydantic models. So you define Pydantic models on top of your data, and you do the transformations underneath. And then what the agent sees is a manifestation or a view of the underlying data. And the difference it it it's not just a scale issue. It's also providing the data in the way the agent expects to get it. So I'll give you a simple analogy here. It would be like, if I told you, you know, hey. You know, let's say let's say I said to you, hey. I'm an agent, and I need you to go get some data. And you said, great. It's in that filing cabinet. And I gotta go rummage around as an agent calling a whole bunch of MCP tools and doing queries and figuring out relationships, etcetera, etcetera, versus I say to you, I need some data, and you just pull the exact file out of the cabinet and say, here it is. And hand it to me. Yeah. And that's the difference. So it's a huge reduction in token costs. Yep. And also agent speed and then a and then a big improvement in terms of performance of agents because the data is essentially massaged into a format, these pedantic models, and then semantically described exactly what the agent needs. So that's what Iris is all about. And then it also has the second component, which is memory. So agent memory is the other big thing we've invested in. We have a state of the art memory server that we've just launched as well.

Speaker 2: Yeah. So I I mean, what what is, like, a reasonable scaling factor for the amount of data from my relational database, my hard drive based database to go into memory? Because I imagine it's you mentioned, like, brings a copy into memory, but I imagine that's not one to one. I wanna do some some condensing down of the data to what's relevant. And I imagine that Iris helps with that, but what is a good rule of thumb? I imagine that there's some sort of cost relative trade off there. But how how how are how are companies even thinking about that?

Speaker 4: Yeah. It's interesting. You know, I haven't really talked to any customers who are thinking about it in that way.

Speaker 2: Okay.

Speaker 4: What they're thinking about is what is the cost delta to scale my data layer in Redis versus purchasing additional licenses of, you know, whatever, NetSuite or

Speaker 2: Sure.

Speaker 4: You know, Salesforce or this or that other thing, whatever that whatever that underlying asset is. And so but I would say so so it's good question. I actually don't know the answer to that. Yeah. But they do think about it in terms of accuracy.

Speaker 2: Yeah.

Speaker 4: Like, you know, you want the data to be served up in a way that is the best possible and most accurate data. So semantic descriptions this is why we use the pedantic models is you can put semantic descriptions on each thing. So so so all that encoded knowledge of, like, what to query, what database, what record, what table, that all gets encoded in the system. What the agent gets is a really nice set of MCP or CLI tools that say, like, you know, search customer records.

Speaker 2: Yeah.

Speaker 4: And we have a super fast search underneath the covers. We have a great vector search and then a b m 25 search. So we can search across all those records and then just deliver exactly what you need. And so what that all amounts to for the end customer Mhmm. Is a much faster and much more token efficient agent experience.

Speaker 2: Yeah.

Speaker 4: And and the second piece of it, and this is important, we should talk about it, is that that context should get better over time. Like, agents learn things as they go, and they need to remember the things that they've learned, not just facts about the user. Like, when people talk about memory these days, we often talk about remembering user preferences. That's interesting. But you also need to remember, hey. When I when I checked the shipping status for this particular customer, like, that system was wrong, but this system was right. Mhmm. And that's the truth of large enterprises and their data is that they're really messy in most cases. And so expecting them to sorta, like, get all that stuff in order in advance, it's just too tall of an order. And so we need to also remember things that the agent has learned over time and then store those. And that and that gets stored in agent memory. So we have a state of the art model there called agent memory server that does the extraction and all the kind of stuff you would expect from a memory platform.

Speaker 2: Yeah. Yeah. How are you interacting with benchmarks these days? Because most of the benchmarks are centered around performance, like meters, like how how advanced of a software engineering task can the frontier models crank on and they're up to like twenty four hour it would take a software engineer twenty four hours to do something, but 4.7 or 5.5 can can can do it, period, and can achieve it with 50% accuracy. They're not really talking about the time to return that result. And Right. We've sort of settled into this equilibrium where if it's a big query, ten minutes is acceptable for most people. Maybe twenty. And then for, you know, a knowledge retrieval, I want to know an answer. It's got to come back in like thirty seconds, but it's not we're not in the Amazon e commerce era where a hundred milliseconds means losing dollars, which is sort of where you're where where the Redis DNA comes from in caching. I imagine that a pitch to an agent company might be something like, yes, the vast majority of wall clock time is going to be waiting for tokens to inference and turn out on, you know, a big cluster somewhere. But we're gonna keep the GPUs fed so much more effectively by keeping this in memory. How are you thinking about quantifying that for customers?

Speaker 4: Yeah. Well, so the first point you made about agent run time, certainly that we're we're witnessing what everyone else is witnessing, you know, the the the length of time an agent can run unattended. And the and the issue with that is context becomes even more important. Right? Like, if I told you to solve a problem and then I locked you in, like, a closet and didn't give you access to the outside world for eight hours, you'd just hallucinate a bunch of answers. Sure. But if I stuck you in the New York Public City library and with a Google terminal, like, you'd be good, and you'd come up with an answer, and it would be good. So context becomes super important when you're running these really long tasks. And the transition that has happened really over the last couple of years from what started with Rag, which was kinda engineers thinking, hey. We'll just preload the context window with all this stuff.

Speaker 2: Yeah.

Speaker 4: And and then the agent can go and go figure it all out. And there was this whole idea that context windows would get bigger, and you could just load everything into the context window. Your whole code base

Speaker 2: Yep.

Speaker 4: You know, all of your enter but but the truth is that really doesn't work. To stick everything into the context window, number one, is expensive.

Speaker 2: Mhmm.

Speaker 4: And number two, just really, it's overloading. You're just getting way too much rot in in the context window. And so it's much better to provide a tight set of tools to the agent to let them reason over the data and sort of do searches and what what can I access and and that kind of stuff? So what we see is the longer the agent can run, the the better the context has to be Yeah. To make it effective. Otherwise, it just starts to go haywire.

Speaker 2: Yeah. Yeah. That makes a lot of sense. Switching over to just your philosophy as a CEO, you said 1,500 people, something like that, over a thousand work for Redis. You're obviously using these tools. How do you see the shape of the organization changing over the next few years?

Speaker 4: Well, dramatically. I mean, so I I've been coding since I was 11 years old and professionally since I was 18 in high school and at a startup. And, you know, I woke up one day with these tools and realized, like, all the way that I learned how to build software thirty years ago is just not relevant anymore.

Speaker 2: Mhmm.

Speaker 4: And so, you know, I'm not gonna rely on a bunch of other people telling me, you know, and and, like, watching, you know, Twitter people breathlessly telling me how the world is changing. I'm gonna go learn it myself. So I've gone back to basics over the last year and a half. I mean, really, since we started using ChatGPT for coding

Speaker 2: Yeah.

Speaker 4: And OpenAI, and then really have been diving in myself personally. So I I actually sit on teams. I've been contributing and building my own projects on the side as well as contributing to our own code. And I think there's a few maybe non obvious things that I've learned. You know, there's the obvious part that is like, the code is now can be written mostly by by agents and by, you know, by coding agents. But but that if you just do that, it doesn't really change much because then you still have the same people in the same process. The process is all set up to basically handle a world where the coding takes a really long time. That's the long poles. That's not the long pole anymore. There's all these other long poles like meetings and daily standups and processes that were all built around that fundamental assumption of coding is the long pole in the tent. Now that that's gone, we're having to reinvent those processes. And I've basically found and same with my CTO, we have to go right back into the front lines with the teams and build code ourselves as we reinvent the software development life cycle. And frankly, we're finding that a lot of folks have to make a big jump in terms of how they do work. Like a developer with 10 agents is more like a development manager of old. And the development manager does a different job. They coordinate, they express the right their requirements in the right way, they have taste. They decide what's the right approach to solve a problem. And that's the new job. And it's really fundamentally different than what the developer of, let's say, three years used to do before these agents showed up. So I and by the way, I'm having a blast. Like, I love coding. I've always loved coding. I I love everything about it, and I love it even more now. I mean, it's like the I've taken out the gnarly part in the middle, which was the, you know, typing everything in and finding missing semicolons, and now I just go right from expressing intent to getting the result, and that's awesome. I mean,

Speaker 2: it's This is super cool. Are you seeing it instantiated more in like new greenfield projects, new internal tools or actual product velocity on the core product?

Speaker 4: Both, but it more on greenfield. On the brownfield, what we've and first of all, like, we use it differently. So for, like, front end stuff

Speaker 2: Yeah.

Speaker 4: You know, we can, like, pretty much vibe code everything.

Speaker 2: Sure.

Speaker 4: You know, on core Redis system software

Speaker 2: Yeah.

Speaker 4: I'll give you a good example. We just launched a new data type. Salvatore Sanfilippo, who's the original author of Redis Yeah. Launched a new data type called arrays. Yeah. It's 4,000 lines of c code. It took him four months, and he was deeply using codex

Speaker 2: Interesting.

Speaker 4: And and Anthropic. Okay, Claude. Yeah. The whole time. Yeah. And it was it's but the difference so it it took it was faster to do. Yeah. Okay? So that same idea, that that array data type would have taken probably a lot longer. Yeah. But more important, like, eight eight months maybe for him just sitting there writing c code. But more importantly, it's way higher quality right out of the gate, huge amounts of tests, huge amounts of infrastructure, like, all kinds of benchmarks, all that extra stuff that comes around the edges. And we really do use even at hardcore systems level coding, we're using the AI to give really good suggestions. We're often pitting them against each other to sort of say, hey. Come up your bet with your best design for this, and then we'll throw it at the other AI to say, what do you think? And back and forth. So so at that level, you really are still crafting the code at the systems level, which is kinda where the world that I come from. But at the higher end and and kind of for greenfield projects, you know, JavaScript and, you know, Next. Js applications, you're just, like, five coding and just going crazy. Yeah.

Speaker 2: Yeah.

Speaker 4: I would say if we have one project, what is a good example in a greenfield, it would have taken a typical like, we're building this big management infrastructure for for the Iris project. It would have taken us probably a year for, like, 10 devs to do something, like, big like that with LDAP support and all the different things you need for enterprise software. It took five guys one month. That's awesome. Guys and girls, actually.

Speaker 2: So Yeah.

Speaker 4: Of so that's a big acceleration on that front, but it's different at the systems level software side and brownfield.