Formula
MACCR = (branches where ≥2 concurrent
agent sessions submitted
overlapping CHI scope for
same Ledger entities
within 24 hours
÷ total CHI submissions
from agent sessions)
× 100Thresholds
Well-coordinated agent scope
Target statePartial scope coordination gap
Add pre-spawn scope checkOrchestration dispatching blind
Implement check_chi_scope()Reading it
MACCR measures architectural contention between parallel agents — the design-intent equivalent of a merge conflict. As fan-out patterns become the norm (3–8 agents on parallel worktrees), multiple agents may independently determine they need to modify the same Ledger entity. High MACCR signals that the orchestration layer is not coordinating CHI scope before dispatching agents, leading to competing design proposals queuing for architect review.
This failure mode does not exist at meaningful frequency for human developers. At agent scale it becomes structural. A single orchestration run spawning six agents across six worktrees can produce six concurrent CHIs targeting the same entity, each proposing an independently coherent but collectively contradictory design direction. The result is not a code conflict — it is an architect queue full of mutually exclusive proposals.
MACCR is the early signal that this is happening before it floods the review queue. A rising MACCR is not a problem with the agents — it is a problem with the orchestration layer failing to assign scope before dispatch.
How rkito produces it
When a CHI is submitted, rkito checks for other active CHIs from agent sessions covering overlapping Ledger entity scope submitted within the preceding 24 hours. Overlap is defined as the same entityId appearing in two concurrent agent CHIs. MACCR is the percentage of agent CHI submissions that had at least one such concurrent overlap.
- 01
Agent session submits a CHI
CHI records the submitting session type (agent) and the set of Ledger entityIds in scope
- 02
rkito queries active agent CHIs from the preceding 24 hours
All CHIs from agent sessions (not human) submitted within the 24-hour window are retrieved
- 03
Entity scope intersection check
If any entityId in the new CHI appears in any active agent CHI, a collision is recorded
- 04NO COLLISION
No overlap found
CHI scope is unique — not counted in MACCR numerator
- 05MACCR++
Overlap found — collision recorded
Two or more concurrent agent CHIs target the same Ledger entity — MACCR increments
- 06
MACCR computed as % of agent CHI submissions with at least one collision
Surfaced on org dashboard alongside ADRIFT and AIFI
Who reads it
MACCR surfaces when the agent orchestration strategy is creating architectural contention. High MACCR means the orchestration layer needs to assign CHI scope before dispatching agents. It is not a signal to reduce agent parallelism — it is a signal to add scope coordination as a pre-dispatch step.
MACCR is the early warning before two divergent agent implementations of the same entity produce a collectively incoherent architecture. By the time two competing CHIs reach the review queue, significant implementation work may already exist in both branches. MACCR catches the scope collision at CHI submission time, not after.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
Multi-agent CHI scope is well-coordinated. The orchestration layer is dispatching agents without significant entity scope overlap.
- No action required. Confirm agents are actually running concurrently — near-zero MACCR with sequential-only workflows is expected and not a positive signal.
Some entity scope collisions are occurring between concurrent agents. Review which entities are appearing in multiple concurrent agent CHIs.
- Identify which Ledger entities are appearing in multiple concurrent agent CHIs. These entities are likely at architectural seams — high-connectivity nodes that many agents independently determine are in scope.
- Consider adding a scope coordination step in the orchestration layer: before spawning agents, check existing agent CHIs for overlapping entity scope. Assign exclusive entity ownership per agent at dispatch time.
The orchestration layer is dispatching agents without CHI scope coordination. Competing design proposals are queuing for architect review at structural scale.
- Implement pre-spawn CHI scope checking using
check_chi_scope()before starting each agent. The orchestration layer must query active agent CHIs for each candidate entity before assigning that entity to an agent session. - Alternatively, assign explicit entity scope to each agent at orchestration time — each agent receives a non-overlapping set of entityIds at spawn. This eliminates collision by construction rather than detection.