The first Software Factory is usually local. A team has a class of work it wants to hand over, so it gives an agent the repository, runs the harness somewhere sensible and connects the tools it needs. Engineers are still close enough to the setup that they can fill in missing context themselves.
Early on, much of that setup can remain provisional.Some of it will disappear as the team figures out what the workflow actually needs then people start reusing the bits that worked.
Another team copies an MCP. A second factory needs the same internal service but with different permissions. Architecture guidance gets pulled into a workflow it wasn’t written for. Credentials work differently because another factory happens to run somewhere else.
A few months later, some things are still clearly team-specific and others have become dependencies without anyone really noticing.
Teams can keep control of how their factory plans, evaluates and escalates work.
Model access, credentials, shared integrations and run evidence become harder to treat as local once other factories rely on them.
A Software Factory eventually becomes infrastructure
An MCP written for one workflow can be changed casually because its author controls both ends. If five factories depend on it, the same edit has a different consequence even if nobody ever sat down and declared it part of an internal platform.
Architecture guidance can end up there too. So can credential handling.
Reuse itself isn’t enough to tell you much. Two factories may use similar code and still be better off owning it separately. Something with one consumer may deserve much tighter control because it carries sensitive access.
Who else gets hurt when it changes is closer to the question we’d ask.
There’s a cost on the other side too. Teams remember when something they could change themselves in ten minutes became a request to another group. Sometimes maintaining two versions really is cheaper than coordinating one shared version.
We’d expect enterprises to discover some of these boundaries late. The first sign that an integration needed an owner may be the migration where nobody knows who is supposed to update it.
Different teams need control over the same runtime
Take an internal account-management application. The agent can inspect the frontend and backend repositories and run CI. To test the change properly it also needs a browser against staging and a few operations from an account service.
The engineering team mostly wants the workflow to finish. The account-service team knows its API contains operations the factory has no reason to call. Security cares where the browser can go. A platform team may maintain the MCP because several factories now use it. There may also be restrictions on which models can process the repository.
The people designing the workflow shouldn’t also be able to grant it whatever access makes implementation easier.
Early factories blur that separation because there may be no practical reason not to.
Not initially at least.
One engineer owns the workflow, tool configuration, and credentials. Everybody involved understands what it can do.
A second team copies the account integration later. It needs another operation and adds one. Nothing necessarily goes wrong.
Months later the account service changes, and somebody finds three versions of the integration, two credential schemes and an old factory in another repository that is still calling the deprecated API.
Pulling some of that into a common runtime now sounds sensible. It also means the factory team can no longer necessarily fix its own problem.
If a legitimate exception takes three weeks, somebody will eventually find another route. If exceptions are easy, permissions have a habit of surviving the reason they were granted.
Governance has to sit inside execution
A browser that may reach staging but not production shouldn’t be able to reach production. If the workflow needs four operations from an internal service, expose four. Repository credentials can permit reads and pull requests without permitting a direct push to the default branch.
The harness running in its own environment also means the enterprise can expose approved browsers, APIs and business systems there rather than relying on whatever happens to be available on individual developer machines.
Prompts can tell the agent about those restrictions. They’re not where we’d put the restriction itself.
That gap between adoption and enforcement is already showing up in enterprise security data. IBM’s 2025 Cost of a Data Breach research found that 63% of breached organizations either lacked an AI governance policy or were still developing one. Among those that experienced an AI-related security incident, 97% lacked proper AI access controls.
The annoying part comes later. Somebody grants additional access for a run, the work gets done, and six months later the permission is still there. At minimum, the run should tell you how it got there.
Shared environments and assets stop every team from rebuilding the stack
The wiki says service A. Everyone on the team uses service B.
An old API still works, but the platform team has been trying to retire it for a year. A library appears all over existing repositories even though the architecture team doesn’t want it used in new ones.
Experienced engineers absorb this kind of mess without noticing how much they compensate for it. They remember the discussion where a decision was made, know which wiki page nobody trusts and recognize that a pattern in a five-year-old repository is history rather than current guidance.
An agent gets whatever version of that history the factory can make explicit.
This is where we think context engineering gets reduced too easily to retrieval. Sometimes retrieval works exactly as intended and the information retrieved is still wrong, stale or missing the qualifier that everyone on the team happens to know.
The enterprise problem starts when that guidance is reused across factories. What was once a local workaround can become shared infrastructure without anyone explicitly deciding to own it.
An MCP might start as a helper for one factory. Six months later five factories depend on it and its original author has moved teams. The service changes, and suddenly people want to know which version everyone is using, whether the old behavior can remain available and who is supposed to test the replacement.
At that point it’s become an internal product, whether anyone intended to build one or not.
Architecture guidance can acquire the same responsibility without looking like software. One update can remove a recurring mistake from several factories. A bad update can spread just as widely.
A bad shared update worries us more than a few duplicated prompts.
A note beside one workflow feels provisional. Put the same rule into centrally maintained “enterprise architecture context” and it starts to look authoritative. The agent won’t know that three engineers privately think one paragraph is outdated.
We wouldn’t turn all of this into one giant context bundle. Some knowledge belongs to a repository. Some skills make sense for one type of work. An MCP with enough consumers may need an owner and versions. There are going to be awkward cases in between.
And sometimes there’s nothing particularly wrong with the factory. If the real engineering rule is still “ignore the docs and ask Sarah,” somebody probably needs to fix the docs.
Observability and FinOps make factory activity measurable
A factory can close plenty of tickets while retrying tools, producing work reviewers repair later or quietly sending difficult cases back to engineers. PR count won’t tell you much about that.
At enterprise scale, the value of observability is that the same evidence can be used across engineering, platform, security and finance rather than disappearing inside one team’s factory.
That evidence can come from the execution layer itself. Orq.ai can receive OpenTelemetry traces through its OTLP endpoint:
exporter = OTLPSpanExporter( |
That gives the shared runtime a common trace stream across agent steps, model calls and tool use, rather than leaving each factory to invent its own instrumentation.
In the FinOps Foundation’s 2026 survey, 98% of respondents said their teams now manage AI spend, up from 63% a year earlier. Granular monitoring of AI spend was also the most requested new tooling capability.
The cost data is useful beside those patterns.
A run used $4.87 of model and tool spend. Doesn’t mean the bug cost $4.87 to fix. An engineer may have spent forty minutes rescuing it.
The change may have saved several hours. QA might send it back tomorrow.
After enough runs you can at least ask whether the expensive planning model is reducing rework, whether a cheaper model is creating retries somewhere else, or why one integration is consuming much more than expected.
That’s about as far as we’d take the economics from the trace alone.
Sovereignty means keeping control as models, harnesses, and clouds change
The stack is unlikely to stay fixed. Orq’s Software Factory direction is explicitly composable across model, harness and infrastructure rather than assuming one combination forever.
Take an early factory that runs in the team’s existing cloud environment with an approved harness. A year later, another harness works better for part of the workflow, a regulated workload needs to run closer to private infrastructure, or a different model becomes a better fit for some work.
Some things will need rewriting. We wouldn’t try to hide that.
The surprises are elsewhere. The old harness disappears and repository restrictions disappear with it. Moving execution breaks run evidence the security team has started relying on. Months of architecture guidance turn out to live in provider-specific configuration.
Building portability layers around everything can easily become its own architecture project.
But changing the model shouldn’t unexpectedly change whether the account-management factory can delete real accounts. Moving the workload shouldn’t turn staging access into production access.
The rest you may only find out when you actually try to move it.
At small scale, a Software Factory can live almost entirely inside one engineering team. But at enterprise scale, the dependencies around it stop being local.
Access, shared integrations, context, run evidence, and cost controls start affecting teams that didn't build the original workflow. The hard part is deciding which pieces should remain close to the factory and which now need owners, controls and guarantees because other factories depend on them.
That’s the infrastructure required to make Software Factories repeatable beyond the first successful team.
If you’re moving from one successful factory to something multiple engineering teams can rely on, find out how Orq.ai helps enterprises build the shared runtime, controls and infrastructure that Software Factories need to scale.
