October 15, 2026

Anthropic Scion: When Agents Outrun Git and CI

A source-control story with a useful question for every team: where does a finished change spend its time?

7 min read

Contents

What Scion changes
Start with the lifecycle of one change
A worksheet you can use this week
Separate throughput from activity
Diagnose the bottleneck before choosing a fix
Make dependencies visible before dispatching agents
Improve CI without removing the evidence you need
Run one controlled improvement
Put the measurement beside the work
Frequently asked questions

Anthropic Scion illustrates the infrastructure demands of prolific coding agents. For your own workflow, start by asking where work waits after an agent finishes.

An engineer and ghost coding agents move code boxes through a conveyor and inspection gate.

On October 13, 2026, Anthropic introduced its internal version-control system, Scion. It reported approximately 2,500 daily merges in May, over 30,000 in September, and 25 million daily CI checkouts. Its Git migration took five months. These company-reported figures describe an unusual workload. Anthropic's engineering report.

The rest of this guide develops a practical response for a team using Git today. It includes a diagnostic worksheet, an illustrative queue calculation, and a way to decide whether the next investment should be faster agents, better review, or different infrastructure. The examples are planning tools, not results from a measured Agentastic deployment.

What Scion changes#

Scion moves substantial work onto servers. Clients retrieve needed objects; APIs answer history and comparison questions. Sparse and on-demand checkouts limit materialization, and Anthropic built separate review tooling.

The design serves a huge monorepo and online consumers, with different tradeoffs around offline work. Anthropic explicitly limits its applicability and describes migration as a change across development infrastructure. Scion architecture and scope.

For a smaller team, the transferable idea is to measure the work surrounding code generation. A faster implementation step can expose delays that were previously hidden behind it.

Consider a feature that takes an agent twenty minutes to implement, then waits three hours for review. Cutting implementation time to ten minutes helps, but it does little for the person waiting to use the feature. If several agents each produce another change during those three hours, the review queue can become the dominant part of the day.

Start with the lifecycle of one change#

A change passes through several distinct states:

Task ready
    → implementation
    → local verification
    → ready for review
    → review and revisions
    → integration checks
    → merged
    → deployed and observed

Each arrow can contain waiting. An agent may be ready to test but lack a database. A reviewer may be available but unable to understand a sprawling diff. CI may be fast once a runner becomes free, yet spend most of its time queued.

Do not collapse these into one “agent completion” metric. Completion can mean the end of a model turn, the existence of a commit, a passing test run, or a delivered feature. Choose the event you care about and name it explicitly.

For a repository team, a useful first milestone is a reviewable change: a bounded diff, a description of the intended behavior, and evidence that the relevant checks ran. A separate milestone is acceptance. The two should not be interchangeable in your dashboard or status reports.

Our software factory implementation guide describes the stations. The measurement below tells you which station to improve.

A worksheet you can use this week#

Take the next ten reasonably similar changes. Record timestamps as work happens; reconstructing everything on Friday tends to hide interruptions.

Copy this header into a spreadsheet:

csv

change_id,task_ready_at,work_started_at,review_ready_at,review_started_at,approved_at,merged_at,ci_queue_minutes,ci_run_minutes,review_active_minutes,rework_minutes,outcome

Keep timestamps in one timezone. Add a short note when a change changes scope, is abandoned, or waits for a product decision. An abandoned attempt still consumed time and may explain why the apparently successful runs looked expensive.

Use these definitions:

Measurement	How to calculate it	What it helps distinguish
Implementation elapsed	Review ready minus work started	Time until a useful first result
Review waiting	Review started minus review ready	Availability and coordination
Review effort	Active minutes reading and testing	Difficulty understanding the change
CI waiting	Minutes queued before a runner starts	Capacity and scheduling
CI execution	Minutes running checks	Test and build work
Rework	Active minutes revising or reconciling	Unclear requirements and integration problems
Delivery elapsed	Merged minus task ready	The whole path through acceptance

Some intervals overlap. For example, CI can run while a person reviews. Do not add every column and call the sum lead time. The timestamp difference gives elapsed time; the other columns explain where effort went.

Also record changes that merge quickly but later require a revert or urgent repair. Optimizing the merge timestamp alone can reward moving defects downstream.

Separate throughput from activity#

Suppose, purely as an illustration, three agents produce twelve reviewable changes per day. Your team can thoroughly check and accept eight changes per day.

If both rates remain steady, the queue grows by four changes each day. Faster generation increases the arrival rate; it does not increase the rate at which review can finish.

New work waiting = prior waiting + changes arriving - changes accepted

This arithmetic is simple, but teams often obscure it with attractive activity metrics: tokens consumed, agents running, commits created, or lines changed. Those measurements can explain utilization. They cannot establish that useful work shipped.

The practical response is a work-in-progress limit: an explicit cap on unfinished changes. For a first experiment, let each reviewer have only a small number of changes actively awaiting attention. Choose the cap together and adjust it based on observed waiting.

When the cap is reached, agents can help with the existing queue: reproduce a reported failure, shrink a patch, explain an unfamiliar module, or prepare missing acceptance evidence. Starting another unrelated feature is only one possible use of available compute.

Diagnose the bottleneck before choosing a fix#

The same symptom—“agents finish but shipping is slow”—can have several causes.

Observation	First experiment	What to measure afterward
Long wait before anyone opens the diff	Reserve review windows and reduce concurrent work	Review waiting
Review starts quickly but takes hours	Split the change around behavior and dependencies	Active review minutes and missed defects
CI spends most time queued	Inspect runner capacity and redundant jobs	Queue time, not only job runtime
CI starts quickly but runs slowly	Profile the slow checks and separate feedback stages	Time to first useful failure
Changes repeatedly conflict	Make ownership and integration order explicit	Rework and repeated conflict count
Setup dominates every run	Reuse reproducible environment preparation	Time until the first test can run
Tasks pass checks but miss the request	Improve specifications and acceptance criteria	Acceptance rate and revision rounds

Treat this as a menu of hypotheses. “We need a faster model” and “we need a new source-control system” are also hypotheses; both deserve evidence.

For environment delays, start with worktree setup for dependencies, ports, and databases. For unclear outcomes, use a specification for an existing application. A different bottleneck requires a different intervention.

Make dependencies visible before dispatching agents#

Separate workspaces prevent agents from editing the same files accidentally. They do not make logically dependent tasks independent.

Imagine a reporting feature with three changes:

Introduce a reporting query interface.
Expose the query through an endpoint.
Add a page that calls the endpoint.

The endpoint depends on an interface that might change during review. Launching all three agents against an unspecified design can create three locally reasonable implementations that disagree.

Agree on the interface first. Then decide which work can overlap. The page can be designed against a documented response fixture while the endpoint is implemented. The final integration still needs a check against the actual endpoint.

Stacked pull requests are useful when each change depends on the previous one. A stack makes those relationships explicit and keeps review slices smaller. It does not remove the need to test the assembled feature.

Improve CI without removing the evidence you need#

A slow test suite is a real cost, but “run fewer tests” is an incomplete proposal. Specify which failures each stage should catch.

A reasonable design exercise is to list:

Checks that provide fast feedback while the agent edits.
Checks required before a reviewer spends substantial time.
Checks required for integration with the current base.
Deployment checks and observations that cannot be reproduced locally.

Then look for duplication, unnecessarily repeated setup, and avoidable transfers. Keep the correctness argument alongside the optimization. If a cache saves time, what ensures an incompatible dependency or build setting cannot reuse the wrong result?

GitHub's merge queue can validate groups of changes against an updated target branch. If you use GitHub Actions for required checks, the workflow must respond to the appropriate merge_group event for those checks to run in the queue. Review the repository-specific configuration rather than assuming a normal pull-request run covers it. GitHub merge queue documentation.

That is one example of why integration policy belongs in the workflow design. A green result for an earlier commit is evidence about that commit.

Run one controlled improvement#

Choose one bottleneck and one change to the process. Keep task size and type reasonably comparable during the experiment.

For example:

Observation:
Changes wait longer for review than they spend in implementation.

Experiment:
For the next ten changes, cap the waiting queue and require a
behavior summary, relevant test output, and a small review scope.

Measure:
Review waiting, active review time, revision rounds, accepted changes,
and defects discovered after acceptance.

Decision:
Keep the new process only if it improves the overall outcome.

This template deliberately includes a decision rule. Otherwise a process experiment easily becomes a permanent ceremony because someone invested effort in creating it.

A small sample will not prove a universal productivity claim. It can reveal a missing handoff, an expensive setup step, or an overloaded reviewer clearly enough to justify a better next experiment.

Put the measurement beside the work#

In Agentastic, start with two agents in separate Git worktrees. Give each a bounded task, inspect the resulting diffs, and use code review before deciding what to merge. Keep the worksheet in your normal project records.

Agentastic supplies the workspace, terminals, and review surfaces for this Git workflow. The timestamps and diagnostic calculations above are a method you can apply; they are not a claim that the app automatically attributes every delay.

When those two tasks move cleanly through implementation, verification, and review, increase concurrency carefully. Our agent orchestration guide covers coordinating more workers. The useful scaling signal is that the whole workflow can accept more good changes.

Frequently asked questions#

What is Anthropic Scion?#

Scion is Anthropic's internal version-control system for its unusually large, heavily automated monorepo. Anthropic described the system in October 2026; it is not a general-purpose Git product.

Should a team using coding agents replace Git?#

First measure checkout time, review waiting, CI execution, and integration rework. A change to version control addresses only some of those costs. Most teams can begin by improving task boundaries, review capacity, and existing Git workflows.

Does running more coding agents increase delivery throughput?#

Only while the rest of the workflow can absorb their output. When completed changes arrive faster than they can be checked and reviewed, unfinished work accumulates.

What should an AI coding workflow measure?#

Record when a task starts, when its first reviewable change appears, when checks finish, when review begins, and when it merges. Track retries, abandoned changes, and failures after merge as well.

Does Agentastic support Scion?#

This guide describes a Git-based workflow in Agentastic. It does not announce or demonstrate a Scion integration.