{
  "video_id": "nlduRWBt4S8",
  "channel_slug": "deeplearningai",
  "channel_handle": "DeepLearningAI",
  "title": "AI Dev 26 x SF | Aditi Gupta: Building SRE Agents with the Redis Context Engine",
  "duration_seconds": 1893,
  "url": "https://www.youtube.com/watch?v=nlduRWBt4S8",
  "upload_date": "20260520",
  "transcript": "I'm really excited to talk to you guys\nabout what we're doing with the Redis\ncontext engine and what my team, the\napplied AI team at Redis,\num has been building and how we built an\nSRE agent that you can actually trust in\nproduction. And as you guys might know,\nthat's a feat. Let's start with the\nproblem statement. So, why did my team\nbuild out an SRE agent in the first\nplace?\nUm when we work with our larger\nenterprise customers, a single Redis\nservice rarely means one thing. It looks\nmore like X clusters over X regions.\nWe've got some customers that have\n60-plus clusters distributed over three\nto five different regions. We got dozens\nof different deployment types. We've\nalso got hundreds of instances, each one\npotentially with its own versions, its\nown configuration, and its own\noperational history, right? So, TLDR,\nthe infrastructure gets complex. And\nthat's really what production looks\nlike. And when something goes wrong, you\nneed answers fast. And you need to have\na low MTTR, which is your mean time to\nresolution.\nAnd you want to make sure that when\nyou're debugging your particular\nenvironment, you're using the right\ncontext for your cluster. Now, that's\nwhere we come into play. We're the\ncontext engine. So, I want to talk you\nthrough a little bit of how we used our\nexpertise in the applied AI team to\nbuild this engine leveraging some\nRedis's technologies, but also just as\nan engineer, what are some of the things\nthat we learned? Um and we actually\nbrought on design partners to, you know,\ntest this out with us. Um some of our\ndesign partners are top-five financial\ninstitutions um that are really hosting\nRedis at scale. And so, we actually\ndeployed this in their environment at\nscale in production. So, let's get into\nit.\nUm\nSo, first I think a question a lot of\npeople like to ask is why do we even\nneed an agent in the first place, right?\nLLMs are getting\nextremely smart. And, you know, it's\nlike every other day a new model is\ncoming out and context windows are\ngetting extremely large. We've hit about\na million token context window at this\npoint. Um agents can reason for a very\nlong period of time without human\nintervention. And like I mentioned,\nthey're getting extremely fast and\nthey're getting cheaper as well. So,\nmany people will potentially try to\napproach this problem just by sending\nsome of their data to an LLM and seeing\nif it can potentially triage for them.\nBut, a lot of the problem lies in the\ncorpus of data that the LLM is actually\ntrained on. And it goes out of date\nextremely quickly, right? So,\nthese days, especially with coding\nagents,\nsoftware features are coming out left\nand right. Um and documentation is\nconsistently changing as well. And so,\nif you're just leveraging what the data\nthat an LLM is trained on, you're using\nout of date information already, right?\nAnd something you guys might say is,\n\"Okay,\nLLMs might have outdated data, but they\ncan actually leverage tools to do web\nsearch, right? So, then they can go out\nand fetch new up-to-date information.\nSo, why can't we just use that?\" The\nproblem with web search is that it's\nunfiltered. So, it's going to surface\ncommunity forum posts, it's going to\nsurface some Stack Overflow posts from\nlike 2019 that is not relevant anymore.\nUm and it's going to run docs for a\nversion that you're potentially not even\nrunning in your environment. So,\nthe main problem is that it's not only\nretrieving this information, but it's\nactually uh reasoning on top of it\nextremely confidently. And so, in SRE\nwork, that's not really like a minor\ninconvenience, right? That unsafe\nrecommendation on some config change\nlike how our failover is set up can be\nextremely detrimental and worse than no\nrecommendation at all. So, that's kind\nof an understanding of why we built out\nan agent in the first place. Why do you\nneed this wrapper around a LLM for these\nkinds of issues?\nSo, we set a clear design goal. The goal\nwas that we want a trustworthy SRE\nagent, and I think that is probably a\ncommon um thought for many of the people\nthat are attending this conference today\nis like, how can I build an agent I\nactually trust? So, that word became\nvery load-bearing for us, and it\nactually informed every architectural\ndecision that we made.\nWe believe that the agent has to be, you\nknow, grounded in the right sources.\nIt's got to be context aware of your\ndeployment, evidence-driven from live\ndata, um and extremely verifiable,\nright? So, it should cite where the\nanswers are actually coming from. We\nwant the agent to meet the KPIs of the\nleast possible MTTR that I had talked\nabout earlier, and we want to make sure\nwe've got maximum service uptime. So,\nthis is really like the goal that we\nstarted with.\nSo, I'm going to talk a little bit about\nthe foundation of this agent. The\nfoundation is a knowledge base that's\nbuilt on trusted sources. It's not the\nopen web, but it's official Redis\ndocumentation across all of our\ndifferent deployment types. So, we\nsupport open source. We have something\ncalled Redis Cloud, Redis Enterprise,\nand this is specific to our agent\nbecause we're building an SRE agent that\nmanages Redis infrastructure. But, this\ncan really be applicable to whatever\nagent you're building out, or if you're\nbuilding out an SRE agent for other\ninfrastructure, make sure to pull in\nofficial documentation into your\nknowledge base. And, this matters a lot\nbecause the quality of the agent's\nanswers is directly tied to what it's\ngrounded in.\nGarbage in is garbage out. So, you want\nto make sure you're feeding the agent\ncorrect data. All of this data is then\nchunked, embedded, and stored in Redis,\nleveraging it as a vector library.\nSo, why a vector library? This gives us\na few key benefits, all right? So,\nsemantic search is the obvious one. Uh\nwe can actually find the most\nconceptually relevant content for a\nquery. Another one is we can actually\nattach metadata to every chunk. So, when\nyou do retrieval, it's not just going to\nbe ranked, but it can also be filtered.\nAnd most importantly, it's fast. I think\na lot of people here might know Redis um\nas a cache, and the reason that we have\nthat reputation is because we're an\nin-memory database, um and that makes us\nextremely fast. But, that's not Redis\nisn't the only reason this is a fast\napproach. At query time, we're not\nrereading documents. You don't want to\nbe reading the entire markdown file or\nhowever your data is stored every time.\nYou might want to do a vector similarity\nsearch against an index that's already\nbeen created, and in our case stored in\nmemory. So, we're starting off strong.\nWe've got an agent that walks into every\nconversation extremely confidently, and\nunderstanding the technology uh for the\ninfrastructure from authoritative\nsources. So, that's our base.\nSo, I think like ingestion can sound a\nlittle boring sometimes. Like, yeah,\nokay, we know rag. We've heard about\nrag. That's everywhere. But, what if I\ntold you there's a little bit of nuance\nand strategy here? And it's actually\nwhere a lot of agents failed.\nSo, let's talk chunking strategy.\nChunking is the process of breaking down\nlarge texts into smaller and manageable\npieces that we're going to call chunks.\nSo, this actually optimizes LLM\nperformance because it ensures that\nwhatever data we're reading in is\nactually going to fit within that\ncontext window, and we're reducing token\ncosts, right? By only pulling in data or\nchunks that are relevant to our query,\nand not pulling in entire document. So,\nthe left column on the slides um is\ngoing to show show the naive approach to\nchunking. almost like at the instinctual\napproach to chunking. Like, let's chunk\nevery N characters. Okay, I want to\nbreak this document down. Let's do every\n50 characters or something like that.\nUm\nand using the same strategy across every\ndocument, you're going to end up with\ncommand docs that are actually missing\nsome of their constraint information.\nSo, you're going to also see giant\ndocuments that are dominating the\nresults. So, in case you have like, I\ndon't know, a 50-page runbook, that\nrunbook is going to be dominant\ndominating the chunks that you have\nstored within your vector database and\ntherefore dominating retrieval as well.\nAnd you're going to have snippets that\nlook relevant, but they're actually\nlacking the context to be like actually\nuseful. And so, I want to talk a little\nbit about what we did in terms of our\nstrategy, kind of learning from these\nmistakes. So, our strategy is a lot more\nspecific to the type of document that\nyou have. Um CLI and API docs should\nstay whole because if you split a CLI\ndocument, you might just chunk\nyou know, the command, or you might even\nhit a partial command. You might miss\nsome of the parameters that you want to\npass in. So, all of that information is\nuseful to the agent. So, we keep all of\nthose documents whole.\nAny extremely long documents that we\nhave, like I mentioned, you don't want a\nlarge document to just take over your\nretrieval strategy, we um actually set a\nchunk limit. So, there's only a certain\namount of chunks you can extract from a\ndocument and then we'll adapt chunk size\naccordingly.\nWe also look at things like metadata\nthat you might not want your agent\nsearching against. So, big thing with\nknowledge bases is you have to be really\ncareful about the quality of the data or\nwhat data you're putting in your\nknowledge base. And\nthat includes metadata, which is\nsomething we miss every now and then.\nSo, we strip all YAML front matter from\nour markdown files. Um so, it doesn't\npollute any vector similarity searches.\nSo, this is making retrieval a lot safer\nand it's protecting us from potential\nhallucinations. So, these are some real\nstrategies that you can use for your\ncurrent rag kind of workflows.\nAll right. So, instead of building a\nsingle agent that tries to do it all, we\nbuilt out three specialized agents in a\nmulti-agent architecture. I'm sure you\nguys have experienced\nthe absolute frustration that comes from\nbuilding out this agent that you're\ntrying to do it all with, and it's\nhallucinating left and right. We wanted\nto protect ourselves from that. So, we\nactually built three agents that have um\nspecialties, and we're using a query\nrouter to classify incoming requests,\nidentify the need, and dispatch to the\ncorrect agent. So, first let's start\nwith the knowledge agent.\nIt's going to handle pure documentation\nrequests. So, if someone is asking about\nbest practices or general Redis\nquestions, Redis infrastructure\nquestions, it only has access to the\nknowledge base, which makes it extremely\nfast and focused. It's not doing any\nother tool calls.\nWe've got the chat agent. So, this is\nthe default lane that your query is\ngoing to take if it's attached to an\ninfrastructure target, in our case a\nRedis infrastructure target. It gets\nfull tool access, so it's able to do\ntriage, health checks, diagnostics,\ntroubleshooting. And lastly, we have the\ndeep triage agent, and that's for when\nyou need a really exhaustive\ninvestigation. You're okay with the\nagent running for a longer period of\ntime or potentially using more tokens,\nand that's for, you know, major incident\npostmortems. It runs parallel\nmulti-topic research um using MapReduce.\nSo, let's talk a little bit about that\nand how we built that out. So,\nfor deep triage, we don't want the agent\nto run just one giant query. We're going\nto flood our context window so fast. So,\ninstead, it extracts topics from your\nquery, and then it ranks those topics by\nseverity.\nAnd then it spins up parallel workers\nand each parallel worker is assigned to\na separate topic.\nWe also make sure it's a cap the amount\nof topics that we extract so that we\ndon't have too many parallel threads and\nthe agent isn't just getting away from\nus. So that's a way of get of getting\nyour system in control.\nNow each worker is going to be producing\ntheir own recommendations and evidence.\nThe orchestrator agent is then going to\ntake all of their outputs and reduce\nthem into a final report. So that's the\nmap reduce portion of it and this is how\nwe do an exhaustive investigation of a\ncomplex incident without the whole thing\nbecoming one enormous context window.\nSo I just want to point out one critical\npiece at the end which is that we have a\nfact corrector pass. So even after we\nextract all of these different topics,\nwe have a second model that's actually\ngoing to review our final output and\nit's going to remove any unsafe or\nfabricated commands because it has\naccess to our knowledge base and that\nmakes sure that we don't redo the full\ninvestigation and it's our last line of\ndefense before recommendation makes it\nback to the originator of the query.\nSo\ndespite the instinct, it's not always\nbest practice to use the beefiest model\nfor everything that you want done within\nyour agent.\nFor some things, it makes sense. Like if\nyou have heavy reasoning work, uh you\nwant to do some large synthesis, you\nwant to make some final recommendations.\nYes, use the biggest and the best model.\nBut even then you have to be smart. A\ndeep triage investigation like I showed\nyou guys earlier, it might involve\ndozens of model calls. And if you're\nrunning all of those model calls on your\nheaviest model, it's going to be really\nslow and it's going to be really\nexpensive. And so we leverage a mini\nmodel to do per topic research and that\nmodel is fast enough to work in parallel\nand it's smart enough to produce useful\nsummaries. So, we also use that model to\ndo all of our knowledge tasks\ncuz again, you don't need that that big\nhefty model for all of these particular\ntasks. The nano model then\nalso handles classification. So, if\nwe're classifying, like for example, our\nagent router, we again, we just need one\nthat's going to be able to say this\nquery is headed to the knowledge agent,\nthis query is headed to the chat agent,\nor the triage agent. So, these are some\nof the different model strategies that\nwe employ to make sure that the model\ncapability is mapped to the task\ncomplexity in a way that it makes the\nagent practical to run at scale. So,\nagain, like in the short term, using a\nbigger model, fine, but once you're\nrunning these things at scale, you need\nto be careful about the amount of\nlatency you're incurring as well as\ncost.\nAll right. So,\nsomething that we noticed is that\nknowledge queries repeat a lot, right?\nWe've got engineers asking the same\nquestions about commands or different\nconfiguration options or best practices.\nAnd so, we leverage a strategy called\nsemantic caching.\nSo, we use Redis as a semantic cache and\nwhen a query comes in, we go ahead and\nembed it and we run a vector similarity\nsearch against the cache which contains\nall previous queries. So, if there's a\nmatch above a certain threshold, then we\ncan return the cached answer with the\ncitations, no LLM call needed. So, if\nyou go to our booth, and I love talking\nabout this, if you go to our booth,\nwe've got stickers that say, \"Call your\nmom, don't call your LLM.\"\nAnd this is what we're talking about.\nDon't do the same work and spend tokens\non it, leverage the work that the agent\nhas already done. And I I want to say\nthat this is something that's become a a\ncore strategy for those leveraging\nRedis. Many of you know us again, I\nspoke about how we're reliable caching\nlayer, but we've now taken that strategy\nto agents. And I I also want to call out\nthat this strategy is not going to work\nfor all use cases, right? It's going to\nwork best when you have kind of the same\nquestions that are coming in in\ndifferent ways and you have a more\ndefined set of answers. For more dynamic\nsystems like take our chat agent or our\ndeep triage agent, this wouldn't make\nsense\nbecause tool outputs are continually\nchanging. So, you want to be smart about\nwhere you employ these strategies, but\nwhen used in the right context, it can\nbe extremely extremely powerful.\nAnd I think it's on the slide, but our\ncustomers have seen that\nafter using semantic cache, it's about\n15 times faster and 98% cheaper. So, you\ncan visualize many of the concepts that\nwe've covered here.\nSo,\nI don't know about you guys, but I'm\nmore of a visual learner.\nSo, it helps me to see how different\ncomponents connect together in an\narchitecture diagram. So, you can see\nour three specialized chat agents.\nWe've got the knowledge agent,\nour chat agent, and our deep triage\nagent.\nAnd you can see the live infrastructure\nthat the agents will be interacting with\non the top right.\nYou can see the knowledge base that's\nstored within Redis indices.\nAnd let's talk a little bit about how we\naccess these agents. All right, we've\ngot a few different interfaces that we\nexpose.\nWe've got the UI and the CLI for human\nusers.\nAnd we've got MCP and API for\napplications or AI-enabled applications\nthat may want to leverage this agent as\na tool.\nSo, you'll notice that we haven't built\na solution that's per interface. We've\nbuilt a solution that works across all\nof these interfaces leveraging a thread\nmanager.\nSo, you can start a thread via one\ninterface and then continue in the other\nwith absolutely no problems.\nAll of this thread data is stored within\nRedis, so it can be easily and quickly\nfetched by the agent.\nSo, something I want to say is that this\nis not just a chat app with tools that\nare bolted on.\nWe need to make sure that it's an\noperational runtime\nand that can manage capability scope per\nconversation.\nWe separate tools into always-on base\ntools like knowledge, utilities, target\ndiscovery. We also have dynamic tools\nthat are loaded based on the resolved\ntarget.\nSo, for example, if you've got a prompt\ncoming in that's specific to a Redis\nEnterprise instance, we're going to load\nRedis Enterprise tooling, but you won't\nnecessarily need that if you're talking\nabout an open-source instance, something\nalong those lines.\nThis prevents the model from even\nconsidering tools that don't apply. So,\nyou're not wasting, again, your context\nwindow. Tools and it makes things\nfaster. So, tools are organized by\ncapability.\nAs I mentioned, we've got diagnostics,\nwe've got metrics, we've got logging.\nEach family has its own schema, its own\nlife cycle. So, we've really organized\nthe way in which your agent is using the\ntooling and each tool can emit status\nupdates so that the user knows what's\nhappening during a long-running\ninvestigation.\nYou can also specify multiple targets\nfor a specific prompt and we're able to\nmanage that with a tool routing table.\nSo, once we resolve a target, only the\ntools that are relevant to that target\nare loaded, like I mentioned earlier.\nSo, that helps us kind of, again, speed\nup the agent.\nAll right. So, I I've talked about the\nLLM context window many times in this\npresentation and I want to talk a little\nbit about what that context window\noverwhelm or context run actually means.\nAs the context gets larger,\nyou start to see some pretty consistent\ndegradation effects.\nOne of them is called the loss in the\nmiddle problem. Models tend to pay more\nattention\nto the beginning and the end of the\ncontext window. They're much less\nreliable at using information that sits\nsomewhere in the middle.\nSo, if it's something important that's\nburied middle in the middle of these\nlogs or traces, there's a good chance it\ndoesn't get used.\nAnother thing I want to talk about is\nrecency bias.\nThe model tends to overweight what was\nadded most recently to the prompt, even\nif it's not the most relevant signal.\nSo, newer information can actually crowd\nout earlier context that might matter\nmore. So, what's interesting that you'll\nsee is that you'll see both of these\neffects happen way before the context\nwindow hits maximum capacity. You're\ngoing to see it at about the halfway\nmark.\nSo, we actually thought about that a\nlot, especially because we were seeing\nvery large tool outputs.\nThink 10,000 tokens tokens of raw\nmetrics or log data,\nwhich is absolutely going to blow up\nyour context window if you're not\ncareful.\nSo, we have a few strategies that we\nemploy here.\nOne is that we compress large tool\noutputs to\naround 500 token summary. So, we kind of\nset that static for the moment\num before putting them into context.\nObviously, when you compress large tool\noutput, you're going to lose data,\nright? And you have to be careful with\nthat. So, we kind of leave it up to the\nLLM. Does the LLM require more data in\norder to solve the issue that we've\npassed in? All right. Now it has access\nto an expand\ncontext tool. And so, it's going to go\nahead and call that tool and then\nreceive the entire tool output from\nbefore. So, we store that tool output\nwithin Redis and then we can leverage it\nwhen needed rather than just again\nflooding that context window by default.\nWe also cache tool results within a\nterm. So, if that same tool is used and\ncalled with the same parameters multiple\ntimes in one session,\nthe second call is going to return\nimmediately because it's going to use\nthe results from the initial tool call.\nAnd this is again per session run.\nSo, if you think about our map reduce\ntriage flow, you got these parallel\nagents running per topic. They might\nneed to leverage the same tool, but\nwithin their parallel execution that\ntool output is not going to change. So,\nwhy have the tool run over and over\nagain using tokens and decreasing\nincreasing latency? Let's actually take\nadvantage of our cache and have all of\nthese parallel workers access that same\ncache.\nAll right. So,\nwith our partners, we realized that\nevery organization has knowledge that\nlives nowhere except in people's heads.\nOr it might live in a confluence\ndocument that that nobody reads. Um, but\nwe can give customers a few ways to\nbring that into their agent. So, skills\nare operational runbooks. So, they're\ningested as first-class documents and\nthey're retrieved automatically when a\nrelevant question comes in. So, you want\nto make sure your agent has support for\nskills. We're building modern agents\nhere. People are kind of making their\nown skills on MD and they want to be\nable to influence how the agent runs.\nYou don't want your agent to be a black\nbox. Skills enable you to add\nfunctionality or add behavior to your\nagent when you need it. So, we've added\nsupport for that. So, our partners are\nable to kind of use the agent as they\nwant.\nWe've also leveraged something called\npinned policies. So, within every\nenterprise, there's kind of certain\nrules or policies\num that they enforce and every engineer\ndoes that by default. Okay, so why\nshould the SRE agent be exempt from\nthose rules? You can actually add that\nto your knowledge base and you can pin\nit. So, what pinning a document means\nis that no matter what the query is that\ncomes in, it's always going to be passed\nin a system context to the agent, no\nmatter what. So, if we're not doing any\nsemantic querying here,\num and it's always surfaced. So, that\nmakes that very reliable.\nLastly,\nobviously, these um organizations want\nto leverage support tickets that they've\ncreated or they see internally. So, we\ngo ahead and ingest that within our\nknowledge base as well. Um and that\nallows us and our agent to be able to\nsearch across past resolutions um when\ndiagnosing new issues.\nSo, there's actually something that we\nlearned while adding support\nfor uh support tickets for our design\npartners, we realized when they're\nsearching with queries like\n\"Tell me about the issue that we hit in\nINC12345.\"\nSemantic search is going to look for\ntickets that are semantically similar to\nINC12345, but you don't want that.\nSometimes you just need an exact text\nmatch search.\nAll right, but full text search isn't\ngoing to work here either because if\nsomeone asked a question like, \"Give me\nincidents that handle timeout issues\nsimilar to the one that I saw in\nINC12345.\"\nNow, all of a sudden, you need both. You\nneed an exact text merge match to be\nable to find INC12345,\nbut you also need semantic search to\nfind other tickets that were kind of\nrunning into the same issues.\nSo, luckily, Redis supports hybrid\nsearch. And this basically takes both of\nthose individual search mechanisms and\ncombines them with RRF fusion, which\nbasically just means retrieval rank\nfusion, um and enables to us to to\nhandle these more complex queries.\nOkay. So, we've built out an agent with\ntrusted data sources. We've added tool\ncalling strategies. It's got a ton of\ndata and it can reason effectively.\nAwesome. Okay, but we are missing one\ntool though, which is the agent itself.\nAnd the longer the agent runs, the more\nit learns about each user and each\ninfrastructure target. And we want to be\nable to leverage that. So, we use\nsomething that um my team created, the\nApplied AI team. It's called the Redis\nagent memory server. And this is our\nopinionated view on how to approach\nmemory within an agent.\nSo, agent memory stores all messages\nwithin the session as well as well as\nevery tool call results. So, you do have\nyour two layers of memory, right? Your\nshort-term memory, which is your session\nmemory. Then your long-term memory,\nwhich is your ephemeral memory that\npersists across sessions. So, you're\ngoing to go ahead and store that\nshort-term memory within Redis. Again,\nall your messages, all your tool calls.\nBut what's going to happen that you\ndon't really have to worry about is\nyou're going to have an extraction\npipeline that's running very regularly\nand you can set the period of time to\ngraduate those messages into memories.\nSo, you can create your own custom\nextraction strategy, which is what we\ndid, um in order to be able to pull\ninformation about user preferences,\nrecurring incidents, and facts about the\nenvironment and topology. So, what it's\ngoing to do is it's going to take the\nmessages, it's going to only grab\nmemories. So, we use a nano LLM and run\nthat on the messages and use the\nextraction strategy and pass that into\nthe LLM. Then it extracts anything that\nthat we've decided we feel is valuable\nto us in long-term memory. We also\nextract topics. So, we use a transformer\nin the back end to extract any relevant\ntopics so that you can filter very\neasily on your search on the other side.\nWe also do known entity extraction or\nnamed entity extraction. So, if you did\ntake a particular name or you used, I\ndon't know, a company name or a product\nname or a place name, Like, you're not\ngoing to want to specify all of that\nwithin your extraction strategy. We\nenable that, so it kind of happens by\ndefault, and we're able to allow you to\nfilter and make the process faster on\nthe other side.\nSo, our agent isn't just processing\ndata, it's generating it, and we're\ntaking full advantage of our ecosystem.\nWe're also not just taking entire\nsession data and storing it again in our\nlong-term memory, and using up more\nstorage costs, as well as flooding our\ncontacts window on the other side. We're\nbeing succinct about what we take out\nand what we want to store. And then\nagain, when the agent has a query come\nin, you can go ahead and leverage that\nmemory, and look for anything\nsemantically similar or related to that\nuser ID, or that cluster ID, etc., and\nthen be able to pull relevant memory up\nand give that to your agent from the\nget-go. So, an example of this is\nyou know, we have uh particular users\nthat are like\n\"I just want a succinct answer from the\nagent.\" And they're not going to write a\nskill for that, they're just going to\ntype that to the agent, \"Hey, next time\ngive me a succinct answer.\" Or we're\ngoing to want someone who's like, \"Hey,\nalong with all the commands you're\ngiving me, make sure you give me\nextensive details on what they actually\ndo.\" So, each user has their own\npreferences, you're going to want to\nstore that within memory, and then\nsurface that up the next time the user\ninteracts with the agent. So, that's\njust one example.\nAll right, fantastic. We've got an agent\nthat we can trust.\nBut how do we prove it?\nAnd in an SRE context\n\"The agent said so\" is really like not\nenough. Um the engineer needs to be able\nto trace the answer back to an\nauthoritative source, and then make the\nfinal call themselves. We're not trying\nto replace SRE engine engineers.\nSite reliability engineers can leverage\nthis agent to help them make extremely\nfast decisions. And that's why every\nanswer the agent produces includes\ncitations. So, this includes what\ndocuments were accessed within the\nknowledge base, what tool calls were\nmade, and this isn't just for audit\nauditability,\num but it's how an on-call engineer can\nactually verify the recommendation\nthemselves.\nAll right. So, one last kind of thing I\nwant to talk about is that the agent can\nalso operate on a schedule.\nAnd so, you can instead of making the\nagent more reactive, you can make it\nproactive, right? Especially for things\nlike triaging infrastructure, you can\nhave it monitor the infrastructure, or\nyou can set it on, you know, developers\nknow it's cron job.\nAnd it'll allow the agent to alert you\nbefore you think to ask. So, we\nbasically have used that to run\nautomated diagnostics, uh generating\ndaily health summaries, like execs might\nwant, you know, a health summary of the\ninfrastructure every week or something\nlike that. You can use the agent and set\nup a schedule in order to do that.\nOkay. I love diagrams. I think I choked\nthat out earlier, but I can say it with\na little bit of a clearer voice now.\nUm diagrams help us really visualize\nwhat's going on, and this allows you to\nbasically see all the ways that our\nagent is working. We've got all of our\ndifferent interfaces. We've got all of\nthe startup information that you need,\num including skills, including runbook,\naccessing the knowledge base. We got our\nagent router, and then we've got it\nleveraging the memory server,\nand running tool calls. And as you can\nsee, our tool calls are grouped by their\nfunctionality. Um so, that's kind of a\ngist of how the entire agent ecosystem\nlooks, but we got into a lot more detail\nthan what's shown on here.\nUm I want to close with something that\nmight seem really obvious in retrospect,\nbut shaped the entire architecture.\nMy goal today was not to deliver a\nmarketing talk, but really to talk just\nfrom an engineering perspective how we\nbuilt this agent out. And for us, Redis\nwasn't just a cache, like the way that\nmany people use it within the system.\nIt's the semantic vector store. It's the\nthread manager. It enabled us to have\nhybrid search across a knowledge base.\nIt stored schedules for proactive\nfunctionality. It's a semantic cache.\nIt's a place where partners can add\ntheir tribal knowledge. It's the memory\nserver and it's a catalog across all of\nour infrastructure resources. Thanks to\nthese features and these architectural\ndecisions, the agent is now grounded,\nit's context aware, it's evidence\ndriven, and it's verifiable. And the\nRedis context engine was really the\ntissue, the connective tissue that made\nall of that possible.",
  "transcript_chars": 30801,
  "ingested_at": "2026-05-21T19:16:42.644878+00:00",
  "source": "retry-no-transcript",
  "yt_meta": {
    "view_count": 169,
    "like_count": 2,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w"
  }
}