Agents Need Memory, Fresh Data, and a Cache to Survive Production

A weekend wiring up a real agent against those needs — and testing one new service, Redis Iris, that claims to handle them.

Most agent demos work because they live in a single conversation with a model holding the whole world in its context window. Production agents don’t get that luxury. Put one in front of real users and the hard part stops being the model and becomes the plumbing around it — which turns out to be surprisingly specific.

Build anything real and the same four requirements show up:

• Memory within a session. A constraint stated early — a budget, a preference, a goal — should still hold ten turns later. Lose it and the agent feels broken.
• Memory across sessions. What they told it last week shouldn’t need repeating today. This is the difference between a tool and an assistant.
• Real data, not vibes. Answers about your customers, orders, or inventory should pull from your system of record — current values — not hallucinations. And the data has to stay fresh as the source changes.
• Cost control. The hundredth user asking a near-identical question shouldn’t cost a hundred LLM calls. Without caching, the bill scales linearly with traffic and the math stops working.

None of these are exotic — they’re the baseline for any agent you’d ship. The catch is you normally build and maintain all four yourself, moving parts that have nothing to do with your product.

So when Redis launched Iris last week pitching exactly these four as managed services, it caught my attention — not as a product to review, but as a claim to test. Does the boring-but-hard plumbing actually hold up as a service when you wire it into a real agent? I had a weekend, so I built one and put it through its paces.

This isn’t an endorsement. It’s an opportunistic, hands-on read — what worked, what I worked around, what I couldn’t access, and what I’d ask the Redis team before running any of it in production.

Where Redis Iris fits

Redis Iris packages those four jobs as managed services, and the pieces map almost one-to-one to the requirements:

• **Agent Memory** → memory. Short- and long-term, with semantic retrieval.
• **LangCache** → cost control. Semantic caching that matches on intent, not exact strings.
• **Context Retriever** → real data. Point it at a schema over your business data and it auto-generates MCP tools, so the agent navigates entities instead of writing raw queries.
• **RDI — Redis Data Integration** → freshness. Keeps Redis current with your system of record via change data capture.
• Redis Search sits underneath, handling live filtering and retrieval.

One caveat: I got Agent Memory, Context Retriever, and LangCache working hands-on, but RDI is still in preview and not generally available — you contact Redis to evaluate it — so I wrote a small sync script in its place (more below).

My test agent: a travel concierge

I wanted a use case that exercises all four requirements at once — and a travel concierge fits perfectly: it has to hold a preference across turns, recall it in a later session, return real hotels instead of invented ones, and not pay twice for the same popular question.

I based it on Redis’s official LangGraph sample, but that sample only covers one of the four — Agent Memory, with no caching, retrieval, or data layer. So I kept its travel framing and memory foundation and built out the other three myself, which is the clearest measure of what’s actually mine here.

How I built it

On top of the sample’s Agent Memory foundation, I added the two components it never touched — LangCache and Context Retriever — a real data layer to retrieve against, and a UI that surfaces every layer as a live panel so you can watch the whole pipeline at once. Piece by piece:

Data layer: I used PostgreSQL with a small schema — 8 destinations, 8 hotels with ratings and amenities, 9 activities, 9 restaurants, and a user-preferences table. Small, but enough to make retrieval and filtering non-trivial.

RDI (stand-in — still in preview): RDI isn’t generally available yet — you contact Redis to evaluate it — so I stood in with a sync script: read from Postgres, write JSON into Redis:

pg_cursor.execute("SELECT * FROM hotels")
for row in pg_cursor.fetchall():
    redis_client.json().set(f"hotel:{row['id']}", "$", to_json(row))

RDI does this continuously over CDC; my script just produces the same end shape so Context Retriever has fresh data to read. It’s the one piece I’d swap for the real service once it opens up.

Context Retriever: I created a Surface (Redis’s term for the data-access layer) in the Cloud UI, pointed it at my instance, and ran auto-detect against the JSON. It generated 15 typed MCP tools across my five entities — a filter, get, and search for each — with no API code on my side. This is the piece that most lived up to the pitch.

Context Retriever

Point it at data, get 15 tools back. Every one was generated, not written.

LangGraph integration: a node that detects travel intent, calls the right Context Retriever tool over MCP, and hands structured results back to the model.

Seeing all four layers at once

What I cared about most wasn’t that it worked — it’s that you can watch it work. Each layer gets its own live panel, so one conversation lights up the whole pipeline.

A fresh session, before anything runs:

Travel Concierge Agent — Fresh Session with No Context

And after the flow runs — short-term memory holding the conversation, three facts extracted to long-term memory, a Context Retriever tool call returning real hotels, LangCache reporting a hit:

Travel Concierge Agent with short-term memory, LangCache status, Context Retriever tool calls, retrieved long-term memory, newly extracted long-term memory.

The flow, end to end

The exact sequence from the demo scripts. I’ll flag where a panel needed a warm index to fire.

Session 1

1 — Set preferences → LTM extraction. “My name is Sarah and I prefer luxury hotels with spa facilities near the beach. I’m vegetarian.” Agent Memory extracts three durable facts — name, hotel preference, dietary restriction — into long-term memory.

2 — First query → cache miss. “What are the best luxury beach destinations in Europe?” Nothing to match yet: the model generates a fresh response and caches it.

3 — Similar query → semantic cache hit. “Which European beach locations are ideal for a luxury vacation?” Same question, different words. LangCache returns the cached response with no LLM call. Caveat: this fired reliably only once the cache index was warm (see below).

Session 2 (new session, same user)

4 — Cross-session recall → LTM retrieval. “Can you recommend destinations for me?” A brand-new session with no short-term context — yet the agent pulls Sarah’s stored preferences and personalizes. Same warm-index caveat as step 3.

5 — Tool calling → Context Retriever. “Find me luxury hotels in Barcelona.” Context Retriever fires a tool call and returns two real Barcelona hotels — actual rows from the data layer, not hallucinations. This is the moment hardest to fake, and the one I’d point to first: real data, through an auto-generated tool, filtered against a preference remembered from a different session.

▶ Watch the 2-min demo — the full flow: preferences extracted to memory, a semantic cache hit, cross-session recall, and real hotels returned through Context Retriever.

What worked

Integration was fast. Each client is a few lines of config — zero to a working multi-component agent in an afternoon.

Auto-generated tools saved the most time. Point Context Retriever at data, get MCP tools back — no schemas, no REST boilerplate. The feature I’d miss most if I had to hand-build the data layer again.

Observability was legible. Each component logs what it’s doing — intent detected, tool called, cache hit/miss, memory extracted — so debugging was a non-event.

What I had to work around

RDI isn’t generally available yet. Still in preview — you contact Redis to evaluate it — so I used a stand-in sync. I’d want the real service before trusting freshness in production, and I’d test it under real change load.

Generated tool names follow a fixed pattern. Names are operation_entity_by_field — filter_hotel_by_destination_id, get_hotel_by_id, search_hotel_by_text — so they may not match what you'd reach for by intuition (I assumed a price-range filter that didn't exist). Not a blocker: list the generated tools and bind to what's actually there.

tools = requests.post(mcp_url, json={"jsonrpc":"2.0","method":"tools/list","id":1},
                      headers=headers).json()["result"]["tools"]

The open question: tools are generated from the entity model — change the entities and you change the tools — but there’s no documented way to author or customize an individual one. The 15 were plenty for this demo, but a real app will eventually want a composite filter or custom logic the schema won’t infer. Whether that’s coming or out of scope is the first thing I’d ask Redis.

Cold indexes don’t fire on the first run. On a cold start, the cache hit (step 3) and cross-session retrieval (step 4) didn’t register — the indexes need a few writes before they’re queryable. Run the flow a couple of times to warm them and both fire reliably. Worth knowing before you demo a cold run and think something’s broken.

The economics, on paper

I didn’t run a controlled benchmark — a weekend on a toy dataset wouldn’t produce numbers worth trusting. More useful is the model: where caching savings come from, and what makes them disappear.

The one variable that decides everything is cache hit rate. The higher it is, the more queries skip the LLM entirely — cost drops in proportion, and a hit returns from a Redis lookup (milliseconds) instead of a model round-trip. At ~$0.025 per LLM call:

These are illustrative — a cost model, not a measurement. Savings depend entirely on the hit rate, which reflects your traffic rather than the product: a long tail of unique questions might sit at 10–20%, while a support bot answering the same hundred all day could reach 80%. So rather than quote a headline percentage, the useful step is to estimate the hit rate for your own workload.

More interesting than cost is the correctness tradeoff. You raise the hit rate by loosening the similarity threshold — but loosen it too far and the cache returns an answer to a question that wasn’t really the same, so the response is wrong rather than just slow. Finding the threshold that maximizes hits without serving wrong answers is real work — exactly what I’d want to dig into with the Redis team.

How it deploys, and which piece is for what

In my setup, the only things outside Redis Cloud were the agent and the Postgres database. Postgres stayed where it was, a sync mirrored it into Cloud, and the agent used Cloud for memory, retrieval, and cache. With the real RDI in place, the pattern is the same: your database stays put, RDI keeps a current copy in Cloud, and the agent reads everything from one fast place. For an enterprise that won’t move its production database, that’s what makes the whole thing realistic to adopt.

Beyond whether the bundle is good, the practical question is which piece you actually need for a given agent — because adopting all four means running things some agents never use:

• Context Retriever — the default yes. Almost any agent needs grounded data access, and the auto-generated tools remove the tedious part. If I adopted one piece first, it’s this.
• Agent Memory — when personalization or continuity matters. It shines for assistants that remember you across sessions — a concierge, an account copilot, a coding agent. For a stateless, single-shot agent, it’s overhead.
• LangCache — high-repeat workloads only. The sharpest fit boundary. A support or FAQ-shaped assistant is where it pays off; an agent doing one-off analysis sees a low hit rate, little benefit, and inherits the correctness risk for nothing. Match it to traffic, don’t bolt it on by default.
• RDI — the enabler underneath, not a feature you “use.” Its job is freshness; you feel it when data is stale. I couldn’t evaluate the real service, which is exactly why it’s the piece I most want to pressure-test.

The summary: Context Retriever for nearly everyone, Agent Memory when you’re personalizing, LangCache when traffic repeats. A more useful lens than “adopt the platform.”

Where I land

The core idea — let Iris handle the context plumbing so you can focus on the agent — held up well in my testing. I got every component I could access working hands-on, and the Context Retriever auto-tooling and cross-session memory were the two I enjoyed most.

A few things I’d genuinely like to understand better, and would happily dig into with the team:

• RDI in practice. I only tested the downstream shape with a stand-in, so I’m curious how the real service behaves under continuous change — what the lag looks like between a source write and the agent seeing it.
• Tuning the cache. Semantic caching trades a little correctness risk for speed and cost; I’d love to learn how the similarity threshold is meant to be tuned and what the recommended defaults are.
• Portability. The auto-generated tools and memory model are convenient — I’d want to understand how they map if you’re integrating with an existing stack.
• How the pieces evolve. It’s an early, fast-moving release, and I’d be interested in how the components are meant to version together over time.

Stepping back: a production agent needs memory, fresh data, and cost control, and today you mostly build and maintain all four yourself. Iris is a bet that these belong in infrastructure rather than application code — and on a weekend’s evidence, that’s a bet worth taking seriously. The pieces I could reach were genuinely fast to adopt, and the open questions are the normal ones for any new platform.

Based on my evaluation, if you’re building agents and tired of hand-rolling memory and data access, it’s worth giving a shot — which is exactly what I did.

Try it yourself

I’ve put the demo on GitHub: https://github.com/balajisiva/redis-iris-travel-agent

Included: the LangGraph agent, Postgres schema and seed data, the stand-in sync script (placeholder for RDI until it’s generally available), the Context Retriever Surface config, a Docker Compose that runs it locally, and demo scripts for each feature.

git clone [YOUR_REPO_URL]
cd redis-iris-travel-agent
cp .env.example .env          # add your Redis Cloud credentials
docker-compose up -d
./demo_flow.sh

Fork it to swap models, add data sources, or point it at a different domain.

Forked from and full credit to Redis’s redis-agent-memory-with-langgraph-demo, which provided the Agent Memory + LangGraph foundation I built on.

Built with LangGraph, Redis Iris (Context Retriever, Agent Memory, and LangCache, with a stand-in sync for RDI until it’s generally available), PostgreSQL, and Docker. A weekend project; the Iris integration itself was a small amount of glue code. Cost figures are an illustrative model, not a benchmark.