Salvor v1.0.0-beta: I got tired of my projects forgetting what they learned

About a year into building an HFT tool with AI agents, I typed one command that deleted three days of work. Not the code. The code was fine, committed, all of it. What I deleted was the understanding. We had been deep in quantitative analysis on engine configuration runs for three days straight (honestly probably longer, but I'll say three to be conservative). Alpha signals, correlative signals, win-rate patterns. This is not my domain of expertise, which was exactly why the sessions were so valuable: I effectively had a PhD-level quant working alongside me who had personally derived every conclusion we were operating on, and who knew which of the fifty things we'd tried were dead ends and why.

Then Claude Code showed me that helpful little hint. Save ~900,000 tokens of context by using /clear.

I did it. I assumed the important stuff would still be accessible somehow, maybe not perfectly, but somehow.

It wasn't. The next message I sent went to what I can only describe as a bright college CS intern. Polite, capable, and completely unaware of everything we had learned. The signals we'd validated, the correlations that looked promising but weren't, the constraints we'd discovered the hard way. Gone from the working relationship, all of it. I spent the next day and a half reconstructing intelligence I had already paid for once. Somewhere in that day and a half, frustrated, I asked the fresh session a simple question: how do we make sure this never happens again?

That conversation is where Salvor started.

The problem isn't the model. It's where the knowledge lives.

Here's the distinction that incident made painfully concrete for me: Git preserves what changed. Git doesn't reliably preserve what the project learned.

Your repository holds the source state. Every line, every diff, full history. But the engineering knowledge around that state (why things were done this way, which approaches already failed, what constraints were discovered experimentally, which weird-looking code is weird on purpose) lives somewhere much more fragile: in a context window, in a chat log, in your head. Sessions end. Context compacts. Teammates rotate. Agents spawn other agents. Models change. And every one of those boundaries is a place where the project's accumulated understanding can quietly fall out of the workflow.

The models keep getting dramatically better at writing code. That's not the bottleneck anymore. The bottleneck is that every new session starts from the source state and has to be re-taught everything the project already knew.

The workaround that wouldn't stop growing

The first fixes were built right inside the HFT project, out of necessity.

A two-tier state file, so the current working picture lived in the repo instead of the context window. A hub-and-spoke context layout, partly a Claude convention, partly a token-efficiency measure. And the one that mattered most for that project: learned failures. We had burned real time and real money discovering which signal sources and strategies were red herrings, and I kept watching brand-new sessions confidently propose the exact strategy we had already disproven two sessions ago. Writing failures down, with the rationale, in the repo, changed that. New sessions stopped re-losing old battles.

Meanwhile other projects were growing their own organs of the same animal. One project developed a disciplined file for deferred findings, the things you notice mid-task, agree are real, and explicitly park (that file's pattern became a core Salvor capture class). Another project, a multi-agent orchestration system, became the proving ground for something different: I was using V0's models for the web surfaces and Claude Code for the rest, and agents arriving through that shared, well-scaffolded brain needed far less re-teaching and started from a much more useful picture of the project.

For a while these looked like unrelated project-specific hacks. Then I started noticing I had the same problems in every configuration I tried: single agent, agent swarm, harnessed orchestration, didn't matter. And when I compared notes with friends in my dev network, they were hitting the same wall. Everyone's projects were forgetting.

At that point the fragments stopped looking like workarounds and started looking like one thing. In June I extracted the pieces from their host projects, reconciled them, anonymized them, and made them a standalone protocol.

I named it Salvor. Partly for Salvor Hardin, the Foundation mayor who preserved civilization with knowledge rather than force. Partly because a salvor is literally someone who salvages, who rescues value from loss. Both meanings earn their keep.

What Salvor actually is

Salvor is a repo-native engineering knowledge layer and governance protocol for coding agents. Install is one paste: a single setup prompt that scaffolds your repository with a version-controlled brain. No CLI, no account, no hosted service, no telemetry.

The mental model, in order of importance:

Knowledge lives in the repo, as Markdown. Decisions with rationale. Learned failures. Domain learnings. Deferred findings. Session state. All of it is plain text in your repository: reviewable in PRs, diffable, branchable, owned by you and not by any AI vendor.

Capture is human-gated. Agents don't silently write to the durable record. When something durable surfaces, the agent asks you, with an exact question, and you approve or you don't. The brain contains reviewed knowledge, not accumulated chat sediment. (There's an experimental agent-capture mode for overnight runs; it's off by default and everything it produces sits in a lower trust tier until you ratify it.)

It survives boundaries. Sessions, branches, teammates, vendors. Knowledge artifacts get collision-free IDs and structured headers, so parallel branches can each capture things and a merge-time reconcile ceremony surfaces duplicates and contradictions for a human decision instead of silently shipping both.

It's vendor-portable. The canonical brain is one set of files; thin adapters route Claude Code, Codex, and Gemini-compatible tools to the same knowledge. Switching agents doesn't mean migrating memory.

That's also why I've stopped describing this as "AI memory." Many memory systems focus on retaining prior information and deciding what to recall. An engineering project needs something stricter: governed knowledge, where facts carry rationale, supersession is explicit, and a human approved what's in the record. I've been calling the construct persistent engineering cognition. Git preserves what changed; Salvor preserves what the project learned.

Salvor built Salvor

Since mid-July, the Salvor repository has been running Salvor on itself. Every decision about the protocol is captured with the protocol.

The launch you're reading about was built across three different AI surfaces sharing that one brain: Claude Code did the original extraction from the constituent projects, plus the benchmark harness and the release integration ceremonies. Codex built the GitHub Pages site and most of the contract and visual test suites. ChatGPT reviewed release artifacts for canonical consistency across all the docs and pages. Different vendors, different tools, different sessions, one persistent project brain, and I never had to sit down and re-explain the project from scratch to any of them.

I want to be careful about what that proves. It does not prove Salvor makes every workflow better. It's dogfooding evidence for one specific claim: the workflow can preserve coherent project knowledge across model and tool boundaries. For that claim, it's the most honest evidence I have, because I lived in it daily.

And in the spirit of honest evidence: before launch I ran a clean-room benchmark suite (six experimental arms, third-party scoring only, tamper-evident cost ledgers, methodology published and written to be attacked). The short-horizon results were nulls. A frontier agent saturated the single-agent tasks at 100% with or without any memory system, and in the multi-agent arm, agents given a fully verified shared brain simply never consulted it under single-shot task pressure. I'm publishing those numbers as measured, alongside why I think current benchmarks structurally can't observe compounding knowledge (short tasks have no future in which learning pays off), and an open RFC for a longitudinal harness that could, one where Salvor should be falsifiable. I tested it. That test did not validate the longitudinal thesis. I'm publishing the result anyway, and I want a better test that can actually falsify what Salvor claims to do. If the community can help build that, I genuinely want to know what it shows either way.

Why open source

The techniques behind Salvor materially improved how I work. I could have kept them as a private edge. That felt like the wrong call for two reasons.

First, this space (agentic development, durable project knowledge, multi-agent and multi-model workflows) is a frontier, and frontiers should be explored in public. Other developers will benefit from this, and more importantly, other developers will discover things I haven't. I want those discoveries in the protocol, not scattered across fifty private setups.

Second, the entire premise of Salvor is that important knowledge shouldn't be trapped in one head or one vendor. Running the project any other way would be a little absurd. So: MIT licensed, decisions and rationale inspectable in the repo's own brain, design disagreements welcome in GitHub Discussions, and a real intent to evolve the protocol through contribution rather than decree. Salvor is opinionated, but I don't believe I should have the only voice just because I started it.

About the token

There is a token. I'll explain it plainly and briefly, because it's a supporting mechanism, not the product.

Open-source development needs contributors, and useful contributors deserve compensation. $SALVOR is an experiment in creating an economic rail around that work without turning the token into the project. Contributors may eventually earn compensation for useful code, testing, issue work, integrations, documentation, and other real contributions.

Launch allocation

Outside these identified project-controlled buckets, the remaining supply was not reserved as founder or project inventory. Streamflow charged 570,000 SALVOR (~0.057% of total supply) to create the vesting contract; that amount is no longer project-controlled.

Why MEOW? I owe that community some context. KittehCoin ($MEOW) goes way back in my history — the original coin launched on Christmas Eve 2013, and by early 2014 I was lead developer on the community takeover and relaunch (the original 2014 relaunch thread is still up). This year a MEOW appeared on Bags around that history, and at first I believed the revival was genuine. I claimed the creator fees associated with it, which unintentionally gave people a pretty reasonable signal that I was coming back. When I dug into the distribution, I found coordinated supply behavior I wasn't willing to stand behind. I exited the position and liquidity, and published the evidence instead of asking anyone to take my word for it: the full forensic report covers the methodology, the fixed snapshot, and the blacklist process, with explicit false-positive controls. The plan was a clean relaunch for legitimate holders. Then Salvor consumed basically every spare development cycle I had. I still haven't decided whether MEOW itself gets relaunched. The 5% claimdrop is simply a small thank-you to those already-identified holders for their patience while I've been heads-down here. Eligibility was established before SALVOR existed; nobody receives more for promoting or buying anything.

Bags creator fees are associated with me and create another funding rail for Salvor: development, infrastructure, contributors, grants, and my own documented work on the project. I'm not going to pretend I have no economic participation here; the point of publishing the structure is that nobody should have to guess about it.

Verify it:

• Official mint 4KxtNWc5XTL3cuyc8PJMchqB6RYggvEFeMub727GBAGS · Solscan · Bags

• Contributor & Ecosystem Treasury CWC2S8CdeyNs9wET7f661qQiVdiNjLFT2L52knMVWRYh

• Long-term contributor vest Streamflow · XxN8CmX4XPtz6JkAZ1HxSWk9m5Z4XoGmxb12BTkHGVq

• Founder allocation FGQi71HcS8RoVACEmKtWr9kEdb8qWjkkuax7QAH5K5mW · 50M SALVOR

• MEOW claim reserve CgNxDzhqhQubXhZG8n6fKroQxA5CwEY5XRb1BBePMYRx · 50M SALVOR

I deployed the token and its verification info quietly before this announcement, and people found it considerably faster than I expected. That's all I'll say about markets. Token questions belong in GitHub Discussions, and I'll answer them there.

This is a soft launch. That's the point.

Salvor today is v1.0.0-beta. It has worked very well for me across real projects. It has not yet survived contact with a hundred other engineers' repositories, habits, and edge cases. That's what a beta is for, and I'd rather find out in public. What I'm hoping for over the next few weeks:

Install it on a real project. Greenfield is the easiest place to feel it compound. A mature repo works too, and setup will offer to adopt your existing docs into the brain, but be honest with yourself: Salvor is only as smart as what the brain contains. Give it real project knowledge, and every later session starts with more to work with.

Tell me the truth. Not testimonials. If something is awkward, confusing, or wrong, I want to hear it while the protocol is still young enough to change easily. GitHub Discussions is the front door for questions, ideas, disagreements, and showcases; Issues and PRs for actionable work.

CONTRIBUTE. I'm working out public contributor grants and bounties funded from the treasury; the structure isn't finalized, but the direction is immediate. Real contributions will be recognized and compensated where appropriate. I want this to be built by more people than me.

Come argue with me live. I'm planning an X Space a week or two after this launch: early user experiences, architecture questions, criticism, proposals. A real engineering conversation.

The roadmap after beta includes longitudinal validation (that RFC), stronger multi-agent workflows, more vendor adapters, and the Claude Code plugin in v1.1. But the honest truth is the near-term roadmap should be shaped substantially by what you all break first.

I built Salvor because I lost three days of hard-won understanding to a single keystroke, and I refused to keep paying that tax. If your projects have been forgetting what they learned, come try this. Break it. Tell me why the design is wrong. Help me figure out how far the idea goes.

Start here: github.com/dwasyluk/salvor · salvorknows.dev · @SalvorKnows

— Dan