# Agents changed the requirements. We rebuilt the infrastructure.

Anthropic had to rebuild the ground under its engineers. We think everyone will have to. Here is ours.

---

6 p.m. Léa finds a bug in the refund calculation. She starts a fix, gets halfway, and goes home.

Today, here is what happens next.

She pushes a wip-do-not-merge branch. Overnight, an agent picks it up. It clones the entire repository, with its full history. It rereads dozens of files to work out what Léa was trying to do. It doesn’t know why the refund code is written the way it is, so it guesses.

In the morning, Karim reviews the work from Montreal. He doesn’t know what the agent read, or what it relied on. He asks on Slack: “Why this choice?” Nobody can answer: Léa is asleep, and the agent no longer exists.

In the afternoon, a second agent has to finish the job. It starts from scratch.

Four participants. The same preparation, four times over. And at every handoff, part of the context is lost.

The same day, on Logposa:

• Léa stops. Her uncommitted work is already in a shared checkpoint: an exact, durable version others can read.
• Agent B opens that checkpoint. It downloads only the files it reads. It asks why refunds are calculated this way. It gets the original decision, with its file and line. It finishes the fix and publishes a new checkpoint.
• Karim sees what the agent changed, from which version, and which source it relied on. He disagrees on one point. His proposal is kept next to the agent’s instead of overwriting it.
• Agent D starts from the exact version Karim approved. It finishes, publishes the commit, and the review happens in Logposa. Every line keeps its author, human or agent.

Nobody cloned the repository. Nobody asked the same question twice. Every participant started where the previous one stopped.

That is what we are building: a forge where the work outlives whoever started it.

Even Anthropic had to rebuild

In May 2026, Anthropic merged about 2,500 changes a day into its monorepo. By September, more than 30,000. Twelve times more in four months, much of it written by Claude.

At that scale, the tools gave way. The history approached 100 GB. A compressed working copy exceeded 25 GB. CI, agent sandboxes and research jobs ran about 25 million checkouts a day. Served the conventional way, that would have meant more than 600 PB of Git traffic every day.

Anthropic tried everything: shallow clones, sparse checkouts, several hundred internal Git mirrors. It bought time. Not enough.

So a team of seven built Scion, a new source control system, and its own code review tool, Antique. Migration completed in five months.

Their diagnosis comes down to one idea: Git was designed for developers working offline, each with a complete copy. Agents and jobs are “online by definition.” The original model works against them.

When one of the most advanced AI labs in the world has to rebuild the ground under its engineers, the problem isn’t the engineers. It’s the ground.

But Anthropic says it plainly: Scion is not a general replacement for Git. It is built for its own giant monorepo. It took a dedicated team and a rebuild of much of the toolchain.

Most teams have neither. They have a forge designed for humans who push a few commits a day, and agents that never stop.

Those agents need:

• the right files, right away;
• evidence they can verify;
• an API rather than a UI;
• a way to work with others before anything is committed.

Logposa starts from those needs, for everyone.

1. Stop downloading everything to read three files

Scion’s first choice concerns the working copy: virtualized checkouts, whose files arrive only when they are needed. The result at Anthropic: checkouts in seconds instead of minutes, and infrastructure roughly 200 times lighter than the old Git mirrors.

Back to Agent B. In the legacy model, its first task isn’t fixing the bug. It’s cloning the entire repository and its entire history, to read three files. A human does that once. Agents do it every session, on every branch, in parallel.

Logposa Storage works differently. The workspace first receives the shape of the tree. A file’s contents arrive only when it is read. What has been verified stays in a bounded cache. On Linux, the workspace mounts as an ordinary folder: the usual tools work unchanged. And native Git is still there for those who want it.

We measured the gap. On a test repository with about 100 MiB of current files and 1 GiB of history, groups of 1, 8 and 32 clients performed partial reads followed by two complete builds:

Per client	Logposa	Complete Git clone
Disk space after the builds	≈ 206 MiB	≈ 1,127 MiB
Data downloaded	≈ 103 MiB	≈ 1,025 MiB

Ten times less data per participant. And the complete builds verified the whole tree: the agent was not working on a partial version of the code.

The consequence matters more than the ratio. Adding an agent shouldn’t cost another clone. With Logposa, it costs what it reads.

2. Every answer comes with its source

Scion moved the heavy computation to the server: history, blame, commits, merges. The client keeps a bounded cache. That is the right move. But blame answers “who wrote this line.” It doesn’t answer “why.”

That is Agent B’s question. Why are refunds calculated this way? Which decision justified it? Is it still true?

Today, an agent that can’t find the answer invents a plausible one. And nobody can check where it came from. Many memory systems make this worse: they ask an LLM to summarize what is worth keeping, and the summary replaces the source. The day the answer is wrong, there is nothing left to reread.

Logposa Graph does the opposite. It never answers without showing where the answer comes from.

• Its index is built without a single language-model call. Nothing is rewritten, nothing is invented at indexing time.
• Every answer returns the original passage, with its file and line. Not a summary: the source.
• The original material is kept intact. The day a question turns on a detail that seemed unimportant, it is still there.

For Agent B, that changes everything: it no longer guesses, it cites. For Karim, the next morning, the agent’s claim is no longer a black box: he opens the passage and judges for himself. And for an auditor, six months later, the chain is unbroken: this change, this answer, this source, this line.

Traceability doesn’t cost quality. We evaluated it on LoCoMo, a memory benchmark for agents: 1,540 questions, the same reading and grading protocol for every engine.

Engine	J-score	Strict correctness
Logposa	90.97%	75.78%
Entire Graph	90.26%	74.29%
Mem0 OSS	89.16%	70.65%

And it doesn’t cost speed: 17.4 ms median latency, 20.7 ms at p95.

The level of the best memory systems, with no LLM to index, fast enough to call at every step of a task. Plus what no summary can offer: the proof.

3. A forge you program, not one you click

At Anthropic, every source control query is exposed through an API. Many jobs no longer need a local repository at all.

The legacy model serves humans through a web interface. Agents go through workarounds: clone, edit, commit, push, open a PR. Five steps to change one line, and no guarantee nobody changed the file in the meantime.

With Logposa, the API and SDKs read files at an exact version, list the changes between two versions, and write atomic checkpoints. A safe edit takes three calls:

const file = await workspace.readText("src/payments.ts");

const checkpoint = await workspace.checkpoint({
  key: "refund-fix-1",
  changes: [{
    path: "src/payments.ts",
    content: patchedSource,
    expected: file.entryVersion,
  }],
});

const saved = await workspace.readText("src/payments.ts", {
  version: checkpoint.version,
});

expected rejects the write if someone changed the file in the meantime. The checkpoint returns the exact resulting version. The final read checks that state.

That is what lets Agent D start from the exact version Karim approved, not from a copy that is roughly up to date. Every tool can say what it read, what it changed, and which version the next participant should inspect.

That is what we mean by programmable: explicit state in, explicit outcome out.

4. Working together before the commit

Anthropic didn’t only rebuild source control. It also built its own review tool. When the volume of changes grows twelvefold, the way people and agents work together has to change too.

Léa’s day showed work as a relay: one after another. But most of the time, people work at the same time.

10 a.m. The refund bug is urgent. Everyone jumps on it.

Today:

Léa fixes the calculation in her branch. Agent B adds tests in its own. Karim renames a function used everywhere. Agent D, launched by another colleague, fixes the same bug a different way, without knowing Léa is on it.

Nobody sees anyone else. Everyone works on their own copy.

The conflict blows up at 4 p.m., at merge time. Four branches, two incompatible fixes, a rename that breaks everything. An hour of rebasing. An agent that “resolves” the conflict by overwriting Léa’s work. And nobody knows anymore which version was tested.

The conflict had existed since 10 a.m. It was found six hours too late.

On Logposa:

• Léa starts. Her intent is visible: she is working on the refund calculation.
• Agent D arrives in the same area. Before writing a line, it sees Léa is already there, and on which files. It doesn’t redo her work: it takes the tests.
• Karim renames his function and publishes a checkpoint. Everyone sees the new version immediately, not at 4 p.m.
• Agent B tries to write to a file Karim just changed. The write is rejected: the version it read is no longer current. It rereads, adapts, rewrites. Nothing was silently overwritten.
• Léa and Agent D end up proposing two different fixes for the same line. Neither erases the other. Both stay side by side, with their author and their source. Léa chooses.

The conflict surfaced the moment it happened. The right person settled it, in minutes. And every version that matters has a name.

What makes this possible is that Logposa distinguishes three stages, where the legacy model knows only one:

1. Local: the work is on the participant’s disk.
2. Shared checkpoint: the work has crossed the shared durability boundary. Others can read it, pick it up, challenge it.
3. Git publication: the canonical commit, when the work is ready.

Between the first and the third lies all the real work: edits in progress, half-tested ideas, disagreements. In the legacy model, that zone is invisible. In Logposa, it is shared, versioned and durable.

This is where we go further than Scion. Scion solves code distribution at Anthropic’s scale. Logposa also solves how work moves before it becomes published code, for any team.

We tested it in the hardest case: two real coding-agent sessions, a server crash in the middle of the task. The second agent retrieved the first one’s exact uncommitted files. It read them, continued the work, and sent back its changes. Nothing was lost.

Our ambition goes beyond files: conversations, decisions, evidence, and durable organizational agents. Checkpoints and the relay are the foundations.

5. Knowing who did what, and on what basis

When Karim reviews Agent B’s work, he asks the question every auditor will ask tomorrow: who made this change, and on what basis?

In the legacy model, the answer stops at an author name on a commit. With Logposa, every step leaves a verifiable trail:

• every Graph answer cites its file and line;
• every edit records the exact version it read and the one it produced;
• every agent change carries its attribution, kept current in blame;
• every checkpoint marks an exact state an auditor can reopen.

Speed is worthless if it’s wrong

A fast search is useless if it returns the wrong source. A fast checkpoint is useless if its confirmation doesn’t mean what the caller thinks.

The backend keeps computed Git results across requests and restarts. Repeated requests share their computations. Blame accounts for the exact state of the repository, and agent attribution stays fresh. Storage keeps persistence and publication clearly separate. Recovery and integrity are part of our qualification tests.

And we also measure what we don’t reach yet. On a warm workspace, with 4 KiB operations:

Concurrent clients	Median read	Median durable write
1	0.50 ms	1.70 ms
8	0.58 ms	3.59 ms
32	1.10 ms	8.83 ms

At 32 clients, we miss our 1 ms read and 5 ms write targets. We publish it because an agent performs these operations hundreds of times per task, and a human who is waiting feels every pause.

The forge that carries the work

Scion shows the pressure: twelve times more changes in four months, and tools that gave way. Entire Graph and Mem0 show how much understanding code and retaining knowledge matter. Logposa brings all of it into one forge, for humans and agents, and for the teams that don’t have seven engineers to dedicate to source control.

The foundations already exist: lazy workspaces, source-grounded retrieval, a versioned API, durable shared checkpoints, native review and merge, agent provenance.

Back to Léa. Whether she hands off in the evening or works with three others in the morning, the question is the same: does the next participant start where she stopped? On Logposa, yes. They arrive with the relevant evidence. They open the source behind a decision. They edit an explicit version. They share a verifiable checkpoint. And disagreements are settled when they appear, not six hours later.

The work gets easier to continue with every contribution.

Yesterday’s forges were designed for humans who push a few commits a day. Logposa is designed for what comes next.