Seu agent não é burro. Seu contexto está quebrado.

Autoria: Prompt Engineering · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Your Agent Isn’t Dumb. Your Context Is Broken. · Canal: Prompt Engineering · 12:58 · Assistir no YouTube

Tópicos: Agentes de IA, Dados, bancos de dados e embeddings, Engenharia de prompts e contexto

Resumo

Agents costumam falhar não por falta de inteligência do modelo, mas porque recebem contexto desatualizado, desconectado ou lento. O vídeo diferencia prompt engineering de context engineering e apresenta quatro requisitos para um contexto eficaz: ser navegável, atualizado, rápido e capaz de acumular aprendizados. Em seguida, demonstra como usar Redis e um MCP server para fornecer memória de longo prazo a um agent de programação entre sessões. Os experimentos mostram recuperação semântica de convenções do projeto e extração automática de preferências a partir de conversas.

Pontos-chave

Falhas como alucinações, informações desatualizadas e respostas lentas podem decorrer de problemas no contexto, mesmo quando o raciocínio do modelo está correto.
Prompt engineering ajusta a instrução inicial; context engineering constrói o sistema de runtime que seleciona e entrega informações ao agent.
Um contexto adequado precisa ser navegável entre entidades, atualizado, rápido e capaz de acumular aprendizados ao longo do tempo.
A memória de trabalho guarda informações temporárias da tarefa; a memória de longo prazo preserva fatos úteis entre sessões.
Uma camada automatizada pode extrair fatos duráveis, recuperar apenas os relevantes e evitar o acúmulo de informações redundantes ou transitórias.
Na demonstração, Redis armazena memórias como hash e vetor, permitindo busca semântica por meio de um MCP server.
Um agent de programação recupera convenções do projeto em uma sessão nova e as aplica ao escrever e testar código.
Os experimentos também mostram busca semântica sem correspondência literal de palavras-chave e extração automática de preferências do usuário.

Capítulos

Início	Capítulo	Resumo
00:00	Por que agents falham: problemas de contexto	O vídeo apresenta falhas de contexto, como dados isolados, desatualizados ou lentos, e diferencia context engineering de prompt engineering.
03:17	Requisitos e memória para um contexto eficaz	O contexto deve ser navegável, atualizado, rápido e cumulativo, com memória de trabalho e memória de longo prazo.
06:59	Demonstração de memória entre sessões com Redis	A demonstração conecta um agent de programação a Redis por um MCP server e mostra como convenções do projeto são salvas e recuperadas.
10:17	Busca semântica e aprendizado contínuo	Os experimentos verificam a recuperação semântica e a extração automática de preferências, mostrando como os aprendizados podem se acumular.

Citações

Eles falham porque o contexto que você fornece está quebrado. — 00:00

Prompt engineering é o que você diz ao modelo. Context engineering é todo o ambiente de runtime que você constrói ao redor dele. — 02:42

Se o agent age com um estado desatualizado, age com confiança, mas de forma errada. — 03:51

O contexto que você fornece ao seu agent é mais importante do que o tamanho do modelo. — 12:24

Conceitos e entidades

context engineering (conceito): Abordagem que constrói o sistema de runtime responsável por selecionar e fornecer contexto relevante ao agent em cada etapa.
Prompt Engineering (conceito): Prática de estruturar e ajustar a instrução inicial dada ao modelo.
working memory (conceito): Memória temporária que mantém o estado e as informações necessárias à tarefa em andamento.
long-term memory (conceito): Memória que preserva fatos úteis, como convenções de projeto, entre sessões ou execuções.
semantic search (conceito): Busca que recupera informações por significado, em vez de depender apenas de palavras-chave iguais.
Redis (ferramenta): Tecnologia apresentada na demonstração para armazenar e recuperar memórias do agent.
Redis 8 (ferramenta): Versão mencionada como base para armazenar cada memória como hash associado a um vetor.
MCP server (ferramenta): Servidor usado para conectar o agent ao serviço de memória do Redis e disponibilizar ferramentas de memória.
DeepSeek Coder (modelo): Modelo de programação citado na demonstração como não tendo memória entre sessões por padrão.
4.1 flash (modelo): Modelo identificado na transcrição como usado na demonstração por meio de uma API.
UV (ferramenta): Ferramenta mencionada para gerenciamento de dependências e execução de testes no projeto demonstrado.
Ruff (ferramenta): Linter indicado como convenção do projeto na demonstração.

Tradução completa (pt-BR)

00:00 Os agents não falham porque o modelo que você escolheu não tinha inteligência suficiente. Eles falham porque o contexto que você fornece está quebrado. E, como se vê, fornecer a um agent um contexto estruturado e cirúrgico supera fazer upgrade para um modelo flagship gigantesco, todas as vezes. Mas a pergunta é: o que exatamente significa um contexto melhor? E como exatamente você o constrói? Essa é uma questão urgente neste momento. Recentemente, a Redis publicou um relatório sobre isso que confirma o que as equipes em produção vêm observando: nós temos

00:33 otimizado a camada errada da stack. Neste vídeo, vamos analisar os modos de falha arquiteturais. Depois, vou mostrar uma demonstração de como construir contexto com Redis. Mas primeiro, vamos analisar alguns modos de falha comuns que os agents encontram. Digamos que você tenha um agent de suporte ao cliente e o usuário pergunte sobre o status do pedido. O primeiro modo de falha é o que vamos chamar de beco sem saída. O agent busca o ticket de suporte, mas não há nenhum caminho relacional até o registro do

01:05 pedido, porque eles ficam em silos diferentes. Então, o modelo faz o que os modelos de linguagem fazem quando estão às cegas: simplesmente alucina. A segunda falha é o estado desatualizado. Nesse caso, o agent encontra o pedido, mas usando uma exportação feita 12 horas antes. Isso está relacionado à atualização dos dados. O pacote, na verdade, foi enviado hoje de manhã, mas o agent não sabe disso. Então, nesse caso, o agent diz com confiança que ele não foi

01:36 enviado e acaba fornecendo informações erradas ao usuário. A terceira falha é a latência. Digamos que o agent consiga encontrar os dados certos, mas encadeie oito chamadas sequenciais de ida e volta entre três APIs diferentes. Quando finalmente responde ao usuário, o usuário já fechou a sessão de chat, porque a latência foi simplesmente alta demais. Agora, em todos esses três casos diferentes, o raciocínio do modelo estava bom. A falha não é falta de

02:09 inteligência. Basicamente, o problema é fornecer a ele o contexto certo na hora certa. E isso pode, de fato, comprometer seus sistemas agênticos sem que você perceba. E o suporte da Redis mostra exatamente isso. Então, vamos retomar o que exatamente é engenharia de contexto para um agent e em que ela difere da engenharia de prompt. A engenharia de prompt trata basicamente de como você estrutura a instrução inicial para o modelo. Você pega uma única string e ajusta a

02:42 formulação, adiciona alguns exemplos curtos e impõe um schema. É útil, mas tudo fica dentro dessa única string. A engenharia de contexto opera em uma camada inteira acima disso. Ela consiste em construir o sistema em tempo real que decide qual estado dos agents usar em cada etapa. Por exemplo, qual registro de cliente buscar, quais estados atuais inspecionar e como fornecê-los com rapidez suficiente para produção. Então, engenharia de prompt é o que você basicamente diz ao modelo. Engenharia de contexto é todo o ambiente de execução

03:17 que você constrói ao redor dele. E a maioria das falhas que você vê em sistemas agênticos vem do fornecimento de contexto errado ou quebrado. Voltando àqueles modos de falha, o contexto pronto para produção precisa satisfazer quatro regras mecânicas. A primeira é que ele precisa ser navegável. O agent precisa percorrer as relações entre entidades como usuários, pedidos e tickets, em vez de fazer buscas às cegas por palavras-chave ou em texto bruto. A segunda é que ele precisa estar atualizado. Se o agent age com base em um estado desatualizado,

03:51 age com confiança, mas de forma errada. Por isso, a atualização é fundamental. A terceira é que ele precisa ser rápido. Quando uma tarefa aciona dezenas de subconsultas, a latência das consultas se acumula diretamente e compromete os workflows. Então, você precisa levar a latência em consideração. E a quarta é algo que a maioria das configurações ignora: o contexto precisa se acumular. Hoje, quando a sessão do agent termina, o contexto é apagado por completo. Quando o mesmo usuário volta no dia seguinte,

04:21 o modelo precisa reaprender quem ele é, quais convenções usa e o que deu errado da última vez. Mas, para um sistema de produção ser realmente eficaz, ele precisa ficar mais inteligente quanto mais você o usa. E é por isso que os aprendizados do sistema precisam se acumular ao longo do tempo. Tudo isso diz respeito a um contexto excelente, não a prompts maiores. O importante é ter a informação certa na hora certa. Agora, a pergunta é por que a maioria das equipes não consegue construí-lo. É aqui que

04:52 a maioria das equipes de engenharia fica travada. Digamos que existam duas ou três equipes diferentes. A equipe A cria um agent e configura bancos de dados vetoriais isolados para busca de documentos, o que funciona muito bem. A equipe B cria um agent e desenvolve seus próprios scripts personalizados de persistência em um armazenamento separado. De novo, isso funciona muito bem. Mas então há uma equipe C que conecta algumas ferramentas. O problema é que elas não se comunicam entre si, porque todas estão em silos. Agora, digamos que, seis meses depois, você

05:24 tenha uma dúzia de pipelines de dados desconectados, ninguém consiga garantir que os dados estejam atualizados e cada novo agent passe a maior parte do tempo reconstruindo a infraestrutura de contexto. E é isso que acontece na maioria das organizações de engenharia hoje. Certo, vamos falar sobre como os agents acumulam contexto entre sessões. Para isso, o agent precisa de dois tipos de memória. O nível um é a memória de trabalho, que é basicamente um bloco de rascunho para a tarefa ativa. Você precisa ter acesso às chamadas de ferramentas imediatas

05:57 e ao estado de execução delas. Quando a sessão termina, isso é apagado. O nível dois é o que vamos chamar de memória de longo prazo. Ela armazena fatos duradouros que precisam persistir entre sessões ou execuções, incluindo coisas como decisões de projeto, configurações de ambiente ou casos extremos de depuração. E um ótimo agent precisa dos dois tipos. O truque está em como os fatos passam de um tipo para o outro. Você não pode depender dos usuários para marcar os fatos manualmente

06:29 Então, você precisa de uma camada automatizada de memória que analise a conversa e extraia fatos duradouros em segundo plano. Isso precisa acontecer automaticamente. Assim, quando uma sessão nova é iniciada, ela faz uma busca semântica para recuperar apenas os fatos históricos específicos relevantes para o prompt ativo. Mas também é preciso evitar que a memória vire uma gaveta de tranqueiras abarrotada. O mecanismo lida com duplicações e expiração, descartando

06:59 ruídos temporários e mantendo fixas as regras permanentes do projeto, o que também garante que o contexto seja navegável, atualizado, rápido e se acumule ao longo do tempo. Infelizmente, a maioria das implementações agênticas atuais não tem isso de verdade. Então, neste caso, vou mostrar uma solução simples baseada em Redis, que vai fornecer ao seu agent um contexto rápido, atualizado e que se acumula. Para contextualizar tudo o que discutimos, vamos analisar um exemplo prático.

07:33 Neste caso, estou trabalhando com o harness Deep Seek e o modelo 4.1 flash, que acessamos pela API. Por padrão, o DeepSeek Coder não tem memória entre sessões integrada. E é isso que vamos construir. Vamos usar um servidor MCP, que vamos conectar ao servidor de memória de agents da Redis. Por baixo, o Redis 8 armazena cada memória como um hash com um vetor associado. Assim, você pode pesquisá-las por significado, em vez de

08:09 fazer uma simples busca por palavras-chave. Este é o experimento. Na sessão um, vou contar ao agent algumas convenções do projeto. Depois, a sessão dois será uma sessão completamente nova, na qual nada será mantido da anterior. E vamos atribuir a ele uma tarefa de escrita. Se a memória funcionar como queremos, o agent da sessão B deve consultar a Redis primeiro e aplicar essas convenções sem que eu precise repeti-las. Então, vou mostrar o que aconteceu quando executei o experimento.

08:40 Certo, vamos falar primeiro sobre a integração. Precisamos de um arquivo YAML que informe ao harness que existe um servidor MCP chamado Redis memory. Observe a última parte da URL, que é o namespace. Assim, tudo o que esse agent armazena fica limitado a esse projeto específico. A segunda linha configura o modelo. Neste caso, iniciamos o modelo e, em seguida, ele pergunta ao servidor MCP quais ferramentas estão disponíveis. Aqui, você vê uma lista de 10 ferramentas diferentes

09:11 que podem criar memórias, pesquisar memórias, editar, excluir e assim por diante. Certo, vamos falar sobre o que aconteceu exatamente na sessão A. Aqui, eu disse que vamos usar UV para gerenciamento de dependências, Ruff para linting, e que cada função deve ser pura e apenas retornar uma nova tupla. Como o MCP está conectado, o agent primeiro verifica a memória e não encontra absolutamente nada, porque estamos começando do zero. Então, ele chama a ferramenta de criação de memórias de longo prazo e armazena esses três fatos separadamente

09:45 os fatos que acabamos de descrever no nosso prompt. Então, podemos ver exatamente o que ele fez aqui. Agora, podemos olhar o conteúdo do próprio Redis. Se você consultar o servidor de memória, ele vai retornar essas três memórias. Você também pode ver o hash bruto do Redis incluído. Então, este é o texto, o namespace, o usuário e o tópico. E, como estamos fazendo recuperação semântica, ele tem esses embeddings. Agora, vamos olhar a sessão P, uma nova sessão no mesmo repo, com zero

10:17 histórico de conversa. Neste caso, estou pedindo que ele adicione uma função para remover tarefas, com um teste, e depois execute os testes e o linter. Agora, veja exatamente o que ele faz. Antes de ler um único arquivo, ele chama a busca por memória de longo prazo; depois, retorna as convenções encontradas: funções puras que retornam novas tuplas e um erro de chave para IDs desconhecidos. Então, basicamente, ele lê o código e

10:50 escreve as funções. Podemos olhar o diff: a função retorna uma nova tupla, exatamente de acordo com o estilo existente que descrevemos. E, para verificar, ele executa uv run test. Estamos vendo que cinco testes diferentes estão passando. Agora, usando Redis, conseguimos adicionar memória de longo prazo diretamente ao nosso agente de programação, que não tinha memória de longo prazo. Certo, aqui estão mais alguns experimentos que fiz. O primeiro foi verificar se ele está realmente usando busca semântica ou apenas busca baseada em palavras-chave. Então, perguntei ao servidor de memória qual linter e gerenciador de pacotes este repo usa. Nenhuma dessas palavras-chave aparece na memória armazenada, mas, como você pode ver, ele identifica “rough” e apresenta as menores distâncias, o que significa que está fazendo busca semântica, não uma simples correspondência baseada em palavras-chave. O segundo experimento que eu queria fazer era verificar se a memória cresce por conta própria. Então, neste caso, enviei uma conversa simples para a memória de trabalho, apenas usuários dizendo que preferem anotações de tipo e nomes de testes descritivos. Não pedimos especificamente que ele usasse a ferramenta de armazenamento de memória, mas você pode ver que a instrução para salvar a memória foi concluída e uma memória foi extraída. Então, você pode ver exatamente o que o usuário quer que fique na memória de trabalho de longo prazo, o que é ótimo, porque agora o agente poderá extrair informações úteis das conversas com o usuário e

11:21 busca ou simplesmente busca baseada em palavras-chave. Então, perguntei ao servidor de memória qual linter e gerenciador de pacotes este repo usa. Nenhuma dessas palavras-chave aparece na memória armazenada, mas, como você pode ver, ele recupera resultados aproximados e com as menores distâncias, o que significa que está fazendo busca semântica, não correspondência simples baseada em palavras-chave. Agora, o segundo experimento que eu queria fazer era ver se a memória cresce sozinha. Então, neste caso, enviei uma conversa simples

11:52 para a memória de trabalho: apenas usuários dizendo que preferem dicas de tipo e nomes descritivos para testes. Não pedimos especificamente que ele usasse a ferramenta de armazenamento de memória, mas você pode ver que a instrução para salvar na memória foi concluída e que uma memória foi extraída. E então você pode ver exatamente o que o usuário quer manter na memória de trabalho de longo prazo, o que é ótimo, porque agora o agent poderá extrair informações úteis das conversas com o usuário e

12:24 colocá-las na memória de longo prazo, que é baseada no Redis. E o bom dessa abordagem é que os aprendizados vão se acumulando à medida que você usa esse sistema. Certo, para encerrar: como discutimos ao longo deste vídeo, o contexto que você fornece ao seu agente é mais importante do que o tamanho do modelo. Para isso, você precisa de uma ótima camada de memória que o agente possa usar. Redis é um ótimo exemplo, e você pode acessá-lo pelo servidor MCP.

12:58 O bom é que você pode conectar isso a qualquer agente de programação, e ele vai fornecer um contexto melhor sem sacrificar a precisão e o desempenho. Enfim, me diga se você achou este vídeo útil. Obrigado por assistir e, como sempre, até a próxima.

Transcrição original

[00:00] Agents are not failing because the model you picked lacked intelligence. They fail because the context you feed into them is broken. And as it turns out, giving an agent structured surgical context beats upgrading it to a massive flagship every single time. But the question is what exactly better context means? And how exactly do you build it? This is a burning question right now. Redis recently posted a report on it that confirms what teams in production have been seeing, which is that we have

[00:33] been optimizing the wrong layer of the stack. In this video, we’re going to break down the architectural failure modes. And then I’m going to show you a demo of how to build context with Redis. But first, let’s look at some common failure modes that the agents run into. Let’s say you have a customer support agent and the user asks about the status of their order. The first failure mode is what we’re going to call dead end. The agent pulls the support ticket, but there is zero relational path to the

[01:05] order record because they live in different silos. So, the model does what language models do when blind, it simply hallucinates. The second failure is stale state. In this case, the agent finds the order, but from an export taken 12 hours ago. This relates to the freshness of data. Now, the package has actually shipped this morning, but the agent does not know about it. So, in this case, the agent confidently says that it has not

[01:36] shipped and it ends up providing wrong information to the user. The third one is latency. Say the agent is able to find the right data, but it chains eight sequential round trips across three different APIs. Now, by the time it responds to the user, the user has already closed the chat session because the latency was just way too much. Now, in all of these three different cases, uh the model’s reasoning was fine. The failure is not the lack of

[02:09] intelligence. It’s basically providing it the right context at the right time. And this can actually break your agentic systems without you even realizing. And Redis support shows exactly that. So, let’s revisit what exactly is context engineering for an agent and how exactly it differs from prompt engineering. So, prompt engineering is basically all about how you structure the initial instruction to the model. You basically take a single string and tweak the

[02:42] phrasing, add a few short examples, and enforce a schema. It’s useful, but everything lives inside that single string. Context engineering operates an entire layer above that. It’s building the real-time system that decides what the state agents on every single step. For example, which customer record to fetch, which live states to inspect, and how to deliver them fast enough for production. So, prompt engineering is what you basically say to the model. Context engineering is the entire runtime

[03:17] environment you build around it. And most of the failures that you see in agentic systems comes from providing wrong or broken context. Looking back at those failure modes, production-ready context has to satisfy four mechanical rules. The first one is that it must be navigable. The agent needs to traverse relationship between entities like users, orders, and tickets instead of doing blind keyword lookups or raw text. Second, it must be fresh. If the agent acts on stale state,

[03:51] it acts confidently wrong. So, freshness is critical. Third, it must be fast. When uh task triggers dozens of subqueries, query latency directly compounds into broken workflows. So, you need to think about latency. And fourth, this is what most setups ignores. It must compound. Today, when agent session ends, its context is wiped down to zero. When the same user returns tomorrow,

[04:21] the model has to relearn who they are, what conventions they use, and what broke last time. But, for a production system to be very effective, it has to get smarter the more you use it. And that’s why the learnings from the system needs to compound over time. Now, all of this is about great context, not bigger prompts. It’s all about the right information at the right time. Now, the question is why most teams are not able to build it. So, here’s where

[04:52] most engineering teams get stuck. Say there are two three different teams. Team A builds an agent and set up isolated vector databases for document search, which works great. Now, Team B builds an agent and rolls their own custom persistence scripts over a separate store. Again, this works great. But, then there is a Team C who is stitching together a few tools. The problem is none of them are actually talking to each other because all of them in are silos. Now, say 6 months later, uh you are

[05:24] going to have a dozen of disconnected data pipelines where nobody can guarantee the data freshness and every new agent spends most of its time rebuilding the context plumbing. And this is the case with most engineering organizations right now. Okay, let’s talk about how do agents compound context across sessions. Now, for this, agent needs two types of memories. Tier one is working memory, which is basically active task scratchpad. You need to have access to the immediate

[05:57] tool calls and their state execution. Now, when the session ends, this is going to be wiped out. Tier two is what we’re going to call long-term memory. These stores durable facts that must survive across sessions or runs, uh including things like project decisions, environment configurations, or debugging edge cases. And a great agent needs both of them. The trick is how facts transition between them. You can’t rely on users to manually tag

[06:29] facts. So, you need to have an automated memory layer that parses the conversation and extract durable facts in the background. Now, this needs to happen automatically. So, when a fresh session boots up, it runs a semantic search to pull only the specific historical facts relevant to the active prompt. But, you also need to be careful to prevent memory from turning into bloated junk drawer. The engine handles duplication and expiry, dropping

[06:59] transient noise while pinning permanent project rules, which also ensures the context is navigable, fresh, fast, and it compounds over time. Unfortunately, most of the current agentic implementations don’t really have that. So, in this case, I’m going to show you a simple solution based on Redis, which is going to provide your agent with fast, fresh, and compounded context. To put everything that we have been discussing into perspective, let’s look at a practical example.

[07:33] So, in this case, I am working through the Deep Seek harness with the 4.1 flash model that we are accessing through the API. Now, by default, the DeepSeek Coder does not have cross-session memory built in. And this is what we’re going to be building. Now, we’re going to be using an MCP server where we are going to connect it to the Redis agent memory server. So, underneath it, Redis 8 holds every memory as a hash and a vector attached to it. So, you can search them by meaning rather than

[08:09] simple keyword search. Now, here’s the experiment. Session one, I’m going to tell the agent a few project conventions. Then, session two is going to be a completely new session uh where nothing is going to be carried over. And we’re going to assign it a writing task. Now, if the memory works the way we want it to, the agent in session B should go to Redis first and apply those conventions without me repeating them. So, let me show you what happened when I ran this.

[08:40] Okay, let’s first talk about the integration. So, we need to have one YAML file which tell the harness that there’s an MCP server called Redis memory. Notice the last part of the URL as the namespace. So, everything this agent stores is scoped to this specific project. The second row paints the model. Now, in this case, we start the model and then it asks the MCP server which different tools are available. So, here you get a list of 10 different tools

[09:11] which can create memories, search memories, edit, delete, and so on. Okay, let’s talk about what exactly happened in session A. So, in here, I said that we’re going to be using UV for dependency management, Ruff for linting, and every function is supposed to stay pure and just return new tuple. Now, since the MCP is connected, uh the agent first checks its memory and finds absolutely nothing there because we are starting with a clean slate. Then it calls the create long-term memories and store these three separate

[09:45] facts that we just described in our prompt. So, we can see exactly what it did here. Now, we can actually look at the content of Redis itself. So, if you query the memory server, uh this is going to give you those three memories back. You can actually look at the raw Redis hash that is included. So, this is the text, the name space, the user, and the topic. And since we’re doing semantic retrieval, it has those embeddings. Now, let’s look at the session P, a new session within the same repo with zero

[10:17] chat history. So, in this case, I’m asking it to add a remove task function with test, then run the tests and the linter. Now, look at what exactly does it do. So, before reading a single file, it calls the search long-term memory, then it comes back with conventions found, pure functions returning new tuples, and then key error with unknown IDs. Then basically it reads the codes and

[10:50] writes the functions. We can actually look at the diff, which is pure returns a new tuple, then exactly matching the existing style that we described. And then for verification, it runs the UV run test. Uh we’re seeing that five different tests are passing. Now, using Redis, we’re able to add long-term memory directly to our coding agent that did not had long-term memory. Okay, so a couple of other experiments that I ran here. The first one was to see whether it’s actually using semantic

[11:21] search or simply keyword-based search. So, I asked the memory server which linter and package manager does this repo use. Neither of those keywords appear in the stored memory, but if you see, it picks up rough and with the lowest distances, which means it’s doing semantic search, not simple keyword-based matching. Now, the second experiment that I wanted to run was to see does the memory grow on its own? So, in this case, I pushed a plain

[11:52] conversation into working memory, just users saying they prefer type hints and descriptive test names. Now, we didn’t specifically ask it to use the memory store tool, but you can actually see that the several locks instruction completed, one memory extracted, and you can then see the exact things that the user want in the long-term working memory, which is great because now the agent will be able to extract useful information from user conversation and

[12:24] put them in long-term memory, which is based on Redis. And the beauty of this approach is that the learnings are going to compound as you use this system. Okay, so to close this out, as we have been discussing throughout this video, context that you provide to your agent is more important than the size of the model. And for this, you want to have a great memory layer that the agent can use. Which Redis is a great example, and you can access this through the MCP server.

[12:58] The beauty is that you can connect this to any coding agent, and it’s going to provide you better context without sacrificing the accuracy and performance. Anyways, do let me know if you found this video useful. Thanks for watching, and as always, see you in the next one.