Your Agent Isn't Dumb. Your Context Is Broken.

Author: Prompt Engineering · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Your Agent Isn’t Dumb. Your Context Is Broken. · Channel: Prompt Engineering · 12:58 · Watch on YouTube

Topics: AI agents, Data, databases and embeddings, Prompt and context engineering

Summary

The video argues that agents often fail because their context is broken, not because their model lacks intelligence. It distinguishes prompt engineering from context engineering and says production-ready context must be navigable, fresh, fast, and able to compound across sessions. The video describes working and long-term memory, then demonstrates using Redis through an MCP server to store and retrieve project conventions for a coding agent. The experiments show semantic retrieval and automatic extraction of durable user preferences into long-term memory.

Key points

Agent failures can stem from disconnected data, stale information, or slow chains of API calls rather than poor reasoning.
Prompt engineering shapes the initial instruction; context engineering builds the runtime system that selects and delivers relevant information.
Production-ready context should be navigable, fresh, fast, and able to compound over time.
Working memory holds active task state and is cleared when a session ends; long-term memory preserves durable facts across sessions.
An automated memory layer can extract durable facts and retrieve relevant ones when a new session starts.
The demo connects a coding harness to a Redis agent memory server through an MCP server.
A new session retrieves stored project conventions before editing code, despite having no chat history.
The experiments demonstrate semantic search and automatic extraction of preferences such as type hints and descriptive test names.

Chapters

Start	Chapter	Summary
00:00	Why agents fail: broken context	The video introduces context as a common source of agent failures and illustrates dead ends, stale data, and latency.
02:09	Context engineering and its requirements	It distinguishes context engineering from prompt engineering and defines context as navigable, fresh, fast, and compounding.
04:52	Memory across sessions	The video explains how isolated team data stores create silos and describes working memory, long-term memory, and automated retrieval.
06:59	Building a Redis memory integration	The demo connects a coding agent to Redis through MCP and shows how project conventions are stored and retrieved in separate sessions.
10:50	Testing retrieval and automatic memory	The experiments test semantic search and automatic extraction of user preferences, then conclude that useful context can compound over time.

Quotes

They fail because the context you feed into them is broken. — 00:00

Context engineering is the entire runtime environment you build around it. — 02:42

production-ready context has to satisfy four mechanical rules. — 03:17

you need to have an automated memory layer that parses the conversation and extract durable facts in the background. — 06:29

context that you provide to your agent is more important than the size of the model. — 12:24

Concepts and entities

context engineering, Prompt Engineering, working memory, long-term memory, semantic search, Redis, Redis 8, MCP server, DeepSeek Coder, 4.1 flash, UV, Ruff

Full transcript (original language)

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.