Ammatti-identiteetti, AI-mindset ja tulevaisuuden uhat – The AI Club vastaa kuulijakysymyksiin

AI agents are increasingly capable of reasoning and performing autonomous work over long periods. However, as agents take on more complex, longer horizon tasks, keeping them supplied with the right information becomes the core engineering challenge. The industry is moving away from pre-loading context up front toward a model where agents dynamically navigate and retrieve the data they need when they need it. Redis is approaching context management using a context engine, which is an architecture built around four pillars. On-demand context retrieval, data that is always current, fast retrieval, and a memory layer that improves over time. In practice, this means building materialized views of data with the semantic layer on top, rather than giving agents direct access to production databases. A memory system sits alongside this, extracting and compacting information asynchronously as the agent works. Symba Cotter leads AI strategy at Redis, and he previously co-founded the feature store platform FeatureForm, which was acquired by Redis in 2025. In this episode, Symba joins Kevin Ball to discuss why context has become the defining challenge in a genetic AI, how context engines differ from traditional rag architectures, how materialized views underpin reliable agent data pipelines, how memory systems can improve through async extraction and compaction, and how engineering teams need to adapt their practices as AI-driven development accelerates. Kevin Ball, or K-Ball, is the vice president of engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served a CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in action discussion group through latent space. Check out the show notes to follow K-Ball on Twitter or LinkedIn, or visit his website, K-Ball.llc. Symba, welcome to the show. Thanks for having me. Yeah, well let's get started, learning a little bit about you and your background, and then we can move into Redis and talking about that. So how do you explain yourself to folks? When I grow up, I want to surf all day, but for today, I'm in AI. Okay, I mean I could resonate with that surfing is like blast. Yeah, I started the software engineer, then technical. When I started my career, I was at Google, a software engineer there. I solved a lot of really fun technical problems, worked with some super smart people, but I was always kind of itching to like go and learn on a slope that I felt like I had been learning on before. So I left Google, I started my first company, kind of did well there, started a company after which was feature form, which then was acquired by Redis, and I've always loved Redis as a product, so it's kind of awesome to become a huge part of the AI strategy here, but yeah, that's kind of the short. All right, well, and can you quickly describe feature form and what it is so that we have that as well as background? Yeah, so feature form, we were a feature store company, VC backed kind of that self company. The problem that we solved was around anyone building models and getting them to production. Every model, like when you open Spotify, you get all these personalized recommendations. You can imagine that every time you open the app, it's looking up your favorite song, favorite category, favorite genres, all these concepts about you, these signals, and you can imagine that there's this whole team as Spotify whose whole job it is to optimize these signals, come up with new ones, etc. The signals are called features, and what feature form was, it is the whole team is here and we're growing it and hiring by the way, but what feature form does is it enables a data scientist to define their features as code, the name even I want Terraform for features, and it deploys those to production and keeps them up to date, it runs a compute on your compute whether it's Spark or Snowflake or whatever, it maintains like a view, like a materialized view and redness so that you can get your features up to date, but you have your training data as well. What's interesting and I'm sure we'll get into it is if you change feature for context variable, it looks not to the similar, excluding the training part for what people are building today for agents. Yeah, so that actually is a nice transition into kind of what I think a lot of the meat of this, right? Five years ago, you didn't have to worry about what was getting fed to your model or how it was representing things or any of this unless you were deep down in data science or integrating it and you were doing that. Nowadays, we're all having to learn about machine learning, how do you put things in there? What does context even mean? All these different things. So I'd be curious to kind of get your take on the environment that we're in right now, like as devs, we're at the bleeding edge of it. So maybe we start there of how this is changing the world of software development and then we can kind of dive into how those future pieces are becoming contexts and what that looks like. Yeah, the thing that's happening, there's a few things happening in parallel and they're all really interesting. One is, it's even funny they say like us as devs because I almost feel like everyone's a dev now in an interesting way. Like our jobs are changing. Not that like if you need to just build a website and app, my uncle could go do that or my uncle could go put something together, you know, things have changed. No, could they build a database? No. So anyway, this kind of the side. The main thing that we're saying in terms of the overarching landscape is a couple years ago, even last year, you could trust an agent unsupervised for maybe a few minutes. And that was cool. I mean, that was huge change from before, like keeping like imagine like five minutes of an agent running by itself to software task. Now, I mean, I think the actual metric is about an hour. You can trust an agent to solve unsupervised, solve a software task that takes up to an hour to complete, which is roughly around complexity. And the interesting thing is is Anthropics says that that number is going to double every six months. So it's an hour now and we do repeat, you know, in a year, it's going to be four hours of unsupervised agents working. And so what's changed with that is if you do rag, like traditional rag, naive rag, what you're going to find is you're not going to be able to get enough context to feed it for four hours. Right. The limit is less the models ability to pay attention and more like how do you keep relevant tasks in front of it? Exactly. And my take is an emphasis take has been that for many use cases, the agent will give the agent access to the context, let it find what it needs and use it. Don't try to like put it all up front, you know, it's not just a context window problem, but almost like tool based context or trouble. And that's really the thing that's happening now. And if your agents don't look like that and your AI applications don't look like that, then you are not taking advantage of this reasoning wave that is happening. And so your really naive rag app is pretty much capped out. It's not going to get better because it's not like the agents are getting smarter or they like have more inherent facts, I guess, maybe a little bit, but what they're really good at is they're able to see a coherent for longer, we're able to reason about more complex tasks that have a longer time horizon and be able to solve them into end. That's the thing that's changed. It's almost like the RL, the post training has gotten better, but the pre-trains about the same. So that's I think the fundamental thing that's changing and because of that, all that matters is this context. Yeah, so I think you're describing something that I've also seen where we've shifted from this model of trying to pre-compute what are all the things that we can then do a single step pattern match to instead saying, hey, let's just give this thing this thing can reason now. Give it the ability to pull what it needs, explore, you know, and we're seeing this in the ways that things are being managed. Just no longer as you say naive rag where you're like, do a search up front, dump it in the context window run. Here's the search tool, call it when you need it, get some things back, or even seeing that in terms of how you manage local stuff instead of like, here's all the things I want you to do. You're like, here's a set of skills that you can progressively disclose context when you need it not previously. So yeah, that totally tracks what I'd be interested is where's the limitation area there? What is it that you can do at Redis or in another environment to facilitate agent stability to do this? There's a pattern I'm seeing emerge. And the term that we use is a context engine. And what a context engine is it has, I would say, four pillars. One, and argument that's the most important is that agents should be able to navigate and retrieve context that they need. And this doesn't have to, by the way, be tool-based. Well, it's always tool-based in some way, but it can be a CLI, it can be MCP. It actually, we have opinions and like with our newer products, we typically do both MCP and CLI, but that's almost an implementation detail of the context engine. So that's one. Is that you need to be able to navigate and find data? Two, is that your data always has to be up today. Three is that that data should be fast. For many use cases, speed is really important to have the UX and everything feel natural. This is more obviously if you think of an extreme or like every single tool called as a whole spark query, which takes three minutes. It just fundamentally doesn't feel like an agent anymore. And the four is that the context should get better with time. This means a lot of things. It could mean personalization. It could mean that it's keeping track of decisions and errors it's made in keeping track of those things. So it doesn't make them again. There's a log in there. But in the end, what you end up with is I have a surface of context that I can go navigate and look through. I can retrieve the context that I need, but I will always feel like that context is either the source of truth or that it's a view. It's always up to date. And then four, that it's always just going to get better. This is the moat. But if the reasoning is solved, not solved, but it's constantly getting better and it's doubling every year, the moat is who can build this context moat that really separates them out from everyone else. Arguably, this is literally the difference between anthropic and open AI and everyone else is that as they get better, they get more data and their context get better and they're able to build better models. So let's maybe break down those steps. Which we use the example, I think probably most of our audience is familiar with a coding tool of some sort. So we can use a coding tool and like work through what does that actually mean to that context? So imagine we're building the redis based version of like cloud code or something like that. First step, Asian should be able to navigate and retrieve the context that they need. What does that look like in a code setting? I think code and we can go through code. I think the thing that makes code a little unique is that it's almost always going to just be on your local system. So the retrieval step and the sync step and a lot of those things are solved just using Git. I think where maybe a good one might be like a customer support agent. So with the customer support agent, what you'll find is one, the information you need, someone asks why is my order late. I use this example a lot because if you think of a rag and how you build a rag app, you would take a knowledge base, you would chunk it up, put in bedding, someone asks why is my order late and you would say here common reasons for delays, which is desirable. Exactly. Generic service search against it. Yeah, totally. And that's what most people do. And will you end up with the last iteration of AI apps where kind of glorified summarizers, where pretty much is showing off. All of them can do the thing is that most people kind of know what all of them can do now. I mean, not everywhere, but for a lot of tech forward places like San Francisco, New York, people are getting it. So now it's like, okay, when someone asks why is my order late, I need to go get the order. I might need to go get information about the order, the deliverer. I need to look up our policies. All those things are going to be in different places. So firstly, I need to give the agent tools to be able to access all of those things. Now what you'll find is there's a major question that pops up there is like, how do we, do we just let our agent have access to our Postgres DB directly and just run queries? Like, what do we? What could possibly go wrong? Exactly. It's like, why is that prod database? So where is it? It's like, did you delete it? It's like, you're absolutely right. So don't do that. So what we see more often, and this is where the context engine architecture comes up, is that people are going to are building materialized views of data where they might have all these systems of record and they don't want to deal with scale and all the other things that come up with a ton of agents hitting it. So it's like, let's create the materialized view. And then on top of materialized view, let's create almost like a retriever service, a set of tools that can go and access these things. At Redis, things that we are doing are more around like putting almost like a semantic layer on top of Redis and semantic layers are not new, but we've never seen a semantic layer on top of something like Redis because it would make zero sense before agents. It would be a very strange thing to do. So anyway, one piece is having almost an ETL synchronization layer. This has a product called RDI, which is pretty much a ETL. It maintains, it builds views and maintains those views as information changes. Now I have a materialized view of context. I control what's in that context, except rules are on how that context is accessed. I don't have to worry about scaling a ton of random systems for agent use, and I own it. It's my thing. It's not like a vispartisan Salesforce and vispartier and vispartier. So in the customer support use case, I might have some postgres databases, I might have some different APIs, etc. I build a materialized view. I describe what is this information, it's almost like a semantic layer on top, which we can compile into a set of tools, an MCPN point, or a CLI. Have the agent connect to that, and now I have a fundamental ETL built for context with a retriever set. So a couple of things that'd be interested to know on that. So one, are you building a single set of materialized views that you're exposing to all of these different agents? Are you able to customize that down to like this agent gets a materialized view with literally what the current customer could see or something like how fine grain can you get this thing? Very fine. So you can use ACLs with a row layer, you can do our back at the agent layer so the different agents can see different things. You can mix them up with different forms. But yeah, for sure, you definitely have to make sure that you nail it down, but it's a lot easier to nail down when it's in something that you built for context. The issue is like, if you give access to postgres, you then have to try to nail down postgres to work in a generic way. And the thing is is that people don't typically build postgres databases of the idea of like any random person can query this. And so they're not well set up for that. And so then it's like, do you try to set that up or do you build a whole different like API suite for it? And then how do we deal with all the new indices that we're going to want to create for all the kind of unusual search patterns that we expect agents to have? So that's where we see the materialized view use case come up. Yeah, that makes a lot of sense. I'd be interested. You mentioned the semantic layer on top of it. And one of the things that I think has been fascinating to see with LLMS is how much semantics matter. Right? Like the more you can shape your data into something that linguistically makes sense to the agent or is able to live in that part of the LLMS like training data that is well covered, the better it's going to be able to use it. So what does that look like for Redis and how do you see it used? Obviously on the point of this thing, it works really well. I agree. And actually you said like for things for agents to understand, I would go and say for humans to understand too. A lot of times we define tables in ways that are optimized for compute.