Engram and Waypoints: agent-enhanced development, in public
We kept describing a memory system where an agent's knowledge follows the code, branch by branch, like schema migrations. So we built it in the open, had three different kinds of AI agents check each other's work, and published everything you need to run it yourself.
Our whole thesis is that experiencing beats believing — we'd rather hand you a working thing than a deck about the thing. That has to apply to our own process too. So instead of writing another essay about Agent-Enhanced Development, we built two open-source projects that demonstrate it, in public, and this post is the tour.
The repos: engram, a memory system for coding agents, and waypoints, a small app that exists to show what happens when our whole toolchain is used in conjunction.
The reviewer who wasn't in the room
Here's the problem that started it. Picture a team of five developers, all working with coding agents. A bug fix comes in against a ticket — but a long-running project from a couple of months back, whose code is long since merged, has an impact on that change. The person fixing the bug wasn't part of the original decision-making. How does their agent find out why the code is the way it is?
Most agent-memory approaches answer with an append-only journal: every note, visible to everyone, forever. That solves recall and creates a new problem — context that doesn't belong to the branch you're on, piling up without end.
Engram: memory that behaves like schema
Engram treats agent memories the way Rails treats database schema: as migrations that live in the repository. A memory is a small markdown file committed under .agents/memories/, so the decision-making travels with the work it describes. Because memories ride the commit history, they're branch-scoped for free:
- A reviewer can switch to a feature branch and their agent's memory comes up to what's supposed to be happening on that branch — then switch away, and it's as if that agent never knew anything about it.
- When the work lands in the main trunk, the memories get ported along with it, like any other file.
- Two branches carrying contradictory decisions collide at merge time — in the memory files, right when a team most wants to discover that two features disagree about the world. Merge conflicts become decision conflicts.
The tooling friction had to round to zero, so the whole system is one static binary: a SQLite cache that syncs automatically on branch changes via git hooks, full-text search with recency ranking, optional semantic search through any OpenAI-compatible embeddings endpoint (a local Ollama works fine), and a built-in MCP server so any agent — Claude, Codex, whatever comes next — can search and record memories as tools. No database server, no required cloud anything.
brew install crimson-knight/tap/engramEngram dogfoods itself: its own repo carries engram memories recording why it's built the way it is, and it ships its agent-facing docs in the repo so your agent knows how to use it the moment you clone it.
Waypoints: everything used in conjunction
A memory system is hard to evaluate in the abstract, so waypoints is the demonstration: a deliberately small bookmarks CLI built with the full AED toolchain at once — engram for branch-scoped memory, our Shards fork's AI-documentation distribution (a library ships its agent docs and skills, and shards install places them into the consuming project, checksummed), and llamero running a real local model on-device for the semantic features.
The part I'd point a skeptic at: waypoints has an unmerged branch, feature/semantic-notes, left unmerged on purpose. Check it out and run the sync, and your agent holds the author's context for that work — including a memory that supersedes an earlier decision. Switch back to main and that knowledge is gone. That's the reviewer story from the top of this post, running on your machine.
The build was also the demonstration
How the repos got built matters as much as what they do, because the question we're actually testing is whether these workflows hold up across multiple agent types — not just one vendor's model reviewing its own homework.
Engram was built by a team of Claude Sonnet agents working from a written spec, gated by a Claude Opus reviewer that took three rounds to pass it, and then handed to OpenAI's Codex with instructions to attack it. Codex found a genuine blocker the Opus gate had missed: two agents recording memories in the same second could silently overwrite each other. Every spec had passed — because no spec modeled two writers. The finding was triaged, fixed, and the fix adversarially re-verified (twelve concurrent writers, corrupted-cache recovery, hostile file paths) before we shipped. For waypoints we inverted the roles: Codex built, Claude completed and gated.
The lesson we keep re-learning: cross-agent review is not redundancy, it's coverage. Different agent types caught different classes of defect, and neither reviewer subsumed the other. That's now a standing part of how we work.
Run it
Everything is public and reproducible — each repo documents the exact environment it was verified against, so you can tell quickly whether a difference on your machine is your setup or our gap.
brew install crimson-knight/tap/engram
git clone https://github.com/crimson-knight/waypointsIf you try it and something doesn't hold up, open an issue — that's the point of doing this in public. And if you want the deeper background on the process itself, start with Agent-Enhanced Development.