routine and recall

Two unglamorous pieces of infrastructure a solo operator running many agents actually needs — a workflow that doesn't skip steps, and a memory that doesn't quietly accumulate contradictions.

Neither of these is exciting on its own. A pile of shell hooks and slash commands. A Go binary that stores facts in SQLite. But most of what makes an agent look competent over months isn't the model — it's whether the same review gets done the same way every time, and whether what it remembers about you stays true instead of just accumulating.

personal multi-agent stack — triage, review, reporting

The honest way to describe this is a chief-of-staff and a PR reviewer, each backed by a persistent wiki instead of a fresh context every session, plus the hooks that keep both of them from skipping the parts that matter. It's been running daily against real work for months, then sanitized for sharing — org names, IDs, and internal references swapped for grep-able placeholders rather than pretending it was built generic from day one.

The design choice worth stealing is where enforcement lives. A rule in a system prompt is a request; a PreToolUse hook that blocks a non-compliant branch name or an undrafted PR is a control the agent can't reason its way around, the same distinction that runs through everything in this space. Outbound actions — sending a message, merging, publishing — stay human-gated by the same logic: a draft is cheap to review, a sent message is not.

The review pipeline prefers a second model family for adversarial review — different training, different blind spots. When that's not reachable, a same-family reviewer runs instead, as a fresh, unprimed pass rather than nothing. It self-labels cross_vendor: false in its own output, every time, so a same-vendor fallback is never quietly presented as the real thing it's standing in for.

The other principle that shows up everywhere once you look for it: expensive judgment stays on the capable model, cheap mechanics move to a fast one. A fetcher pulling raw PR data doesn't need the same model synthesizing severity across a whole review — that split alone is most of what keeps a daily-driver agent stack affordable to actually run daily.

self-hostable memory layer with conflict resolution built in

The one-sentence pitch explains the whole design: similarity is not truth. Ask a vector store what it knows about someone's job and 'I love my job' from three weeks ago and 'I quit' from yesterday both come back — they're topically similar, so a naive agent synthesizes both into an answer that's wrong the moment it's assembled. memkit's job is to notice the second fact contradicts the first and supersede it, not file it alongside.

For example: 'User works at Google' becomes superseded once 'User works at OpenAI' is observed. The superseded fact isn't deleted — it's archived, still inspectable as history, just excluded from what search returns as current.

Under the hood that's a cheap token-overlap heuristic doing the classification (add / update / duplicate) for the clear cases, with a small model consulted only for the genuinely ambiguous ones — 'I love my job' versus 'I hate my job' shares almost no overlapping tokens, exactly where a lexical heuristic goes blind and a few hundred tokens of real judgment earns its cost. The system prompt for that resolver is cached, and any API failure falls back to the heuristic rather than blocking the write — a memory layer that goes down because a model provider hiccupped would defeat the point of it.

Compared to a typical hosted alternative, memkit is a single Go binary rather than a Python service plus cloud account; conflict resolution is built in, not bolted on; and data never leaves your machine by default.

The conflict engine itself, conflict-lens, is factored out as its own dependency-free module rather than living inside memkit's binary — the same instinct as extracting a shared validation helper instead of importing a private one across files: one tested implementation, reusable wherever the same problem shows up again.

memkit's published roadmap listed some of this as upcoming — three of six items are already shipped in the same README that lists them as future work. Below is what's true now, not what the doc says.

Shipped — Conflict resolution: heuristic + optional small-model resolver, prompt-cached, fail-open to the heuristic. Listed as roadmap, already built.

Shipped — Consolidation cron: background loop prunes superseded facts past a configurable retention window. Also listed as roadmap, also already built.

Shipped — conflict-lens extracted: already its own standalone repository, not bundled inside memkit's binary.

Open — Postgres backend: SQLite only today — fine for one operator, a real constraint past a single-writer deployment.

Open — Embedding-backed recall: search is lexical + time-decay today, not semantic. Genuinely open, not just undocumented.

Small thing worth fixing, not a design flaw: both projects' own READMEs still point at their old GitHub location from before this move — a stale link, not a stale idea.