A bot doesn't simply have memory or lack it. Memory comes in layers. Below is the framework we use to judge memory, then the test that shows the real differences between products.
Six layers of memory
| Layer | What it should keep | Why it matters |
|---|---|---|
| Current working context | The conversation and material needed for the current task | Lets the bot reason now. It shouldn't be your only record. |
| Job definition | Responsibilities, boundaries, preferred outputs | Keeps the bot focused on its continuing job |
| Learned memory | Stable preferences, recurring facts, corrections | Saves you repeating yourself |
| Procedures and skills | How to do a repeatable job | Turns feedback into work it can repeat |
| Durable project records | Requirements, decisions, exceptions, files, task status | Makes the work recoverable and auditable |
| Live source access | Current email, calendars, project documents, accounting records | Stops stale memory from overriding what's true now |
This is a way to evaluate products. It doesn't claim every product builds the layers the same way. Grok documents role memory, skills, routines and shared files. Muse documents memory, identity, goals, files and scheduled tasks as separate things. Duet inherits memory and skills. Dots combine retained context with research in connected sources and action rules. docs.x
For engineering work, we weigh durable project records and live source access above a bot's memory for conversational details.
Learning is not retraining
When a vendor says a bot "learns your preferences," that doesn't mean it retrains its model. The documented mechanisms are keeping context, updating memory, carrying skills and saving workflows. Any of these can change future behavior without touching the model's weights. A bot can seem to have "upgraded itself" when it has really saved a better procedure or a new preference. docs.x
That's much like a person who keeps better notes. The skill hasn't changed, but the notes have.
What can't be compared
The documentation gives no common measure of memory capacity, retrieval accuracy or how reliably exceptions are kept. A table saying one product has "more memory" would mislead. We also don't say which database or retrieval method each product uses, because the documentation doesn't say. docs.x
Don't compare products on subscription alone. A more useful measure is the cost of each accepted deliverable, counting the time spent correcting and supervising the bot.
Keep a project packet
No bot's private learned memory should be the only record of a project. Ask the bot to keep an explicit project packet:
Project brief Approved requirements Decision log Exceptions and their scope Open questions Current task status Reusable procedures Source-document index
This is a way of operating that we propose. It is not a feature that products provide automatically.
Scope every exception
A good exception record reads like this:
For Project A only, permit the substitute enclosure approved on October 25. Do not apply this substitution to other projects. Record the approver and supporting document.
That is much safer than an unscoped memory such as "the owner accepts substitute enclosures." People have long kept a deviation tied to the one job it was approved for. Bots need the same rule, written down.
The 10-step test
Give each product the same small project, and test it over several sessions. Asking which one has the largest context window won't tell you much.
- Give it a project brief, requirements and a standard procedure.
- Introduce one exception that applies only to this project.
- Correct an earlier instruction and say plainly that the correction replaces it.
- Start a fresh session and ask it to continue.
- Change a source document and see whether it checks the new version.
- Ask it to show the durable record behind its answer.
- Interrupt a task and test whether it recovers.
- Give it a second project and check that the exception doesn't leak into it.
- Try a consequential action that must require approval.
- Export what it knows and see whether another system could pick up the work.
Score it on: exceptions kept, accuracy against current sources, recoverability, auditability, permission compliance and supervision time.
Fill this in yourself. We haven't run the test, so the grid is empty on purpose.
| Criterion | Grok Bot | OpenAI dots | Meta Muse | Claude Duet |
|---|---|---|---|---|
| Exceptions kept | ||||
| Accuracy against current sources | ||||
| Recoverability | ||||
| Auditability | ||||
| Permission compliance | ||||
| Supervision time |
The research wrote this test for these four products. You can add columns for OpenClaw, Perplexity Computer or any of the coding workers.
What you're looking for isn't a bot that remembers more conversation. You want a bot that turns experience into explicit procedures and trustworthy records, and that can show which record governs its next action. File-backed memory makes that possible, but it doesn't guarantee it. docs.x, code.claude, docs.openclaw, github