Who Owns the Interfaces Across the AI Stack?

Maggie Nanyonga · 2026-07-21 · Engineering Management, AI Infrastructure, Software Architecture, Organizational Design

Every consequential seam in a production AI stack needs a named owner. Your org chart is quietly deciding which seams go without one.

Every consequential seam in a production AI stack needs a named owner, and your org chart is quietly deciding which seams go without one.

This article builds on The AI Stack Is a System, which argues that production AI fails at the interfaces between components; here I take up the question that essay could only gesture at: who, organizationally, owns those interfaces?

In 1968, Melvin Conway published a paper in Datamation called "How Do Committees Invent?" and handed systems designers their most durable warning: "organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." He put it more vividly a few paragraphs earlier: an organization that is not completely flexible in its communication structure "will stamp out an image of itself in every design it produces." Half a century later the software industry turned the warning into a tool. The inverse Conway maneuver, which Thoughtworks' Technology Radar defines as "evolving your team and organizational structure to promote your desired architecture," reasons from the same premise in the opposite direction: the org chart will imprint itself on the system whether you like it or not, so draw the org chart to match the system you want. Skelton and Pais's Team Topologies built a full team-design method on that move, with four team types and three interaction modes and boundaries drawn on purpose.

The AI stack gives that old advice its hardest test yet, because its dangerous seams are unusually easy for an org chart to miss. My evidence base is the same one behind the flagship: fourteen written interface contracts*, one per consequential boundary in a production AI stack, and twenty-two documented failure chains: seventeen observed AI-stack incidents and three observed non-AI analogs, all traced to primary-source reports, plus a literature-anchored pattern and a derived scenario. Read the chains for their organizational content and a pattern falls out. No incident in the register happened because a team was incompetent. The expensive ones happened where an outcome was nobody's contract. That is Conway's law running in the direction nobody brags about: the org chart stamped its image onto the system, and the image had holes in it.

A note on vocabulary, carried over from the flagship: four working terms get an asterisk at first use (domain, interface contract, feedback path, and the dual-membership ownership rule) because they are my coinages, defined with their nearest established relatives in the flagship's glossary.

Three incidents where the org chart was the root cause

Start with the incidents, because the abstract claim ("organizational seams must map to technical seams") sounds like a poster in a hallway until you watch it fail.

Meta, October 4, 2021. A routine backbone maintenance job issued a command intended to assess capacity. The designated safety gate existed and did not work: "a bug in that audit tool prevented it from properly stopping the command." The command disconnected Meta's data centers from the internet, the DNS servers withdrew their routes in self-protection, and then the second failure surfaced, the one that matters for this article: "the total loss of DNS broke many of the internal tools we'd normally use to investigate and resolve outages like this." The recovery tooling rode the same network path as the thing it existed to recover. Engineers had to drive to data centers, where the physical security hardening slowed them further; the postmortem drily notes "it was interesting to see how that hardening slowed us down." Ask the ownership question about each piece. The audit tool had an owner, the network had an owner, DNS had an owner. The guarantee that recovery capability is independent of the production path it repairs belonged to no team at all. It was a real, nameable, cross-boundary property, and it sat unowned until the day it mattered.

Cloudflare, November 2, 2023. A power cascade took out the Flexential PDX-04 facility, an event Cloudflare had explicitly designed to survive: any one of three core facilities could go down and the rest would carry on. Two ownership failures [author-position], in my classification, turned a survivable facility loss into a control-plane and analytics outage that ran from November 2 at 11:44 UTC to November 4 at 04:25 UTC, nearly 41 hours. First, the residence owner was a different company, and the escalation obligation across that boundary silently failed: "Counter to best practices, Flexential did not inform Cloudflare that they had failed over to generator power." Cloudflare learned its facility was dying when the routers went dark. Second, and worse, the redundancy itself was a fiction for a subset of services, because "two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04" while services that depended on them ran on the supposedly highly-available cluster. Nobody had lied. Nobody had checked, either, because checking was nobody's job. Cloudflare's own postmortem names the vacancy: "We were also far too lax about requiring new products and their associated databases to integrate with the high availability cluster." A written resilience policy existed. What did not exist was an owner with the authority to block a GA launch that ignored it, which is why one remediation reads like an org-design patch: "Require all products and features that are designated Generally Available have a reliable disaster recovery plan that is tested." Cloudflare runs a central platform organization [author-position], the shape that looks best on paper for exactly this class of policy. Central capability is not enforcement. The policy still needs a named enforcer, or it is decoration.

Google, February 27, 2026. The flagship tells this incident in full, quotes and all, as an interface failure; here it earns its place as the counterexample, the one where ownership machinery worked. The short version: a configuration change to a safety-filtering service shared by every Gemini model turned into roughly two hours of elevated errors across model versions and regions, 429s for pay-as-you-go customers and 503s for provisioned throughput. A governance component failed as a serving outage. Under the ownership model I will lay out below, that is one event breaching two contract clauses, and it routes as one incident with two workstreams: the governance owner who owned the change, and the serving on-call who owned the symptom, jointly accountable at the seam, with neither allowed to close until both clauses are healthy again. Google's report says nothing about how the work was routed internally, so that mapping is mine [author-position]; what the report does show is consistent with it. The fault was found, rolled back, and resolved in about two hours, and both published remediations, tighter validation on rollouts and closer monitoring of critical dependencies, read as contract clauses acquiring owners. The contrast with Meta and Cloudflare is the point. Where the fault mapped cleanly onto clauses with parties on both sides, a fleet-wide failure was fixed in two hours. Where the seam had no named party at all, recovery took most of two days.

One more ownership vacancy belongs here, and this series budgets exactly one sentence for it: when Air Canada argued before a British Columbia tribunal that it could not be held liable for information provided by its chatbot (a position the tribunal characterized as suggesting, in effect, that the chatbot is "a separate legal entity that is responsible for its own actions"), the tribunal assigned the airline the ownership it had declined to assign itself, and every organization running a customer-facing model should read that ruling as a preview.

The staffing bill: what actually has to be owned

So what does "own the interfaces" mean concretely? Each of the fourteen interface contracts carries three organizational fields: an accountable owner, an escalation path, and revalidation triggers. The assignment rule is the dual-membership ownership rule* the flagship states in full, and it gets one sentence here: accountability follows the contract a component fulfills, wherever the component happens to run, and every dual-homed component (one that runs inside one domain while fulfilling another's contract) carries a five-field accountability block, of which the two fields this article leans on are the accountable owner and the residence owner.

Apply that rule across all fourteen seams and you get a staffing bill. This is the table I wish every VP of engineering drew before drawing team boundaries, because it is the demand side of the org-design problem:

| Accountable owner | Seams owned | What this means in practice |

|---|---|---|

| Orchestration domain | 3 (device exposure, workload submission, serving reconciliation) | A team that can answer for admission, placement, and preemption semantics |

| Data infrastructure domain | 3 (atomic-commit seam, feature/training data, index consistency) | A team that signs for table semantics, skew, and rebuilds, and accepts the application team's acceptance gate on rebuilds |

| Evaluation plane | 3 (evidence custody, model gates, application gates) | A standing function that issues release verdicts from evidence it holds in its own custody |

| Physical foundation domain | 2 (accelerator envelope, placement locality) | The locality seam is multi-party by construction: declaration, provision, carriage, and residency policy are four different obligations |

| Applications domain | 1 (context assembly) plus quality-gate roles on retrieval | The only domain positioned to own user-horizon outcomes |

| Governance plane | 1 (enforcement points across every domain) | Policy intent and audit state; the enforcement points sit inside each domain but answer to the plane |

| Per-path | The five feedback paths* | Deliberately no single feedback owner; each path names its own |

Two things about this table are load-bearing. First, the planes are not domains. A purely functional decomposition (one team per specialty) produces no home for the four plane-owned seams, and an unhomed seam is a pre-written incident. Second, the table already contains two honest vacancies, recorded in the research rather than hidden: the human labeling capacity that bounds how fast production data can become retraining data is owned by no domain in the model, and the classification of scale-to-zero decisions at the serving-orchestration seam is unassigned (the interim rule makes it inherit both the autoscaling and preemption clauses, deliberate over-coverage instead of a gap). I keep these two on display for a reason. Every organization's ownership map has holes like them. The difference between a tracked hole and a hidden one is the difference between Cloudflare's tested-DR gate existing before November 2023 or after.

Five team shapes, three tests

The research program scored five candidate shapes against that staffing bill, and I want to be straight about epistemics before scoring anything: the org-design literature contains no large-N study that says "shape X wins for AI stacks." The scores below apply the program's own evidence (the contracts, the chains, the register of dual-homed components) to each shape, and where the application is a judgment call it is labeled [author-position]: that includes each shape's Team Topologies mapping below, where Skelton and Pais supply the vocabulary and the match to an AI stack is my read. Three tests, derived from that evidence:

Functional teams with interface owners. Specialist teams map one-to-one onto the domains, and named owners manage the boundaries. In Team Topologies vocabulary this is closest to keeping specialist teams and adding explicit boundary roles. It staffs the domain seams cleanly and fails structurally in two places: the plane contracts have no home team unless you create evaluation and governance as functions in their own right, and composite outcomes (the symptom that spans four domains and a plane simultaneously) belong to nobody. Sculley and colleagues named the founding hazard of this shape a decade ago: the engineering ownership of an input signal is separate from the engineering ownership of the model that consumes it. Functional decomposition manufactures exactly the seams the fourteen contracts exist to govern, which is tolerable only if the named-owner discipline is real.

Cross-functional platform teams. Teams form around a slice of the stack, an ingestion-to-features path or a serving path, roughly Team Topologies' stream-aligned teams. Seams internal to a slice become cheap to operate, and just as cheap to stop writing down; the contract discipline that a between-teams seam enforces socially disappears inside a single backlog, and the register decays into tribal knowledge [author-position]. The plane test is where this shape fails outright: a team that owns a path end-to-end has no internal reason to separate the verdict from the artifact, so evaluation quietly becomes a stage in its own pipeline. And the slice edges are seams again, now between platform teams instead of between specialties, with the same multi-party ambiguity you started with.

Central platform plus federated applications. A central team owns common infrastructure and assurance; application teams own domain outcomes. This is Team Topologies' platform-team pattern with X-as-a-Service interaction, and it maps onto the staffing table more cleanly than any other shape: nine of the fourteen accountable-owner cells staff from the central team, the dual-membership register gets a natural registrar, and verdict independence comes free because the gate is not owned by the team shipping the artifact. Its defining trade is the bottleneck. The contracts record the failure modes in advance: a central evaluation harness outage becomes a release stoppage for everyone, and a central function that cannot keep pace with federated promotion cadence either blocks everything or gets bypassed, and bypass pressure is itself a documented failure mode. Cloudflare is this shape's cautionary tale from the inside: a central platform makes cross-cutting enforcement possible, and the GA-to-HA policy still went unenforced because possible is not the same as assigned.

Product-aligned AI teams. One cross-functional team owns the full application outcome, consuming platform capabilities as services. This is the only shape that staffs, by construction, the role the chains keep finding vacant: the end-to-end outcome owner. It is also the shape that cannot exist alone. It has no answer for the infrastructure seams (it does not own them and cannot duplicate them per product), and it concentrates the self-issued-verdict hazard at maximum strength: the team that wants to launch runs its own gate. OpenAI's postmortem of the GPT-4o sycophancy launch is the canonical record of how that ends, in the company's own words: "we decided to launch the model due to the positive signals from the users who tried out the model," and "Unfortunately, this was the wrong call." Some expert testers had said the model's behavior felt slightly off. The quantitative gate outranked the qualitative flag, inside a single decision loop with nobody structurally positioned to say no. Product-aligned teams work as the federated half of the central-platform shape, with gates supplied and adjudicated from outside the team.

An architecture council. The fifth option works differently: it is a decision mechanism layered onto whichever team topology you run, and scored as a sole model it fails instantly, since it staffs zero of the fourteen owner cells. Scored as a complement, it is the piece the other four all turn out to need, because every escalation path in every contract has to terminate somewhere, and some decisions re-draw ownership itself: register changes, boundary reopenings, launch-blocking arbitration, and cross-cutting policy gates of the kind Cloudflare lacked. The documented failure direction is ceremony, councils that meet and decide nothing, so the scoping rule is strict: the council owns only the decision classes just listed, and it seats the accountable owners themselves rather than their delegates [author-position].

Here is the scorecard in one view:

| Test | Functional + owners | Cross-functional slices | Central + federated | Product-aligned | Council (complement) |

|---|---|---|---|---|---|

| E1: staff 14 owners | Holds, if planes get a home | Holds, but contracts decay inside slices | Holds | Fails alone; needs a platform | Staffs none; registrar of changes |

| E2: planes without diffusion | Holds, if evaluation reports outside the artifact teams | Fails alone | Holds, at the cost of handoff latency | Fails alone (self-issued verdicts) | Enables E2 everywhere else |

| E3: survive the chains | Weak on composite outcomes and cross-cutting policy | Weak at slice edges | Strongest on paper; Cloudflare is its counterexample | Strongest on outcome chains; blind below the product | Answers launch arbitration; operates nothing |

Two findings fall out of the table rather than any row [author-position]. First, no shape passes all three tests alone; each leaves at least one documented chain pattern unowned, so the operative question is "which gaps does my shape leave open, and are they named." Second, the council is orthogonal: the real comparison is four team shapes crossed with one decision mechanism, and the mechanism is required plumbing, since fourteen contracts' escalation paths presume a terminus that exists.

Which shape fits which organization

This section is entirely my judgment applied to the evidence above, so it carries the label once for the whole section [author-position]. The corpus has no org-size-to-structure data, and anyone selling you a universal answer is selling.

One AI product, one team that can hold it. Product-aligned is the only staffable option; fourteen owner roles can be held by fewer than fourteen people so long as the register records who holds what. The gap to manage by hand is the verdict: someone whose incentives are not the launch should adjudicate the gate, even if that is one named senior individual rather than a plane team. The council degenerates gracefully into a recurring decision meeting with minutes, which is the NIST documented-roles floor at minimum viable scale.

Several AI products on shared infrastructure. Central platform plus federated applications matches the evidence best; it is the only shape that fully staffs the owner table, and it gives the register and the revalidation triggers a home. Budget its two documented costs up front rather than discovering them: provision the central gate machinery against the promotion cadence of the federated teams, and give the cross-cutting policy class (GA gates, DR tests, recovery-path independence) a named owner with blocking authority, because the Cloudflare lesson is precisely that the central shape does not produce that owner automatically.

Large or regulated organizations. Functional-with-owners or central-plus-federated, with the council as a standing body owning the four decision classes. If you deploy high-risk systems in EU scope, the accountability floor stops being an architecture choice: the AI Act binds deployers to organizational measures and effective human oversight regardless of which shape you run.

At every size: the council stays a complement (run it as the whole model and it staffs nothing), and the unowned gaps travel with you. Whichever shape you pick inherits labeling capacity, scale-to-zero, recovery-path independence, and whatever your own equivalents are, on day one.

When it breaks anyway: escalation and the shared SLO

Shape chosen, owners named, an incident arrives that crosses a seam. Every contract in the program shares one four-step escalation ladder, and its organizing idea is that the breached clause decides who responds; rank never enters it.

Step 1: the clause owner responds first. Allocation failure pages the orchestration on-call; driver-state failure pages the foundation on-call. Each contract writes this routing down in advance, so nobody has to negotiate it while the pager is going off.

Step 2: dual-clause events become one incident with two workstreams, coordinated by the accountable interface owner. The Gemini filter incident is the worked example: a governance fault with a serving symptom, both routed, neither orphaned, and the closure rule holds that neither owner may close until both clauses are green.

Step 3: verdict disputes are settled by re-deriving the verdict. The evaluation plane keeps the evidence package behind every verdict in its own custody; a disputed verdict is re-derived from that package, and if the evidence is intact the verdict stands. Any release exception is a recorded governance action; a model team cannot grant one to itself. This is how you make "the gate said no" survive contact with a VP.

Step 4: boundary-definition disputes leave the incident entirely. "Is this a platform or an application responsibility?" is a seam-definition question, and it goes out-of-band to whatever body holds the architecture decision log, gets answered once, and gets recorded. Unresolved semantics are never improvised mid-incident.

Two standing properties make the ladder livable. Silence is an alarm: a dead emitter produces the same signal as a compliant quiet system, so every monitor carries its own liveness SLO, a lesson Meta paid for when its audit gate sat inert. And every interface, every enforcement point, and every dual-homed component has exactly one named incident owner. An escalation path that terminates nowhere is itself an ownership failure waiting for a date.

The SLO framework underneath the ladder has one principle worth carrying even if you adopt nothing else here [author-position]: every seam carries two levels of objective, and the second cannot be derived from the first. Component SLOs (availability, latency, freshness of one thing, held by one owner) are necessary; they localize faults and price hosting obligations. The shared-outcome SLO is a per-interface metric constructed so that it can fail while every component measure on both sides stays within target: recall against a golden set per pinned embedding version at every index rebuild, divergence between live production behavior and the gate verdict that authorized the release, realized disruption cost per drain event during orchestrator operations. Each shared metric belongs to the contract's accountable owner, with the counterparties bound through the contract, and trade-off disputes at the seam escalate along the ladder rather than to an unscoped committee. On numbers: no source in my evidence base publishes cross-organization targets for these quantities, so I will not invent any. Set yours against measured impact, the way Google's ML testing rubric asks teams to establish what amount of staleness their system can actually tolerate.

Name your two un-owned seams

The inverse Conway maneuver is usually pitched as a way to get the architecture you want. For AI stacks I would pitch it lower and harder: it is a way to stop paying for the seams you already have. Meta's recovery-path dependency, Cloudflare's untested DR policy, and my own map's labeling-capacity hole share one property: each was visible in advance to anyone who asked "who owns this?" and heard silence.

So run the exercise. List your seams; if you have no better inventory, the seven-row staffing table above is a start. For each, write three names: accountable owner, residence owner, escalation terminus. Somewhere between the model team and the data team, between the platform and the products, between your organization and the facility or vendor underneath it, you will find seams where all three lines are blank. In my experience of running this against the program's own architecture, you will find at least two, because I did, and I had the advantage of doing it slowly, in writing, with twenty incident reports open on the desk. Your two are different from mine. Find them this week, and name an owner for each, out loud, in a document someone can cite during an incident. Conway's law will keep stamping your org chart onto your stack either way. The only choice you get is whether the image has holes.

Research method, evidence register, and archived sources: available from the author on request. Program terms marked with an asterisk (domain, interface contract, feedback path, dual-membership ownership rule) are the author's coinages, defined in the flagship's glossary. The unstarred working terms are also the author's: ownership failure is defined in the flagship's glossary; evaluation plane, governance plane, and enforcement point are introduced in the flagship's body under "cross-cutting plane." Judgments not carried by a cited source are marked [author-position] inline.

References

Tier convention: Tier 1: primary documents (operator postmortems, incident reports, adjudications, standards, peer-reviewed papers). Tier 2: reputable practitioner and secondary sources. All Tier 1 quotations are verbatim from the primary document cited, with the speaker attributed in the text; org-design sources were live-verified 2026-07-09.

— Maggie Nanyonga