In agentic software development, a Software Factory is shared infrastructure for running software-engineering work through AI agents.
The coding agent is only one piece of it. When an engineer runs an agent locally, a lot of the surrounding setup is easy to overlook.
Authentication may already be configured, internal tools are available, and the engineer knows which documentation is current along with which bits everyone ignores.
Move the same work into the background and those dependencies have to become explicit parts of the system.
That means providing somewhere to run, access to the right systems, relevant context, reliable checks, and clear limits around what happens when the task starts changing shape.
Software factories themselves aren’t a new idea. The term predates generative AI by decades.
What’s changed is that AI agents can now carry parts of the engineering workflow themselves, while earlier approaches focused more on standardized tooling, reusable assets, automation and structured development processes.
What actually moves into a Software Factory?
Short answer is there isn’t one standard architecture for an agentic Software Factory.
A mature platform team may already operate much of the underlying machinery: environments, secrets management, service metadata, internal tooling, and deployment infrastructure.
Another enterprise could be starting with little more than engineers running coding agents locally and CI/CD handling whatever they push eventually.
The details differ, but a useful way to break the shared layer down is into five parts:
Intake: Issues, alerts or other work entering through a known route, with enough scope, acceptance criteria, ownership and boundaries to determine what work the workflow has actually been given.
Context and tools: repository guidance, internal documentation, skills, architecture information, and access to relevant internal systems.
Execution: the repository, build environment, dependencies, credentials and network access needed for the job.
Agent runtime: the model access, coding harness, session state and tool execution involved in carrying out the task.
Controls, verification, and evidence: Permissions, provider restrictions, automated checks, approvals, spend limits and enough run history to reconstruct the model, context and tools involved when something goes wrong.
Incoming work might be classified as ready to run, missing information, blocked or outside the workflow’s scope. In a simple design, only the first category reaches the agent. The others wait for a person or another workflow to resolve what’s missing.
One team might build a factory around vulnerability remediation while another uses one for frontend maintenance.
The work, context, and execution environment can be different while both inherit the same underlying security, observability, and cost policies.
Context has to belong to the workflow
It’s tempting to treat context as mainly a retrieval problem.
One version of that approach is to retrieve everything that might be relevant and let the model sort through the result.
That gets out of control fast.
A package upgrade may need a migration guide, the current dependency policy, and one or two approved examples. A database change may need schema ownership and rollout instructions.
Giving both jobs the same pile of architecture documents and historical design proposals is unlikely to make either workflow better. It just creates more material the retrieval and reasoning layers have to distinguish.
Architecture direction is particularly difficult because the codebase records where the system has been as well as where the team wants it to go.
Engineers close to the system often carry that distinction implicitly: which patterns are still approved, which ones are being retired, and which migrations are only half finished.
There probably won’t be one context package that works across the factory but the useful material depends on the work entering it.
The same idea can apply to instructions and methodology. A migration workflow might expose a migration Skill only when that work arrives rather than loading the same guidance into every agent run.
Current Orq.ai Skills follow that pattern: a lightweight description is available first, with the fuller methodology, examples and references loaded when the Skill becomes relevant.
Execution should follow the job
The execution environment becomes easier to reason about when its boundaries are explicit.
A test-repair workflow might only need source code and a build environment.
A service migration might need staging access and credentials for an internal system.
A vulnerability patch might need an approved package registry and the scanner that raised the finding.
The execution environment isn’t the only thing that can vary as model choice can vary by workload too.
Routine maintenance may not justify the same model as a difficult migration, while policy may restrict sensitive repositories to particular providers, regions or privately hosted infrastructure.
That’s one reason to keep the model, coding harness and execution environment separable. If those layers are decoupled, the factory can change one without forcing every workflow onto the same stack. And in regulated environments, that optionality can extend all the way to running the workload in the enterprise’s own cloud or on-premise environment.
And once work runs outside somebody’s interactive session, the final pull request is no longer the whole story. A poor result could come from stale documentation or a missing migration guide.
You won’t inspect that history after every successful task, but you’ll want to when the same kind of failure keeps appearing.
Some of that evidence already exists in current coding-agent infrastructure. A coding session routed through the Orq.ai Gateway can record the model serving each call along with token usage, cost and latency.
That won’t tell you why an engineer rejected the eventual pull request, but it can show whether the run became unusually expensive, slow or spent much of its time making model calls before it got there.
A vulnerability patch inside a Software Factory
Vulnerability remediation is a useful example because the factory has more to do than just handing a ticket to an agent.
Let’s say patch and minor dependency upgrades are allowed into the workflow for a known set of repositories.
Major-version upgrades stay outside this workflow for now.
Changes involving authentication are excluded. If the finding doesn’t map to a remediation path the workflow supports, the task never enters this workflow in the first place.
That intake rule has already done useful work by deciding which class of task the factory is actually responsible for. An accepted job gets the repository, the current dependency policy, and any migration material relevant to the package.
Sometimes, the run isn’t very exciting.
The package changes, one API has moved, a test needs fixing, and the result goes back as a pull request. What’s worth paying attention to is the run that stops being so uninteresting.
An upgrade exposes a dependency on a shared authentication component. The agent may be capable of following that dependency into another service and continuing until the tests pass.
Capability isn’t really the question anymore.
The workflow was designed to patch dependencies in a defined set of repositories. Shared authentication has different owners, different consequences, and possibly even different approval requirements. As coding agents become more capable, explicit workflow boundaries become more useful rather than less.
A more capable agent may be able to keep following dependencies into work nobody intended to delegate, which makes explicit scope more important as capability improves.
METR’s original time-horizon dataset estimated that the 50%-reliability task horizon for frontier agent systems doubled roughly every seven months from 2019 to 2025. Though that benchmark shouldn’t be read as a direct measure of real-world enterprise autonomy.
If the patch stays inside its boundary, the rest should be fairly uneventful. The factory opens a pull request and the existing delivery process continues.
Little reason to invent a new source-control or CI/CD stack because an agent wrote the change. Pay attention to what happens after the same workflow has run a lot of times.
One internal SDK keeps reaching review with the same mistake.
Someone checks the run history and notices that the migration guide for that SDK never reaches the agent. Add it to that workflow and see what happens.
It could be the case that the next set of upgrades is clean, or perhaps failures continue because engineers have always relied on application-specific knowledge that was never documented. That tells you something different. The package family may not belong in this workflow at all.
“Give the model more context” isn’t always the answer.
Sometimes the tests are weak.
Sometimes the task was poorly selected.
Sometimes the work was never as repetitive as it looked from the outside.
Run evidence changes how much autonomy you allow
Autonomy doesn’t need to be decided for the entire factory.
Take a maintenance workflow that starts with plan approval and ends with normal code review. After enough runs, the planning approval may start to look ceremonial. Engineers rarely change anything there, code review is different, and reviewers are still finding important issues in a subset of the pull requests.
No reason those two gates have to move together.
For the part of the workload where plan approval rarely changes the outcome and the downside is bounded, you can test removing that gate while keeping code review.
Then look at the PRs people still correct.
Cost also becomes more useful when you relate it to the engineering outcome rather than the run alone.
A cheap agent run isn’t necessarily efficient if the pull request is rejected or substantially rewritten. A more expensive run can be the better trade if it reaches review in a form engineers are willing to merge.
That makes metrics like cost per accepted change more informative than model spend per run on its own, especially when you pair them with review effort and downstream outcomes.
Most of them probably involve one package family or they share the same missing piece of guidance. The same evidence can also move a workflow in the other direction. Models change and tests deteriorate.
Engineers start improving the workflow, not just the PR
A Software Factory gives engineers something else to improve besides the individual code change: the workflow that keeps producing it.
If an agent keeps taking the same wrong path, fixing the pull request only fixes that run. The repeated behaviour may point somewhere else: the Skill needs updating, the agent needs a better internal tool through MCP, or the workflow is missing an architecture blueprint.
Fix the shared workflow and later runs can inherit the change instead of waiting for another reviewer to catch the same problem.
Nothing about that learning is automatic. Someone still has to turn the failure into a better Skill, tool, check, policy or piece of context and make sure later runs actually use it.
Doesn’t mean senior engineers stop writing code and spend their days watching fleets of agents. They’ll still have to deal with incidents, architecture, difficult implementation work, and everything else senior engineers already do. The leverage comes from turning a repeated review correction into something the workflow can apply before the next pull request reaches a reviewer.
But repeated agent behaviour creates opportunities to improve the system around the work rather than correcting each output separately. The same applies to the strongest coding-agent setups inside a team.
One engineer develops a useful migration skill. Another connects the right internal system through MCP. A third keeps improving repository instructions because they repeatedly see the same failure.
When those improvements live only in individual setups, their benefit stays fairly local.
In a shared factory workflow, those useful pieces can be codified once and made available to later runs. There’s maintenance hidden inside this model too as skills go stale and documentation drifts.
A workaround added after one incident can survive long after the underlying problem disappeared and instructions accumulate history just like code does.
A factory needs deletion and cleanup as much as it needs more context.
Where does this sit next to CI/CD and platform engineering?
Platform teams are likely to sit close to this layer because they already operate many of the capabilities it depends on: environments, secrets, service metadata, deployment systems and observability.
Inside the factory, a coding agent can carry out implementation work:
Editing files
Calling tools
Reading code
Running tests
The Software Factory coordinates how that work is selected and governed.
Platform engineering can provide much of the infrastructure underneath the factory, while existing CI/CD can remain the authoritative path for integration testing and deployment once the agent produces a change.
Here’s what a simple path can look like:
Issue or alert → Software Factory → Coding agent → Pull request → Existing CI/CD
Production doesn't have to be the end of that path. A rollback or monitoring signal can become new factory input, provided the team can connect the production outcome to the run that produced the change.
A bounded workflow can start there without replacing the rest of the software delivery stack. Enterprises don’t necessarily need a second source-control system or a replacement delivery stack only because agents are producing more of the code.
The Software Factory is the layer that determines how work reaches an agent, what the agent can use, how the run is checked and what happens when it finishes.
One workflow may use a different model or coding harness from another. Sensitive repositories can be restricted to approved models, providers or deployment environments.
A routine maintenance task might use a lower-cost model once it meets the workflow’s quality bar, while a difficult migration can be routed to a more capable one.
The factory doesn’t need to turn all of those choices into one monolithic platform.
When does an enterprise need a Software Factory?
A useful signal is when coding-agent adoption starts creating problems that individual developers can’t solve on their own.
Several signal tends to recur:
A few engineers are getting much better results than everyone else, but nobody can quite reproduce their setup.
Reviewers keep correcting the same agent-generated mistakes.
Security needs to know which tools and MCP servers agents can use to reach sensitive systems.
Platform teams are finding libraries or technologies in agent-generated changes that fall outside established architecture standards.
A recurring workflow is consuming much more model or CI spend than expected.
Enough agent work is running in the background that nobody has a clear view of what is happening across it.
Those are stronger reasons to build shared infrastructure than starting an “autonomous Software Factory” because the phrase sounds like the next stage of AI adoption.
There can be an economic reason to start with maintenance too. Enterprises already spend part of their engineering budget simply keeping existing systems running: patching, upgrading and supporting them.
When the workflow is repetitive, bounded and performs well enough in practice, moving some of that work into a factory can reduce manual effort and return engineering capacity to other work.
Start with one bounded workflow the team already understands, then use the first runs to work out what the shared infrastructure actually needs.
If your teams are already reaching that point, book a demo to see how Orq.ai can support the context, controls, and observability around agentic software development.
