Your support agent confidently tells a customer they qualify for a refund under a 60-day return policy. Your actual policy is 30 days. The agent hallucinated the longer window, and the easy reaction is to blame the model. But the model never saw your return policy. The failure happened upstream, in what got loaded into the context window.
Recognizing this is driving a shift in how teams build AI apps, and the practice now has a name: context engineering. It's the discipline of designing and managing everything an LLM receives during inference, not just the prompt but the full set of tokens that land in the context window.
This guide covers what context engineering is, why it's become an important foundation for reliable AI agent systems, what infrastructure you need to support it, and how to gauge how mature your own context layer is.
What is context engineering?
Context engineering means deciding what goes into the context window at each step of an agent's run. Those inputs include system instructions, conversation history, retrieved documents, tool definitions, tool call results, and working state. The guiding principle is simple: find the smallest set of high-signal tokens that maximizes the likelihood of your desired outcome.
Each of those inputs competes for space in a finite context window, and each affects the quality of the model's output. Where prompt engineering focuses on phrasing a single instruction, context engineering covers everything else that fills the window around it.
| Dimension | Prompt engineering | Context engineering |
|---|---|---|
| Scope | Crafting the instruction text | Determining everything that fills the context window |
| Methodology | Often one-off, focused on phrasing | Systematic, repeatable architectural frameworks |
| Production fit | Effective for single-turn, stateless interactions | Required for multi-step agentic systems |
| Key question | "How do I phrase this instruction?" | "What information and environment does the model need to succeed?" |
Why agents need context engineering to work
Agents need context engineering because they can't function reliably without it. A single-turn chatbot can get by on a well-phrased prompt, but agents run across multiple steps, call tools, accumulate state, and often resume work after delays. Every one of those actions changes what should be in the context window, and there's no prompt clever enough to manage that on its own.
In many agent patterns, tool outputs land directly in the model's context window. Over a multi-step task, that accumulated context can exceed the window's capacity, increase costs and latency, or degrade the agent's reasoning quality. Without a deliberate system for deciding what to keep, retrieve, compress, or discard at each step, agents drift, lose track of earlier decisions, and hallucinate. Most of those failures trace back to context.
These failures cluster into four modes:
- Fragmentation: Context lives across many systems (CRM, warehouse, object storage, event streams, app state), and no single one holds a complete, current picture of any entity. The agent's answer comes back confident and internally coherent but built on a partial view of reality.
- Opacity: Even when the data exists and is current, the agent can't navigate it. It retrieves text chunks but can't traverse relationships between records, disambiguate entities that look alike, or tell which records are actually relevant rather than just keyword-adjacent. Raw database or API access also makes access control almost impossible to enforce.
- Speed degradation: Latency is a correctness property, not just a performance one. An agent can make a dozen retrieval calls in a single reasoning loop, so a step that feels fine once becomes a problem when it runs at every step, and calls that approach timeout thresholds create intermittent failures that are hard to reproduce.
- Non-accumulation: The agent delivers the same level of capability no matter how long the system has run or how many interactions it has handled. Without memory, the infrastructure depreciates instead of appreciating, and every session starts from zero.
Each of these failures sits upstream of the model, in how context is assembled and managed across the run. Context engineering exists to address them at that layer.
Your agents aren't the problem
The data feeding them is. Grade your context layer and get a roadmap for fixing it.The four operations of context engineering
Those failure modes lead to a practical question: what do you actually do about them? Most context-engineering approaches map to four operations:
- Write: store context externally instead of letting it pile up in the window, keeping scratchpads, tool outputs, and long-term memory outside the model and pulling them back only when needed.
- Select: retrieve only what the current step needs, which is where retrieval-augmented generation (RAG) fits in, and narrow which tools and memories an agent sees the same way.
- Compress: shrink what you can't exclude through summarization and trimming, knowing that a bad summary contaminates every step that follows.
- Isolate: keep unrelated work from bleeding together, which multi-agent architectures get for free by giving each sub-agent its own context window.
Infrastructure requirements for context assembly
Write, select, compress, and isolate all depend on the systems running underneath them. Context engineering puts retrieval directly in the inference path, which means the storage and query layer determines whether your context pipeline runs fast enough to be useful in production.
Multiple query modalities, one latency budget
An agent's context has multiple layers: working state, long-term memory, and structured metadata. Each one needs different storage and retrieval semantics. Short-term working memory benefits from low-latency key-value access by session or thread ID. Long-term semantic memory needs vector-indexed retrieval over vector embeddings. Metadata filtering needs inverted indexes for exact-match and range queries. Teams often run multiple storage and retrieval primitives in parallel rather than forcing all of this through a single general-purpose database.
Hybrid retrieval makes this even more demanding. Combining BM25 keyword ranking with semantic embedding search means the platform has to support multiple query modalities and merge or rerank the results within a shared retrieval latency budget.
Grade your context layer
Most teams are further behind on context infrastructure than they think. Score yours.Real-time data freshness
Fast retrieval doesn't help if the data behind it is stale. Context loaded through hourly or nightly batch refreshes is already out of date the moment it's consumed, and for agents working with live events or operational data that means reasoning about a world that has already moved on. Streaming ingestion fits better for apps where freshness directly affects whether the model's output is correct.
The context engineering maturity model
Those requirements come together as four pillars a production-ready context engine has to satisfy, each one the answer to a failure mode:
- Navigable: agents traverse business entities and their relationships instead of guessing across raw tables. Solves opacity.
- Fast: retrieval holds up under the many calls an agent makes per step. Solves speed degradation.
- Fresh: context reflects the current state of your systems, not last night's batch. Solves fragmentation.
- Compounding: memory makes each interaction more useful than the last. Solves non-accumulation.
How far you've built out those four pillars is your maturity level. It falls on a five-stage scale, from ad hoc to competitive asset:
- Stage 1, ad hoc: context is assembled by hand and pasted into prompts, and nothing persists between sessions.
- Stage 2, exploratory: a RAG pipeline and vector store exist but sit in silos, with batch refreshes and little durable memory.
- Stage 3, standardizing: teams converge on shared interfaces, often MCP servers, and a common retrieval layer.
- Stage 4, managed: all four pillars run as engineering targets, with SLOs for latency and freshness and memory running as a service.
- Stage 5, competitive asset: the context layer improves with use and becomes something competitors find hard to copy.
Score each pillar against those stages and grade yourself from D at stage 1 to A+ at stage 5. The rule that matters is that your overall level is your lowest-scoring pillar, not your average: agents fail through the weakest one, so an excellent vector index paired with nightly batch refreshes is still a stage 2, not a stage 4. That gap is where the next investment pays off. The full maturity model breaks each pillar into a stage-by-stage self-assessment you can score yourself against.
Where Redis fits in the context engineering stack
Redis goes far beyond caching. It acts as a real-time context engine that gathers, syncs, and serves the data your AI apps need to respond accurately and at speed. A production context architecture typically means stitching together a vector database, a cache, a messaging layer, and a task queue. Redis combines those primitives in one in-memory platform, so a single system covers the storage, retrieval, and messaging paths a context pipeline depends on. Redis packages this as Redis Iris, its real-time context engine, whose components map onto the four pillars: Context Retriever for navigable access, Redis Search and LangCache for fast retrieval, Data Integration for freshness, and Agent Memory for compounding memory. That mapping is what moving from stage 3 to stage 4 looks like in practice.
Agent memory: short-term & long-term in one system
Redis serves agent memory through a dual-tier architecture. Short-term memory uses in-memory data structures for sub-millisecond access to immediate conversational context: agent state, chat history, and running summaries. Long-term memory holds durable facts and user preferences extracted from past sessions, retrieved by conceptual similarity rather than exact keywords.
Vector search for retrieval
Vector retrieval runs directly in the inference path. Redis Search supports exact vector search with FLAT indexing and approximate search with Hierarchical Navigable Small World (HNSW), alongside full-text and numeric search. Vectors and their associated metadata can be stored inside hashes or JSON documents, so a single query can filter on structured fields and run similarity search at the same time.
Semantic caching with Redis LangCache
Paraphrased queries don't need a fresh LLM call. Redis LangCache provides this as a managed semantic cache, delivered via REST API. Apps get cache hits without building the embedding and similarity logic themselves. In benchmarks, Redis LangCache reported up to 15x faster responses for cache hits and up to 73% lower costs.
Is your context production-ready?
Score the retrieval, memory, and data layer behind your agents, and find the gaps before they reach production.Build your context engine on Redis
If prompt engineering is about phrasing, context engineering is about system design. Model quality matters, but what you feed the model matters just as much. Assembling that input reliably is an infrastructure problem spanning retrieval, memory, caching, real-time ingestion, and multi-agent coordination.
Teams that treat context as an engineering surface, with explicit ownership and purpose-built infrastructure underneath, tend to ship more reliable agents than teams optimizing prompts alone. Consolidating those pieces in one system reduces the number of moving parts in the critical path between a user request and a model response. Wherever you land on the maturity model, the fastest returns come from fixing your weakest pillar first.
Try it yourself with a free Redis account, or talk to the team about building your context engineering stack on Redis.
Get started with Redis today
Speak to a Redis expert and learn more about enterprise-grade Redis today.