I wanted Claude Code to remember, and to keep working when I walk away.

The problem

Claude Code is a great pair programmer with no memory. Every session starts cold. You re-explain the project, the decision you made last week, the mistake you already fixed. Then the session ends and it's gone again.

Letting an agent run on its own is the other half. Left alone, agents ship junk: changes nobody measured, tests that pass because they test nothing, PRs that merge on top of a broken main. Speed without checks just makes more to clean up.

The approach

• Choose the context. Memory, decisions and a shared vocabulary live outside the model. A session loads the ones the task needs, and skills load only when they're called. Memory, skills.
• Gate every change. The pipeline works in its own worktree, measures its result, and keeps it only if nothing got worse. Nothing reaches main without my Approve and a gate that re-checks it. Pipeline, merge gate.
• Measure every claim. If MARVIN says something helps, there's a bench run or a count behind it, with the method in the repo. When a measurement says I was wrong, the default changes.

What I've measured

MARVIN runs a bench against plain Claude Code on the same model, with known answers. A result only goes on this page when it holds across a set of tasks. Results from a single task, like memory recall or routing simple questions to a smaller model, stay in the bench write-up with their scope, because one task doesn't show they generalise.

I measured my own tools, and dropped one

I added a code knowledge graph and told every session to search it first. Then I tested it: 30 real questions with known answers, scored without an AI judge. Plain keyword search put the answer in the top five 67% of the time. The graph managed 38%. On questions that need two files, keyword search found 3 of 4 and the graph found none. So the rule flipped to keyword search first, and the graph kept the structure questions it's good at. Results, 26 Oct 2026.

It ships

Green is code the pipeline wrote on its own, then I reviewed and merged. Amber is work done in a session with me. Most of the pipeline's count landed in one week in early October (64 PRs). Since then most merges have come from sessions with me, a lot of it tightening the gates the pipeline has to pass.

The proof that counts most is outside this repo. Seal Speak is a live-captioning app for iPhone that I built with MARVIN. It went from first commit to the App Store in 50 days, and 19 of its merged PRs came from the pipeline.

Open engine, optional add-ons

The engine is open source and stays free: memory, skills, the pipeline, the gates, the dashboard. Each person's own state lives in their own private repo, never in the engine. Later, optional add-ons will sit on top for people who want more, each in its own repo. The rule I hold myself to: the free engine has to be good on its own. An add-on earns its place by doing something new, not by taking something away.

Where it's going

These are the north stars every change gets checked against, in plain words:

1. Do more with less. A change only counts if quality holds at the same or lower cost in tokens, compute and time.
2. Be reachable from anywhere. Phone, laptop, any machine, working offline, and never breaking silently.
3. Leave people more capable, not more passive. If doing a thing yourself makes you better at it, MARVIN should coach, not take over.
4. Be the best tool for making tools. Work that makes MARVIN better at building and shipping things beats work that builds one thing.

What's being built now and next is on the roadmap. What changed recently is in the changelog.

How each number was counted

All counted on Nov 2, 2026.

Who builds it

I'm Gil Eskayo. I build MARVIN for my own work first and use it every day. More on the about page. The code is on GitHub.