Only what's relevant
The assistant gets what this task touches, not a dump of the whole project.
Case study Engram
Giving coding
assistants a memory.
An engram is the trace a memory leaves behind. This one holds a project's decisions, lessons and reasoning, and hands an assistant only the part that matters right now — so the next session doesn't start from nothing.
01 / The problem
Everything the last session forgot.
AI assistants got very good at writing code and stayed hopeless at remembering why. Every session starts from zero. The reasoning behind last week's fix lives in a chat log nobody can search, and the developer re-explains the same project every single morning.
- Explaining it all again
- Drifting off task
- Code nobody understands
- Nothing shared between repos
- Decisions gone missing
- Onboarding from scratch
Six things a developer loses between Friday and Monday.
Outlasts the session
Plans, decisions and lessons are kept as you work. Pick it up days later in full context.
Shared by the team
One store every developer writes to and reads from, so knowledge compounds instead of scattering.
02 / The test
Same bug, two approaches.
The question the study set out to answer: does a real memory actually reduce the work, or does it just move it around? So I ran the same task both ways — assembling the assistant's context by hand, then letting it be retrieved. These are measurements from the prototype on my own projects, not a benchmark.
Same bug, two approaches
By hand
You assemble the context yourself
0words of context
- bug history pasted from chat
- three whole files, just in case
- "remember when we…" from memory
- an old decision doc, possibly stale
- the previous fix, half-recalled
- raw test output
Easy to miss the edge case buried in an earlier fix.
With Engram
You describe the task in a line
0words of context
engram start "fix the checkout race condition"engram find "payment retries"
Comes back with
the exact file and lines that handle itthe lesson: retries must not double-chargethe decision, and why it was made that way
The relevant lesson, the earlier plan, the risky areas and the code that matters — gathered automatically, ready to work with.
Roughly half the context, and far less typing. The more useful result was the second-order one: what the assistant is given stops depending on what the developer happened to remember that morning.
Understanding, checked at three moments
Speed is only worth having if somebody still understands the result. The study built the checks into the workflow rather than leaving them to good intentions — cheap on routine changes, thorough where the risk is real.
-
01
When code first arrives
The assistant reads the project and records what looks fragile, unowned or far-reaching. That map is stored once, so everyone who comes later inherits it instead of discovering it by breaking something.
-
02
When work begins
Each task gets guidance scaled to how risky the change actually is. Small changes stay light; anything touching a sensitive area gets the full brief.
-
03
When work is done
The finished change is reviewed against what was actually understood about it, and the verdict can't be waved through if it touched something critical.
03 / Learning
The store curates itself.
A memory that only grows becomes a junk drawer. The interesting part of the study was making it prune itself: what keeps proving useful surfaces more often, what doesn't quietly sinks, and nobody has to maintain it by hand.
-
01
Retrieve
A task pulls in the notes and code it needs, and what was used is recorded.
-
02
Observe
When the work finishes, the review says whether it actually went well.
-
03
Credit
That verdict is traced back to the specific notes that were used.
-
04
Rank
Next time, the notes that helped come back first. The loop closes.
Deliberately conservative: one bad run can't bury a good note, and anything a person has explicitly confirmed is protected from being demoted at all.
04 / How it works
Many assistants, one memory.
Teams don't all use the same tools, and the tools change every few months. So the memory sits outside them: every assistant reads and writes the same store, which means switching tools costs nothing and nobody's knowledge is trapped in a vendor.
- Claude Code
- Cursor
- Codex CLI
- Copilot
- Windsurf
- and others
Assistants
People and AI, treated the same
Both ask the same questions and get the same answers back.
The store
One project's knowledge, one place
- the code itself
- decisions and why
- lessons learned
- reviews and risks
- rules and constraints
- plans in progress
Searching three ways at once — by meaning, by wording, and by exact name — then merging the results. An answer arrives as a precise pointer, so the assistant opens the right file at the right lines instead of guessing.
For the technically curious
- Splitting
- Code is split along its real structure — functions and classes, not arbitrary blocks — so a retrieved fragment is always something whole. Prose splits on its headings.
- Two vocabularies
- Code and prose are indexed by separate models, because the phrasing that finds a design document is not the phrasing that finds a function.
- Search
- Meaning-based search, keyword search and exact-symbol lookup run together and their rankings are merged. Searching for a bare function name skips straight to the exact match.
- Across repositories
- Work spanning several repositories is linked as one effort, so related changes surface deliberately — with no accidental bleed between unrelated projects.
- Where it lives
- Runs against your own database, self-hosted or managed. The knowledge stays somewhere you control.
05 / What's next
From study to product.
The study answered its question: a project memory changes how a team works with AI, and the effect grows with the size of the codebase. The next step is making it something a team can switch on rather than build — a hosted version, in preparation now.
If your team is shipping fast with AI and losing the reasoning behind it, I'd like to hear how. Early conversations shape what gets built first.