Engineering
Enterprise
New
By Factory, Nikita Lilichenko - August 3, 2026 - 8 minute read -
Share
How Factory's organization model gives enterprises central governance with explicit organization boundaries for access, integrations, policy, spend, and data residency.
A large engineering organization is a complex orchestration. Dozens of departments, subsidiaries, and regulated groups operate at once, arranged in nested hierarchies and distributed across countries, regions, and legal jurisdictions, each carrying its own requirements for access, integrations, policy, usage, and data residency. No two are organized the same way.
Building a software factory that fits inside that environment is a challenge. AI agents act autonomously, use credentials, consume spend, and operate inside customer environments. As such, any deployment has to respect every access boundary, residency requirement, and policy the business already enforces. It also has to be malleable enough to adapt as the structure changes, instead of forcing the business to reshape around it.
The Factory Organization Model provides that flexibility. One commercial relationship and one control surface sit above distinct organizations for the parts of the business that need to operate differently, and the model flexes as the business does: organizations can be created, nested, and scoped to match how the company runs today and reshaped as it changes. It gives teams a way to expand AI development beyond an initial group without losing control of governance, residency, spend, or access.
The result is a governable software factory: central control at the top, explicit boundaries where teams differ, and one structure that scales from an initial group to the entire enterprise.
Factory gives companies controls to separate the enterprise account from the organizations that operate within it.
The enterprise account is the commercial and administrative umbrella: the customer relationship, billing, identity configuration, and enterprise-level administration.
An organization is the operating boundary. Users, integrations, policies, model access, usage limits, membership, and regional settings are all defined at the organization level, and integrations in particular are defined per organization only.
Organizations can be created under the enterprise account or nested under another organization, so the hierarchy reflects business structure while every operating boundary stays explicit.
A parent organization can represent a major operating boundary, such as a region, platform group, or delivery practice. Child organizations sit beneath it when a narrower group needs its own membership, admins, integrations, model policy, usage limit, or residency setting. Enterprise admins keep centralized visibility and governance across the hierarchy, while each child organization can carry different controls when one shared configuration would be too broad.
An organization can represent a department, business unit, region, subsidiary, agency, client delivery group, regulated environment, or deployment environment. Organizations are best used when a group needs a real boundary:
The examples below reflect where we see this model deliver the most value, drawn from working directly with large, global companies every day to configure Factory around how they actually operate. Each keeps central governance in place while giving operating groups their own boundaries.
A large, highly regulated financial institution often needs to separate regions, regulated workloads, shared platform groups, and pre-production environments while keeping billing, identity, and governance centralized.
A consulting firm that organizes by project can keep one enterprise account while giving each project multiple scoped organizations for delivery, client-specific integrations, and controlled environments.
A multinational telecom operator may organize Factory by geography, operating company, and infrastructure environment, giving each boundary its own residency, administration, integrations, and controls.
Some companies want their most sensitive work to run entirely through their own keys or a customer-hosted gateway (BYOK), while keeping lower-risk work on Factory-managed inference. Because model access is set per organization, that split is clean: a high-sensitivity organization can be restricted to BYOK or customer-hosted models, while other organizations use Factory inference under the same enterprise account. Sensitive projects stay isolated behind the customer's own keys, and everything else runs on Factory without forcing the whole company into BYOK.
Enterprise admins manage their organization hierarchy in the Enterprise Admin Console in the Factory app, a dedicated surface for running the entire deployment from one place. It gives them a single view of every organization and its usage, along with billing, identity, and per-organization controls and limits.
From there, admins create organizations anywhere in the hierarchy, assign each to a global or regional deployment to meet data residency needs, and manage identity through SSO, domain verification, and SCIM-based Directory Sync, all without owning each organization locally. Billing stays tied to the enterprise account as Factory expands.
The enterprise account, nested organizations, and the Enterprise Admin Console are how Factory runs in production today, and every boundary in the Console maps to a concrete control.
Identity flows through SSO, SCIM-based Directory Sync, and domain verification. Data residency is set per organization across global and regional deployments. Model access, policy, usage limits, and integrations are all governed at the organization level, including BYOK and customer-hosted inference for the work that requires it. Billing, directory, and visibility stay centralized on the enterprise account.
The result is a software factory a company can actually govern: central control at the top, real boundaries wherever access, policy, model choice, spend, or residency differ, and one structure that scales from an initial group to the whole organization.
The Factory Organization Model and the Enterprise Admin Console are available to enterprise customers. Learn more in the docs: Organization Model, Organizations, and Admin Console.
start building
Start building
