Keep Git: give agents shared answers about change

Assay · by Medici — October 2026

Anthropic built Scion after its growing repository and agent workload made Git expensive to operate. It reports more than 30,000 merged changes a day and tens of millions of daily CI checkouts. Scion moves source-control operations onto servers, where programs can ask questions without acquiring a working copy. Anthropic also says it is unsuitable as a general replacement for Git. Anthropic’s engineering account

Most teams can keep Git. The question worth borrowing is what their agents should have to reconstruct every time they work.

Over the last month, our workflow merged around 50 PRs a day, including code, documentation and verification work. We have lost review visibility to GitHub throttling while the primary API quota still had capacity. We have also repaired a publication check that judged the wrong set of commits. These are smaller problems than Anthropic’s, but both concern the quality of the answer an agent acts on.

I would keep Git as the record of source and give agents shared answers about what changes affect and which evidence still applies. That changes the design of the workflow around GitHub or GitLab, even when the repositories stay exactly where they are.

Answer the development question

As an illustration, consider an agent changing how a payment is settled. Before it can proceed, it needs to know which components are affected, which checks apply and whether the required review exists.

An agent can assemble those answers from a checkout, build configuration, policy files and forge requests. Several agents can assemble them separately. Each repeats some work; each may observe a different moment or miss a different relationship.

Scion makes source queries directly available to its consumers. Anthropic began serving metadata questions before replacing Git’s client and storage format. That is a useful migration lesson for a smaller team: make a recurring question cheap to answer before undertaking a larger infrastructure change.

For the payment change, the useful answer goes beyond a list of modified files. It connects those files to the settlement path, the checks that exercise it and the review required by the team’s policy. Git supplies source and history. GitHub or GitLab supplies review and check records. The workflow needs to connect those facts without pretending they all have the same owner.

Our throttling incident exposed the cost of repeatedly asking the forge for the same state. Sharing observations and coordinating refreshes is a sensible first step; GitHub recommends webhooks, efficient conditional reads and request queues. A failed refresh must remain visible as an unknown answer. It cannot become an empty review queue. GitHub integration guidance

A library or an existing coordinator may be enough to provide that answer. The interface matters before the deployment shape does.

Reuse the reasoning that still holds

Suppose the payment change touches the settlement function and a shared serialization library. One analysis establishes the affected components and applicable checks. A second agent should be able to use it without reconstructing the same relationships.

Scion’s derived indexes offer a useful precedent: information such as ancestry and file history is computed from immutable revisions, with work performed eagerly or when needed. Applying that pattern to impact and verification is a further design proposal, not a capability Scion’s article demonstrates for us.

The distinction matters. Caching a diff reuses an existing answer. Maintaining impact analysis means updating the answer when its inputs change.

A commit alone does not identify all those inputs. The team might tighten its payment policy while leaving the code untouched. A dependency might change, or the analysis tool might be corrected. The earlier analysis remains a record of what was concluded under its original conditions. It may need replacing as guidance for the next action.

For the payment example, retain the analysis with the source, dependency information and policy it used. When something relevant changes, identify the conclusions that need reconsideration. This can begin with explicit relationships in build files and review rules; it does not require a complete model of the organisation.

It does require humility about missing relationships. Start with recommendations while ordinary CI still runs. Compare the suggested checks with failures and review findings; a missed dependency is a reason to repair the analysis and keep the broader checks. The potential benefit is less repeated reasoning with its assumptions intact. It is not permission to skip tests because an agent thinks a change looks isolated.

Keep readiness current as code moves

Now another change lands in that shared library while the payment review is waiting.

The payment patch has not changed. Its earlier test result has not become false: those tests passed against the version they examined. But the combined system is different. The team must decide whether the existing evidence still supports integration.

A documentation change elsewhere might leave it applicable. A change in the library used to encode payment messages may call for fresh integration checks. A policy change may require another approval. These are different reasons to reconsider readiness, and a useful workflow should explain which one applies.

For this payment change, the next reviewer should get a specific answer: the earlier settlement test passed with the old library; the shared library has changed; check settlement against the new combined version before proceeding. Preserve the earlier result and explain why it is no longer sufficient. Once the new check passes, record which combined version it examined.

Anthropic describes its rapidly changing integration state as a reason to invest in post-merge and pre-deployment testing. Smaller teams need not copy that testing model. They do need to make explicit what a passing result certifies and when it must be revisited.

Our publication repair taught a narrower version of this lesson. A check treated commits already on the remote as new work. The fix established the actual destination history and carried the checked source through publication. The relationship between the evidence and the action was part of correctness. Publication repair

The same discipline applies to reviews and integration: name the revision being approved or tested, retain its relevant context and check what changed before acting. Carry that revision into the provider operation where supported. GitHub and GitLab have different controls; a fresh read alone cannot prevent another writer changing the head immediately afterward. GitHub review controls, GitLab approval controls

Source evidence and current authority also remain separate. A reusable analysis does not grant access to private code or permission to publish it.

Earn the extra machinery

There is a strong argument for stopping at ordinary Git, CI and a few disciplined scripts. A small team with reliable checks may spend more operating a shared service than it saves. Central coordination also creates availability and credential-management responsibilities.

Keep that alternative open. A shared understanding of change is an interface and an operating practice before it is a new service.

We have added opt-in local timing and request counters to several tools. They let us start investigating repeated work, but coverage is incomplete and they do not establish savings from the proposed architecture. Calls outside the measured paths still need accounting. Logging implementation

Pick one question agents repeatedly reconstruct, such as which checks a payment change needs. Record its cost and what makes its answer stale. Try sharing the answer alongside the normal workflow, comparing repeated work and waiting time for the same class of change, including the cost of maintaining and operating the shared answer. A missed affected component or an answer using an obsolete policy is a failed trial, even if it saves requests. Keep it only if the saved effort is worth the added maintenance and those decisions remain dependable.

If repository transfer and maintenance dominate instead, investigate hosting or source-control changes on that evidence. If reconstructing change consequences is the expensive part, improve that capability first.

Git can continue recording the code. The workflow around it should make clear what the code affects, what has been checked and whether those checks still support the next step.