Agent memory vs RAG

RAG finds answers in documents. ContextDB remembers the customer.

Use RAG to answer product and policy questions. Use ContextDB to remember what this customer said across calls and chats, then evaluate policy-trusted evidence before booking, refunding, or changing an account.

Short answer: RAG retrieves from your documents. ContextDB remembers each customer. Keep both when your agent needs product knowledge and a continuous customer history.

Architecture boundary

Documents and customer memory solve different problems.

Need	RAG	ContextDB
Best at	Answering from product docs and company knowledge	Remembering users and past interactions
Returns	Related document passages	Customer facts with source, time, and confirmation status
Across calls and chats	Only if your application builds that layer	One customer history across sessions and channels
Before a booking or refund	No built-in check that the customer confirmed it	Returns act, ask, or abstain from policy-trusted evidence. The customer host enforces the result.
After something goes wrong	Your application must reconstruct what happened	Shows the policy decision, evidence IDs, and host-reported result

Relevance without permission

RAG can retrieve “maybe Friday,” and your agent may book it.

A retriever finds “Friday might be easier” because it is relevant to scheduling. The model sees it beside the booking tool and treats it like authorization. Retrieval worked. The action boundary did not.

ContextDB evaluates source, confidence, freshness, confirmation, conflicts, and the configured action policy. The gate returns act, ask, or abstain from policy-trusted evidence. The customer host must enforce ask and abstain before it calls the tool.

# retrieval result
"Friday might be easier, maybe."
similarity = high

relevance ≠ authority

# action decision
source = "user_stated"
confidence = 0.4
confirmed = false
policy_trusted = false

recall_for_action("book Friday") → outcome = "ask"
reason = "tentative preference"

Choosing the boundary

Use RAG for knowledge. Add ContextDB for customer history and actions.

Use ordinary RAG when

The agent answers from a document corpus
A person reviews the generated output
Relevant context is the main requirement
No recalled statement directly authorizes a mutation

and

Add ContextDB when

The agent acts using remembered user facts
Tentative and confirmed statements need different treatment
Your host enforces ask or abstain before the tool call
An operator needs the reason after the action

RAG and memory FAQ

Where ContextDB sits beside RAG.

Is ContextDB a vector database?

No. It is customer memory for agents. It keeps facts across conversations, records where each fact came from, and helps agents check current details before they act.

Should I remove my existing RAG pipeline?

No. Keep it for product and company knowledge. Add ContextDB for customer history and before tools that book, refund, or update.

Does act mean the remembered fact is objectively true?

No. It means policy-trusted evidence passed the configured policy for that action. Confirmation is one policy signal, not the only path to act. An API or MCP confirmation records authenticated project-credential context against one scoped memory. It does not authenticate the end user. The customer host authenticates the end user and retains any end-user attestation. A Console confirmation records operator context. No confirmation proves objective truth. ContextDB's result remains advisory. The customer host authorizes and executes the action.

Test customer memory beside your RAG pipeline.

Use one remembered customer detail in a booking or support flow.

Add the customer-memory check