Manus Remembers Your Preferences. It Forgets What It Was Doing.

A founder sets Manus on a nightly task: draft tomorrow's investor update from today's metrics. "Use the same format as last time," she writes. The format lands perfectly, every section in the right place, the tone exactly right. Encouraged, she adds a second request: "Follow up on the three risks you flagged on Thursday." Silence, then a confident fresh take that contradicts Thursday's analysis on two of the three points.

Both requests look the same from the outside. Only one of them touches the kind of memory Manus actually has.

Two kinds of memory, one confusing product

When people ask whether Manus remembers, they usually mean one of two very different things, and Manus answers them very differently.

The first is memory of you: your formatting habits, your tone, the standing facts about your project. This memory is real. Tell Manus once that investor updates open with traction, and the next update opens with traction. Save a standing instruction and it shows up in later sessions. This is the memory Manus's materials describe, and reviewers confirm it works.

The second is memory of the work: what last Tuesday's task found, which options it already eliminated, why it made the call it made, what went wrong halfway through. This is where the floor drops out. Each Manus task executes inside its own isolated cloud VM — great for reliability, fatal for continuity. When the task ends, its working state ends with it. A new task the next day does not inherit the previous task's reasoning. It inherits your preferences and whatever you explicitly told the system to record, and nothing else.

That split explains the contradictory things you read about Manus. The "persistent memory" claims are about preferences. The "session-scoped" findings from hands-on reviewers are about task state. Both are true. The confusion comes from using one word for two systems.

Where the gap actually bites

Preference memory covers the cosmetic layer: format, tone, style. Task-state memory covers the expensive layer: judgment. Three places where operators feel the difference:

Recurring research. A weekly market scan re-gathers week one's data in week four because nothing told the new task what the old task already collected. You pay for the same digging every cycle, and worse, the conclusions drift: without the earlier reasoning on record, the agent re-litigates decisions it already made.

Lead and list refreshes. A nightly job that scores new leads re-scores the same dead ones, because "we disqualified this company last month" was a decision inside a dead task, not a recorded fact. Each run looks productive. The list never actually gets smarter.

Multi-day projects. Split a big analysis across tasks and every seam is a memory seam. Task three does not know what task two ruled out. You become the human router, carrying context between runs in your own head — the exact job you hired the agent to do.

Notice the pattern: the longer the horizon, the more the missing memory costs. One-off tasks barely notice. Anything recurring or sequential bleeds a little on every run.

Your options, honestly ranked

The handoff brief. Write a short summary at the end of each run — findings, open items, decisions — and paste it into the next run's brief. It works on day one. By month three the brief is a document, the document needs maintaining, and every run burns context window re-reading history instead of doing work.

The living notes file. Keep one running log the agent can read, with instructions to read it at the start and update it at the end of every task. Cheap, and the first thing that breaks the moment a task skips the update step. There is no enforcement mechanism except your prompt, and prompts get ignored under pressure.

Your own memory infrastructure. A database, retrieval code, retention policies — full control, and a second production system to build and babysit. Storage, embeddings, monitoring, and the slow realization that you are now maintaining infrastructure so your automation can have the continuity it should have shipped with. Justifiable for a team running agents at real scale; overkill for most operators.

One shared memory, zero infrastructure. This is what Vilix AI exists for. It is a cloud-hosted memory layer — nothing to install, run, or maintain — that your agents read and write through MCP. Every run loads the relevant context from previous runs before it starts: the full conversation history, not just extracted facts, so the reasoning survives, not only the conclusions. What the run learns gets saved back to the same store. And because it is one memory tied to your account, it follows you across tools: Manus AI is on the supported list, alongside Claude, Codex, Cursor, and the rest, so the nightly job, the planning session, and the review can all draw on the same past. Builders get the same deal with less work: a built agent connects with an API key as Bearer to the MCP endpoint and gets full memory with zero memory infrastructure on your side.

The terms are deliberately low-friction: free forever on the free plan, a 7-day Pro trial with no credit card, and your data stays yours — export everything in a portable format or delete it anytime.

The question to ask before your next recurring task

"If this run vanished tonight, what would tomorrow's run need to know?" Whatever your answer is, that is your memory spec — and right now, for Manus, the honest answer is that you are supplying it yourself, in the brief, every time. That works until the project gets big enough that the brief becomes the job. At that point, stop re-briefing the agent and give it a memory instead.

Give your agents one memory that survives every run: Vilix AI — cloud-hosted, shared across your tools over MCP, free forever.