The Federated Factory at Enterprise Scale

Our position. We hold that nobody can buy or copy a factory: it is coupled to the codebase and conventions it runs on, so each organization builds it as a capability (You can’t copy someone else’s factory (opens in a new tab)).

That is why building one factory and running many are different design problems. An enterprise is not one Stripe but dozens of small Stripes, and the platform that serves them needs a shape of its own. The tier model and the capability split follow the vendor whitepaper Software Factories at Enterprise Scale.

Why don’t the published factories transfer to an enterprise?

The published factories all run in conditions almost nobody shares. Stripe’s Minions sit on one monorepo with roughly three million tests and around 500 internal MCP tools that human engineers built over half a decade. OpenAI’s harness team had one codebase and one toolchain to itself. Ramp’s Inspect covers frontend and backend repos in a single org. The throughput comes from the system, and the system was put in place slowly, long before the agents arrived (the anatomy of each is on Software Factories and Harness Engineering).

A real enterprise has product lines at different maturities, regulated and unregulated estate, teams in different countries, and acquisitions still running their own conventions. Even a single-product company at scale has platform, product, data, ML, and security teams whose demands on the harness are genuinely different.

Why do one central factory and one factory per team both fail?

One central factory for everyone. It fits the team that built it. For everyone else the conventions, test maturity, risk profile, and stack are wrong, so teams either reject it (the platform becomes shelfware) or adopt it grudgingly and lose velocity to the impedance mismatch. Either way the central team takes the blame. This is not an execution problem. A platform that fits a new TypeScript core with a modern test suite cannot also fit a fifteen-year-old Java monolith with sparse coverage, and forcing it produces something that serves neither.

Every team builds its own. No shared identity directory, no shared MCP registry, no shared audit log, no shared blueprint library. The maintenance cost is paid many times over, security and compliance fragment, and the lessons one team learns never reach the next. The reason to be one organization disappears.

What are the three tiers?

The middle path assigns each capability to the layer that can actually own it, with an explicit contract between layers.

• Platform tier is the central control plane and runs once: the versioned blueprint registry, the scoped tool router deciding which MCP tools each agent role can reach, the identity directory, and the immutable audit log. A secure API proxy sits below it and holds the real credentials. Agents never see them; the proxy injects scoped tokens at egress and writes the call to the audit log on the way back.
• Domain tier holds context shared across clusters of teams. A domain can be regulatory (every team touching payment data shares PCI blueprints), technical (everyone on the new core stack), business, or geographic (EU teams sharing GDPR patterns). It is plural by construction: teams sit in several domains at once.
• Team tier is where execution happens: local sandboxes, team-owned MCP servers, local conventions on top of forked blueprints.

The most important detail is in the audit log. Every agent carries its own non-human identity, distinct from any human user’s, and every logged action preserves both: which human delegated the work, and which agent executed it. Collapse the two and every action shows up as either the proxy or the delegating human, and accountability disappears at agent volume.

Runtime is chosen by what the work does, not by how heavy it feels. Anything that touches a filesystem, runs a shell, installs packages, or compiles needs a kernel underneath it: a container, a microVM, or a userspace-kernel sandbox. Lightweight edge isolates boot in milliseconds and cost a fraction, but they have no filesystem and no shell, so they fit stateless data transformation and API routing, not coding work. Interactive work runs in a local devbox. The platform supports all three because the blueprint runtime is decoupled from the execution layer.

Which tier owns which capability?

Six capabilities show up in every working factory: orchestration, isolated environments, context and memory, validation, governance, and learning. At enterprise scale the question for each is not whether you need it but which tier owns it.

Two rows carry the argument. Validation looks the same at every tier and differs in specifics: a change to a payment system must pass PCI verification before a human sees it, a change to a marketing site must not. The harness pattern is shared, the checks are local. Learning propagates upward while the data stays put: when a team finds that a review pattern catches 30% more bugs, the lesson is anonymized into the domain reference and other teams adopt it without ever seeing the originating code. Standardization happens through demonstrated value, not mandate.

Blueprint forks are observable rather than forbidden. One team running a custom build-and-deploy blueprint while every other team in the domain runs the canonical version shows up in the registry, which turns “should this fork propagate or be retired” into a data question instead of an opinion.

Why is MCP the seam between the tiers?

The consequential architectural decision is making MCP the standard interface between agents and every internal system. The accounting system, the customer database, the CRM, the deployment pipeline all get wrapped as MCP servers, each exposing a small well-scoped tool set, each owned by the team that owns the application, so the central platform team never becomes the bottleneck for new integrations. A central registry knows which servers exist and who owns them; the gateway sits in front of every call, checks RBAC, scrubs credentials, and logs the transaction.

The gateway also filters the tool surface per agent, and that is a security control as much as a reasoning one. An agent that needs three tools should not see a catalogue of four hundred: oversized catalogues degrade model reasoning and widen the attack surface. The NSA’s information sheet on MCP security names this directly, alongside unverified task propagation between MCP servers and session reuse through unscoped tokens. These are governance problems rather than protocol problems, and the gateway is where they get solved.

This is a real commitment. Every team building an internal application accepts a contract: expose the service through MCP, conform to the schema, accept the auditing. The payoff is that every agent in every team can use the application immediately, with governance enforced by the path rather than by checklists. Without that commitment the platform fragments back into point integrations and the network effect is gone.

How do two factory patterns share one platform?

The dark-factory pattern works, and it works only under preconditions: a current test suite, a standardized dev environment, conventions encoded in an AGENTS.md. Greenfield work usually has them. Brownfield work, the legacy estate that arrived through acquisition, usually does not: thin tests, conventions in people’s heads, a bespoke environment. Running an unattended agent against that produces broken PRs at scale.

Both positions are correct, for different parts of the estate. The honest design runs both: dark-factory blueprints against repos that meet the preconditions, interactive-assistant blueprints against the ones that do not, on the same runtime, with the classification held as metadata in the blueprint registry. Promising dark-factory autonomy on a legacy estate is the most common way these initiatives lose credibility, and it is entirely avoidable.

What happens when an acquisition joins the platform?

Onboarding a team becomes procedural once the platform exists: stand up a tenant, ingest the team’s operational documentation into its MCP layer, grant access to the blueprint libraries, and let the team keep working its way while adopting standards where they earn it. A new internal team, a new product line, a regional office, and an acquired business all get the same flow.

The economics are most visible for acquisitions, where traditional integration of an engineering organization consumes 12 to 24 months and a large slice of central IT capacity. With the platform in place, the operational part, the part that makes agents work against the acquired codebase, becomes a question of weeks. The platform absorbs new teams without proportional growth in central headcount. That claim comes from the vendor and has no published independent replication, but the mechanism is legible.

What makes the platform hard to copy?

Generic engineering practice is being absorbed into foundation models quickly. The operational knowledge inside an organization is not: the particular decisions this codebase has made, the vendor relationships this team relies on, the institutional memory of thousands of design discussions. None of it exists in any public corpus and none of it ever will. Encoding it into the team-tier MCP servers is what compounds. It is also why the advantage cannot be bought: the architecture, the context base, the validation harness, and the team’s understanding of what agents can and cannot do all have to be built over time.

Which problems are still unsolved?

The five open problems at single-team scale (memory and context at scale, evaluation versus reality, specification quality, governance velocity, the talent pipeline) all survive federation. Three more appear on top.

• Cross-team knowledge propagation without data leakage. The lesson should travel; the data behind it must not. In the published implementations the anonymization step is human-mediated and slow. This is also the problem that decides how much value federation actually delivers, because the alternative is every team learning independently, which wastes the network effect the platform was justified by.
• Fork versus adopt. When a team forks a platform blueprint, is that valid local adaptation or tech debt? The answer comes from judgment, and getting it wrong costs years of parallel maintenance. The plausible heuristic, measuring whether the fork produces better outcomes than the canonical version, needs measurement infrastructure that does not exist in any published implementation.
• Identity at federation scale. The auth model is simple in principle: the agent inherits the user’s permissions and nothing more. Then a user works across two teams, a domain blueprint needs to read from three, and an internal auditor needs read access to a team’s data without that team seeing the audit.

How do you start?

Do not build the federated platform in one go. Build one factory against one team, prove it works, and design the Platform tier alongside it so the second team joins as a tenant of an existing platform rather than as a copy of the first team’s bespoke build. By the third team, the federation effect should be visible: shared blueprints adopted on demonstrated value, lessons crossing the domain layer, the MCP registry growing as each team wraps its applications.

Four field principles hold at every scale: use boring, well-documented technology because agents work more reliably against it; keep context in the repo because anything outside it is invisible to the agent; verify away from where you generate because agents optimize for any signal you give them; and treat the agent platform as a product. At enterprise scale, add the fifth: the platform spans many teams but governs from one place.

Related

• Federated Context Platform for Enterprise AI Agents: the same federation applied to context rather than to the factory.
• The platform layer: the gateway and registry seen from the context side.
• Security and Runtime Isolation: the gateway, sandbox and audit controls in security terms.
• The enabling environment: what each team tier needs before its agents can verify their own work.
• Dark Factory Patterns: the patterns for the repositories that meet the dark-factory preconditions.
• Build or Buy Framework: how to decide which parts of the platform to build.

Resources

Research

• NSA Cybersecurity Information Sheet on MCP security (opens in a new tab) - Government guidance on MCP threat surface: oversized tool catalogues, unverified task propagation, unscoped session tokens.
• Software Factories at Enterprise Scale (opens in a new tab) - Vendor whitepaper on the three-tier federated platform, the capabilities-by-tier split, and MCP as the federation seam; gated behind a form.