Architecture
Project memory
Memory is the differentiator. The goal is not to store every transcript, but to preserve useful knowledge in a compact, reviewed, reusable form.
What it captures
Memory entries are typed by kind so they stay organized and retrievable:
- Codebase facts — stable facts about files, modules, and ownership;
- Architecture decisions — decisions, rationale, and tradeoffs;
- Workflows — setup, test, deploy, rollback, and debugging procedures;
- Team conventions — style, naming, and review preferences;
- Task outcomes and a domain glossary for product language.
The lifecycle
Memory moves through a deliberate lifecycle. Review is the important step: unreviewed memory becomes noise quickly.
- Extract — a run proposes candidates from useful work;
- Review — a human approves, edits, scopes, or rejects each candidate;
- Store — approved memory is saved to the project;
- Retrieve — future runs load relevant approved memory;
- Refine — stale or low-value memory is edited, merged, or archived.
A candidate is only ever a proposal. The model never sees a candidate on a later run, only entries you have explicitly approved.
Keeping memory trustworthy
Several deterministic signals help review stay efficient and keep the store clean:
- Duplicate detection rejects exact duplicates and scores near-duplicates against existing active memory;
- Stale detection flags approved memory that newer entries appear to supersede;
- Quality scoring gives an advisory score and findings for content that is too short, too long, or vague;
- Sensitivity scopes mark entries normal or sensitive, and retrieval returns normal-only by default.
Every change to an entry is recorded in an audit history you can inspect with memory audit, and an edit can be rolled back with memory restore.