Three AI models, one 36-second video

The animation

The idea was "100 agents, one repo brain", built on how Salvor actually works. Sessions from Claude Code, Codex and Gemini CLI enter through their own entry files (CLAUDE.md, AGENTS.md, GEMINI.md) and read the same .salvor/ folder in the repository. A session reads the short current state first and opens the long archive only when needed. A known failure (LF:) stops a retry. New knowledge waits for a human "yes" and reaches the repository through a reviewed pull request.

Codex designed it as an inline SVG with CSS animation. The first version passed its own checks but broke in a real browser: the 100 dots were <use> references to symbols without a size, and Chromium painted them as giant colour blobs over the page. Codex's sandbox cannot start a browser, so it never saw this. Claude found it in a screenshot, replaced the dots with plain shapes and redrew the wiring so no line crosses a label. The second version, by Codex again, split the sessions into three labelled groups and moved the brain into a GitHub repo card.

Sound without ears

The video needed sound that matches the picture exactly. The animation is a fixed 18-second CSS loop, so every event has a known time: packets leave at 0.72 s, a failure is blocked at 6.30 s, the merge lands at 14.94 s. Claude read these times out of the keyframes and wrote them into a timeline that all three models shared.

None of the three models can hear audio. So each round followed the same pattern: generate, then measure, then let a human listen. The measurements were plain numbers from the WAV file:

• when each sound starts, compared with the timeline
• whether a sound comes from the left (where the agents are) or the right (where the repository is)
• how the energy is spread across low, middle and high frequencies
• loudness, peak level and how much the volume moves over the track

Measurements catch timing and balance mistakes. They do not say whether something sounds good. That part stayed with me.

How the rounds went

• Sound effects, round 1 (Claude). Synthesised ticks and chimes on every event. Timing was right, but my verdict was that entries and exits were hard to tell apart.
• Round 2 (Grok spec, Codex code). Grok wrote a sound-design spec. Codex built it with a different sound for "leaving" (left side) and "arriving" (right side), and a quiet air sound that pans with each packet. This one worked.
• Background music, three tries. An electronic bed was irritating. A soft piano version did not convince me. A chamber piece with guitar and cello turned out muffled: the analysis showed almost nothing above 6 kHz.
• Codex composing on its own. A brighter, catchy track. Good energy, but not the mood I wanted.
• Film style. This is where the tone finally felt right, but something was missing.

The discussion round

For the last step, the three models discussed the film piece. Claude measured it and found four concrete problems. The sound had no top end: almost all energy sat between 150 Hz and 1 kHz. The build-up section was quieter than the intro. Only two of eleven picture moments were audible. And the theme was an arpeggio rather than a melody. Grok gave a critique as an orchestrator, with numbers for every fix. Codex answered each point, agreed or disagreed, then wrote version 2.

Version 2 kept the tone I liked and fixed what the numbers pointed at. It is the one I kept.

What Salvor added

This work ran inside projects that keep their memory with Salvor, and that showed in a few concrete places:

• The session survived a context reset. Partway through, the conversation was compacted. The next session opened each project's short state file (active_state.md) first and knew which version was live, how deploys work and what was still open, without me explaining it again.
• A stale state was caught. At session start, a freshness check compared the memory with the live site and reported that the memory still named an older live version. It was corrected before anything was built on it.
• Owner rules were followed without reminders. The rules live in the repository's DOMAIN_REF.md: no project names except Salvor, every illustration in the same animated line style, every article gets its own cover in the series style. This article got its cover because that rule is written there, not because anyone asked in the moment.
• Codex started from the same memory. Each brief pointed Codex to the same state and rule files, so it worked within the same constraints as Claude: local only, no commit, no deploy.

I had no problems with Salvor during this whole session. Salvor's job is to keep what a project has learned and hand it to every new session, and it did that smoothly from start to finish. Checking how a newly generated drawing looks in a browser, or how a piece of music sounds, is not its job; the browser and I did that part. The SVG lesson from this session is now written into the next brief. Once I approve it, it also goes into the project's learned-failure list, so later sessions will remember it too.

What I took from it

• A model that cannot see or hear the result needs someone who can. The SVG bug and every music verdict came from a browser and a human, not from the model's own checks.
• Give all models the same facts. The shared timeline taken from the real keyframes is why the sound lines up with the picture in every version.
• Turn a feeling into numbers before asking for a fix. "Something is missing" became "no energy above 1 kHz, no build-up, 2 of 11 moments audible". Only then did the revision work.
• Let them disagree. Asking Codex to answer each point from Claude and Grok, instead of just applying them, produced a better plan than either list alone.

All audio is synthesised from scratch in Python, with no samples and no imitation of existing songs. The live animation is on the Salvor page.