There is a vision circulating in engineering leadership circles that has real momentum behind it: a small number of human experts coordinating large fleets of coding agents that do the overwhelming majority of software development. Not as a distant aspiration — as an actively pursued organizational model. The arguments are real: dramatic throughput increases, elimination of execution as a constraint, human judgment operating at a higher level of abstraction while agents handle implementation. The push is serious and the trajectory is credible.
What is missing from this conversation is its second half. If agent fleets deliver on the execution promise, what happens to the constraint?
The Assumption Nobody Is Completing
The fleet thesis rests on a specific diagnosis: execution is the bottleneck. If development could move faster, products would improve faster, organizations would compete better, teams would accomplish more. Agents are the proposed solution to that diagnosis, and it's a coherent one — given the diagnosis.
In most organizations, that diagnosis is wrong. Most organizations that ship slowly aren't slow because engineers type slowly. They're slow because the feed of product direction is unreliable: requirements are ambiguous at the point of execution, edge cases are discovered during build rather than before it, decisions get made by the wrong people at the wrong time, and the rationale for why something is being built lives in three Slack threads and a meeting that half the team missed. Engineers aren't blocked by their own velocity. They're blocked by the quality and consistency of what they're working from.
Speeding up execution against that backdrop doesn't make organizations faster. It makes them faster at building the wrong thing, at higher volume, before anyone notices.
The organizations pushing hardest for fleet-scale execution would benefit from completing the sentence: if execution becomes cheap, the constraint doesn't disappear. It migrates. And where it migrates is almost entirely to Product.
What the Migration Looks Like
The migration isn't subtle. When a fleet of agents is executing in parallel across multiple work streams, the quality of requirements determines the quality of outputs at machine speed. One ambiguous spec doesn't produce one poorly-built feature — it produces an entire feature built on a wrong assumption before the PM has seen the first PR. Human engineers slow this down organically: they ask questions, push back on things that don't make sense, make reasonable assumptions and surface them for review. Agent fleets are faster precisely because they don't do that. The fidelity with which the fleet executes is a direct function of the fidelity of what it was given.
Decision bandwidth becomes a chokepoint nobody anticipated. Engineering leadership frames fleet coordination as the technical problem — how do you direct many agents at once? But the product side generates its own decision queue: is this edge case in scope? What's the right error message here? The design doesn't account for this state — do we handle it or file it? These questions used to surface across a sprint's worth of standup conversations. They now surface at the pace the fleet generates them, which is faster than any PM is currently staffed to answer.
Discovery can't accelerate the way execution can. You can parallelize code generation. You cannot run customer interviews faster than users' schedules permit. You cannot compress the time it takes to learn whether your model of the problem is correct. If execution speed increases by an order of magnitude but discovery stays human-paced, you're not building better — you're building assumptions at speed. The pipeline runs dry, or worse, it runs full of work that's validated in name only.
Context coherence breaks across parallel work streams. In a traditional team, coherence is maintained by shared mental models: engineers who've worked together know how the product thinks, what terms mean, where the model has been stretched. A fleet working in parallel across four simultaneous features has no shared mental model. Feature A and Feature B can each be internally consistent while being mutually incoherent. Nobody notices until both are done.
The Product Backplane
The per-project ProductHarness repo handles project-scoped context well. Steering documents encode the org's technical patterns, work product formats, and conventions. But the per-project harness is an island. A product decision made on Project A — how authentication works, what "member" means versus "user," which data model governs pricing — doesn't automatically exist in Project B. In a world with one project at a time, that's a manageable inefficiency. In a fleet model with multiple parallel work streams, it produces divergence at speed.
What's needed is an org-level context layer above the per-project harness: a product backplane. A version-controlled repository that holds what's true across all work streams — the canonical user model, the glossary of terms and how they're defined, material product decisions with their rationale, cross-cutting standards for UX patterns, and hard constraints from legal, regulatory, or platform requirements. Project-level steering documents reference the backplane rather than duplicating it, so when the backplane changes, the change propagates. Not through manual updates to every active repo, but through a defined review process: which active work streams are affected by this decision change, who updates their steering documents, by when.
The backplane also solves a problem that isn't specific to fleet scale but compounds with it: institutional memory. Right now, decisions made on one engagement don't reliably inform the next one. They live in someone's head, in a Confluence page nobody reads, or not at all. The backplane accumulates the organization's product decisions over time — version-controlled, citable, machine-readable by every future work stream that stands it up. The org's product standards become a default rather than something that has to be reconstructed from scratch each time.
Governance of the backplane is different from governance of a per-project harness. Individual PMs don't own it. Changes require product leadership review — not because the content is complex, but because changes to the backplane have downstream effects on every active work stream simultaneously. That's architectural change management, and it belongs at a level of authority appropriate to that scope.
The implementation mechanism that makes propagation practical is git subtrees. Each project harness configures the backplane as an upstream remote, and the backplane content is included at a defined path within the harness — backplane/. Agents read it from there like any other local file: no API calls, no separate checkouts, no additional tooling. When the backplane updates, pulling the change into an active harness is a single command.
# Initial setup in the project harness repo
git remote add backplane git@github.com:org/product-backplane.git
git subtree add --prefix=backplane backplane main --squash
# When the backplane updates
git subtree pull --prefix=backplane backplane main --squashThe ownership rule that keeps this conflict-free: files under backplane/ in the harness are never edited directly. Changes to backplane content go upstream to the backplane repo first, then pull down into active harnesses on the next sync. Project-specific steering documents live outside that path and are never upstream candidates. The boundary between "what's true everywhere" and "what's true here" is structural, not a convention someone has to remember to follow.
Decision Triage Before the Fleet Engages
The decision bandwidth problem has two possible solutions: more PM capacity to answer questions, or fewer questions arising in the first place. The second is more tractable, and the mechanism is pre-definition rather than real-time resolution.
Before a fleet engages on a work stream, Product and the fleet coordinator co-author a decision authority document: a taxonomy of decision types the fleet will encounter, with pre-assigned ownership and SLAs for each. Some decisions belong to the coordinator and are made autonomously — implementation approach within defined patterns, for instance, where the pattern exists in the steering documents and the choice between valid approaches is a technical judgment. Some decisions belong to the PM and have a defined resolution window — scope questions, user-facing copy, anything that changes acceptance criteria. Some decisions require the fleet to halt and log a request rather than proceed on assumption.
The halt-and-flag category is the most important one to define precisely. A fleet that halts unnecessarily is a productivity loss. A fleet that proceeds on an assumption that turned out wrong is a rework cost that compounds with everything built downstream of that assumption. The pre-defined taxonomy converts "the fleet is waiting for a PM decision" from a real-time crisis into a managed queue. The PM works the queue against defined SLAs. The fleet works on something else while it waits.
The decisions that get made — by coordinator, by PM, by default from the backplane — should be logged back into the steering documents, not just into the conversation where they were resolved. This is what keeps context current and propagates learning into future work streams. A decision made at 10am on Tuesday that lives only in a Slack thread is invisible to the fleet by Wednesday morning.
Discovery Pipeline Staging
If execution can run significantly faster than it does today, the organization needs a much longer runway of validated, fleet-ready work than the current two-week sprint model provides. Most teams today do refinement one to two weeks ahead of execution. For fleet-scale operation, that lead time is structurally insufficient.
What's needed is an explicit pipeline with defined stages and a gate before work enters fleet execution. The stages are something like: raw signal, synthesized problem statement, opportunity assessed, hypothesis written, evidence gathered, and finally fleet-ready — the formal gate where a PM has confirmed that requirements are unambiguous, acceptance criteria are complete, context is loaded into the harness, and the work can execute without further product direction. Work that doesn't meet those criteria isn't fleet-ready regardless of urgency.
The pipeline math is unfamiliar to most Product Orgs but becomes load-bearing in the fleet model. If the average lead time from raw signal to fleet-ready is six weeks, and the fleet can execute twenty work items per week, the organization needs roughly 120 items in active pipeline stages at all times to maintain flow. Most organizations today don't track pipeline inventory at all. Making it visible — how much is fleet-ready, how much is in earlier stages, how much is assumption versus validated — converts the discovery deficit from a silent risk into a manageable operational metric.
The structural implication that most engineering-side advocates for fleet execution don't address is that discovery work needs dedicated capacity, not time borrowed from delivery obligations. PMs who carry delivery commitments will systematically underfund discovery because delivery is more immediately visible and its failures are more immediately punished. Fleet-scale execution requires this to be resolved at the organizational level — dedicated discovery roles, or explicit time allocation models with teeth — not left to individual PM judgment about how to spend their week.
The Coherence Review Function
Human engineering teams maintain product coherence informally. Senior engineers notice when Feature A and Feature B are making conflicting assumptions. PMs who are present in sprint ceremonies catch when two things are being built that don't compose into a coherent user experience. This informal coherence function works at human execution speed. At fleet speed, it breaks: features are completed before the informal check has time to catch the conflict.
Coherence review needs to become a formal, scheduled function with explicit ownership and real authority. Someone — a senior PM, a product director, or a role that might be called product architect — is responsible for periodically reviewing what all active work streams are producing and checking it against the product model: are we using the same terminology? Are two features making incompatible assumptions about how users navigate? Are data models converging or diverging? Does the aggregate of what was built this month still tell a coherent story to users?
The authority part is non-negotiable. A coherence review that can identify conflicts but can't halt a work stream or require a steering document change is documentation of drift, not a remedy for it. The role needs to be able to stop things, require decisions, and escalate to product leadership when the conflict is above its resolution authority. Without that, the function becomes a reporting mechanism for problems that have already shipped.
Coherence review produces artifacts: what was reviewed, what conflicts were found, what decisions resolved them. Those decisions propagate back into the backplane and the relevant project steering documents. The product model gets more precise over time rather than drifting as the fleet generates more surface area.
The PM-Coordinator Interface
The fleet coordinator — the human expert whose job is directing the agent fleet — is primarily operating at the technical level: architecture, implementation quality, fleet direction, exception handling. What that role needs from Product is fast, clean access to product decisions when the fleet surfaces them. What Product needs from that role is visibility into what the fleet is doing, what decisions it's making autonomously, and where it's generating uncertainty.
That interface needs to be designed rather than improvised. Three components matter most.
First, a decision queue: a structured, always-visible log where fleet coordinators record pending product decisions with their urgency, context, and the default behavior if unresolved. PMs work the queue against defined SLAs. The queue is not a Slack thread — it's tracked, prioritized, and resolved with written rationale that feeds back into the steering documents. A decision that lives only in a conversation is lost to the next work stream that encounters the same question.
Second, a context update protocol: when a product decision changes mid-execution, there's a defined process for formally updating the relevant steering documents and notifying the coordinator. The failure mode this prevents is the one that creates the most rework: the coordinator directing the fleet on a mental model that the PM has moved on from, with neither party aware of the divergence until significant work has been built on the stale premise.
Third, a brief weekly alignment: pipeline inventory review, decision queue health check, and any coherence conflicts the coordinator has flagged that need PM input. The coordinator knows things Product doesn't — which decisions the fleet has been making autonomously, where the requirements have had gaps, what ambiguities the decision triage taxonomy didn't anticipate. That information should flow to PM on a rhythm, not on crisis escalation.
The Relationship to ProductHarness
The per-project ProductHarness harness is the right unit of execution in this model. Structured requirements, steering documents as persistent context, the repo as source of truth, the tier system for right-sizing overhead — none of that changes. Each fleet work stream runs on its own harness. The harness remains the mechanism through which the fleet consumes product direction.
What changes is the layer above it — and when you include the production codebase below it, the full architecture is three tiers with upstream remotes connecting the lowest two.
Backplane repo → org-level product context, decisions, glossary
↓ upstream remote (git subtree)
Project Harness repo → project steering, requirements, work artifacts
↓ upstream remote (Tier 3 sync scripts)
Production code repo → shipping codebaseThe backplane sits at the top and maintains what's true across all work streams. Each project harness pulls from it via the subtree mechanism described above — the agent reads backplane content from a local path, no different from any other steering document. The Tier 3 sync relationship at the bottom already exists in the framework: sync scripts, a manifest tracking which artifacts are ready, and feature branch creation in the production repo. That relationship is now the bottom of a three-tier chain rather than a standalone capability.
The decision triage protocol lives in each project harness, referenced from the backplane. The discovery pipeline feeds fleet-ready work into new harnessses as it's validated. The coherence review function spans across all active harnessses and feeds decisions back into them. The PM-coordinator interface keeps the product side and execution side synchronized. Together, these extend the model from "a structured approach for a PM working with AI on a project" to "an operating system for a Product Org feeding an agent fleet." The per-project harness handles the project. These handle the organization operating multiple projects at fleet speed.
What the Backplane Actually Contains
Not everything that exists in a product organization belongs in a backplane. The test is simple: if a piece of context would be true and relevant to a completely different feature, built by a completely different team, on a completely different product area — it belongs in the backplane. If it's specific to a project, a sprint, or a particular implementation, it belongs in the project harness. Within that boundary, content falls into three tiers based on what happens without it.
Critical
The context a fleet cannot operate coherently without covers five things. Canonical terminology is first: a glossary that defines what "member" means versus "user" versus "subscriber," what "active" means, what constitutes an account. Without shared definitions, agents across parallel work streams independently resolve the same terms differently, and the divergence materializes simultaneously in data models, API contracts, and user-facing copy. The entity and state model comes next: the canonical definition of the product's core objects — what a User is, what properties it carries, what states it can be in, how it relates to Account or Workspace or Organization. Everything agents build touches these; without a shared model, work streams produce incompatible assumptions about the data layer.
Material product decisions with rationale are equally critical: why the product is subscription-based rather than usage-based, why a specific capability was descoped and won't be built, why multi-tenancy is supported. These decisions constrain every work stream, and without them agents implement things that conflict with prior choices or PMs spend decision bandwidth relitigating settled questions. Hard constraints complete the load-bearing tier: legal, regulatory, compliance, and platform policy requirements that apply universally — GDPR data handling, WCAG accessibility level, data retention limits, prohibited content categories. The fleet needs these before it builds anything user-facing. Finally, core navigation and information architecture: the top-level structure of the product, major sections, routing conventions, how users move between areas. Without it, agents building features make incompatible assumptions about where things live.
Value-Add
This tier covers context that meaningfully improves quality and consistency without being load-bearing for coherence. UX interaction patterns — how the org handles empty states, destructive actions, error recovery, confirmation flows — prevent features that work correctly but feel like they came from different products. Voice and tone guidelines affect every piece of copy the agent generates; without them, register and framing vary feature to feature. Core product principles are the 3–5 statements that govern tradeoffs when requirements don't specify: "optimize for the expert user," "default to transparency." These are the calls agents make autonomously dozens of times per feature — pointing them toward the right answer is high-leverage with low cost.
Current OKRs and key metrics tell agents what the org is optimizing for, which shapes scoping and risk decisions at the margin. Cross-product API standards — authentication scheme, error response format, pagination convention, rate limiting approach — prevent inconsistent API surfaces that are expensive to normalize later. Data handling principles beyond the legal minimums round out this tier: what's collected, retention policies, what users can access and delete. Every feature that reads or writes user state is implicitly making decisions about these; the backplane makes those decisions explicit.
Nice to Have
This tier enriches outputs without being structurally required. Competitive positioning helps agents make better calls in genuinely ambiguous product decisions. Named customer segments and personas improve scoping and prioritization judgment in ways that are useful but not fleet-critical. Known future direction — what's coming, what's been considered and ruled out — prevents work streams from building things that will be superseded or that conflict with planned work. Production incident learnings encode institutional risk awareness that agents would otherwise have no access to. Standard partner and vendor integration patterns prevent agents from reinventing known interfaces to third-party systems the org has already standardized on.
What Doesn't Belong
Technical standards, component library specifics, infrastructure patterns, and CI/CD configuration belong in the project harness steering documents. They may be templated from backplane principles — an accessibility standard in the backplane, component-level WCAG implementation in the harness — but the implementation detail is project-level. Anything project-specific by definition stays in the harness. The backplane is where work streams converge, not where any one of them lives. Mixing project-level content into the backplane turns a governance asset into a maintenance burden; the boundary is what makes both layers usable.
The Honest Caveat
None of this has been validated in practice at fleet scale, because fleet-scale product development at this level of maturity doesn't yet exist in the organizations that would adopt this framework. These are structural answers to structural problems that follow from the premise — if execution becomes cheap, the constraint migrates, and here's what needs to exist to handle where it lands. But the specific shapes these functions will take, the failure modes that will emerge in practice, the parts that will prove unnecessary and the parts that will prove insufficient: those will be revealed by doing it, not by reasoning about it from outside.
What I'm confident in is the direction. The organizations that treat the fleet's arrival as purely an engineering infrastructure problem — and leave the Product side to adapt reactively — will find the promised throughput gains diluted by the bottlenecks they didn't anticipate. The organizations that build Product-side infrastructure in advance, before the fleet is running, will be the ones that actually capture the returns.
The per-project harness was built that way — from the conviction that structure built ahead of execution is worth more than structure retrofitted after the problems emerge. The same logic applies here, one level up.