inkentry 1.0: one search over the code and the reason behind it

grep finds the line that sets the retry to 800ms. It can't find the argument that landed on it. That argument was never a line of code: it was made in a thread months ago, weighed against two alternatives, and settled by someone who has since moved teams. The number in the file is what the decision produced. The reasoning that produced it is nowhere grep can reach.

That gap is the most expensive recurring work in software. Every time an engineer, or an agent acting for one, re-derives intent that someone already worked out, the team pays for the same thinking twice. Worse, an agent that cannot see the decision will confidently undo it, because from the code alone the decision is invisible.

inkentry 1.0 out today. It is a CLI that runs on your machine, MIT-licensed, and free.

One search, both layers

Ask where the retry logic lives. inkentry returns the function, and directly beneath it, the decision that set the timeout, interleaved into one ranked list. Code chunks and memory entries are fused by rank position (reciprocal rank fusion), so the most relevant answer wins whether it is a definition or a decision. There is one search command and it returns the most relevant result, no matter the source.

Three actions

Day to day, with inkentry there are three actions you'll run: context, search, memory. Catch up on the state of the project, ask a question of the code and the decisions behind it, record a decision as you make it.

Not another AI tool

Semantic search, code graph, memory, context: all of it is deterministic and runs without a model, an api key or a network connection. Summaries are composed structurally and come out byte-identical on every run. Same query, same answer.

One feature keeps a large language model: harvest. Harvest is for catching up on the history from before you installed inkentry. Reading years of git history and session logs to recover the decisions buried in them genuinely needs a model, and harvest writes durable memory rather than producing a throwaway answer. Point harvest at your git history on day one and past commit messages become a queryable decision log. After that, a post-commit hook keeps capturing as you work, so the record stays current the same way the code does: by you doing the work you were already doing.

Memory that travels with the repository

inkentry keeps decisions in git notes, so the reasoning sits in the same place as the code. The memory lives in your git history, as json any tool can read. A teammate who pulls the code pulls the decisions behind it.

A decision is not overwritten when it changes. Superseding strikes the old line and writes the new one beneath it, and both stay legible, so you can read what the team believes now and what it used to believe, and ask the log --as-of any past date. This is captured intent: the decision as the person stated it, kept as a fact in its own right. It is a different thing from a reason guessed after the fact from commit archaeology.

If you already have a store, inkentry import reads a portable dump into a fresh store. It verifies the whole dump before it writes anything, so an import either lands complete or does not land, and what it imports is appended to git notes so it travels onward with the repo.

Minute one

inkentry init. In about a minute the repository is searchable over full text, and semantic ranking builds in the background, starting with the most-central code, so the results get sharper while you work. Nothing about setup is a wall to climb.

curl -fsSL https://get.inkentry.com/install.sh | sh

Homebrew (mac and linux): brew install inkentries/inkentry/inkentry. Scoop (Windows): scoop bucket add inkentry https://github.com/inkentries/scoop-inkentry. The source is at github.com/inkentries/inkentry.

What inkentry is not

It is not an agent, and it does not review your pull requests or supervise anyone. It does not run inference on our infrastructure. It does not hold your codebase: your code stays on your machine unless you explicitly point inkentry at a team server you run. It hands you or your agent the context when grep isn't enough, and the reasoning stays yours.

inkentry is your project's memory: the decisions behind your code, kept in context and handed back when they matter. Deterministic and open source, runs on your machine, for people and the agents working alongside them.