A memory lifecycle from write to delete
Retain information useful to future tasks, then update or delete it when it changes or is no longer needed.
Write
Receive a fact, preference, task state, or experience that should persist, together with the necessary source and time context.
Retrieve
Use the current task, scope, and relevance to return memories that can support the next action.
Update
Correct an existing record when a fact, preference, or task state changes.
Delete
Remove content that is no longer needed, has expired, or should not be retained under a user request or governance rule.
Scope memory by project and user
Define scope, source, and lifecycle during integration to prevent context from crossing users, projects, or tasks.
Project scope
Organize connections and usage boundaries by project so application environments remain clearly separated.
User scope
Maintain distinct user context while the integrating application supplies a stable, compliant user identifier.
Sources and metadata
Keep the source, time, and relevant business labels needed for later judgment and governance.
Illustrative request shape
The example shows the identity, content, and source information a memory write may contain so teams can discuss an integration model.
POST /v1/memories
Authorization: Bearer $MEMORAX_API_KEY
Content-Type: application/json
{
"user_id": "user_123",
"content": "Prefers concise weekly updates",
"metadata": { "source": "assistant" }
}Illustrative request only. Confirm endpoints, fields, permissions, limits, and data handling before production use.
Discuss an API integration
Tell us your agent type, the context that should persist, and your data boundaries.