What Slowave remembers

What gets saved, how memories stay organized by project, and how Slowave keeps the useful ones and lets old ones go.

What gets saved

Slowave keeps things that will help in a future task. It does not keep a transcript of everything.

Decisions

“We chose Postgres over MySQL because of JSON support.”

Rules and constraints

“Never call the billing service from tests.”

Preferences

“Use small commits with clear messages.”

Lessons

“The build fails if you skip the codegen step.”

Procedures are a separate, key feature

Besides these facts, your agent saves methods that worked, such as the steps for adding a new endpoint. Learn how procedures work.

Memories are organized by project

Each memory belongs to a scope, usually one project. When you work in a project, your agent sees that project’s memories, not those from unrelated work.

Memories change over time

Specific experiences become lasting lessons. Useful ones grow stronger and old ones fade.

1. Helpful memories grow stronger

   When your agent reports that a memory helped, it is more likely to appear again.

2. Unused memories fade

   Memories that never help slowly drop down the list.

3. Outdated memories are replaced

   When your agent saves a newer decision and reports the older one as stale, the old memory is marked as replaced.

You can see all of this in the dashboard. Nothing happens out of sight.

What Slowave does not do

It does not read your whole codebase

Your agent already does that. Slowave stores the reasons behind the code, not the code itself.

It does not guess

Slowave saves what your agent chooses to save. Quality depends on your agent giving honest feedback.

Next: where your data lives

Everything stays on your computer.