An agent-scale Git readiness scorecard for writes, hot refs, and CI fan-out

GitHub describes coding-agent traffic as sustained concurrent reads and writes. Frequent checkpoints raise push demand, merges contend on a shared reference, and each push can trigger substantial CI and scanning read fan-out (GitHub’s architecture account).

The operating question is therefore not simply how many agents can run. It is how their writes move through shared publication points, downstream systems, and human review. The answer has to come from local measurement: GitHub’s experience describes a workload shape, not a capacity forecast for another repository.

Concurrency produces an event chain

A repository may look quiet along one axis while pressure accumulates elsewhere. A moderate number of agents can create frequent checkpoints. A small number of pushes can initiate many reads. Independent branches can converge on one shared ref at publication.

A compact way to organize the measurements is:

agent runs × pushes per run × downstream work per push

This is a proposed measurement frame, not a sourced performance formula. Its purpose is to keep an agent limit from standing in for the workload that limit produces.

Independent coverage interprets GitHub’s account as a repository-capacity problem. It recommends tracking pushes, clones, Actions runs, cache hits, review wait time, and failed jobs, together with explicit concurrency limits for agents and CI jobs (Made With Models). The same brief reports that GitHub is separating durable storage from compute and caches. That is a description of GitHub’s architecture, not a prescribed topology for other teams.

For one observation window and one workload class, record the chain in a single scorecard. Keep routine dependency updates separate from broad refactors, for example.

Dimension	Record	Pressure signal	Local decision question
Agent activity	Concurrent runs and run start rate	Runs accumulate faster than they finish	At what concurrency does queueing begin?
Write activity	Pushes per run, pushes per minute, and rejected pushes	Write rate or rejection rate rises with concurrency	Is the limit associated with agents, their checkpoint cadence, or both?
Shared publication points	Pushes and merges by target ref, plus wait and retry time	One ref carries disproportionate contention	Can publication be staggered or partitioned without changing correctness?
Downstream fan-out	CI runs, scanning jobs, and fetches per push	Work per push rises or queues lengthen	Which triggers are intentional, duplicated, or deferrable?
Cache behavior	Hits, misses, evictions, and cold-fetch volume	Misses or evictions rise during bursts	Does the cache absorb repeated reads under the tested workload?
CI execution	Queued, running, failed, and canceled jobs	Queue age or failed jobs increases	Is agent concurrency outrunning CI capacity?
Human review	Open review items and time waiting for first review	Completed agent work waits longer for review	Is repository capacity being shifted into a review queue?

This scorecard is an original SGL worksheet derived from the operating questions raised by the two sources. Every value needs its denominator and time window. Twenty failed jobs means something different across twenty runs and two thousand runs. A cache-hit percentage without request volume can also conceal a larger absolute miss load. These are measurement cautions, not findings reported by the sources.

Locate pressure at publication

Total push volume does not show where writers collide. Record the target ref for each measured publication event, then group wait time, retries, and failures by ref.

GitHub identifies merges contending on a shared reference as part of the workload it describes (GitHub’s architecture account). That makes the busiest shared refs useful comparison points in a local test, but it does not establish that ref contention will be the bottleneck elsewhere.

Keep branch-local checkpoints and publication to a shared branch in separate series. Combining them can let a high checkpoint rate obscure a smaller set of contended publication events. This separation is an analytical choice proposed here.

Attribute fan-out to its originating push

For representative pushes, attach downstream work to the event that created it. Record:

• CI and scanning jobs triggered
• repository fetches or clones attributable to those jobs
• cache hits and misses
• queue time before execution
• completion, failure, and cancellation state

GitHub says each push can cause substantial CI and scanning read fan-out (GitHub’s architecture account). A local trace measures the fan-out created by a particular repository configuration; it does not convert GitHub’s platform experience into a local capacity estimate.

Event-level attribution also separates two possible interventions. Reducing push frequency changes the number of trigger events. Removing redundant downstream work changes the cost of each event. Local measurements determine whether either intervention helps.

Find the first ceiling

Start with a short baseline at the current concurrency. Increase one limit at a time while holding the workload class and trigger configuration stable. At each level, preserve this sequence:

agents → pushes → hot-ref waits → downstream jobs and reads → review arrivals

Choose provisional ceilings for measures that matter locally, such as push rejection rate, ref wait time, oldest queued CI job, failed-job rate, or review wait time. The concurrency budget is the highest tested level that remains within those locally selected ceilings. It applies only to that test window and configuration; it is not a permanent repository rating.

Keep agent and CI limits under separate controls. The independent brief recommends concurrency limits for both agents and CI jobs (Made With Models). Varying them independently can show whether pressure first appears in repository writes, downstream execution, or the handoff into review.

Repeat the test after material changes to checkpoint behavior, branch strategy, CI triggers, scanning rules, cache configuration, or review staffing. This retest condition is an SGL prescription because each change can alter the measured path; the sources do not establish a universal interval.

Report the envelope, not an agent count

The result should remain attached to the conditions that produced it:

Under this workload class, branch policy, CI configuration, and observation window, the tested concurrency stayed within the selected write, queue, cache, and review ceilings.

That statement gives operators a bounded decision without implying that one number describes every repository state. Teams preparing a broader agent deployment can incorporate the scorecard into the architecture and delivery work described on Build. Begin with one representative workload at the current limit, then follow the first queue that grows.