RAG / Knowledge
Curated organizational information: policies, documents, product material and other evidence that should be retrieved without becoming agent-authored memory.
AI AGENT MEMORY · TECHNICAL REFERENCE · REVIEWED 21 SEP 2026
AI agent memory vs RAG: retained state and retrieved knowledge solve different jobs.
RAG retrieves curated knowledge for the current task. Agent memory reintroduces context learned from prior work when scope and policy allow it. Production systems often need both—and should keep their write authority, freshness and trust boundaries separate.
SCOPED CONTEXTREAD / WRITE BOUNDARIESPROVENANCE-AWARE
MEMORY SCOPE
WORKSPACE
USER / SUBJECT
AGENT
CONTEXTretrieved for this run
READconfigured scope
WRITEseparate policy
01 · DEFINITION
What is the difference between AI agent memory and RAG?
AI agent memory is reusable context that an agent can retrieve across interactions or tasks. RAG retrieves evidence from a curated corpus. Memory carries permitted state from prior interactions or executions. They can use similar retrieval infrastructure, but they differ in who writes the data, how it changes, and which agent is allowed to reuse it.
In Createting, Knowledge Bases and MAGMA memory are separate capability surfaces. Linked knowledge should not be silently copied into memory, and request context is descriptive rather than authoritative for memory scope.
02 · SCOPE
The useful distinction is not vector search. It is ownership, lifecycle and scope.
A vector store can support both retrieval patterns. The architecture decision starts with what the data represents, who is allowed to write it, and how stale or conflicting state is prevented from becoming invisible authority.
Agent memory
Reusable context learned from prior work. Reads and writes should be scoped to the actor and trusted server grants rather than inferred from user-provided context.
Working context
Task state, recent conversation and execution context can stay local to the current run. Not every useful fact needs to become durable memory or enter a knowledge corpus.
03 · RAG VS MEMORY
RAG retrieves evidence. Memory carries permitted state forward.
KNOWLEDGE BASE
AGENT MEMORY
Primary roleRetrieve curated company information
Primary roleReuse relevant context across work
Typical sourceDocuments, records, approved sources
Typical sourceInteractions, observations, prior execution
Default postureRetrieval from an authoritative corpus
Default postureScope-sensitive read and potentially write behavior
Key questionWhich sources may this agent retrieve?
Key questionWhat may this agent remember, reuse or change?
04 · WRITE AUTHORITY
Memory introduces a write problem that RAG does not have.
Retrieving an approved document and writing durable agent memory are different operations. Current Createting memory policy limits agent-callable writes to private Tier-2 memory owned by the acting agent; broader scopes require trusted server-side authority.
01Retrieve
Retrieve only the memory scope granted to the current principal.
READ02Observe
Keep Knowledge Base evidence separate from agent-authored memory instead of silently copying one into the other.
REVIEW03Write
Allow durable memory writes only through the configured scope and ownership policy.
WRITE05 · TRUST & FRESHNESS
Neither RAG nor memory should become invisible authority.
RAG can retrieve stale or irrelevant material. Memory can preserve outdated or incorrect state. The safer design keeps provenance, scope and operational systems of record explicit so retrieved context can inform a decision without silently replacing authoritative business state.
OBSERVATION“Customer prefers email”
→
PROVENANCEsource · actor · time
→
RETRIEVALrelevant + permitted
Use memory for continuity, RAG for curated evidence, and live tools or systems of record when the answer depends on current operational truth.
06 · HYBRID ARCHITECTURE
Most production agents need memory and RAG together—not one giant context store.
A configured agent can retrieve company knowledge, use allowed memory from prior work, keep current task state separate, and call live systems when fresh operational data is required. The important boundary is which source answers which question.
AGENT STUDIOMISSIONSSUBAGENTSVOICEBROWSERAUTOMATIONSKNOWLEDGETOOLS
07 · PRACTICAL QUESTIONS
AI agent memory vs RAG: practical architecture questions.
Is agent memory just RAG over conversation history?
Not necessarily. Both may use retrieval, but memory adds a write and lifecycle problem: what becomes durable, who owns it, who may read it later and how changed state is handled. RAG normally retrieves from a separately curated corpus.
When should I use RAG instead of memory?
Use RAG when the agent needs evidence from curated organizational knowledge such as documents, policies or product material. Keep that knowledge separate from agent-authored memory so retrieval does not silently mutate durable state.
Should every agent share the same memory?
No. Shared memory can leak context and couple unrelated work. Createting defaults custom agents toward agent-scoped access; wider team, organization or orchestrator access must come from trusted server-side grants.
Can an agent read memory without writing to it?
Yes. Read scope and write authority are separate concerns. Many agents need historical context without permission to mutate durable shared memory.
Does memory or RAG replace a CRM, ERP or live system?
No. Memory and retrieved knowledge can inform the agent, but authoritative operational state should remain in the relevant system of record. Use live tools when the answer depends on current business state.
What is the main governance difference between memory and RAG?
Memory can be agent-authored, so write authority and cross-agent scope matter in addition to retrieval permission. RAG still requires access control, but the corpus is normally curated outside the agent's own memory lifecycle.
ARCHITECTURE REVIEW
Map memory, RAG and systems of record before the agent starts writing state.
Bring one workflow. We’ll separate curated knowledge, durable agent memory, short-lived task context and live operational data—then define who may read or write each layer.