LLM Wiki — Synaptic Lattice

redis-iris-agent

Properties1
tagsentity, repository, tool, agentic, memory, retrieval

Leitura de 3 min

Overview

redis-iris-agent (coleam00/redis-iris-agent, 20 stars, MIT, Python) is a Pydantic AI agent demo that gives an LLM a real “context layer” built on Redis’s preview product Redis Iris. It pairs two distinct concerns: a Context Retriever (live business data, exposed through governed MCP tools auto-generated from an entity model) and Agent Memory (short-term session memory plus long-term memory auto-promoted across sessions). It ships with a conversational CLI and a full reproducible support-desk demo (“Northpeak Outfitters”).

Key Facts

  • Stars: 20. License: MIT. Language: Python. Status: explicitly a proof-of-concept — both Context Retriever and Agent Memory are marked “in preview,” not production.
  • Context Retriever: publishes a streamable-HTTP MCP endpoint at /mcp, authenticated with an X-API-Key header, wired into the agent via Pydantic AI’s native MCPToolset. Tool names are auto-derived from the entity model’s field index type: tag → filter_*, text → search_*, numeric → find_*_by_*_range, key → get_*_by_id. A field carries exactly one index type, so an entity with no text field gets no search tool.
  • Agent Memory: the managed redis-agent-memory SDK, wrapped as two plain tools (search_memory, store_memory). Durable facts are auto-promoted from a conversation in the background; working memory resets per session (/newsession) while long-term memory persists.
  • Explicit architectural split: “Context Retriever is the data; Agent Memory is who the user is.” The two never overlap — one queries live business state, the other recalls user-specific facts across sessions.
  • Access control: scoped server-side by the agent key — the agent only ever sees data that key is allowed to reach, unlike a folder of files handed to an agent wholesale.
  • Demo dataset: 134 support records (customers, products, orders, shipments, tickets) provisioned into ~5 entities / ~29 auto-generated tools via configure_surface.py.

Relationships

  • “belongs-to” agent-memory-systems — memory-first family instance: session + long-term memory exposed as agent tools, same pattern as mem0/HippoRAG but on Redis’s own managed service rather than an open-source library
  • “uses” model-context-protocol — Context Retriever is implemented as a streamable-HTTP MCP server with auto-generated, schema-derived tools
  • “is-sibling-of” mem0 — both are memory layers for agents, but redis-iris-agent is a vendor preview product/demo (Redis), not a standalone open-source memory library
  • “differs-from” mem0 — redis-iris-agent bundles memory with a second, distinct concern (live data retrieval via auto-generated MCP tools); mem0 is memory-only

Implications

redis-iris-agent is useful in this vault as a concrete example of two patterns converging in one system: (1) MCP tools auto-generated from a data schema rather than hand-written, and (2) agent memory as a managed service exposed through plain tool calls rather than a custom retrieval pipeline. Because it is an explicit vendor proof-of-concept (Redis Iris, in preview) rather than a general-purpose OSS library, it should not be treated as interchangeable with mem0/cognee/rightmemory when comparing memory-first architectures — it is narrower in scope (tied to Redis Cloud) but demonstrates the “memory + live context, cleanly separated” design point well.

Open Questions

  • Redis Iris (the underlying managed product) itself does not yet have a vault page — worth capturing separately if it recurs across other sources, since this repo only documents it as a consumer.
  • No information in the source on how Agent Memory’s fact-promotion (conversation → durable memory) actually decides what counts as durable; unresolved compared to mem0’s documented consolidation approach.

Sources

Visão de gráfico

Backlinks