Code remembers what. Who remembers why?

The missing layer

A repository can tell an AI agent a great deal. It can show the implementation, the tests, and the history of changes. But the reason a team rejected an approach may be much harder to find. The surviving code is only one part of the engineering record.

That gap is the idea behind Hunch. I built it to give coding agents access to a team’s decision history: what was chosen, what was rejected, which failures mattered, and what needs to remain true as the code changes.

Memory that travels with the work

Hunch keeps engineering memory in Git and exposes it through a CLI and an MCP server. The intention is practical: make the relevant record available where the work is happening, with sources that can be inspected.

A decision has more value when it is connected to the code it explains. A rejected alternative has more value when an agent can find it before proposing the same change again. A bug history has more value when it helps someone understand which assumption failed.

I want a new session to begin with useful context, rather than another long explanation of the project. That does not mean loading every recorded fact into every prompt. It means finding the small part of the record that matters to the task.

A record is not a substitute for judgment

Recorded context can be stale, incomplete, or simply irrelevant to the next decision. Treating every note as an unquestionable rule would create a different problem. Hunch is advisory by default; blocking behavior requires explicitly trusted rules and enforcement.

The distinction matters to me. Delivering a useful memory is not the same as proving that the agent applied it. Running a check is not the same as proving every part of a change is correct. The tool needs to keep those claims separate.

The assistant still has to inspect the code, make a decision, and verify the result. Memory should make that work better informed. It should not become a reason to stop thinking.

Building it with other people

Hunch started as a solo project and grew to include outside contributors. I review their code and help shape the roadmap with them. That is an important part of the project for me: an engineering tool has to remain understandable to people who were not there when its first assumptions were made.

My contributions to adrkit sit close to the same interest. Stale-decision warnings, consistent machine-readable output, and reliable cross-platform behavior all help turn architectural intent into something tools and people can actually use.

The question I keep coming back to

How do we make the next person, or the next agent, better informed without making them carry the entire history of the project?

Hunch is my ongoing work on that question. The useful result is not a larger pile of notes. It is a better next decision, with enough evidence to understand how we got there.