Built the execution layer and the memory layer that keep my coding agents honest.

What changed

Split the job into two tools: RepoKernel gives every task an isolated worktree, an atomic claim, and a gated merge; engram gives every agent one local memory with consent built into the write path.

Why it matters

Together they cover the failure modes that actually bite when agents do real work. RepoKernel is a real state machine (task, sprint, epic; queue, lane; review, gate), with a Git merge driver that resolves concurrent state edits deterministically and atomic per-sprint claims that stop two dispatch loops from grabbing the same work. engram draws the trust boundary through memory itself: ten fact kinds, four that auto-save, six that never write without my approval. I run my own multi-agent sprints on this stack, and every failure mode it handles is one I hit first.

Readouts

RepoKernel current release, published on npm

v1.33.x

the whole task lifecycle, CLI-only state writes

7 verbs

of sensitive memory that never auto-write in engram

6 kinds

Highlights

• Defined a small vocabulary (task to sprint to epic, queue to lane, review to gate) and a seven-verb lifecycle so an agent reads and writes state through the CLI instead of inferring it from markdown tables. A bundled hook intercepts any tool call that targets state files directly and denies it, routing the agent back through the CLI verbs.
• Every task runs in its own Git worktree, with the file paths it owns declared in its sprint and anything committed outside them held at the review gate. Parallel agents never collide on files, branches, or commits, and main stays clean until something actually merges.
• Wrote a custom Git merge driver that unions the state registry by id instead of leaving JSON conflict markers: merging a then b produces the same result as merging b then a, and the more-progressed status wins. The guarantee only holds for merges run locally on a clone with the driver installed; GitHub's and GitLab's web merge buttons don't execute it, so I still run validation in CI to catch anything a hosted merge might let drift.
• Gated concurrent dispatch with an atomic per-sprint claim, a lock file per sprint id, so two dispatch loops can never both pick up the same sprint. That, plus the merge driver, are the two fixes for the failure modes I actually hit running agents in parallel.
• Nothing reaches main without a recorded human review verdict and a passing check command. A failed check leaves the sprint active, not merged, so I retry it or discard it on purpose instead of it landing half-done.
• Added tracker and PR bridges (Linear, Jira, GitHub Issues, GitHub PRs) as explicit, adapter-gated writes, not silent auto-sync: pulling a ticket into an epic never writes back, and every comment or transition is a command I run on purpose.
• Built engram as the memory half: plain Markdown facts in one local folder I can read, diff, and delete, served over MCP so Claude Code, Codex, opencode, or any MCP client reads and writes the same store.
• Split memory into ten fact kinds and put consent in the write path: preference, tooling, project, and infra facts save automatically, while identity, fiscal, people, constraint, location, and health facts wait in a review queue until I explicitly approve them.
• Added transcript harvesting that mines past agent sessions for facts through a local model endpoint (LM Studio, Ollama, or any OpenAI-compatible server), so transcript content never leaves the machine.

Outcomes

• RepoKernel is open source under MIT, published on npm as repokernel, currently at v1.33.x. engram is MIT on GitHub, a Python MCP server.
• The state model holds up under real parallel dispatch: worktrees, atomic claims, and a merge-safe registry that survives concurrent branches without me hand-editing JSON.
• Every agent I use starts warm: preferences, project context, and infrastructure facts are known once and recalled everywhere, and I know exactly what is written down about me, because I approved it.
• Both are personal tools in daily use. I do not claim a user base for either.
• RepoKernel is deliberately narrow. For a one-off script, a throwaway prototype, a non-Git workflow, or a team that already gates on CI and branch protection, it is overhead you don't need, and the README says so.
• Schema and CLI are still evolving between releases, so anyone embedding RepoKernel in CI should pin a version instead of tracking latest.

Stack

• TypeScript
• Node.js
• Git worktrees
• Commander.js
• Zod
• Vitest
• GitHub Actions
• npm
• Python
• FastMCP
• MCP