All use cases

Memory by use case

AI memory for coding assistants

Project conventions learned once, applied in every session.

Why memory matters here

A coding assistant that starts from nothing each morning asks which package manager you use, proposes a library you removed last month and formats code the way you corrected yesterday. Most of what it needs is small and stable: conventions, decisions and the reasons behind them.

Who a memory belongs to

One memory per repository for conventions and decisions, and one per developer for personal preferences.

The moment it shows

It writes the test in the style the team uses and runs the right command without being told.

What to remember

  • Build, test and lint commands that work in this repository.
  • Decisions and their reasons: "we left library X because of Y".
  • Corrections the developer has made more than once.

What to forget

  • Facts the code already states. Read the file; do not store a copy that goes stale.
  • Secrets and tokens seen in the terminal or in environment files.
  • Notes about a branch that has been merged or deleted.

See recall before you build it

Add a few facts from your own use case and ask a question.

Coding assistants: common questions

Why not just put everything in a project instructions file?

A hand-written instructions file is a good form of memory and works well for stable rules. Agent memory adds the things nobody thinks to write down, such as a correction made in passing during a session.

How does a coding assistant avoid stale memories?

Store the reason and the date with each memory, prefer the code when the two disagree, and delete a memory as soon as it is found to be wrong.

Other use cases

Pack the doko. Ask it anything.

Nine memories, one question, no account. See which facts an agent would carry into its next answer.