Blog
Blog
Notes from building inkentry: what we shipped, what we deleted, and why. When something published here turns out to be wrong, it gets struck and corrected in place, not quietly edited.
inkentry 1.1: GPU everywhere
inkentry 1.0 shipped GPU embedding on Mac only. 1.1 brings it to Windows and Linux, on almost any GPU from the last decade, with a faster engine underneath.
Read the post →inkentry 1.0: one search over the code and the reason behind it
grep finds where the code is. inkentry 1.0 puts the decision that shaped it in the same result.
Read the post →More features we removed
A follow-up to the features we deleted. We shrank the model until one feature writes memory and nothing else reaches for it, folded a pile of search modes and three search commands into a single search, and deleted an exploration loop we'd built into the tool itself. Why a second round of subtraction left a smaller, more deterministic thing to hold in your head.
Read the post →spelunk is now inkentry
Same project, same people, same licence, new name. What it means if you already have spelunk installed, how to bring your memory across, and why the name changed.
Read the post →The second kind of review fatigue
Review fatigue has two shapes. One is how much you have to read. The other is how much you have to already know before you can judge any of it safely. Most of the attention goes to the first. The second is the one that decides whether a reviewer catches the change that quietly undoes a decision someone made last year.
Read the post →Common is not correct
A new hire is told the right way once, then spends a month immersed in the old one. When they finally build something solo, they build it the way the codebase taught them, and everyone treats the result as a mistake. Nobody did anything wrong. The decision that would have spared them had simply evaporated.
Read the post →The authoring tax
The person best placed to record why a change was made is the one person for whom the why is already obvious, so they skip it. Asking them to author and then defend a second record is bookkeeping piled on a workflow already buried in review. A field note on why we let the work write the record instead.
Read the post →Memory your whole team shares
When one engineer's agents remember the why, that's useful. When the whole team's agents draw from the same memory, something else happens: one person's sharper convention quietly becomes everyone's default. The final beat of the why-layer series.
Read the post →inkentry 0.9: the v1 release candidate
git tracks what changed. inkentry remembers why. 0.9 is the release candidate for v1: a stable CLI we've been running on real work, now with cloud sign-in, two-way memory sync, and a stronger local code-search model so the why-layer follows you across machines and agents.
Read the post →Memory shouldn't belong to your agent vendor
When your agent's memory lives inside one coding-agent vendor, switching agents means starting over. Why we made the memory a separate, callable layer that lives in your git history, not ours.
Read the post →The features we deleted
We cut six CLI commands, drew a hard "no LLM in the CLI" line, dropped a whole backend we'd already built, and removed sources that produced more noise than signal. Why subtracting features was the work we're most confident was right.
Read the post →Memory that travels with the repo: why we put it in git notes
Memory without provenance rots. Git history without intent is a wall of diffs. Here's why agent memory in inkentry lives inside git notes, anchored to commits, with a supersede rule so the history of a decision is never lost.
Read the post →"Why was this written?" the question agents can't answer
An AI agent can read what your code does in seconds. Ask it why the code is the way it is and the confidence doesn't change, but the ground underneath it does, because the reason was never in the code to begin with. First in a series on what we did about that gap.
Read the post →