Update Iris concepts, landing page, and tour for the GA services

content/develop/ai/context-engine/_index.md

@@ -4,18 +4,19 @@ categories:
 - docs
 - develop
 - ai
-description: Redis Iris is a suite of managed and self-managed services for agent memory, semantic caching, and governed data access.
+description: Redis Iris is a suite of managed and self-managed services that give your customers accurate, consistent experiences with your AI agents by providing memories, approved answers, governed access to business data, and turn-by-turn tracing.
 hideListLinks: true
 linktitle: Redis Iris context engine
 title: Redis Iris context engine
 weight: 30
 ---
 
-Give your AI agents the context layer they need to reliably act on business data.
+{{< iris-demo preview="true" >}}
 
-Redis Iris eliminates the infrastructure burden of building context-aware AI agents: persistent memory, semantic caching, governed data access, and live data sync, fully managed on Redis Cloud or self-managed on your own infrastructure.
+Redis Iris eliminates the infrastructure burden of building context-aware AI agents.
 
-<div class="grid grid-cols-1 md:grid-cols-4 gap-6 my-8">
+<!-- TODO: add Intent Router and Agent Mesh tiles and bullets when intent-router-docs-align and codex/agent-mesh-preview-docs merge into iris-ga-docs. -->
+<div class="grid grid-cols-1 md:grid-cols-3 gap-6 my-8">
   {{< tile-card icon="images/dev/icons/icon-redis-iris-64-duotone.png" title="Concepts" description="What happens when an agent asks Redis Iris for context" url="/develop/ai/context-engine/concepts" >}}
   {{< tile-card icon="images/dev/icons/icon-redis-agent-memory-64-duotone.png" title="Agent Memory" description="Persistent short-term and long-term memory across agent interactions" url="/develop/ai/context-engine/agent-memory" >}}
   {{< tile-card icon="images/dev/icons/icon-redis-iris-64-duotone.png" title="Context Gateway" description="One MCP endpoint for the tools of any MCP server and your Redis data" url="/develop/ai/context-engine/context-gateway" >}}
@@ -29,10 +30,11 @@ Redis Iris eliminates the infrastructure burden of building context-aware AI age
 
 Redis Iris is a production-ready context engine for AI agents that:
 
-- **Reduces LLM costs**: Semantic caching returns cached responses for similar queries in milliseconds
+- **Answers recurring questions without a model call**: Agent Playbooks returns the answers and procedures your business published, matched to the agent's task by semantic similarity
 - **Adds persistent memory**: Agents remember past interactions and user preferences across sessions
 - **Connects tools and business data**: Context Gateway gives agents one MCP endpoint for the tools of any MCP server and your Redis data
 - **Keeps data fresh**: Data Integration streams live changes from relational databases into Redis within seconds
+- **Shows why an agent answered the way it did**: Lens traces each turn, from what each source returned to what entered the prompt
 - **Deploys your way**: Check each service’s operator guide for its managed and self-managed deployment options.
 
 ## Why use Redis Iris?
@@ -42,7 +44,7 @@ Redis Iris is a production-ready context engine for AI agents that:
     <h3 class="text-redis-ink-900 font-semibold mb-3">For AI applications</h3>
     <ul class="space-y-1 text-redis-pen-600">
       <li>Agents that remember context across sessions and users</li>
-      <li>Faster responses and lower costs through semantic caching</li>
+      <li>Consistent answers to recurring questions, from content your business approved</li>
       <li>Reliable, structured access to live business data</li>
       <li>No stale data: near real-time sync from your source databases</li>
     </ul>
@@ -53,6 +55,7 @@ Redis Iris is a production-ready context engine for AI agents that:
       <li>Managed and self-managed deployment options documented for each service</li>
       <li>Python and JavaScript SDKs and REST APIs for all services</li>
       <li>Define your data model once, reuse it across all agents</li>
+      <li>Trace each agent turn to see which context reached the prompt</li>
       <li>No database setup required on Redis Cloud</li>
     </ul>
   </div>

content/develop/ai/context-engine/concepts/_index.md

@@ -4,86 +4,108 @@ categories:
 - docs
 - develop
 - ai
-description: What happens when an agent asks Redis Iris for context, and why that's faster than assembling it yourself.
+description: What happens when an agent asks Redis Iris for context, and how it improves customer experiences.
 hideListLinks: true
 linktitle: Concepts
 title: How Redis Iris works
 weight: 5
 ---
 
-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.
+![The Redis Iris stack beside what an agent needs. Every message goes to Intent Router first. Approved answers come from Agent Playbooks, earlier conversations from Agent Memory, and business data and other tools through Context Gateway. Lens and Agent Mesh work alongside every request.](/images/ai/context-engine/iris-mental-model.svg)
+{width="800"}
 
-Use 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.
-
-![An agent connects to Redis Iris, which stores memories, caches answers, and retrieves context, all backed by Redis or a connected database.](/images/ai/context-engine/iris-mental-model.svg)
-{width="650"}
+Your agent asks Redis Iris for context. Iris returns it through the fastest path that answers the request: an answer your business already approved, 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 builds and maintains that infrastructure for you.
 
 ## The mental model
 
 | Without a context layer | With Redis Iris |
 |:---|:---|
+| Ask a model which agent or tool should handle each message | Match the message to an intent you defined, and dispatch to its target |
 | Replay the full conversation history every turn | Recall only what's relevant, summarized or extracted once |
-| Call the model even when you already know the answer | Return a cached answer when a similar request already ran |
+| Have the model generate an answer your business already wrote | Return a published answer or procedure from a playbook |
 | 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 |
 | Build separate integration code for every data source | Reach Redis or any connected database through the same interface |
+| Guess why an agent gave a wrong answer | Trace each turn to see what context was fetched and what entered the prompt |
+| Start a long agent response over when the client disconnects | Resume the response's event stream from the client's last cursor |
 
 ## What happens on a request
 
-Iris does up to three things before your agent's request reaches the model, in whatever combination the request needs:
+Iris does up to four things around your agent's model call, in whatever combination the request needs:
 
-1. **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.
-2. **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.
-3. **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.
+1. **Route.** Iris matches the message to an intent you defined and returns its target, such as the agent, tool, or workflow that handles it. No model call decides the route.
+2. **Recall.** Iris checks your playbooks for an answer or procedure your business already published, and recalls relevant memory from earlier in the conversation or a past session. A published frequently asked question (FAQ) can answer the request without a model call.
+3. **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.
+4. **Record.** After the model responds, your application records the turn in Agent Memory. Iris extracts what's worth remembering, so the next request, in this conversation or a future one, can recall it.
 
-Not 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.
+Not every request needs all four. A recurring question that a published FAQ answers skips straight to a response. A question about live inventory or account data goes straight to retrieval.
 
 ## Two phases: serving and recording
 
 Most requests touch Redis Iris at two points:
 
-1. **Before the model call**, check whether Iris already has what's needed: a cached answer, relevant memory, or business data a tool can fetch.
-2. **After the model responds**, let Iris record what's worth keeping. The next request doesn't start from nothing.
+1. **Before the model call**, route the message and check whether Iris already has what's needed: a published answer, relevant memory, or business data a tool can fetch.
+2. **After the model responds**, record the turn so Iris can keep what's worth keeping. The next request doesn't start from nothing.
 
 ### 1. Serving the request (reading)
 
 Iris draws on whichever of its capabilities the request needs, before the model call:
 
-- **Cache check.** Iris compares the incoming prompt against previously cached responses. A close-enough match returns immediately, skipping the model call.
-- **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.
-- **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.
+- **Intent routing.** Intent Router compares the message with your intents' example phrasings and returns the closest intents, each with a score and a target. Your application decides whether and how to dispatch to the target.
+- **Playbook discovery.** [Agent Playbooks]({{< relref "/develop/ai/context-engine/agent-playbook" >}}) matches the agent's task against published entries by semantic similarity. A FAQ returns its full answer. A skill returns a preview, and the agent loads the full instructions only if it needs them.
+- **Memory recall.** [Agent Memory]({{< relref "/develop/ai/context-engine/agent-memory" >}}) 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.
+- **Governed retrieval.** [Context Gateway]({{< relref "/develop/ai/context-engine/context-gateway" >}}) calls a tool from a Model Context Protocol (MCP) server or from a Context Surface generated from your data model, instead of running a raw query. For tools you opt in, the Gateway's result cache returns the stored result of an identical call until its time to live (TTL) expires.
+
+<!-- TODO: link Intent Router to /develop/ai/context-engine/intent-router when intent-router-docs-align merges into iris-ga-docs. -->
 
 ### 2. Recording the interaction (writing)
 
-Iris writes back what's worth keeping after the model responds. Your application doesn't do this explicitly:
+After the model responds, your application writes the turn to Agent Memory. Iris handles the rest:
 
-- **Session write.** Iris stores the conversation's events as they happen. The next turn has recent history available.
+- **Session write.** Your application stores the conversation's events as they happen. The next turn has recent history available.
 - **Background extraction.** Iris pulls durable facts and preferences out of the conversation and stores them separately, with embeddings for later semantic search.
-- **Cache write.** Iris stores the new prompt-and-response pair as a candidate to serve the next similar request without a model call.
+- **Playbook proposals.** If you connect a memory store to a playbook, Iris suggests new FAQs from resolved conversations. A reviewer accepts and publishes each one before agents can retrieve it.
+
+Extraction and proposals run in the background. They don't slow down the response your application is waiting for.
 
-This write path runs asynchronously. It doesn't slow down the response your application is waiting for.
+## Alongside the request
+
+Two Iris services work alongside the request rather than supplying its context:
+
+- **[Lens]({{< relref "/develop/ai/context-engine/lens" >}})** traces each turn. It records what each source returned, what entered the prompt, and how long each step took. Agent Memory, Agent Playbooks, and Context Gateway calls appear in the trace with no extra code.
+- **Agent Mesh** keeps a long agent response deliverable when the client disconnects. It retains the response's events in Redis, so the client reconnects with its last cursor and receives the updates it missed.
+<!-- TODO: link Agent Mesh to /develop/ai/context-engine/agent-mesh when codex/agent-mesh-preview-docs merges into iris-ga-docs. -->
 
 ## Where context lives
 
 Redis Iris splits that context across stores, each built for a different lookup pattern:
 
 | Store | Holds | Purpose |
 |:---|:---|:---|
-| Cache index | Prompt embeddings and their cached responses | Sub-second similarity lookups before a model call |
+| Routers | Intents, their example phrasings with embeddings, and their targets | Routing each message to the agent, tool, or workflow that handles it |
+| Playbooks | Published FAQs and skills, with embeddings | Semantic discovery of answers and procedures your business approved |
 | Memory store | Session events and extracted long-term facts, with embeddings | Recall across turns and sessions |
+| Gateway database | Cached tool results and result handles | Reuse of identical tool calls, and large results the agent reads in parts |
 | Your business data | Whatever you already store in Redis or a connected database | Queried through governed tools, not a raw connection |
 
-Run 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.
+Your data stays in your Redis databases. Each Iris service stores its data in Redis databases you own. On Redis Cloud, that's a database in your account. Self-managed, it's your own Redis deployment. Session events, extracted memories, playbook entries, cached tool results, and the embeddings Iris creates for search all use the database's memory like any other data, so you size and pay for that database as usual.
+
+Start small and stay in control of growth. On Redis Cloud, Agent Memory's Quick create uses your free 30 MB database, which is enough to try the quickstarts. As you grow, you configure what to keep and for how long, not how the underlying store works.
 
 ## Build against this flow
 
-- Let Iris decide what's cached and what's fresh. Don't build a separate caching layer on top of the model call.
+- Route with intents you define, not a model call that picks the next agent or tool. Use Intent Router to decide where a message goes, and Agent Playbooks to supply what the answer says.
+- Publish answers your business has approved as playbook FAQs, and repeatable procedures as skills. Don't build a separate caching layer on top of the model call.
+- Cache tool results sparingly. Opt in only the tools whose results stay valid for the TTL you set.
 - Write session events as they happen. Let background extraction decide what's durable, rather than deciding yourself on every turn.
 - Model your business data as entities and relationships once. Let a Context Gateway Context Surface generate the tools your agent calls, instead of writing a tool per query.
 - Scope every write and lookup by user, session, or namespace. This keeps agents and users from colliding.
+- Trace turns with Lens while you build, so you can see which context reached the prompt.
 
 ## Next steps
 
 - [How a request flows through Redis Iris]({{< relref "/develop/ai/context-engine/concepts/request-flow" >}})
+- [Agent Playbooks concepts]({{< relref "/develop/ai/context-engine/agent-playbook/concepts" >}})
 - [Agent Memory overview]({{< relref "/develop/ai/context-engine/agent-memory/overview" >}})
 - [Context Gateway concepts]({{< relref "/develop/ai/context-engine/context-gateway/concepts" >}})
+- [Lens concepts]({{< relref "/develop/ai/context-engine/lens/concepts" >}})
 - An [interactive demo]({{< relref "/develop/ai/context-engine/agent-memory/interactive-demo" >}}) of Agent Memory that runs in your browser

content/develop/ai/context-engine/concepts/interactive-demo.md

@@ -13,11 +13,11 @@ aliases:
 - /develop/ai/context-engine/interactive-demo/
 ---
 
-Redis Iris gives an AI agent governed access to live business data, memory, and cached answers. This tour follows one customer request through all four services, one step at a time. It starts where business data enters Iris, with Data Integration, and then follows the request through the other three services, in the order described in [How Redis Iris works](/content/develop/ai/context-engine/concepts/_index.md). The last step takes one service away to show what the agent loses without it.
+{{< iris-demo >}}
 
-The tour runs in your browser and doesn't connect to any service. Each step links to that service's own interactive demo, which covers it in depth with the same customer and data. The agent's reasoning, the reply, and the timings are illustrative.
+Redis Iris gives an AI agent routing, governed access to live business data, memory, and approved answers. This tour follows one customer request through four services, one step at a time, in the order described in [How Redis Iris works](/content/develop/ai/context-engine/concepts/_index.md). Lens then shows how the request ran. The last step takes one service away to show what the agent loses without it.
 
-{{< iris-demo >}}
+The tour runs in your browser and doesn't connect to any service. Each step links to that service's docs or its own interactive demo, which covers it in depth. The agent's reasoning, the reply, and the timings are illustrative.
 
 ## What each service adds
 
@@ -26,7 +26,9 @@ The tour runs in your browser and doesn't connect to any service. Each step link
 | [Data Integration](/content/develop/ai/context-engine/data-integration/_index.md) | Syncs a change from PostgreSQL to Redis seconds after it happens | The agent reads last night's data and makes a promise it can't keep |
 | Context Gateway | Looks up delivery times, alternatives, and past orders through governed tools | The agent can't check whether the food will arrive in time |
 | [Agent Memory](/content/develop/ai/context-engine/agent-memory/_index.md) | Recalls last week's order and the customer's peanut allergy | The agent can find the order, but not the allergy |
-| [LangCache](/content/develop/ai/context-engine/langcache/_index.md) | Answers the general delivery fee question from the cache | The model answers it, which takes longer and costs output tokens |
+| [Agent Playbooks](/content/develop/ai/context-engine/agent-playbook/_index.md) | Answers the general delivery fee question with the frequently asked question (FAQ) the support team published | The model doesn't know the app's fees, so it gives a vague answer, or makes one up |
+
+[Lens](/content/develop/ai/context-engine/lens/_index.md) is in preview. It doesn't change the reply. It records each step of the request, including which memories entered the prompt, so you can see how the agent got there.
 
 ## Next steps