User and subject context
Keep relevant context attached to the person, account or subject the work is actually about instead of leaking it into unrelated runs.
AI AGENT MEMORY · CONTEXT GOVERNANCE
Agent memory that remembers the right things in the right scope.
Createting can assemble reusable context around the configured user, agent, subject and runtime scope. Reading and writing memory are treated as distinct behaviors, while authoritative business systems remain the source of record.
SCOPED CONTEXTREAD / WRITE BOUNDARIESPROVENANCE-AWARE
MEMORY SCOPE
WORKSPACE
USER / SUBJECT
AGENT
CONTEXTretrieved for this run
READconfigured scope
WRITEseparate policy
01 · DEFINITION
What is AI agent memory?
AI agent memory is reusable context that an agent can retrieve across interactions or tasks. Unlike the temporary prompt for one model call, memory can persist beyond a single turn and be reintroduced when it is relevant and permitted.
For enterprise systems, persistence is only half the problem. The harder question is whose context this is, which agent may use it, and under what write policy. Createting treats that boundary as part of the runtime model rather than one shared conversation history.
02 · SCOPE
Memory should have boundaries before it has scale.
Reusable context becomes useful when it follows the work. It becomes risky when every agent sees the same undifferentiated history.
Agent and runtime context
Different agents can operate with different context boundaries. A support agent does not automatically need the same memory surface as a sales or operations agent.
Session and mission context
Short-lived execution context can stay local to the current interaction or mission while longer-lived memory is retrieved only when it remains relevant.
03 · MEMORY VS KNOWLEDGE
Knowledge tells an agent what the organization knows. Memory helps it retain what the work has learned.
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 · READ / WRITE
Permission to remember is not the same as permission to rewrite memory.
A useful memory architecture separates retrieval from mutation. An agent may need context from prior work without being allowed to create or modify long-lived memory freely.
01Retrieve
Resolve relevant memory inside the allowed scope.
READ02Observe
Capture candidate context without silently turning every observation into durable truth.
REVIEW03Write
Persist or update memory only where configured policy allows that behavior.
WRITE05 · TRUST
Memory should remain context—not invisible authority.
Long-lived agent systems need to distinguish remembered context from verified systems of record. Where evidence and provenance are available, they should travel with memory instead of disappearing into prompt state.
OBSERVATION“Customer prefers email”
→
PROVENANCEsource · actor · time
→
RETRIEVALrelevant + permitted
Memory can enrich decisions, but authoritative business systems should remain the source of record for operational truth.
06 · SAME OPERATING MODEL
Memory can follow the agent system without becoming a separate product island.
When memory is enabled for a deployment, it can participate in the same runtime model as the agents, missions and execution surfaces that use it.
AGENT STUDIOMISSIONSSUBAGENTSVOICEBROWSERAUTOMATIONSKNOWLEDGETOOLS
07 · FAQ
AI agent memory, without the hand-waving.
What is the difference between AI agent memory and conversation history?
Conversation history is usually the transcript of one interaction. Agent memory is reusable context that may be retrieved across interactions or tasks when the scope and policy allow it.
How is agent memory different from a knowledge base?
A knowledge base normally retrieves curated organizational information. Memory is more context-sensitive and may represent relevant information learned through prior interactions or execution.
Should every agent share the same memory?
No. Shared memory can create context leakage and unnecessary coupling. The useful boundary depends on the user, subject, agent role, workspace and execution context.
Can an agent read memory without writing to it?
Yes. Read access and write behavior should be separate controls because many agents need historical context without needing permission to mutate durable memory.
Does memory replace CRM, ERP or other systems of record?
No. Memory can enrich agent context, but operational systems should remain authoritative for business records and state.
How does memory relate to governance?
Memory is another governed resource: who may retrieve it, what scope is visible, and when durable writes are permitted should be explicit rather than inferred from a prompt.
ARCHITECTURE REVIEW
Design memory around the work—not around one giant chat log.
Bring one agent workflow and the context it needs. Map the memory, knowledge and authority boundaries before deployment.