MARVIN

Explore the map

This is MARVIN, drawn from the real system instead of by hand: every skill, job, machine and project it runs. Drag to turn it, hover any dot to see what it does in plain words, and click it to open a larger one right here. The gold lines are the real wiring: which job runs on which Mac, which jobs feed the dashboard, what the ticket pipeline builds, and which skill belongs to which project. There's a full-screen version at g-eskayo.github.io/marvin.

How a session gets its context

Most memory systems dump everything into every session. MARVIN picks. Each request runs two searches at once: a vector database (ChromaDB) finds memories that mean the same thing, and a keyword search finds the ones that use the same words. The two rankings are merged, and only the top of the list loads. If the vector store is down, a tag index takes over, so a session never starts empty.

Four kinds of memory carry over between sessions: who I am, corrections I've given, what each project is for, and where things live outside the code.

Skills, loaded on demand

A skill is a playbook Claude loads only when it’s needed: diagnosing a bug, test-driven development, researching a claim with sources, reviewing architecture, handing work off between sessions, writing in my voice. The list is generated from the skills themselves, so it can’t drift.

They’re all on the map at the top of this page, in the Skills branch. Hover one to see what it does, and the gold lines show which skills call each other.

It works while I'm away

I write a ticket and label it ready. The pipeline claims it, works in an isolated copy of the code, and splits the job: a stronger model plans, a cheaper one writes the edits. Then it runs the project's own tests and keeps the change only if nothing got worse and something got better.

A passing change becomes a pull request with its evidence attached. Nothing merges until I approve it, and the merge gate rebases onto the latest code and re-runs every test the change could affect first.

When it fails, it says why

Every failed run is logged with its cause, and the dashboard shows them by family. When the same failure hits three tickets within two hours, the pipeline pauses itself instead of burning time repeating it.

My favourite bug: for about a month the pipeline looked healthy while its measurements were blind. Five separate defects, from a file-descriptor limit to a # in a folder name, meant it couldn't see test results at all. I found and fixed all five in October 2026, each one pinned by a test so it can't come back.

The dashboard

I built a desktop app to steer all of this. Six tabs, one job each.

Real screenshots, taken in October 2026. Private project names and credential details are blurred.

Three machines, one system

The heavy automation runs on a Mac mini; I work on a MacBook. In October I added a third node: a 2012 Mac mini running Linux that takes test runs, benchmarks and security scans, with its own scheduled jobs. Code syncs over Tailscale, and health checks watch every machine, including telling a laptop that's simply asleep (a quiet moon) apart from one that's broken.

Proving it works

MARVIN has a bench: the same tasks run under three configurations (a clean baseline, a lean one and the full stack) and scored on cost and correctness, so a claim that something is better has a number before it has an argument. From twelve runs in July:

The bench also changes how MARVIN works. In October I scored two ways of answering questions about a codebase on 30 real questions with known answers: plain text search put the answer in the top five 67% of the time, a knowledge-graph tool 38%, and on questions that need several hops it was 3 of 4 against 0 of 4. So MARVIN's agents now search first and use the graph only for structure questions. The repository's scorecard lists the setbacks as well as the gains.

Built with MARVIN

MARVIN isn't a demo. It builds and runs my other projects:

• Resume Tailor: a MARVIN skill that tailors one master resume to each job posting.
• Paper Dive: a MARVIN skill for reading research papers and mapping a whole field's citations. It built the bibliography for a research paper.
• Seal Speak: the live-captioning app I built for my mom, now a paid app on the App Store. MARVIN's pipeline wrote 19 of its 114 merged pull requests.
• This website: MARVIN's portfolio tools build the pages, generate the project images and check every page for broken layouts, links and media before I publish.

Status

In daily use since May 2026, now on three machines: two Apple Silicon Macs and a Linux box. The tests and background jobs run on Linux as well as macOS, and the CI runs on Linux; the dashboard runs on macOS only so far, and WSL2 is untested. Everything is in the open: the roadmap, including what's deliberately not built yet, and a written record for every design decision.

Released shipped and in use Built, in testing built, not released yet Planned decided, not built yet

• ReleasedMemory, skills, the ticket pipeline, the failure breaker, the dashboard and the bench. Everything above this list.
• ReleasedThe Linux node. Test runs, benchmarks and security scans, with its own scheduled jobs.
• Built, in testingTicket builds on the Linux node. The Mini hands Linux-safe tickets to a fresh virtual machine on the 2012 Mac mini, one per ticket.
• Built, in testingAccounts in Vitals. A live check, an expiry warning and a renewal path for every credential MARVIN uses.
• PlannedFailure containment, round two. One alert path to my phone that still works when Claude, the Mini or the network is what broke, and guards that say so when they can't read their input.
• PlannedMARVIN Mobile. An iPhone app that talks to MARVIN over my private network. The design decisions are written; the app isn't built.