Anthropic built Scion to handle a source-control workload most teams have never faced. Its agents and jobs needed answers about code without repeatedly acquiring a working copy. We can borrow that idea while keeping Git, GitHub and GitLab. The useful question is what our agents keep reconstructing.

Our workflow merged around fifty pull requests a day over the last month, including code, documentation and verification. We encountered throttled review reads and a publication check that judged the wrong commits. Those incidents point toward the answers agents act on. They do not prove Git needs replacing.

Consider an illustrative payment change. Before proceeding, an agent needs to know which components it affects, which checks apply and whether the required review exists. Git records the source. GitHub or GitLab records reviews and checks. Someone must connect those facts. Several agents may each repeat that work.

Start by making that recurring question directly answerable. A library or an existing coordinator may be enough. Share observations and coordinate forge refreshes. If a refresh fails, say the answer is unknown. A failed read must never tell the next agent that no review is waiting. But sharing observations is only the beginning.

The payment change touches settlement and a shared serialization library. An impact analysis connects them to the relevant checks. Let the next agent reuse that reasoning, with the source, dependencies and policy it used. Scion derives indexes from immutable revisions. Applying that pattern to impact and verification is our proposal, not a demonstrated Scion capability.

Suppose the team tightens its payment policy while the patch stays unchanged. The old analysis still records its original conclusion, but the required review may differ. Recompute the answer under the new policy, keeping the old result. Start with recommendations while normal checks continue, because the relationships you have recorded may be incomplete. Now let the surrounding code change too.

A new version of the shared library lands while the payment review waits. The earlier settlement test really passed with the old version. Preserve that result. It does not automatically certify the new combination. The next reviewer needs a specific answer: check settlement against the new library before treating the payment change as ready.

When that check passes, record the payment and library revisions it tested. Before publishing a review, identify the revision being approved. Carry it into GitHub or GitLab’s operation where supported. A separate publication repair taught us to establish the actual destination history and carry the checked source through publication. Provider controls differ; a fresh read alone cannot eliminate a concurrent change.

This does not require a new shared service. Ordinary Git, reliable checks and disciplined scripts may already answer the question at lower cost. Sharing creates maintenance, availability and credential responsibilities. We have added opt-in local performance logging, but its coverage is partial. It lets us begin measuring; it does not establish savings.

Try the payment question alongside the normal workflow. Compare repeated work and waiting for the same class of change, including the cost of maintaining the shared answer. A missed component or an obsolete policy is a failed trial, even if requests fall. Keep the improvement only if its saved effort earns that cost and decisions remain dependable.

If repository transfer and maintenance dominate, investigate hosting or source-control changes on that evidence. Otherwise, improve the answers agents keep reconstructing. Git can record the code. The workflow around it should explain what the change affects and whether the available evidence still supports the next step.