Orchestrating AI Coding Agents at Team Scale

7 rules for multi-agent AI development

The architect established seven working rules before any code was written:

1. One project, one master blueprint, one architect. Everything derives from the blueprint. When artifacts disagree: blueprint → contracts → sub-blueprints → task specs → code. Code never wins; it gets corrected.
2. Cut by business capability, never by technical layer. A backend team and a frontend team would mean every feature crosses an ownership boundary, the exact overhead being eliminated.
3. Size each context to one head. Right-sized means the owner can genuinely review every line their agents merge.
4. Every boundary is a contract in the registry. APIs, events, data products, and files are all versioned and all owned. No context ever reads another’s database.
5. Make contracts machine-checkable. Generated clients, generated mocks, compatibility checks, and contract tests in CI. Machines catch shape changes; humans catch meaning changes, keep the human part small.
6. Private things get walls; shared things get versions. Cells hold no foreign code and no foreign credentials, an agent physically cannot violate a neighbor’s boundary.
7. The system is never not running. It exists end-to-end from day two (as mocks) and hardens toward real, no terminal “integration phase.”

The system was cut into four contexts plus a platform layer, every edge declared up front and registered as a typed contract:

Solid = synchronous API · dotted = events · thick = data/file contracts,  every edge is a registry entry.

Who owns what?

The architect guarded the master blueprint, stewarded the registry, and owned the composition layer: the business processes spanning contexts, built purely against everyone’s public contracts, plus the end-to-end tests proving the whole thing worked.

That made the architect the first consumer of every contract; insufficient contracts surfaced in week two, not month four. The architect decided where boundaries went and never reached inside one.
Each owner ran their cell at full mass orchestration: 2–4 agents on deliberately disjoint task specs, every loop closed by the verify command, and everything landing through a serialized merge queue under the owner’s review.

Owners answered to two things: their own published contract as a provider and the pinned contracts of whatever they consumed. Two owners never needed to talk unless a contract changed.

How we scaled AI coding agents: the week-by-week timeline

Weeks 0–1: the map and the mock mesh
The architect’s own fleet produced the context map, the ownership matrix, and draft contracts for every declared edge, then stamped one cell per context from the golden-path template. By day five the mock mesh was live: the entire system ran end to end on generated mocks and canned data. Each cell was handed to its one owner; the architect’s access was removed and never restored.

Week 1–2: hardening
Owners negotiated every contract to v0. This was the loudest fortnight of the project by design: churn was free, consumers pushed back, and every contested meaning was written into the shared glossary. Once every consumer had signed off, enforcement switched on, compatibility checks in the registry, contract tests in every cell’s CI. All unavoidable coordination had been concentrated into the window where it was cheapest.

Week 2–6: parallel build
Four owners built concurrently at full speed, consumers developing against generated mocks and generated clients from day one. As each context passed the conformance suite, the composition environment swapped its mock for the real service, a deployment event, not a code change, while end-to-end tests ran nightly against whatever mixture of mock and real currently existed. By the end of week six, every mock had been swapped and every spanning process ran green against real services.

A mid-build requirement change: one RFC, one sign-off

In week four, the external party’s requirements changed: a new field became mandatory on every outbound submission, a field that had to originate in the core context, crossing two ownerships. Under the old way of working this meant meetings, a coordinated branch, and merge pain.

What actually happened: the gateway owner opened one RFC, proposing the field as additive optional on both affected contracts. The registry verified backward compatibility automatically. The core owner signed off within hours. Clients and mocks were regenerated, and both fleets’ verify loops failed until the new field was handled, adoption was forced by machinery, not chased by humans.

The gateway’s agents tested against the regenerated mock before the core context had shipped anything. The flip to required was scheduled as the next major version with a deprecation window.

Total human synchronization, one RFC, one sign-off: The team also noted the counterfactual: had someone silently reinterpreted an existing field, same shape, new meaning, every machine check would have passed. That class of change is why the project kept exactly one standing meeting: a 30-minute review, twice weekly, only for contested RFCs. Machinery for shape; humans for meaning.

Outcomes: 10–20 concurrent implementation streams, zero integration phase

Concurrency ran on three planes simultaneously: agents in parallel inside every cell, cells in parallel across the system, and integration running alongside implementation instead of after it. In steady state, five steering units × 2–4 agent tasks meant 10–20 concurrent implementation streams, with the serial core reduced to the two-week head plus RFC latency.

There was never an integration phase, because there was never a moment the system wasn’t running, it merely became progressively more real.

When a fifth engineer joined after launch, the scaling recipe held: a context designed with a pre-cut seam was split in two, a short hardening cycle sealed the new edge, and the new cell was handed over. The org chart ended up as a copy of the context map, deliberately.

Challenges and lessons learned

Four pressures appeared, all anticipated and all watchable:

The lessons distill into one sentence: humans own boundaries, intent, and verification; fleets own implementation inside walled cells; and everything meets in the contracts.

• Declare every edge before building anything; edges discovered late are the expensive kind.
• Switch contract enforcement on before parallel build begins; enforcement-on-first-need is late integration by another name.
• One owner per context, sized to what that one human can actually review; review bandwidth, not the agents, is the ceiling.
• Convert contracts relentlessly toward machine-checkable form; every conversion shrinks the surface humans must police.
• Keep the system running from day two; the mock-to-real swap should be a deployment event, never a code change.
• Watch the four signals, blueprint churn, RFC latency, review depth, swap defects, and act on them; they are the model reporting its own health.

The approach is tool-agnostic: it applies whether your fleet runs on Claude Code, Cursor, GitHub Copilot agents, or similar AI coding agents.