From one cockpit to many — a case study in multi-engineer agentic delivery

What this is: a self-contained case study of a five-person team — one architect, four engineers — delivering a complete, working system by running four AI agent fleets concurrently, each inside an isolated subsystem, coordinated only through contracts, under a single source of truth. The case is a representative composite: actors and subsystems are kept generic so the pattern transfers to any domain.

1. Background: the ceiling

The team had already mastered the strongest configuration current AI offers: one engineer steering several coding agents in parallel from a blueprint, every agent's loop closed by a single deterministic verify command (format, static analysis, tests). One head, many hands — and within one subsystem, it delivered working software end to end.

Then came a project too big for one head. The first instinct — putting a second engineer at the same controls — was tried and failed within a week: two people cannot hold one theory of a system without constantly synchronizing, review piled up behind a single merge queue, and the agents received conflicting intent. Concurrency had been added exactly where things must stay serial, and nowhere it was needed.

graph LR
    L0["Level 0<br/>1 engineer · 1 agent<br/>serial assistance"]
    L1["Level 1 — today's pinnacle<br/>1 engineer · N agents<br/>task-level concurrency"]
    L2["Level 2 — this case<br/>M engineers · M fleets · M cells<br/>system-level concurrency"]
    L0 --> L1
    L1 --> L2

The decision that defines this case: don't share the cockpit — multiply it.

2. Terms used in this case

3. The setup

Before any feature work, the architect established seven working rules:

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, files — all versioned, all owned. No context ever reads another's database.
5. Make contracts machine-checkable. Generated clients, generated mocks, compatibility checks, 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:

graph TB
    CORE["Core context · Owner 1"]
    CALC["Provider context · Owner 2"]
    GATE["Gateway context · Owner 3"]
    EXT["External party"]

    subgraph P["Platform and composition — Architect"]
        REG["Contracts registry"]
        COMP["Composition environment"]
    end

    CORE -->|"sync API"| CALC
    CORE -.->|"events"| GATE
    GATE ==>|"data / files"| EXT

(solid = synchronous API · dotted = events · thick = data/file contracts — every edge is a registry entry)

The roles settled as follows. 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, 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.

4. Execution: six weeks

Week 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.

5. Incident report: a contract change in flight

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 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.

6. Outcomes

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.

7. Challenges observed

Four pressures appeared, all anticipated and all watchable. Review decay: mid-project, one owner's fleet outpaced their review depth; the WIP cap of 2–4 tasks was enforced rather than raised, and quality held. Discipline erosion: a week-three back-channel request — "just add this field for me" — was redirected into an RFC; it cost twenty hours of latency and preserved the boundary that made everything else cheap. Seam quality: master-blueprint churn was tracked as a thermometer; it stayed near zero after hardening, the signal that the map had been cut correctly. Mock/real gaps: one swap surfaced a behavioral mismatch the mock could not have shown; the conformance suite was extended so the class of defect could not recur. The model, usefully, instruments its own failure modes.

8. Lessons

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

One sentence to remember: humans own boundaries, intent, and verification; fleets own implementation inside walled cells; and everything meets in the contracts.