Scope Note
The square-law result in this article is about potential pair interactions under shared mutable work. It is a strong upper-level planning signal, not a promise about every deployment. Actual conflict depends on workload locality, lock discipline, and how much work is already partitioned by data or authority boundaries.
1. The combinatorial core
If n agents can interfere with one another in the same workspace, the number of unordered pairs is n(n-1)/2. That alone is enough to explain why conflict pressure rises much faster than team size in unpartitioned parallel systems.
If each pair has conflict probability p, a useful expectation is E[conflicts] = n(n-1)/2 * p. This is the right first-order reason to stop assuming that doubling agents doubles useful throughput.
2. Why the old partition formula was wrong
The earlier version of this article claimed a universal optimum Z* = sqrt(n / p) for the number of zones. That result did not survive scrutiny. It mixed incompatible objectives and implied operating points that were effectively one agent per zone in common parameter settings.
The right lesson from the square law is simpler: if you hold zone size fixed while the total fleet grows, total collisions grow roughly linearly. If you hold zone count fixed while the fleet grows, collisions remain superlinear because each zone becomes crowded.
3. Model by zone size, not just zone count
Let each zone hold k agents on average, so Z = n / k zones. If conflicts are mostly within-zone, expected collision burden is approximately C(k) approx Z * k(k-1)/2 * p = n(k-1)p / 2.
This makes the key design point obvious. For fixed k, conflict grows like O(n). Near-linear behavior comes from bounded zone size, not from a special formula in Z alone.
4. Smaller zones are not free
If smaller zones always won, we would use one agent per zone. But splitting work creates cross-zone merge, synchronization, and review overhead. A simple planning proxy is M(k) = b * n / k, where b captures the average merge cost per zone boundary.
The total coordination burden can then be approximated as B(k) = a * n * (k - 1) * p / 2 + b * n / k, where a prices the cost of one within-zone collision and b prices the cost of one zone boundary.
5. A better optimum
Minimizing B(k) yields k* approx sqrt(2b / (a * p)). This is a more defensible design rule because it says something intuitive: zone size should shrink when collision probability rises and grow when cross-zone merge cost is expensive.
The implied zone count is then Z* = n / k*, which scales roughly linearly with total fleet size. That is exactly what you would expect if you want to keep local contention under control as the organization grows.
6. How to estimate the parameters
Estimate p from actual collision or overwrite logs, not from intuition. Estimate a from the cost of one conflict event: lost work, retry delay, review burden, or rollback effort. Estimate b from the cost of keeping an extra zone boundary alive: merge work, coordination latency, and cross-zone approvals.
Even coarse estimates are useful because they force teams to compare two real costs instead of pretending partitioning is free.
7. Operational guidance for MARIA OS zones
In MARIA OS terms, a zone should be large enough that local coordination is worthwhile and small enough that conflicts stay local and understandable. Split a zone when collision rate per decision climbs, when merge work inside the zone starts to dominate execution time, or when reviewers can no longer explain ownership boundaries clearly.
Merge zones only when cross-zone handoffs dominate and local collision pressure is already low. Operators should think in terms of target zone size and measured contention, not in terms of one universal formula for every universe.
8. Internal replay takeaways
Internal execution replay confirmed the robust part of the theory: unpartitioned shared work showed rapidly rising conflict pressure as the fleet grew, while bounded zone size kept conflict growth much closer to linear. The exact savings depended heavily on the merge discipline between zones.
That is the practical takeaway. Partitioning helps only if the organization also pays attention to what happens at the boundary.
Conclusion
The square law of potential collisions is real and important, but it is only the starting point. The design problem is not to memorize a flashy sqrt(n / p) rule. It is to balance within-zone collision cost against cross-zone merge cost and to keep zone size bounded as the fleet grows. That is what turns quadratic conflict pressure into something an operating system can actually manage.