38. Enterprise adoption and the infrastructure landscape

The previous four chapters described how to run a factory. This one describes how an organization comes to be allowed to run one. It has three parts that usually get discussed separately and should not be: a maturity model that measures observable capability instead of ambition, an adoption path that expands autonomy one proven corridor at a time, and the infrastructure landscape of vendors, open-source projects, deployment topologies, and enterprise controls in which every one of those decisions is made. After reading it you should be able to rate a factory by dimension, defend the rating to a board, choose which layers to buy and which to build, and answer the security questionnaire before anyone sends it.

The problem

Enterprises buy agent capability faster than they build the operating system required to govern it. A team can have excellent coding agents and no release governance; strong CI and no durable WorkOrder authority; a beautiful demo in one repository and nothing repeatable anywhere else. When leadership asks "how mature is our AI software factory?", the honest answer is a set of numbers by dimension and by scope, and what they usually get is a single adjective.

The label matters because it becomes authority. A team rated "advanced" is allowed to do things a team rated "pilot" is not. If the rating measures enthusiasm, model intelligence, or the percentage of code generated by AI, the authority it grants has no evidence behind it, and chapter 3 explained why authority without evidence is the failure the whole factory exists to prevent.

The second problem is that the factory does not run in a vacuum. It runs on somebody's compute, inside somebody's network, under somebody's identity provider, subject to residency law and retention policy, and on top of a stack of languages, frameworks, model providers, and protocols that changes every quarter. The build-versus-buy question is not answered once. It is answered per layer, and the answer for an enterprise with data-residency obligations is different from the answer for a five-person startup. A factory that is technically excellent and cannot pass SSO, tenant isolation, and audit-retention review will not be deployed.

How it works

Maturity is observable capability, scoped

A maturity level describes what an organization can demonstrably do, with retained proof, in a specific scope. The scope is a repository, a workflow, a risk class, or an environment; it is never "the enterprise". The enterprise level, if anyone insists on one, is the lowest material capability required for the claimed use case, not the highest demo achieved anywhere.

The analogy is a hospital's accreditation. A hospital is not "Level 4" because its cardiology unit is excellent; the accreditation is per service line, the standards are about retained records and repeatable process, and a single serious event can suspend a service line's license the same week. Nobody would accept a hospital rated by how enthusiastic its surgeons are.

These levels line up with the autonomy levels of chapter 3, but they describe the organization rather than a single scope's ceiling. Level 5 is an operating condition, not a badge. A critical event demotes or quarantines a scope immediately, and the dotted arrows in the diagram are as much part of the model as the solid ones.

An organization with widespread Copilot use and no governed WorkOrders is at Level 1 no matter how much code the assistants write, because nothing has been delegated: no persistent state, no bounded authority, no independent evidence. That is not a criticism. It is the correct starting point for the path below.

A second lens: skills, loops, factory

The six levels above rate an organisation by how much authority it has safely delegated, with proof. A second maturity ladder in public use rates the same organisation by what it has built: whether its knowledge is reusable, whether its workflows run without a person starting them, whether those workflows observe and improve themselves, and whether the loops are connected into a system. The two lenses are complementary rather than competing, because an organisation can build a great deal of loop machinery without earning the right to delegate authority through it, and can delegate a narrow corridor with almost no machinery at all. Rate both.

The last column is the reason to keep both lenses. A team at skills-to-factory L4 with weak evidence is running many loops it may not lawfully trust; a team at authority Level 3 with no skills is delegating one corridor by hand-written prompt and will not be able to repeat it. The corridors below move an organisation up the authority ladder; the skill registry, the loop engineering of Chapter 23, and the meta loop of Chapter 40 move it up this one.

Two properties of the second ladder are worth stating because they change how the adoption path is planned. The first is that the factory is a continuum, not a destination: AI assistance → skills → automation → loops → connected loops → factory, with the share of work done by loops rising step by step and never required to reach everything (Chapter 2 gives the four working modes this continuum passes through). The second is where it ends up: eventually engineers spend more time engineering the factory than doing the work it automates. That is not a warning. It is the description of the L4 job, and it is the last step of the bottleneck migration Chapter 1 describes, arriving as planned. An organisation that budgets for the tooling and not for the factory engineers will stall at L2 with a large collection of triggers and nobody whose job is to make them better.

Score eight dimensions, and let hard gates override averages

A single number hides the limiting constraint, so the model scores at least eight dimensions: specification, orchestration, quality and evidence, security and identity, delivery and operations, governance and roles, observability and economics, and learning and change control. Numeric scores show trends; bands (the levels above) communicate decisions. Two rules keep the scoring honest. The scope's level is the minimum across the dimensions that matter for the use case, not the mean. And hard gates override averages: a scope with a fabricated-evidence finding is not Level 3 however its other seven dimensions score.

Advance through use-case corridors

Nobody transforms the whole SDLC at once. Adoption proceeds through a corridor: one repeatable, valuable, reversible use case, such as governed issue to validated pull request, the wedge workflow of chapter 26. The corridor gets a baseline before any agent touches it (lead time, change failure rate, human effort, wait time, satisfaction, control escapes) and is promoted only on evidence against that baseline. Prove Level 2 in the corridor, stabilize it, then run Level 3 decisions in shadow before enforcing any of them.

The seven steps are Observe, Assist, Delegate, Shadow govern, Enforce, Conditionally automate, and Scale. Shadow governance deserves a note because it is where most programmes quietly fail. Computing a policy or evidence decision without enforcing it is a learning phase only if the disagreement between the computed decision and the human decision is measured and the calibration is tracked. A shadow mode nobody reads is a delay, not a learning phase.

Promote and demote on evidence

Moving a corridor from Level 2 to Level 3 needs a promotion rule stated in advance. The working default in this guide is at least 100 successful WorkOrders over 30 days, at least 99 percent independent validation success, zero critical policy or security violations, zero unauthorized actions, and an explicit human promotion decision. These are starting policy values, not universal science; riskier domains require more, and a payments repository should not use the same numbers as a documentation site.

Demotion is asymmetric. Failures decay in the scoring over time but never disappear from audit history. Some findings do not wait for the score: a security bypass, fabricated evidence, an unauthorized action, tampering with records, or a high-impact validation escape triggers immediate demotion or quarantine pending review. Chapter 7 holds the policy mechanics; chapter 36 holds the quarantine mechanics.

Change the organization, not only the tooling

A factory changes what each role is for. Product owners improve intent and acceptance criteria, because chapter 6 made intent the input the whole system amplifies. Platform teams provide paved execution and evidence paths. Security encodes policy and reviews exceptions rather than reviewing every change. Quality engineers design assurance systems and adversarial validation rather than executing test plans. Staff engineers own invariants and architecture. Leaders measure customer value, risk, and cognitive load, not generated lines of code.

Adoption therefore needs training, role clarity, psychological safety for reporting failures (a factory whose operators hide escapes will never earn Level 3), and explicit accountability. Approval fatigue, the most common reason a Level 2 programme stalls, is reduced by evidence-centered reviews and exception routing, not by deleting accountability. The decision packet from chapter 37 is the unit of that reduction.

Jay's platform-adoption notes describe the operating model that supports this: product-line design partners, builder listening sessions, forward-deployed engineers, internal champions, weekly usage reviews, release experiments, paved paths, migration support, a deprecation strategy, and adoption and reliability dashboards. The twelve adoption metrics on those dashboards are time to first successful workflow, task success, PR acceptance rate, human correction rate, model-routing quality, token cost per accepted outcome, reliability, repeat usage, time to onboard a new team, bespoke capabilities retired, builder satisfaction, and adoption across product organizations. They complement the delivery metrics of chapter 8 by measuring whether the factory is used, not only whether it works.

Tradeoffs: theater, uniformity, and hidden cost

Maturity models become compliance theater when they assess policy documents instead of workflows. The defence is to require retained proof and to rate what actually ran. Uniform enterprise standards improve control and suppress local learning; the resolution is to define mandatory boundaries centrally (identity, evidence, audit, quarantine) and let teams experiment inside them. Early automation shows fast savings while increasing hidden review and incident costs, so the measure is total human and operational effort, not agent hours saved.

Build, buy, and compose

Chapter 2 introduced the five-layer stack (compute, development environment, inner harness, outer harness, control plane and orchestration) as the frame for build-versus-buy. The practitioners in the HumanLayer and BAML conversation add the rule that makes the frame usable: composition over inheritance. Most buyers assume that whichever layer they buy at, they must also buy everything below it. The better answer is that an engineer should be able to choose each layer and plug open systems together.

Their own choices illustrate it. The BAML team picked the two layers they care about (orchestration and feedback-to-issue intake), explicitly do not want to own the harness because it changes all the time and should be swappable, and do not care whose box the compute runs on. HumanLayer sells the orchestration layer and expects you to bring your own harness. Cognition's Devin covers the top three layers and offers outposts: you run the compute, the outpost brings the harness and tooling into your environment, and vendor and customer co-own the development environment. Anthropic's Claude automations (routines, scheduled runs on a cron) bring the compute environment along with the harness, so a team that likes that harness can compose an all-in-one stack. A fully verticalized cloud agent, convenient as it is, brings friction in defining your development environment and limited choice of compute.

Two observations from that conversation matter for enterprises. First, enterprises want to bring the compute and probably parts of the development environment, and the largest will run the whole thing on-premises; a vendor that cannot separate harness from compute cannot sell to them. Second, on why there is no widely adopted open-source control plane: code is now so cheap to write that nobody wants someone else's control plane unless it arrives with the integrations built; the integrations (Slack, GitHub issues, a CLI, Linear) are the value; every company's working style has a different definition of what an issue even is; and the people building control planes want to sell products. The open-source options that exist tend to be another full stack that asks you to bring compute. So the control plane is the layer an enterprise is most likely to build or heavily adapt, and the harness is the layer to treat as replaceable.

The same conversation predicts that a LAMP-stack equivalent will eventually emerge for the factory stack. Until it does, the enterprise's protection is extensibility: an API surface into which Slack, the issue tracker, the CLI, and the company's own definitions can be plugged, and, since agents now write code, software that its users can extend. Chapter 44 follows that thread.

Six questions per layer

Composition tells you that each layer is a separate decision. It does not tell you how to make it. For every layer, ask six questions, and write the answers down, because the answers change and the reasoning should be inspectable when they do.

The bias that falls out of those questions is consistent: build the durable control plane and the differentiating intelligence; adopt commodity infrastructure wherever an abstraction preserves optionality. In practice that means adopting an orchestration engine, an observability backend, and model providers, and owning the Agent Definition format, the evaluation contracts, the policy model, the builder experience, the capability interfaces, and the learning signals. The adopted pieces are replaceable behind a contract; the owned pieces are the contract. Build where you need durable leverage; adopt where abstraction preserves optionality.

Commodity and differentiated layers

The six questions give a decision per layer. Stepping back, the answers sort every layer into one of two bands, and naming the bands makes the strategy sayable in a sentence. The commodity layer is everything that many organizations need in the same shape and that the market or the open-source community is already converging on: the agent loop mechanics, sandbox provisioning, workflow engines, tracing transport, vector stores, model APIs, the CI runner. Owning it buys nothing a competitor cannot buy, and it costs a team that could be doing something else. The differentiated layer is what only this organization can decide and what compounds when it is done well: the control plane's authority and evidence model, the policy layers, the repository profiles and enterprise context, the evaluation sets built from this organization's real work, the learning signals, and the Builder Experience (BX) through which every builder meets the system. Adopt commodity execution mechanics; build the differentiated control plane and Builder Experience.

The line between the bands is the platform boundary: the set of contracts at which the organization's own components meet adopted ones. Where that boundary sits is a strategic decision, and it moves: a capability that is differentiated today (a review agent, say) becomes commodity as products mature, and a platform that cannot move its boundary is stuck owning yesterday's differentiation. What keeps the boundary movable is an open architecture: components on either side of it communicate through standard contracts (the execution manifest, the event envelope, the tool and capability interfaces, the evidence schema) rather than through one vendor's private API, so that a component can be replaced without rewriting its neighbours. Conformance is how a replacement proves it fits: a suite of behavioural tests that any harness, sandbox provider, or model gateway must pass to be admitted behind the contract, which is the same swappability-by-test rule Chapter 2 applies to the stack.

For the commodity band, the choice is between an open-source foundation and a commercial foundation, and the six questions gain five more that are specific to adopted software. Licensing: what may you run, modify, redistribute, and embed, and does the enterprise tier hold back exactly the controls (SSO, audit, RBAC) the checklist below requires? Community health: for open source, the number and diversity of maintainers, release cadence, issue response time, and governance model; for commercial, the vendor's runway, roadmap transparency, and the customer base that will keep the product alive. Operational burden: who patches it, upgrades it, scales it, and answers at 3 a.m., and whether that burden lands on the platform team that was supposed to be building the differentiated layer. Exit cost: the real price of leaving, measured by an export attempted before signing (records in a documented schema, evidence readable without the vendor, a replaceable harness, an API rather than only a UI). Vendor independence: whether the organization's architecture would survive the vendor's disappearance, acquisition, or pricing change, which is the property the standard contracts and conformance suites exist to protect. An adopted component that scores badly on any of the five is not necessarily rejected; it is adopted with the exit rehearsed and the boundary kept sharp, so that the day it must go is a migration and not a rewrite.

The picture is a restaurant. The kitchen buys its ovens, its refrigeration, and its point-of-sale system, because no diner chooses a restaurant for its oven. It writes its own menu, trains its own cooks, and owns its relationship with the guest, because that is the whole business. A restaurant that builds ovens has confused the two, and so has one that lets the oven vendor write the menu.

Existing agents: a gravity well, not a migration mandate

No enterprise starts from zero. By the time a platform team forms, product teams already have agents: a support bot, a test-generation script, a release helper, each with its own model calls, prompts, and half-built guardrails, each solving a real problem for the team that built it. The platform's first instinct, to mandate migration, is wrong twice over. It ignores what those agents got right, and it makes the platform the enemy of every team that has something working.

The better posture is a gravity well: make the platform the easiest place to be, one capability at a time, so that existing agents drift toward it because each step is worth taking on its own. The order matters, because each step has to pay for itself before the next is offered.

The model gateway comes first because it is the cheapest step for the adopting team (change one endpoint) and the most valuable for the platform (cost attribution and model eligibility for everything that passes through it). Common evaluation comes second because a team that can see its agent's regression rate wants the next step. Observability, governed tools, and finally the runtime follow as trust accumulates. At no point is the team told to rewrite; at every point it is offered something that makes its existing agent better. A gravity well, not a migration mandate.

The contribution model: centralize complexity, federate expertise

Once teams are on the platform, the question becomes who builds what. The answer that scales is a split along one line: the central platform team owns the contracts and the paved road; product organizations contribute domain intelligence inside those contracts.

The left column is everything every team would otherwise rebuild badly; the right column is everything the platform team could never know well enough to build. Centralize undifferentiated complexity; federate differentiated expertise. Domain teams own their business workflows. The platform centralizes the expensive, risky, undifferentiated capabilities that would otherwise be reimplemented, with different bugs, in every organization.

Forward-deployed engineering and its failure mode

An early platform needs engineers embedded with the teams adopting it. They see, in a way no dashboard shows, where onboarding breaks, where an abstraction does not fit the team's work, which capability is missing, and the exact moment a builder stops trusting the system. That is the right investment for the first year.

It has one failure mode, and it is common enough to plan against: the forward-deployed team becomes a permanent consulting layer whose skill at working around the platform hides the platform's weaknesses. The guard is a rule about where discoveries go. Every integration a forward-deployed engineer builds is a finding; the same integration built three times for three teams is a missing platform capability, and the third build is the one that should have been a platform ticket instead. The measure of the forward-deployed function is how quickly teams stop needing it. Forward deployment accelerates the path to self-service; it does not replace it.

The function has a working method, and it is a loop rather than an engagement. Embedded engineering puts a platform engineer inside a product team for a bounded period, working from that team's backlog, on that team's repositories, with that team's builders. What the engineer does there is co-building: not building the integration for the team, and not advising the team on how to build it, but building it with them, so that the team ends up able to do the next one alone and the platform ends up knowing what the abstraction was missing. That transfer is builder enablement, and it is the deliverable; a working integration that only the embedded engineer understands is a failure dressed as a success.

Three of the steps carry their own vocabulary. Productise is the moment a bespoke solution becomes a reusable artifact: a skill, a tool, an Agent Definition, a repository profile template, a migration script, or a piece of documentation, versioned in the Agent Factory (Chapter 11) with an owner and an evaluation, rather than a branch in one team's repository. Migration tooling is the productised form of the most common co-build: scripts and adapters that move a team's existing agent, prompts, or evaluation cases onto the platform's contracts with the gravity-well order above, so that the fourth team's migration is a command and not an engagement. The whole loop is aimed at an adoption wedge: the one workflow, in one team, that is valuable enough to fund the embedding and repeatable enough that its artifacts transfer; the governed issue-to-PR corridor of Chapter 26 is the usual wedge, and each product organization's first wedge is chosen with its design partners, not assigned.

The tension the loop manages is between local factories and the shared platform. A product organization with enough scale will build its own factory (its own harness wrappers, its own review agent, its own evaluation sets) whether or not the platform team approves, and it will often be right to, because it knows its domain and cannot wait. The forward-deployed function is how the shared platform stays connected to those local factories without absorbing or suppressing them: embed, learn what the local factory got right, productise the parts that generalize, contribute them back, and let the local factory keep the parts that are local. The contribution model above (centralize undifferentiated complexity, federate differentiated expertise) is the standing arrangement; the loop is how a local innovation crosses the line from federated to central when it has earned it. What comes back from the loop, besides artifacts, is product and builder feedback with evidence attached, and that feedback is the platform roadmap's most reliable input.

Multi-tenancy, layer by layer

A shared platform serving many product organizations is multi-tenant whether or not the word is used, and tenancy has to be designed at four layers, because each one leaks differently.

The data row is the one most often built wrong: filtering a model's output for things the user should not see is far weaker than never retrieving them, because the model's reasoning has already been shaped by what it read. The memory row is the one most often forgotten, because a shared memory that quietly learns one organization's conventions and applies them to another is a leak with no log entry. The aim is a common platform with differentiated product behaviour: shared rails, separate lanes.

Three release clocks

A platform that ships everything on one release train is either too slow for its models or too fast for its contracts. Three clocks run at once.

The fast clock exists because model quality and price change monthly and the factory should benefit without a release ceremony; the slow clock exists because running work is bound to the contracts and a change there is a migration. Versioning is what makes three clocks safe: Agent Definitions, skills, model configurations, tool contracts, evaluation sets, context policies, and runtime versions are all explicit, and nothing mutates silently. You cannot operate a learning system safely if you cannot reconstruct which version learned what.

Deployment topologies

Where the factory runs is a distinct decision from who built it. Five topologies cover the enterprise conversation.

Managed SaaS is fastest to start and hardest to pass residency and egress review. Bring your own cloud (BYOC) and outposts keep source, secrets, and compute in the customer's account while the vendor operates the control plane; it is the topology the practitioners above expect enterprises to demand (chapter 17 covers the execution-plane side). VPC deployment runs the vendor's software inside the customer's private network with customer-held keys. Self-hosted means the customer runs the software and owns upgrades. On-premises or air-gapped brings the models too, restricting the model choice of chapter 21 to what can be hosted. Each step trades operating burden for control; the maturity model applies identically in all of them, because topology does not change the evidence a level requires.

The enterprise control checklist

The security questionnaire arrives whether or not the factory is ready for it. What it is really asking is whether your AI Infrastructure (the shared model, data, knowledge, tool, identity, runtime, environment, compute, telemetry, and evaluation services used to build and operate AI systems) has become Enterprise AI Infrastructure: the same services operated with explicit organizational identity, tenant isolation, data classification and residency, private networking, audit, policy, quota, support, lifecycle, and accountability requirements. Infrastructure supplies capabilities while product and control-plane contracts determine their authorized use, and "enterprise" names an operating obligation, not a product tier. The controls the questionnaire asks about fall into a stable set, and each maps to a chapter that explains how the factory provides it.

Three rows are about the vendor rather than the factory. Open source versus open-core versus source-available decides what you may run, modify, and redistribute: open source grants all three; open-core keeps the enterprise features (usually exactly the SSO, RBAC, and audit rows) proprietary; source-available lets you read and often self-host but restricts commercial use. Maintainer and project-health risk asks whether a project with two maintainers and a venture-funded sponsor will exist when the three-year plan ends; bus factor, release cadence, issue response time, and governance model are the observable signals. Vendor-exit criteria are written before signing: records exportable in a documented schema, a replaceable harness, a control plane with an API rather than only a UI, and an evidence store readable without the vendor. Composition over inheritance is the design principle; exit criteria are its contractual form.

The technology landscape, dated

The stack a factory runs on changes quickly, so any list is a snapshot. The table below summarises the categories from Jay's platform and runtime glossary as of September 2026, with representative examples rather than endorsements. When a vendor says "we do X", the reader should know which row X lives in and what the factory expects of that row.

The same glossary places these technologies in a five-part enterprise composition: an agent runtime (harness plus execution platform) where agents execute; an enterprise knowledge layer where agents get trusted, permission-aware enterprise context; an Agent Factory where reusable capabilities are built and managed (chapter 11); the Software Factory that composes them with the existing supply chain into a governed path from builder intent to trusted production; and Mission Control, the control plane that governs the delivery. The one-line version: the Agent Factory creates, the runtime executes, knowledge grounds, the Software Factory delivers, and Mission Control governs. Language and framework choices are made per subsystem (Python where the model and retrieval work lives, TypeScript where the platform services and builder experiences live), not ideologically, and the lightest orchestration model that satisfies the workflow wins. Chapter 25 gives the twelve-layer view of the same landscape from the agent's side.

The AI Software Factory tech stack, in five layers

A second cut of the same landscape is by layer rather than by category, because that is how vendors position themselves and how a platform team ends up organising its evaluation. Read from the outside in: the outer layer is where trust is manufactured, the inner layer is where a person meets the system. Every capability named here has a chapter that owns it; the products are a September 2026 snapshot of who sells or open-sources it, not a recommendation, and none of them is where authority lives.

Three things this guide adds to the stack picture that vendor maps leave out. First, the control plane is not a layer you buy: Missions, Plans, WorkOrders, authority, evidence, and acceptance sit above all five layers and are the part an organisation must own (Chapter 13); no product in the table grants or withholds authority. Second, the Agent Factory is missing from the map: the catalogue that authors, versions, certifies, and retires agents, skills, and tools is a system of its own (Chapter 11), and treating it as a folder of prompts inside layer 3 is how skill drift starts. Third, layer 1 is two things wearing one label: telemetry and evals explain behaviour; independent verification decides readiness. A tracing product and a guardrail product can both be in place while nothing in the stack proves a change is safe to ship — which is why the guide keeps evidence (Chapter 27) separate from observability (Chapter 35).

Use the table for build-versus-buy the way the six questions above prescribe: for each layer, which product satisfies the capability, what the factory still has to own around it, and what evidence the vendor's claim rests on.

What breaks first at scale

The bottleneck in an agentic organization does not stay where it started. At the beginning it is generation: can the agents produce useful change at all? That constraint is gone within months, and four others take its place, usually in this order.

Cost breaks first, because experimentation outpaces attribution. Teams discover what agents can do faster than finance discovers what it cost, and the first sign is a bill nobody can explain by workflow. The cure is the cost-per-trusted-outcome ledger of chapter 35, in place before the experiments, not after.

Context breaks second. Enterprise repositories are enormous, knowledge sources are scattered across wikis and trackers and chat, permission boundaries cut through all of them, and a meaningful fraction of the documentation is stale. Retrieval that worked for one team's repository fails for the organization, and it fails quietly, by grounding confident answers in obsolete documents.

Supply-chain capacity breaks third. Pull requests, CI minutes, security scans, artifact storage, and review demand were all sized for human-speed generation. A factory that produces ten times the pull requests produces ten times the CI load and ten times the review requests, and the review side cannot scale linearly, which is the argument of chapter 39.

Trust breaks last and worst. One visible autonomous mistake undoes months of adoption, and the technical system recovers from it faster than the developers do. Everything in Parts IV and V exists to keep that mistake from being visible, or from happening.

The bottleneck will keep moving; design the factory to see where it moves next. That is why the four kinds of health in chapter 35 are all on the same dashboard.

Five lessons from enterprise scale

Large platform organizations that have run agentic delivery across many product teams converge on the same lessons, and they are worth stating before the roadmap because the roadmap assumes them.

1. The platform owns the workflow, not the model. Models change under you; the harness, context, evaluation, and authority around them are what you keep.
2. The paved road must beat the workaround. Adoption cannot be mandated. If the governed path is slower than a laptop and a personal API key, the laptop wins, and the platform learns about it in an incident.
3. Trust becomes the bottleneck as generation scales. Producing change stops being hard long before proving it is safe does.
4. Enterprise context and tools get complicated fast. Retrieval is a permissions, provenance, freshness, and relevance problem before it is a search problem; and the moment a model gets a tool, intelligence becomes authority.
5. Agent platforms become infrastructure earlier than expected. The reliability dimensions of chapter 36 are needed months before anyone plans to need them.

The sentence that holds the five together: do not just scale agents; scale the system that makes their work trustworthy.

From interactive sessions to managed agents

The five lessons describe what an organisation learns. One large engineering organisation has published where that learning leads once agents are in every engineer's hands, and it is the clearest public statement of the strategic shift this chapter's maturity model implies. Its framing organises agent usage into four layers, from the most general to the most specialised. At the bottom is the interactive developer session: an engineer at a terminal, steering a coding harness turn by turn, with the harness's defaults and the engineer's habits deciding what each task costs. At the top is the managed agent: a specialised, headless agent with one job, its own benchmark, its own model, and its own spend tier, started by the platform or by an event rather than by a person. The intermediate layers are the progressively more constrained forms in between, such as reusable skills invoked inside sessions and sessions that agents start on an engineer's behalf. The rule that orders them: the higher the layer, the more control the organisation has over cost, quality, and model selection.

The strategic claim that follows is the one to retain. A managed environment gives complete control over model routing, the execution harness, and spend, and optimising a fleet of specialised managed agents, each with its own benchmark and Pareto-efficient model, is more cost-effective and more scalable than optimising individual terminal sessions across thousands of engineers. Interactive sessions are where adoption happens and where the cost equation's first two terms grow (chapter 8); managed agents are where the middle terms can be engineered down, because one team owns the whole configuration. The interactive layer is not abandoned; its defaults are set centrally through the unified wrapper of chapter 15, and the session-analysis dashboard educates engineers about what their sessions cost. But the organisation's optimisation effort concentrates where control is.

Each managed agent gets its own roadmap, and the roadmap has the same three steps every time: define the target outcome metrics for the agent's job; build the evaluation benchmark from the agent's real work; select the Pareto-optimal model on that benchmark, and re-select as the frontier moves (the method is in chapter 21). Doing this for one agent per SDLC stage is how each stage moves up the maturity model above: an agent with a benchmark and retained outcome evidence is a corridor with proof, and a corridor with proof can be promoted.

The published examples of managed agents map onto the stages a factory already knows: code review on every pull request; self-healing of CI failures; end-to-end pull requests with visual validation of the result; on-call alert triage; bug debugging; and code maintenance. Every one of them carries human review or escalation, which is the on-the-loop control mode of chapter 8, and the agentic merge queue of chapter 39 is where several of them meet.

The scale that organisation reports is worth quoting, with the caveat that it is one organisation's published measurement and not a target for anyone else: more than 70 percent of its pull requests attributed to local or cloud agents; more than 3,600 agent skills built by engineers across the SDLC; more than 30,000 skill executions a day; and a growing share of sessions started by managed agents rather than by people. Read against the maturity model, that is an organisation operating many Level 3 corridors at once, with the managed-agent fleet as the mechanism by which each corridor earned its evidence.

The first year and the next five

The mission plan behind this guide lays out a twelve-month path that follows the corridor logic above, in six phases.

The pilot phase is the Observe-through-Delegate stretch of the adoption path, run on purpose; hardening is where the enterprise checklist gets filled in.

The five-year roadmap extends the same shape. Year one proves the model: an MVP, one repeatable workflow, measurable results, design partners, a category narrative. Year two proves repeatability across workflows, repositories, and teams, improves governance, establishes ROI, builds a small expert team, and earns early revenue or a major internal mandate. Year three proves enterprise scale: multiple business units, enterprise system integration, strong security and compliance, organization-level productivity evidence, public recognition for the operating model. Year four leads the category, expanding beyond development into operations, incidents, security, and platform work, building an ecosystem of agents, models, tools, and workflow templates, and publishing the definitive playbook. Year five is the operating standard: the control plane becomes an enterprise control plane and the human-agent software factory a recognized field. Each year's claims rest on the previous year's retained evidence, which is the maturity model applied to the roadmap itself.

The first ninety days, in outline

For the leader who inherits an organization already using agents, the twelve-month plan starts with a ninety-day stretch whose shape is the same in every enterprise. Chapter 43 carries the full version; the outline here is enough to see how it connects to the adoption path above.

Two things are deliberately absent from the first ninety days: a prebuilt architecture carried in from elsewhere, and a migration of existing agents. Also absent: scaling the team around speculative boundaries, adaptive model routing before evaluation data exists, and recursive self-improvement before a trustworthy baseline. One complete workflow exposing real weaknesses beats ten disconnected demos. And the closing caution: the patterns transfer; the implementation has to be yours.

Explaining it to eight audiences

Adoption is a persuasion problem as much as an engineering one, and each audience needs the same system in its own terms.

To a CEO, the factory reduces the time between strategy and customer value; the company executes more continuously while humans stay accountable for consequential decisions.

To a CFO, it improves output per engineering dollar by automating repeatable execution, reducing rework, shortening cycle time, and allowing growth without headcount rising at the same rate; the chargeback and showback controls above are what make that claim auditable.

To a CTO, it is a governed platform for orchestrating AI agents across the lifecycle, with permissions, evaluations, human approval, auditability, and production feedback built in rather than bolted on.

To a Chief Product Officer, it shortens the delay between customer insight and validated product learning; product teams test smaller hypotheses faster while quality controls hold.

To a security leader, every agent operates through a defined identity, minimum permissions, approved tools, isolated environments, policy checks, and auditable actions; the control checklist above is the questionnaire answered in advance.

To an engineering manager, the role shifts from coordinating repetitive execution to defining outcomes, managing risk, developing people, improving systems, and reviewing the quality of decisions.

To a developer, the aim is not to remove judgment but to remove repetitive work and waiting, so time goes to architecture, product decisions, hard debugging, and technical creativity.

To a board, it is an engineering-leverage strategy with a governance model: faster delivery and better economics without accepting uncontrolled operational risk, and the credible message is "we expand proven corridors", never "AI transforms everything".

How to build it

Assess

1. Pick the scope: one repository, workflow, risk class, or environment. Never rate "the company".
2. Score the eight dimensions using retained proof only, citing the artifact for every score.
3. Take the minimum across material dimensions as the level; let hard gates (fabricated evidence, unauthorized action, security bypass) cap it regardless of the rest.
4. Name the limiting dimension and the smallest 30-day experiment that would move it.

Adopt

1. Choose one repeatable, valuable, reversible corridor; governed issue to validated PR is the default.
2. Baseline it: lead time, change failure rate, human effort, wait time, satisfaction, control escapes.
3. Walk the seven steps in order; in shadow, record disagreement and calibration.
4. Write the promotion rule and the immediate-demotion triggers before the first run.
5. Stand up the adoption operating model (design partners, builder listening sessions, forward-deployed engineers, champions, weekly usage reviews, paved paths, migration support, deprecation strategy) and the dashboard carrying the twelve adoption metrics.
6. Change roles explicitly, train for them, and protect the reporting of escapes.

Choose infrastructure

1. Decide layer by layer whether to buy, build, or compose, answering the six questions (differentiation, control, external maturity, switching cost, total cost of ownership, speed of learning) in writing. Treat the harness as replaceable and the control plane as the layer you will most likely adapt.
2. Bring existing agents in through the gravity-well order: model gateway, common evaluation, observability, governed tools, runtime. No migration mandate.
3. Publish the contribution model (centralized contracts and paved road; federated domain skills, knowledge, agents, acceptance criteria) and the three release clocks with their controls.
4. Design tenancy at all four layers: identity, data, resources, memory.
5. Fund forward-deployed engineers with an explicit rule that a third repeated integration becomes a platform capability, and measure how quickly teams stop needing them.
6. Choose the deployment topology from residency, networking, and key-custody requirements, not convenience.
7. Fill the enterprise control checklist before the questionnaire arrives; for each row name the mechanism and the retained evidence.
8. For every vendor and open-source dependency record licensing model, project-health signals, upgrade policy, support terms, and vendor-exit criteria (exportable records, replaceable harness, API surface, readable evidence store).
9. Date the landscape table and revisit it quarterly.

Communicate

1. Prepare the eight audience paragraphs for your own factory, each grounded in a retained metric.
2. Build the maturity evidence dashboard: per repository and workflow, prerequisites, last accepted proof, incidents, exceptions, autonomy ceiling, next gate.

Failure modes

Enthusiasm rated as maturity. The rating reflects model quality, demo impressiveness, or percentage of AI-written code. Ask for the retained proof behind each dimension; if the answer is a slide, the rating is a slide.

One label for the enterprise. A Level 3 documentation bot lifts the whole company to "Level 3" and a payments repository inherits authority it never earned. Scope every rating and publish the limiting dimension per scope.

Shadow mode as delay. Policy decisions are computed and nobody compares them with human decisions. The absence of a disagreement metric is the tell; calibration is the exit criterion.

Compliance theater. The assessment reviews policy documents while the real workflow bypasses them. Assess a random real WorkOrder against the policy; rate workflows, not documents.

Promotion without a rule, demotion that waits for the score. A corridor is promoted because a quarter ended, or a fabricated-evidence finding is averaged away. Look for the promotion decision record and its evidence; check that hard-gate findings exist in the model at all.

Hidden cost. Agent hours saved are reported while review and incident hours grow. Measure total human and operational effort against the corridor baseline.

Buying the whole stack by accident, or a vendor without an exit. A team buys orchestration and discovers it has also bought the harness, the compute, and a residency problem; or records live only in the vendor's UI. Check each layer against the exit criteria at contract time and attempt an export before signing.

The migration mandate. Existing agents are ordered onto the platform, the teams that own them dig in, and the platform's first year is spent in negotiations instead of on workflows. Offer the model gateway first and let the value pull.

The permanent consulting layer. Forward-deployed engineers become the way anything gets done, each integration is bespoke, and the platform never learns what it is missing. Count repeated integrations; the third one is a platform ticket. Measure teams that no longer need help.

Building for, not with. The embedded engineer ships the integration alone, the team cannot maintain it, and nothing is productised. Detect by asking who in the product team can extend the artifact after the engineer leaves. Fix by making co-building and builder enablement the deliverable, and by requiring every embedding to end in a contributed reusable artifact or a written reason why not.

Local factories suppressed or absorbed. The platform team either bans product organizations' own factories or takes them over wholesale, and loses the domain knowledge either way. Detect by local innovations that never reach the shared platform, or by product teams that stopped building. Fix with the embed-and-contribute loop: keep what is local, productise what generalizes.

Owning the oven. The platform team builds its own agent loop, sandbox provisioner, or workflow engine while its control plane, evaluation sets, and Builder Experience wait. Detect by comparing platform headcount on commodity layers with headcount on differentiated ones. Fix by naming the two bands, placing the platform boundary deliberately, and adopting behind standard contracts.

Adopted without an exit. A commodity component is chosen on features alone; licensing, community health, operational burden, exit cost, and vendor independence were never scored. Detect by attempting an export or a swap in a test environment. Fix by scoring the five before adoption and rehearsing the exit while it is still cheap.

One release train. Model updates wait for a quarterly runtime release, or a runtime contract changes on a model's cadence and breaks running work. Separate the three clocks and give each its own control.

Building everything first. The platform team ships a universal memory layer, adaptive routing, a multi-agent orchestrator, and a hundred generic skills before a single workflow runs end to end. Each is a hypothesis without production evidence. Prove one path with design partners; protect the seams (identity, interfaces, policy, evidence, evaluation, versioning); do not generalize before the abstraction is earned.

Unmaintained dependency. The harness or framework the factory depends on stops releasing. Review project-health signals quarterly; keep the harness replaceable.

Questionnaire surprise. The security review arrives and the factory has no answer for SCIM, tenant isolation, or legal hold. Fill the control checklist before the pilot and treat each row as a factory requirement, not a sales obstacle.

In Mission Control

The v1 assessment was pinned at a490648, with staged-only work excluded from any maturity claim. At that commit Mission Control expressed several Level 2 foundations: governed Missions, Plans, and WorkOrders; Tasks and Attempts; leases; execution manifests; receipts; approval records; policy concepts; model routing; and operator views, with study branches adding stronger sandbox and publication controls. It had not earned a product-wide Level 3 claim: QC adapters were mocked, release automation ran in shadow mode, policy configuration had blocked the golden path, and the complete browser-initiated flow lacked accepted retained evidence. The honest rating was capability-specific: architecture and domain model approached Level 2/3 design; the supported end-to-end operating proof remained below that.

The later study commit d902fae adds material for the enterprise checklist: company, workspace, and repository boundaries with membership authorization, scoped records, and cross-scope tests (tenant isolation); server-side permissions, risk classes, policy envelopes, approval records, and separation of duties (RBAC and governance); feature flags, immutable versions, and migration guidance (upgrade policy); presentation modes that do not alter authority. Fleet-scale and cross-organization load are not established by repository tests, broad adoption remains a future operating proof, and the production admission packet remained blocked by operator configuration. Against the four tenancy layers, identity and data scoping are the layers with evidence; resource fairness across organizations and organization-scoped memory promotion are not demonstrated. Mission Control is an active personal project with the control-plane architecture and substantial deterministic qualification implemented; it is not positioned as fleet-scale production running hundreds of live agents, and no contribution model, forward-deployed function, or three-clock release process exists around it.

Future: a maturity evidence dashboard by repository and workflow (prerequisites, last accepted proof, incidents, exceptions, autonomy ceiling, next gate). The first promotion target remains governed issue to validated pull request; deployment autonomy waits for signed artifact identity, production observation, and rollback proof. SSO/SCIM federation, BYOK, residency controls, DLP and egress policy, and chargeback are not claimed.

Retain this

• Maturity is observable capability with retained proof, scored per scope and per dimension; the level is the minimum across material dimensions, hard gates override averages, and a critical event demotes or quarantines immediately. Rate through two lenses: the six authority levels (how much has been safely delegated, with proof) and the skills → loops → factory ladder — machinery without evidence and evidence without machinery both stall.
• Advance through one corridor at a time along seven steps: Observe, Assist, Delegate, Shadow govern, Enforce, Conditionally automate, Scale. Write the promotion rule and the demotion triggers before the first run; failures decay in scores but never leave the audit.
• Change roles, not only tools; reduce approval fatigue with evidence-centered review, never by deleting accountability. Bring existing agents in as a gravity well, not a migration mandate — model gateway, then common evaluation, then observability, then governed tools, then the runtime.
• Build, buy, and compose layer by layer on six questions (differentiation, control, external maturity, switching cost, total cost of ownership, speed of learning): build where you need durable leverage, adopt where abstraction preserves optionality. Centralize undifferentiated complexity; federate differentiated expertise. Score adopted components on licensing, community health, operational burden, exit cost, and vendor independence, and keep the platform boundary movable.
• Forward deployment accelerates self-service, it does not replace it — co-building and builder enablement are the deliverable, and the same integration built three times is a missing platform capability. Design tenancy at four layers (identity, data, resources, memory) and run three release clocks (models and routing; skills and definitions; runtime and contracts), all explicitly versioned.
• What breaks first at scale: cost, then context, then supply-chain capacity, then trust — the bottleneck keeps moving. Scale the system that makes agents' work trustworthy, not just the agents; the paved road must beat the workaround.
• Agent usage runs in layers from interactive sessions to managed agents; the higher the layer, the more control over cost, quality, and model selection, and optimising a fleet of specialised managed agents beats optimising thousands of terminal sessions. The credible executive message is "we expand proven corridors," and the factory is a continuum where engineers eventually spend more time engineering it than doing the work it automates.

Go deeper

• Related chapters: 2. The factory in one view · 3. First principles · 7. Governance, policy, and risk-proportional approval · 8. Economics, metrics, and human attention · 17. Development environments, sandboxes, and compute · 25. The 12-layer production AI agent stack · 33. Security · 34. The factory as a platform · 40. Governed learning and compounding engineering · 43. Mastering the factory · 44. Where this is going
• Glossary: maturity level, corridor, shadow governance, BYOC, vendor-exit criteria, commodity layer, differentiated layer, exit cost, adoption wedge
• Related for the two bands and the loop: 11. The Agent Factory for where productised artifacts live; 26. Autonomous engineering workflows for the wedge workflow.
• Case studies: Mission Control implementation maturity and evidence map · Capability, workflow, and admission map · Coverage and maturity
• Sources: HumanLayer × BAML livestream, "Software factory design patterns" (Dexter and Vaibhav), on composition over inheritance, outposts, and why there is no open-source control plane; Jay West, "The 12-layer production AI agent stack" coverage audit, section 13 (enterprise and open-source infrastructure); Jay West, agent platform and runtime technology glossary; Jay West, AI Software Factory mission (twelve-month plan, five-year roadmap, adoption metrics); Jay West, audience-framing notes (the eight audiences); Jay West, factory architecture notes, on build versus buy, the contribution model, existing agents, forward-deployed engineering, multi-tenancy, release clocks, scale bottlenecks, the five lessons, the first ninety days, commodity versus differentiated layers and the platform boundary, and the forward-deployed loop (embed, observe, co-build, productise, contribute, reuse, scale)
• Public sources: Uber Engineering, Running a Software Factory Efficiently at Uber Scale (2026) for the four layers of agent usage, the shift from interactive sessions to managed agents, the per-agent roadmap, the managed-agent examples, and the published scale figures; The 4 Layers of an Agent System Explained (public post, 2026) for the meta-harness as the governance layer across many harnesses, which is what makes a managed-agent fleet operable; public practitioner talks, 2026, for the skills → loops → factory maturity ladder, the factory as a continuum, and the observation that engineers come to spend more time engineering the factory than doing the work it automates
• External canon: DORA delivery metrics · NIST Secure Software Development Framework · Team Topologies (Skelton and Pais) · Google SRE