Skip to main content
Every Vibely session has a finite context window. As it fills up, older messages get compacted — summarised and dropped to make room for new turns. Memory is what survives compaction. Anything you want the agent to remember forever in this project belongs in memory. Anything for this turn belongs in the chat. TL;DR
  • Memory lives at .mana/memory.md and is re-read on every turn — so it costs tokens. Pin decisions, not debug notes.
  • Project-scoped. For facts about you across all projects, use custom instructions instead.
  • You can write it, the agent can write it. Ask it to “show me memory” or “clear memory” any time.

How memory works

Memory lives at .mana/memory.md inside your project. Its contents are read back at the top of every compacted block — so it’s always in the agent’s context, on every turn. That means two things:
  1. It’s reliable. The agent never “forgets” what’s in memory.
  2. It costs tokens on every turn. Don’t dump junk in.

What to put in memory

The test: would I want the agent to know this forever in this project? Product decisions worth pinning:
“Save to memory: this is a B2B app for finance teams. Never use playful copy or emoji.”
Design decisions worth pinning:
“Save to memory: primary colour #0ea5e9, secondary #0f172a, font Inter. Don’t deviate.”
Invariants you keep correcting:
“Save to memory: all forms use react-hook-form. Never roll controlled components by hand.”
Domain context that’s load-bearing:
“Save to memory: a ‘deal’ has stages Open → Qualified → Won → Lost. ‘Qualified’ includes a customer-segment field that defaults to SMB.”

What NOT to put in memory

  • Current task state. That’s what the active chat is for.
  • Debug findings. Fix the code; don’t memorialise the bug.
  • Lists of file paths. Vibely can read the project on demand.
  • Things true across every project. Those belong in custom instructions, not project memory.
  • Anything ephemeral. “Working on the dashboard today” — gone tomorrow.

Reading and editing memory

Memory is a regular file. Ask the agent to show, edit, or clear it:
  • “Show me memory.” — prints the current contents.
  • “Remove the line about react-hook-form from memory.” — surgical edit.
  • “Clear memory.” — wipe it. Use sparingly.
You can also edit .mana/memory.md by hand from the file tree. It’s plain markdown — no special format required.

Memory vs. custom instructions

The distinction matters because both ship to the model on every turn, but the scope is different.
ScopeCustom instructionsMemory
WhereYour accountPer project (.mana/memory.md)
Who edits itYouYou or the agent
Travels with project?No — stays on your accountYes — committed with your code
Shared with team?NoYes — anyone in the project sees it
Best forFacts about you (stack, tone, name)Facts about this project
If you find yourself pasting the same thing into memory across many projects, promote it to custom instructions and stop repeating yourself.

Memory doesn’t cross sessions automatically

Memory belongs to one project’s sandbox. It doesn’t carry into:
  • A different project (each project has its own memory file)
  • A fresh chat in the same project (memory persists; chat history compacts)
  • A project you forked or cloned (the fork starts with empty memory unless you copy the file)
To carry knowledge across projects, write it once in custom instructions instead.

Next

Custom instructions

Facts about you, applied to every project automatically.

Prompting

Prompt shapes that work across long sessions.

Iterating

Stay productive over hundreds of turns.

Project settings

Memory, GitHub sync, and other per-project controls.