Memory is product data
If stored memory changes a user experience, it deserves the same operational treatment as profiles, entitlements, billing state, or support notes: inspectable, editable, and accountable.
Memory as an operating surface
Inspect and operate AI memory from the admin console.
MemexAI does not hide memory in an opaque model layer. The admin console gives teams a place to inspect memory files, correct wrong facts, review revisions, follow access logs, test tools, and watch memory health across users.
The console is an operator surface, not an end-user app. Put /admin behind your own auth, keep MEMEX_ADMIN_SECRET and MEMEX_API_KEY server-side, and proxy admin calls in public deployments.
Philosophy
Memory should be operable, not magical.
MemexAI is built around a simple belief: once memory can affect the next answer, it is no longer just model context. It is part of the product surface. The admin console is where that surface becomes visible enough for real teams to trust, debug, and improve it.
Trust comes from visibility
The console exists because durable memory should not be explained as "the model remembered." Teams need to see the file, the read, the write, and the revision behind behavior.
Correction beats mystery
Wrong memory should become an ordinary product workflow: find the record, correct it with a reason, verify the next context, and keep the trail for review.
What you can do
The console covers the core memory operating loop.
Use it after first install to prove the loop, and in production-like environments to debug why an agent remembered, forgot, or changed a durable fact after you have reviewed the security and retention caveats.
Memory files
Browse scoped memory as a tree, open user and shared files, inspect Markdown content, and edit incorrect memory with a reason.
Memory that affects behavior should be readable by the team operating the product.Observability
Track tool calls, p95 latency, error rate, active scopes, hot files, memory topology, hygiene signals, and recent slow or failed calls.
Once memory is injected into prompts, memory health becomes part of debugging production behavior.Revisions
Review every write snapshot with actor, operation, reason, timestamp, and the file content that changed future agent behavior.
A wrong answer should lead to a trail, not a guessing game about model state.Access logs
See read, write, patch, search, and smart-read activity so operators can understand which memory files agents touched.
Trust improves when teams can see what context was actually read, not only what the prompt intended.Tool playground
In a local or private operator session, call memory tools from the console, test raw and agentic flows, inspect responses, and copy integration snippets.
The first proof should be concrete before a team invests in a full integration.Dreaming operations
Configure background consolidation, inspect per-user dream status, pause users, and review dream-agent activity before widening rollout.
Background cleanup is useful only if operators can review and pause it.90-second proof
Make the memory loop visible before you integrate.
01Run the Docker service
02Write one durable memory
03Open the admin console
04Inspect the file, revisions, and access logs
05Use observability to see memory activity
Screens
Memory is visible, revisioned, and testable.
Operations
Wrong memory should be fixable by opening the record.
The admin console turns memory into product data: a team can inspect what exists, correct it, verify the next prompt context, and keep the audit trail.
The admin console is included with the service container at /admin. Keep admin access behind your own authentication and treat the admin secret as server-side operational credential.