{
  "schema_version": 2,
  "id": "develop/ai/context-engine/concepts",
  "title": "How Redis Iris works",
  "url": "https://redis.io/docs/latest/develop/ai/context-engine/concepts/",
  "summary": "What happens when an agent asks Redis Iris for context, and why that's faster than assembling it yourself.",
  "tags": [
    "docs",
    "develop",
    "ai"
  ],
  "last_updated": "2026-09-24T14:12:46-07:00",
  "children": [
    {
      "id": "develop/ai/context-engine/concepts/request-flow",
      "summary": "Trace how a single agent request draws on Redis Iris's caching, memory, and retrieval capabilities before a model call.",
      "title": "How a request flows through Redis Iris",
      "url": "https://redis.io/docs/latest/develop/ai/context-engine/concepts/request-flow/"
    }
  ],
  "page_type": "content",
  "content_hash": "66c992b9813e432576605d9c50f58242793067842c1efd674f12099556f2a273",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Redis Iris sits between your agent and your data. It's one system. Your agent asks for context. Iris returns it through the fastest available path: a cached answer, a remembered fact, or a live lookup against your business data. That data can live in Redis or in another database you connect. You don't wire together separate lookups yourself. Iris decides which path answers the request.\n\nUse Redis Iris when you want agents to respond with cached answers instead of repeat model calls, recall what they've learned across turns and sessions, and act on live business data. Iris builds and maintains that infrastructure for you.\n\n[code example]"
    },
    {
      "id": "the-mental-model",
      "title": "The mental model",
      "role": "content",
      "text": "| Without a context layer | With Redis Iris |\n|:---|:---|\n| Replay the full conversation history every turn | Recall only what's relevant, summarized or extracted once |\n| Call the model even when you already know the answer | Return a cached answer when a similar request already ran |\n| Give the agent a live database connection or let it generate its own queries | Give it a fixed set of governed tools that fetch exactly what's needed |\n| Build separate integration code for every data source | Reach Redis or any connected database through the same interface |"
    },
    {
      "id": "what-happens-on-a-request",
      "title": "What happens on a request",
      "role": "content",
      "text": "Iris does up to three things before your agent's request reaches the model, in whatever combination the request needs:\n\n1. **Recall.** Iris checks whether it already has a cached answer for a similar request, or relevant memory from earlier in the conversation or a past session. If so, it returns that instead of spending a model call.\n2. **Retrieve.** If the request depends on current business data, Iris fetches exactly what's needed through a governed tool call, not a raw database query the agent constructs itself.\n3. **Record.** After the model responds, Iris writes back what's worth remembering. The next request, in this conversation or a future one, can recall it.\n\nNot every request needs all three. A question the cache already answered skips straight to a response. A question about live inventory or account data skips the cache and goes straight to retrieval."
    },
    {
      "id": "two-phases-serving-and-recording",
      "title": "Two phases: serving and recording",
      "role": "content",
      "text": "Most requests touch Redis Iris at two points:\n\n1. **Before the model call**, check whether Iris already has what's needed: a cached answer, relevant memory, or business data a tool can fetch.\n2. **After the model responds**, let Iris record what's worth keeping. The next request doesn't start from nothing."
    },
    {
      "id": "1-serving-the-request-reading",
      "title": "1. Serving the request (reading)",
      "role": "content",
      "text": "Iris draws on whichever of its capabilities the request needs, before the model call:\n\n- **Cache check.** Iris compares the incoming prompt against previously cached responses. A close-enough match returns immediately, skipping the model call.\n- **Memory recall.** Iris searches session and long-term memory for what's relevant to this conversation or user. You don't need to replay the full transcript to the model.\n- **Governed retrieval.** If the request depends on current business data, Iris calls a fixed tool generated from your data model instead of running a raw query."
    },
    {
      "id": "2-recording-the-interaction-writing",
      "title": "2. Recording the interaction (writing)",
      "role": "content",
      "text": "Iris writes back what's worth keeping after the model responds. Your application doesn't do this explicitly:\n\n- **Session write.** Iris stores the conversation's events as they happen. The next turn has recent history available.\n- **Background extraction.** Iris pulls durable facts and preferences out of the conversation and stores them separately, with embeddings for later semantic search.\n- **Cache write.** Iris stores the new prompt-and-response pair as a candidate to serve the next similar request without a model call.\n\nThis write path runs asynchronously. It doesn't slow down the response your application is waiting for."
    },
    {
      "id": "where-context-lives",
      "title": "Where context lives",
      "role": "content",
      "text": "Redis Iris splits that context across stores, each built for a different lookup pattern:\n\n| Store | Holds | Purpose |\n|:---|:---|:---|\n| Cache index | Prompt embeddings and their cached responses | Sub-second similarity lookups before a model call |\n| Memory store | Session events and extracted long-term facts, with embeddings | Recall across turns and sessions |\n| Your business data | Whatever you already store in Redis or a connected database | Queried through governed tools, not a raw connection |\n\nRun all three fully managed on Redis Cloud, or self-managed on your own infrastructure. Either way, you configure what to keep and for how long, not how the underlying store works."
    },
    {
      "id": "build-against-this-flow",
      "title": "Build against this flow",
      "role": "content",
      "text": "- Let Iris decide what's cached and what's fresh. Don't build a separate caching layer on top of the model call.\n- Write session events as they happen. Let background extraction decide what's durable, rather than deciding yourself on every turn.\n- Model your business data as entities and relationships once. Let Context Retriever generate the tools your agent calls, instead of writing a tool per query.\n- Scope every write and lookup by user, session, or namespace. This keeps agents and users from colliding."
    },
    {
      "id": "next-steps",
      "title": "Next steps",
      "role": "content",
      "text": "- [How a request flows through Redis Iris](https://redis.io/docs/latest/develop/ai/context-engine/concepts/request-flow)\n- [LangCache concepts](https://redis.io/docs/latest/develop/ai/context-engine/langcache/concepts)\n- [Agent Memory overview](https://redis.io/docs/latest/develop/ai/context-engine/agent-memory/overview)\n- [Context Retriever concepts](https://redis.io/docs/latest/develop/ai/context-engine/context-retriever/concepts)"
    }
  ],
  "examples": [
    {
      "id": "overview-ex0",
      "language": "mermaid {width=\"90%\"}",
      "code": "graph TD\n    subgraph iris[\"Redis Iris\"]\n        A[\"Store memories\"]\n        B[\"Cache answers\"]\n        C[\"Retrieve context\"]\n    end\n    Agent[\"Agent\"] <--> iris\n    A --> D[(\"Reach Redis or any connected database\")]\n    B --> D\n    C --> D\n    style D width:320px\n    style iris fill:#ffffff",
      "section_id": "overview"
    }
  ]
}