Memory
Memory is not one global blob. It is scoped and reviewable, so agents build durable context without polluting each other.
Scopes
| Scope | Visibility |
|---|---|
global | shared by all agents |
project | shared inside one project |
agent_private | only this agent can read/write |
task | only available during one task/run |
user_profile | your preferences and long-term instructions |
Memory document
{
"_id": "mem_001",
"scope": "project",
"project_id": "nexus",
"agent_id": null,
"type": "architecture_decision",
"title": "Nexus uses MongoDB as orchestration DB",
"content": "The user wants Nexus Core in Rust, MongoDB for state, Kubernetes isolated agents, and Plane as first board integration.",
"tags": ["architecture", "mongodb", "kubernetes"],
"importance": 0.9,
"created_at": "2026-05-30T00:00:00Z"
}
Two layers
1. Declarative memory (MongoDB) — architecture decisions, project preferences, coding conventions, deployment details, known bugs, user preferences.
2. Retrieval memory (embeddings / vector search) — past task summaries, PR summaries, error fixes, debugging history, long logs.
For MVP, plain MongoDB text search + tags is enough. Add a vector store (MongoDB Atlas Vector Search or self-hosted Qdrant) later. Do not overbuild memory.
Human control: review before permanence
Do not allow agents to freely write permanent memory at the beginning. Use this flow first:
Agent proposes memory
→ Nexus stores as pending
→ You approve in UI
→ Memory becomes active
Later, auto-approve low-risk memory.
Memory page (UI)
- Search memory · Filter by scope
- Edit memory · Pin memory · Delete memory
- Approve pending memory
- View which agent created it
How memory enters a run
At dispatch, Core searches memory using the agent's read_scopes, ranks by
importance + tags (+ vector similarity later), and injects the top results
into the run config. After the run, proposed memory lands in the review queue
unless the scope is auto-approved.