Multi-Agent CHI
Collision Rate
The percentage of agent CHI submissions that collide with a concurrent agent CHI covering the same Ledger entities — the design-intent equivalent of a merge conflict.
This page describes the intended design. It requires detecting entity-scope overlap across concurrent CHIs, which isn't built yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
agent sessions submitted
overlapping CHI scope for
same Ledger entities
within 24 hours
÷ total CHI submissions
from agent sessions)
× 100
What it signals
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.
Who this metric is for
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.
Watch
MACCR is only meaningful when multiple agents are running concurrently. An org with sequential agent workflows will naturally have near-zero MACCR regardless of architecture quality — there is no opportunity for scope collision when agents run one at a time. Do not use low MACCR as evidence of good multi-agent governance if agents are running sequentially.
The relevant denominator is agent CHI submissions during periods of concurrent agent activity. An org that runs 10 agents sequentially and one batch of 5 agents in parallel should interpret MACCR against the parallel batch window, not the full submission history. rkito surfaces concurrency context alongside the MACCR value to prevent this misread.
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.
The sibling agentic metric. ADRIFT measures ungoverned agent PRs as a percentage of all agent PRs. MACCR measures a different failure mode: agents with CHIs that are architecturally competing with each other.
AIFI measures whether agents complete what their CHI declared. High MACCR can depress AIFI — when agents collide on scope, one or both must abandon or revise their declared intent.
AHCR measures design conformance quality relative to humans. MACCR measures orchestration-layer coordination. Together they describe whether agents are producing good architecture and whether they are stepping on each other while doing it.
What is your org's MACCR?
rkito computes MACCR automatically on every agent CHI submission by checking concurrent agent scope across the Ledger. Connect your repo and see your multi-agent coordination gap within minutes.