Redis Iris: The Real-Time Context Engine for AI Agents — The Complete Guide for Agentic AI Architects (2026)

Your AI agent just told a customer their refund was approved — 45 days after purchase, when company policy caps refunds at 30 days. The model reasoned flawlessly. The problem was that no one gave it the policy document, the customer’s purchase date, or the memory of what it promised last time. According to Redis’s own engineering blog, this is not a reasoning failure — it is a context failure. And context failures are the single largest category of production agent breakdowns in 2026.

On November 4, 2026, Redis expanded its Redis Iris platform from a preview-stage memory layer into a full-spectrum real-time context engine with six composable capabilities spanning routing, playbooks, memory, retrieval, observability, and agent-to-agent messaging. Four capabilities are now generally available; two are in public beta. For agentic AI architects who have been stitching together vector databases, caching layers, MCP servers, and observability tools from five different vendors, Iris is Redis’s argument that all of it belongs in one runtime — the same runtime that already sits in the hot path of most enterprise applications.

This guide breaks down every component of Redis Iris, shows how they fit together architecturally, walks through the SDK and API surface, compares the platform to the alternatives, and gives you a clear framework for deciding whether Iris belongs in your agent stack.

Table of Contents

• Why Context Is the Bottleneck, Not Reasoning
• What Is Redis Iris?
• The Six Capabilities: Architecture Deep Dive
• 1. Redis Intent Router (GA)
• 2. Redis Agent Playbooks (GA)
• 3. Redis Agent Memory (GA)
• 4. Redis Context Gateway (GA)
• 5. Redis Lens (Beta)
• 6. Redis Agent Mesh (Beta)
• How the Six Capabilities Work Together
• SDK, CLI, and API Quick-Start
• MemoryETL: Turning Documents into Agent Memory
• Redis Iris vs. the Alternatives
• Production Considerations for Agentic AI Architects
• What Redis Iris Means for RPA Teams
• Getting Started
• FAQ
• Key Takeaways
• References

Why Context Is the Bottleneck, Not Reasoning

The models are smart enough. GPT-6, Claude Opus, Gemini Ultra — any of them can reason through a multi-step customer service workflow when given the right information. The problem, as VentureBeat’s analysis of the enterprise retrieval market puts it, is that “the RAG era is giving way to context architecture.” Classic RAG pre-loads data into the prompt before calling the model. Production agents need to pull what they need at runtime — treating data as a live resource rather than a pre-loaded payload.

Redis CEO Rowan Trollope frames it with a mobile-era analogy: when smartphones arrived, legacy backends built for branch tellers suddenly had to serve a million simultaneous users. Redis became the caching layer that absorbed the load. The same structural pressure is hitting enterprise AI. As Trollope told VentureBeat: “Companies will have orders of magnitude more agents than human beings,” which means “orders of magnitude more load on back-end systems.”

The Redis engineering blog identifies four failure modes of agent context that Iris is designed to solve:

According to VentureBeat’s VB Pulse Q1 2026 RAG Infrastructure Market Tracker, buyer intent to adopt hybrid retrieval rose from 10.3% to 33.3% between January and March 2026. Retrieval optimization surpassed evaluation as the top enterprise investment priority for the first time. The market is converging: agents need live context, memory, and fast retrieval while they are actually working.

What Is Redis Iris?

Redis Iris is a real-time context engine for AI agents. It sits between an agent and the data, tools, and other agents it needs to act — providing memory, routing, retrieval, observability, and messaging in a single composable platform built on the Redis runtime.

First launched in May 2026 as a preview, Iris expanded on November 4, 2026 with six capabilities that can be used together or independently:

The platform is built around four design principles: context should be navigable (connected systems agents explore, not silos), adaptive (selective memory that keeps what matters and drops what is stale), efficient (retrieve only what is relevant, reuse what has been resolved), and compounding (context gets more relevant as agents learn from past interactions).

Deployment is available on Redis Cloud (fully managed), Redis Software (on-premises), and through cloud marketplace integrations with AWS, Azure Managed Redis, and Google Cloud. Redis also announced a native Snowflake marketplace launch with connectors.

The Six Capabilities: Architecture Deep Dive

1. Redis Intent Router (GA)

The Intent Router sits at the front door of every agent interaction. Instead of matching keywords, it matches the meaning of a request and routes it to the right destination: a remembered FAQ answer, a specific agent skill, a human handoff, or a fresh LLM call.

Key capabilities:

• Semantic routing: Classifies by meaning, not keyword matching. “I want to cancel my flight” and “please undo my booking” reach the same handler.
• Model and agent routing: Route different request types to different models or specialized sub-agents based on complexity, cost, or domain.
• Guardrails: Block or redirect requests that violate business rules before they reach the LLM.
• Fuzzy if-statements: Decisions are not limited to true/false — the router handles probabilistic, meaning-based branching that traditional rule engines cannot express.

For agentic AI architects, the Intent Router solves a common production headache: every user message hitting a full LLM call, even when 40% of questions are variations of the same five FAQs. By routing known intents to cached answers or lightweight procedures, it cuts both latency and token spend.

2. Redis Agent Playbooks (GA)

Agent Playbooks capture which answers are stable and reusable and which require a fresh data pull and a known procedure. Think of it as institutional memory for your agents — when a customer asks about return policies, the answer is the same every time. When they ask about their specific order status, the answer requires a fresh lookup but follows a defined sequence.

How Playbooks work:

• Teams define stable answers (FAQs, policies, standard procedures) that can be served without an LLM call.
• Teams define repeatable procedures — sequences of tool calls and data lookups — that need current data but follow a known pattern.
• Playbooks include a learning loop: they become more thorough and accurate with each run, reducing resolution times and token costs over time.
• When a new prompt matches the meaning of a resolved playbook, the system reuses the stored response rather than re-running the full reasoning chain.

The combination of Intent Router + Playbooks is where Iris directly attacks the “solving $5 problems for $500” failure mode. If your customer service agent handles 10,000 conversations a day and 60% are variations of the same 50 questions, routing those through Playbooks instead of full LLM calls can reduce your inference costs by an order of magnitude.

3. Redis Agent Memory (GA)

Agent Memory is the core of Iris — and the most technically deep component. It provides managed memory that stores state and context across sessions, channels, and agents.

Two-tier architecture:

Session Memory (Working Memory) stores the ordered list of events for a single conversation. Each event includes an actorId (who sent it), role (USER, ASSISTANT), content, timestamps, and optional metadata. Sessions are keyed by sessionId and have configurable TTLs.

Session summarization is built in. You configure a threshold (e.g., “summarize after 20 messages, keep the most recent 10 verbatim”), and Redis automatically distills older messages into a summary while preserving the latest exchanges in full. This keeps context windows manageable without losing important history.

Long-Term Memory stores durable, searchable records with vector embeddings, scoped by ownerId, memoryType, namespace, session, and topics. Two built-in memory types map to the cognitive science analogy:

• Semantic memories — cross-session generalized facts (“this user is vegetarian and prefers spicy food”)
• Episodic memories — snapshots from specific sessions (“in the October 15 call, they asked about upgrading to the Pro plan”)

You can also define custom memory types through the Redis Cloud console — for example, a trip_preference type with structured fields for destinations, travel periods, and dietary requirements. Each custom type includes an extraction prompt, an enabled flag, and typed fields (str, int, float, bool, list[str], list[float], object).

Automatic extraction: Long-term memories can be created automatically from session events — Redis runs asynchronous background extraction that reads accumulated session events, compares candidates against existing memories, and uses the model to decide whether each one is new information or a duplicate. This deduplication runs at extraction time, not on write.

Sensitive data handling: A configurable “semantic exclusions” prompt tells extraction what categories to drop — passwords, access tokens, payment card numbers, booking confirmation codes. The docs are transparent that this is advisory, not guaranteed: session content still reaches the extraction model provider, and exclusions do not apply to memories created directly through the API.

Search: Long-term memory supports both semantic search (similarity-ranked by vector embeddings) and filter-only queries with operators for exact match, list membership, and boolean logic. Results are paginated (1–100 per page, default 50) and support optimistic concurrency control via revision tokens.

Hierarchical namespaces provide fine-grained scoping — namespaces have stable IDs, so renaming does not break references.

4. Redis Context Gateway (GA)

The Context Gateway is a single, governed entry point to all connected context sources. It solves a problem every enterprise agent team hits: the agent needs data from six different systems, each with its own API, auth model, and rate limits.

Key features:

• MCP-native: Teams bring their own MCP servers. The Gateway presents a single MCP endpoint to agents while federating requests to multiple backends.
• Schema-first data access: Define semantic models (using pydantic models in the Python SDK) and Redis auto-generates MCP tools, with row-level access controls enforced server-side.
• Tool caching: The Gateway caches which tools solve a given problem, reducing token spend on tool selection. When an agent has access to 50 MCP tools, the Gateway narrows the set to the 3–5 relevant ones before the model sees the tool list.
• Reusable results: Stable query results are cached for consistency across sessions — the same customer record query returns the same result within the TTL window, regardless of which agent or session requests it.
• Identity and authorization: Centralized governance over what each agent (and each user) can access.

Redis Data Integration (RDI), which is generally available, provides the CDC pipelines that sync relational databases, warehouses, and document stores into Redis. Connectors for Oracle, Snowflake, Databricks, and Postgres feed the Context Gateway with near-real-time data replicas.

5. Redis Lens (Beta)

Lens is Iris’s observability layer — purpose-built for tracing agent decisions back to their context sources. For every agent “turn” (one exchange, such as answering one message), Lens records:

• What each context source returned (memory recall, retrieval, tool calls)
• What actually entered the prompt
• Which model was called, with prompts, completions, and token counts
• How long each step took
• How the turn ended (outcome tracking)

Why this matters for production: Lens solves the “right data was fetched but dropped from the prompt” problem. Its context manifest for each turn shows, per retrieval step, a source, a state (ENTERED_PROMPT, FETCHED_NOT_USED, INVOKED_EMPTY, NOT_INSTRUMENTED), fetch counts, used counts, and individual candidates with relevance scores.

Integration model: Lens is built on OpenTelemetry and auto-instruments model calls through OpenAI, Anthropic, Amazon Bedrock, and LangChain clients. Redis Iris services (Agent Memory, Playbooks, Context Gateway) trace themselves into the turn with no extra code. Content capture is configurable: full prompts and retrieved text for debugging, or only IDs, hashes, and counts for production.

Read API: The Lens read API is REST-based with endpoints for listing agents, querying sessions (filtered by agent, time range, user, outcome), retrieving turn details with context manifests, and fetching captured content by hash. Session queries support pagination with 5-minute cursor TTLs.

For regulated industries — financial services, healthcare, government — Lens provides the audit trail that compliance teams require: every agent decision traceable to the specific skill, route, FAQ, memory, or source session that drove it.

6. Redis Agent Mesh (Beta)

Agent Mesh handles the communication layer for multi-agent systems. The core problem: when Agent A delegates a subtask to Agent B over SSE, and the network drops for 3 seconds, the response stream is lost and the work has to restart. Agent Mesh makes those streams durable.

Two integration paths (both Python, shipped in the redis-iris package):

A2A (Agent-to-Agent) Server: Built on the official A2A Python SDK 1.2.x. Provides a RedisTaskStore that commits task snapshots, versions, and events atomically. Features include:

• Resumable streams: When a client reconnects, it receives all retained updates after its last cursor position. If history has been trimmed, it gets the current snapshot first.
• Heartbeat and liveness: Default 5-second heartbeat interval with a 15-second alive TTL. If a producer’s lease expires, the task is marked failed with producer_lost.
• Takeover: With takeover=True, another process can claim and resume a task. Saves from the old process are rejected with ConcurrentTaskModificationError.
• Configurable retention: Active tasks default to 7 days, terminal tasks to 1 day, with a 10,000-event approximate log length and 1MB per-event size cap.

FastAPI SSE Integration: For teams using FastAPI, the redis_iris.agent_mesh.fastapi_sse module provides durable event streaming with automatic buffering. Redis itself is the buffer — events go into a per-run log that is retained until the run expires. Agent recipes are included for OpenAI Agents SDK, PydanticAI, Google ADK, and LangGraph.

Requirements: Python 3.11+, Redis 8.6.2+ with native producer idempotency (XADD IDMP). The beta is qualified for standalone Redis and normal A2A operation on three-primary Redis Open Source Clusters; Redis Cloud and Enterprise qualification is pending.

How the Six Capabilities Work Together

The power of Iris is not in any single component — it is in the composition. Here is how a production agent interaction flows through the full stack:

1. User sends a message → Intent Router classifies the meaning and routes it: FAQ → Playbooks; known procedure → Playbooks with a fresh data pull; complex/new → full agent pipeline.
2. Agent needs context → Context Gateway provides a single MCP endpoint. The gateway narrows the tool set, enforces access controls, and caches stable results.
3. Agent needs history → Agent Memory provides the session transcript (working memory) and relevant long-term memories (preferences, past decisions, episodic snapshots).
4. Agent delegates a subtask → Agent Mesh handles the A2A communication with durable streams that survive network interruptions.
5. Every step is traced → Lens records what was fetched, what entered the prompt, which model was called, and the outcome — all queryable for debugging and audit.
6. New knowledge is extracted → Agent Memory asynchronously extracts durable facts from the session, deduplicates against existing memories, and stores them for future sessions.

Trollope’s pitch to architects: “Developers shouldn’t need five infrastructure products to make agents work.” Whether you agree or not, the architectural argument is compelling — every hop between a Redis component is an in-process call, not a network round-trip to a separate service.

SDK, CLI, and API Quick-Start

The primary interface is the redis-iris Python SDK, which includes a CLI:

pip install 'redis-iris>=1.0.0'

For Agent Mesh, install extras:

# A2A support
pip install 'redis-iris[a2a]'

# FastAPI SSE support
pip install 'redis-iris[fastapi-sse]'

# Both
pip install 'redis-iris[a2a,fastapi-sse]'

# Lens tracing
pip install 'redis-iris[llm-tracing]>=1.0.0'

Environment variables:

IRIS_AGENT_MEMORY_URL=<your-endpoint>
IRIS_AGENT_MEMORY_STORE_ID=<your-store-id>
IRIS_AGENT_MEMORY_API_KEY=<your-api-key>

Record a conversation and recall memories (Python):

from redis_iris.agent_memory import AgentMemory

memory = AgentMemory.from_env()

# Record a conversation turn
conversation = memory.conversation(
    owner="user-1042",
    session_id="session-abc"
)
conversation.user(
    "I am visiting Tokyo and Kyoto next month. "
    "I am vegetarian and prefer spicy food."
)

# Later: recall relevant memories
known = memory.recall(
    "What dietary requirements does the user have?",
    owner="user-1042",
    limit=5
)
print(known.as_prompt())  # Ready to inject into your agent's context

Lens tracing (Python):

from redis_iris import lens

lens.init()

with lens.turn(session_id="session-abc", user_id="user-1042") as turn:
    response = client.responses.create(...)
    turn.set_outcome("completed")

turn_id = turn.trace_id  # Use to query the turn in the Lens read API

REST API base path:

{IRIS_AGENT_MEMORY_URL}/iris/data/v1/agent-memory/stores/{storeId}

The REST API supports full CRUD on sessions and long-term memories, semantic and filter-only search, bulk operations, optimistic concurrency with revision tokens, and idempotency keys (replayed for up to 24 hours).

CLI examples:

# Search long-term memories
iris agent-memory memories search "dietary preferences" --owner user-1042 --limit 5

# Show a session transcript
iris agent-memory sessions show session-abc

# List sessions for a user
iris agent-memory sessions list --owner user-1042

MemoryETL: Turning Documents into Agent Memory

One of Iris’s most distinctive features is MemoryETL — an ETL pipeline that transforms text and Markdown documents into structured long-term memories. This is not just document indexing; it is memory extraction.

How it works:

1. Operator creates an extractor — defines a custom memory type and extraction instructions (what to look for in the document).
2. App submits a document — base64-encoded text/plain or text/markdown, with an ownerId, documentId, revision, and extractorId.
3. Two-stage processing:
   • Extraction: Each document chunk is processed into candidate memories (staged, not yet searchable).
   • Reconciliation: Candidates are merged across chunks, duplicates are resolved, and the final set is published. Nothing is searchable until reconciliation finishes.
4. Provenance tracking: Every extracted memory links back to its source document, ingestion, chunk, and optional text span (UTF-8 byte offsets).

Processing states: QUEUED → RUNNING → SUCCEEDED (check createdCount and filteredCount), PARTIAL (some published, some not), or FAILED (do not assume rollback).

Limits: 8,000 input tokens per extraction request; 32,000 tokens per reconciliation request. Document-managed records (documentManaged: true) cannot be edited through normal PUT/PATCH — content changes must go through the ingestion workflow.

The practical use case: a travel agency pre-processes trip itineraries, hotel confirmations, and customer preference surveys through MemoryETL. When the customer calls, the agent already knows their destination, dietary requirements, preferred hotel chains, and loyalty program numbers — extracted from documents, not manually entered.

Redis Iris vs. the Alternatives

Agentic AI architects evaluating Iris will naturally compare it to the tools they already use. Here is an honest assessment:

When Iris has the advantage: If your agents already use Redis for caching, session management, or search, Iris is a natural extension — no new infrastructure to provision or monitor. The integrated observability (Lens traces across all Iris services automatically) is a genuine differentiator for debugging production issues. And the MCP-native Context Gateway eliminates the “glue code” problem that plagues multi-vendor agent stacks.

When standalone tools may be better: If you need a best-of-breed vector database with advanced indexing (HNSW tuning, multi-tenancy at the index level, hybrid keyword+vector search with deep customization), a dedicated solution like Pinecone, Weaviate, or Qdrant gives you more control. Similarly, if your observability needs extend well beyond agent tracing — into full APM, log aggregation, and infrastructure monitoring — tools like Langfuse and LangSmith have deeper ecosystems and more mature dashboards. Lens is beta; the standalone tools are battle-tested.

Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, frames the evaluation well: the first question should be “What does the agent need to know, how fresh must it be, who may access it, and what does each retrieval cost?”

Production Considerations for Agentic AI Architects

Cost model: Redis offers Iris with 5,000 free messages to get started. Beyond that, pricing is available at redis.io/pricing/#iris. The cost argument is that reducing redundant LLM calls through Playbooks and Intent Router pays for the Iris layer. Teams running high-volume customer service agents should model this explicitly: if Playbooks handle 60% of inbound volume without an LLM call, the savings in inference costs often exceed the Iris subscription.

Latency: Redis’s in-memory architecture means context lookups add microseconds to milliseconds, not the 100-500ms typical of a separate vector database round-trip. For voice agents and real-time customer interactions, this difference is audible.

Data residency and compliance: Available on Redis Cloud (managed) and Redis Software (on-premises). The on-premises option matters for healthcare, financial services, and government deployments where data cannot leave the organization’s infrastructure.

Beta caveats: Lens and Agent Mesh are beta. Agent Mesh is qualified for standalone Redis and three-primary Redis Open Source Clusters; Redis Cloud and Enterprise qualification is pending. Plan accordingly — do not build production-critical multi-agent orchestration on Agent Mesh without a fallback path until it reaches GA.

Memory extraction is asynchronous: When your agent records a conversation, long-term memories are not available instantly. The extraction pipeline runs in the background. Design your agent to handle the case where a memory has not yet been extracted — especially in rapid-fire multi-turn conversations.

Semantic exclusions are advisory: The PII exclusion system is prompt-based, not deterministic. The Redis docs are transparent about this: “Semantic exclusions are advisory and do not guarantee exclusion. Session content still reaches the extraction model provider.” For strict PII requirements, layer your own deterministic PII detection before data enters the memory pipeline.

What Redis Iris Means for RPA Teams

If you are an RPA developer or solution architect evaluating agentic AI, Redis Iris represents a pattern that will increasingly shape your work:

The “context layer” is becoming a standard tier in enterprise architecture. Just as RPA bots needed an orchestration layer (UiPath Orchestrator, Automation Anywhere Control Room), AI agents need a context layer. Iris is Redis’s version of that tier. Expect every major infrastructure vendor to ship their own within 12 months.

Agent Memory replaces some of what RPA developers build manually. Today, many RPA workflows store “context” in Excel files, queue items, or database tables — manually maintaining state across process runs. Agent Memory does this natively, with semantic search, automatic extraction, and built-in deduplication. The migration path: identify which of your current “state management” workflows are really “memory management” workflows, and evaluate whether a purpose-built memory layer reduces maintenance.

MCP is the new API standard for agents. The Context Gateway’s MCP-native design reflects a broader industry shift. If you are building integrations for agents to consume, building MCP servers (not just REST APIs) will increasingly be the expected interface. The AgenticOps practices your team adopts should include MCP server monitoring as a first-class concern.

Observability is mandatory, not optional. Lens’s approach — tracing every agent decision back to the specific context that drove it — is what regulated industries will require before approving agent deployments. If your organization’s AI governance framework does not yet include agent decision traceability, Lens-style observability should be on your 2027 roadmap.

Getting Started

1. Sign up for Redis Cloud at redis.io/try-free (5,000 free messages).
2. Install the SDK: pip install 'redis-iris>=1.0.0'
3. Follow the quickstart: Redis Agent Memory Documentation
4. Configure memory types: Define custom memory types and extraction prompts in the Redis Cloud console.
5. Integrate with your agent framework: Iris works with LangChain, LangGraph, OpenAI Agents SDK, PydanticAI, and Google ADK. Start with Agent Memory, add Context Gateway for retrieval, then layer in Intent Router and Playbooks as you optimize.
6. Attend the live demo: November 12, 2026 (Americas) and November 17, 2026 (EMEA) at redis.io/resources/videos/redis-iris-full-spectrum/.

Frequently Asked Questions

Is Redis Iris open source?

Redis Iris runs on the Redis runtime, and Redis 8.8 is available as open source. However, the Iris capabilities (Intent Router, Playbooks, Agent Memory, Context Gateway, Lens, Agent Mesh) are part of the Redis commercial offering, available through Redis Cloud (managed) and Redis Software (self-managed/on-premises). Self-managed deployments are documented for Kubernetes.

How does Redis Iris compare to Mem0 or Zep for agent memory?

Mem0 and Zep are dedicated memory layers — excellent at their specific job. Redis Iris Agent Memory provides similar two-tier memory (session + long-term) but adds MemoryETL for document-to-memory extraction, integrates with the other five Iris capabilities (routing, playbooks, gateway, observability, messaging), and runs on the same Redis infrastructure your application likely already uses. The trade-off is vendor lock-in: Iris ties your memory layer to the Redis ecosystem, while Mem0 and Zep are framework-agnostic.

Does Redis Iris support the Model Context Protocol (MCP)?

Yes. The Context Gateway is MCP-native — it exposes a single MCP endpoint while federating requests to multiple backend MCP servers. Agent Memory also exposes an MCP endpoint that agents can use to search and curate long-term memory. You can bring your own MCP servers and integrate them through the Gateway.

What LLM providers and agent frameworks does Iris support?

Iris is model-agnostic and framework-agnostic. Lens auto-instruments model calls through OpenAI, Anthropic, Amazon Bedrock, and LangChain clients. Agent Mesh includes recipes for OpenAI Agents SDK, PydanticAI, Google ADK, and LangGraph. The Python SDK works with any agent framework. Harrison Chase (CEO, LangChain) has confirmed that Redis and LangSmith’s Context Hub work together to manage agent context across environments.

Can I use individual Iris capabilities without the full platform?

Yes. All six capabilities are designed to be used together or independently. You can start with Agent Memory alone, add Context Gateway when you need governed retrieval, and layer in Lens for observability — without committing to the full stack.

Key Takeaways

• Redis Iris is a six-capability real-time context engine covering routing, playbooks, memory, retrieval, observability, and messaging — four GA, two beta.
• Agent context failures, not reasoning failures, are the primary cause of production agent breakdowns. Iris attacks the four core failure modes: amnesia, memory poisoning, incomplete context, and token economics blowout.
• Agent Memory’s two-tier architecture (session + long-term) with MemoryETL, automatic extraction, and semantic deduplication represents the state of the art in managed agent memory.
• Context Gateway’s MCP-native design with schema-first data access, tool caching, and centralized authorization eliminates the multi-vendor “glue code” problem.
• Lens provides the decision traceability that regulated industries will require for agent deployments — every outcome traced to its skill, route, memory, and source.
• Agent Mesh makes multi-agent communication durable with buffered SSE streams and A2A support, but remains beta with limited qualification.
• The competitive advantage is integration: all six capabilities share one runtime, one SDK, one auth model. The risk is vendor lock-in to the Redis ecosystem.
• RPA teams should watch the “context layer” pattern — it is becoming a standard enterprise architecture tier alongside orchestration and process mining.

References

1. Redis. “Redis Expands Redis Iris to Give AI Agents the Memory, Context, and Messaging They Need to get to Production.” Press release, November 4, 2026. redis.io
2. Khadder, Simba. “The Next Chapter of Redis Iris: What Agents Need to Work in the Real World.” Redis Blog, November 4, 2026. redis.io
3. Redis. “The 4 Failure Modes of Agent Context.” Redis Blog, 2026. redis.io
4. Redis. “Redis Iris — Real-Time Context Engine for AI Agents.” Product page. redis.io
5. Redis. “Agent Memory Documentation.” redis.io
6. Redis. “Agent Mesh Documentation.” redis.io
7. Redis. “Lens Documentation.” redis.io
8. Kerner, Sean Michael. “Context Architecture Is Replacing RAG as Agentic AI Pushes Enterprise Retrieval to Its Limits.” VentureBeat, May 18, 2026. venturebeat.com
9. “Redis Iris — Real Time Context Engine For AI Agents.” I-Programmer, 2026. i-programmer.info
10. AI Agent Store. “AI Agents News — Week of November 8, 2026.” aiagentstore.ai