Use RAG when the answer lives in documents that are the same for every user, like policies, docs and product specs. Use agent memory when the answer depends on what happened with this user before and can change, like preferences, past decisions and open issues. Most production agents need both: RAG for what the company knows, and memory for what the agent knows about the person it's talking to.

For the definitions in depth, see memory vs RAG in our docs. This post helps you decide: five questions that sort most requirements, a worked support-agent example that uses both, and four tests that tell you whether your current RAG setup already covers memory.

Which one do you need?

Ask these five questions about each thing your agent has to know:

Is the answer the same for every user? A refund policy or an API reference is. Use RAG over a shared knowledge base.
Does it depend on what this user said or did before? "What size do I usually wear?" does. Use memory, scoped to that user.
Can it change? A user switches plans, changes a preference or corrects a fact. Use memory that tracks updates, so the newer fact wins.
Is it live business state? "Has my order shipped?" isn't a retrieval question at all. Call the system of record.
Does it need to survive the session? If the next conversation, or another app, should know it, it belongs in memory rather than the context window.

The same answers as a table, with one more case at the end:

If your agent needs to...	Use	Why
Answer from policies, docs or specs	RAG over a shared index	The content is the same for everyone and changes on your schedule
Continue the current conversation	The conversation history in the prompt	Nothing has to outlive the session
Recall a preference or decision across sessions	Agent memory	It's about one user and has to persist
Know which fact is current after a change	Agent memory with updates	Similarity alone returns the old fact as readily as the new one
Check an order, a balance or a booking	A call to the system of record	Live state shouldn't come from a memory or an index
Follow relationships between things	Structured records or a graph	Some questions are about connections, not passages

The last row has its own guide: the Graph RAG tutorial builds a knowledge graph for relationship questions.

Do I need agent memory if I already use RAG?

Only if your RAG setup doesn't already do the things memory is for. RAG retrieves information to answer a request, and nothing stops you from indexing past conversations as documents. The original RAG paper even calls its document index the model's "non-parametric memory". What a document index doesn't give you on its own:

Scope. A shared index mixes everyone's conversations unless every query filters by user, every time.
Currency. If a customer asked for phone updates in March and email in May, both statements match a query about contact preferences, and the index can't tell which one is current.
Extraction. A transcript chunk holds whatever was said around a fact, and the fact you need may not be in the retrieved part.
Forgetting. Deleting what a user asked you to forget means finding every chunk that mentions it.

Our docs illustrate the currency problem with a sneaker shopper: they love Adidas, then their Adidas break, then they say they're switching to Puma. Weeks later, similarity search still returns "I love Adidas sneakers" as the closest match to "what sneakers should I buy?" (docs). A memory layer tracks that the preference was replaced.

If your RAG app passes the tests at the end of this post, a separate memory layer is optional. A bigger context window doesn't replace either one: it only holds what you send with one request.

Worked example: a support agent that needs both

Acme's support agent answers billing questions. In an earlier session, a customer told it they renewed their annual plan on October 3 and want updates by email. Today, in a new session, they ask:

Can I still get my money back for the renewal?

A good answer needs four things, from three places:

Part of the answer	Where it comes from	Why there
Annual plans can be refunded within 30 days of renewal	RAG over the help center	The policy is the same for every customer
This customer renewed on October 3	The customer's memory	Only they said it, in an earlier session
They want updates by email	The customer's memory, as a preference	It should hold in every future session
The renewal payment actually went through	The billing system	Live state, checked before any refund

Here's the retrieval side with supermemory's v5 Python SDK, following the calls in our quickstart. The help center goes in one shared namespace as SuperRAG, which only chunks and indexes it, and each customer's conversations go in their own namespace on the default memory path, which also extracts facts and builds a profile:

from supermemory import Supermemory

client = Supermemory()  # reads SUPERMEMORY_API_KEY

# Shared knowledge: indexed for search, no memories extracted
client.add(
    "acme_support_kb",
    content="Annual plans can be refunded within 30 days of purchase or renewal. Monthly plans aren't refundable.",
    id="refund_policy_v3",
    task_type="superrag",
)

# This customer's history: the default memory path extracts facts and updates their profile
client.add(
    "customer_8812",
    content="user: I renewed the annual plan on October 3, but we might move to monthly.\n"
            "assistant: Got it. Do you want updates by phone or by email?\n"
            "user: Email, please.",
    id="ticket_4471",
)

# Weeks later, in a new session
question = "Can I still get my money back for the renewal?"

policy = client.search("acme_support_kb", query=question, search_mode="chunks", limit=3)
profile = client.profile("customer_8812").profile
history = client.search("customer_8812", query=question, search_mode="memories", limit=5)

context = "\n".join(
    [hit.chunk for hit in policy.results if hit.chunk]
    + [m.memory for m in profile.static + profile.dynamic]
    + [hit.memory for hit in history.results if hit.memory]
)
# Put `context` in the model's system prompt, and check billing before issuing a refund

Search is scoped to one namespace, so the policy and the customer's history are two calls, as in the docs' own example of combining them. Memories form in the background after an add, so a brand-new namespace can look empty at first. For a quick test, pass dreaming="instant" on the add, which bills one extra operation (quickstart).

Here's why the split matters:

With RAG alone, you'd index the old ticket next to the policy. Without a user filter on every query, another customer's renewal could surface, and "we might move to monthly" would be retrieved as readily as anything said later.
With memory alone, you'd store the refund policy in every customer's memory. It isn't about them, it goes stale in thousands of places when it changes, and it costs more to ingest.
With neither, the model would guess at the policy and ask the customer to repeat their renewal date.

The cost difference is real: SuperRAG ingestion is billed at a fifth of the memory rate per token, because it skips fact extraction (billing docs), so reference material belongs on that path. Current rates are on the pricing page.

How to tell whether your RAG app needs memory

Run the same four tests against your current setup and against one with a memory layer, using the same questions and histories:

Correction. Tell the agent a preference, then change it in a later session. Does the new one win?
Across sessions. End the session, start a fresh one and ask something that needs the earlier fact.
Isolation. Ask the same thing as a different user. The fact shouldn't appear.
Deletion. Ask the agent to forget the fact, then check that no answer can still use it.

Score answer correctness and source support separately from retrieval. An answer can be wrong even when the right passage was retrieved, because the failure was in context assembly or reasoning. Then add cost per successful task and latency. If your RAG app passes all four, keep it. If it fails corrections or isolation, that's what a memory layer is for, and the build vs buy guide helps decide whether to build one.

How supermemory handles both

One API covers the two paths. Documents ingested as SuperRAG are chunked, embedded and searchable as chunks only (SuperRAG docs). Content on the default memory path is also turned into memories, linked to earlier ones as updates, extensions or derived facts, and summarized into a user profile (graph memory docs). Search can return memories, chunks or both, inside one namespace per call. The product page walks through the engine, and the docs' comparison page has a cheat sheet for when plain RAG is enough.

Common questions

Is agent memory just RAG over chat history?

Partly. Retrieval is one step of memory, but memory also decides what to keep from a conversation, extracts it as standalone facts, replaces facts that change, scopes them to a user and forgets on request. RAG over raw transcripts does the retrieval step only.

Can I build agent memory on my vector database?

For a handful of preferences, yes: a table keyed by user can hold them, and you may not need semantic search at all. It gets harder once facts change, users span many sessions and apps, and deletion has to be reliable. AI memory vs vector databases separates what a database gives you from what the memory layer still has to do.

Does a bigger context window replace RAG and memory?

No. A context window holds what you send with one request, so nothing in it carries over to the next session unless you save it and send it again. Long prompts also have limits of their own: in Lost in the Middle, models used information at the start or end of a long input much more reliably than information in the middle.

Where do I start if I need both?

Index your shared documents first, since that's plain RAG and easy to test. Then add memory for the one cross-session behavior that matters most, such as remembering a preference, and run the four tests above. The RAG chatbot guide covers the retrieval side end to end.

RAG vs agent memory: which one do you need?