Memory guide
What is project memory?
Memory is the part of the project brain that remembers lessons, conventions, mistakes, and useful patterns after a task ends. It helps the next person or agent avoid relearning the same thing.
What goes in memory
Lessons learned
Things that went wrong or surprisingly well, with enough context to prevent repeat mistakes.
Conventions
Local rules the repo follows, such as naming patterns, UI preferences, test commands, or review expectations.
Warnings
Known traps, fragile integrations, and commands that look correct but have failed before.
Reusable patterns
Reliable approaches for common work, like subscription gating, sync conflict handling, or responsive layout fixes.
Why Amistio chose memory files
Chat history is useful, but it is usually private, long, and hard to review. Memory files are short, portable, and close to the code. They let a team decide which lessons are worth preserving instead of treating every conversation as equally important.
Good memory is compressed judgment. It should be brief enough that a future agent can use it, and specific enough that it changes behavior.
How memory affects future work
- Planning can include known pitfalls before implementation starts.
- Prompts can reference repo-specific conventions instead of rediscovering them.
- Reviews can check whether a repeated mistake was handled this time.
- Local runners can operate from approved lessons instead of stale assumptions.
What not to store
Do not store secrets, credentials, private tokens, provider session identifiers, raw environment details, or unnecessary personal information in memory files. Memory should help future work without turning the project brain into a sensitive data store.