How to choose your software factory stack

We’ve been in the platform and software industry for years and we’ve NEVER seen so much hype around a topic like we do for software factories. It’s the hottest topic of conversation online amongst engineers, but we’ve also been hearing about it nonstop on calls with prospects and customers. Everyone wants to know what this new working model is, but most importantly: how should they build one?

As always with hype, tons of opinions, tools, and sales pitches about why you should do something a certain way will come your way.

So we want to help. Through all these conversations and our deep knowledge of the market, we think we’re in a unique position to cut through all the noise and help you focus on the key decisions you need to make to build (or buy) a successful software factory. 

This map is what came out of those conversations and our read of the market. It puts every component a software factory needs on one page, along with the tools you can choose from in each. That way you can see the whole stack before you commit to any part of it.

It’s written for engineering leaders deciding how to put a software factory together, and for platform teams that already run agents and are planning what comes after the first line.

But before we get into it, here is what we mean by a software factory. If you already know what it is, feel free to skip the next section.

What is an AI software factory, anyway?

An AI software factory is a system where agents ship software autonomously. Agents might occasionally need your attention, but the goal is for them to work without you.

Why do you need a software factory if all your developers already have Cursor and Claude? That’s what we call AI-assisted development. It does speed up the build stage, but doesn’t speed up the whole SDLC. There are still lots of manual triggers and approval stages. Adding agents to other stages only helps if the manual parts disappear.

Software factories are designed to run 24/7 around the clock. Agents inside them are always on, always listening for triggers and always pushing work forward. Because of this “always on” model, agents need constant support in the form of context, orchestration, and governance. The software factory’s goal is to provide them with everything they need to get their work done, with minimal human involvement. What do they need? We explain below.

The software factory market landscape map

It helps to picture everything visually.

The map has three groups. The DevOps platform is the foundation you already run. On top of it sits the AI software factory platform, and at the center of the factory is the AI infrastructure that does the work.

Let’s expand a bit on each one.

DevOps platform

At the foundation of everything you’ll do when automating your SDLC is your DevOps platform. It has everything it needs to deploy changes to your software: CI/CD tools, observability, incident management, IaC, runtime and cloud, issue tracking, and the rest of the tools your teams already run. Neither you nor your agents will replace any of this layer. Agents produce changes that still have to be built, tested, and shipped the same deterministic way.

AI software factory platform

On top of that foundation sits the factory itself: the context, orchestration, governance, approvals, and measurement that turn agent output into verified work on par or better than engineers can ship. 

• Governance: the rules that decide what an agent may or may not do.
• Human in the loop: where people approve, redirect, or add context to agent work, with a record of who decided what.
• Orchestration: the workflows that move work between triggers, agents, people, and tools, with retries and rollbacks.
• Code context: what agents know about the codebase itself, such as its structure, conventions, and history.
• SDLC context: what agents know about everything around the code, such as services, owners, dependencies, deployments, and incidents.
• Engineering intelligence: measurement of agent work against delivery outcomes, cost, and quality.
• AI registry: the list of approved agents, skills, prompts, and MCP servers, with owners and versions.

AI infrastructure

The AI infrastructure is where the work happens. It’s a large stack of its own. At the bottom are the models, like Claude Sonnet 5.5 or GPT-6.1. Above them sits the harness, the loop that gives a model its tools, memory and planning. At the top is the agent, the thing your engineers actually assign work to.

• Models: the LLMs underneath, such as Claude or GPT.
• Agent harness: the loop that gives a model its tools, memory, and planning, and decides when it acts and when it stops to ask.
• Environments: the sandboxes where agents run and test their changes.
• Agents: what your engineers assign work to.
• Cloud coding agents: agents that take a task and return a pull request from a hosted environment.
• Proactive agents: agents that watch for signals and start work without being asked.
• Vertical SDLC agents: specialist agents for one job, such as security fixes, code review, or SRE.
• AI gateway: the single path for model and tool calls, with routing, rate limits, and spend controls.
• AI observability and evals: tracing and testing of agent runs, so you can tell whether a change made output better or worse.

‍

I have the AI infrastructure, why do I need the AI software factory platform?

In short, it’s because agents on their own stop being manageable once you have more than a few of them. Even though the agents are the ones doing the work, the platform is what keeps that work traceable, governed, and portable as the number of agents, teams, and lines grows.

Let’s go deeper into some of the reasons.

Prepare for agentic chaos at scale

Once dozens or even hundreds of agents are working across teams, the only way we can think to describe it is: chaotic. It usually starts with individuals and teams building agents and skills in silos. Each team scripts its own automations on the side, so you end up with several small factories that don’t work with each other, or two teams building the same agent without knowing it. There are no common standards either. The same task comes out differently depending on who wrote the prompt, a prompt that lives on one laptop can’t be reviewed or reused.

Context gets messy at scale too. Each agent pulls from whichever tools it can reach, so it works from information that is scattered across systems and often out of date. That is how an agent rolls back the wrong deployment or pages the wrong team. Agents also burn tokens looking for answers and repeat mistakes the team already learned from.

Control slips at the same time. Each agent has its own credentials and approval habits. Picture an incident where someone asks which agent made a change. The agent ran on a developer’s personal token, so the logs show the developer, and revoking that token stops every other agent using it. People and agents write to separate logs, so nobody can say who changed what or who approved it. When an agent ships a wrong change, there is often no record of what went into it, so the team cannot tell a weak model from weak context and spends weeks rewording prompts.

Everyday work slows down as well as agents multiply. Approval requests may sit in chat threads for days, and the agent’s work stays paused until someone answers. As you can see, chaos multiplies as agents do.

Your software factory will have multiple lines

A line, by the way, is just like in a factory. It takes an input, does something to it, and outputs a finished product. Most factories start with the idea-to-production line, because it solves what you spend most of your day doing: shipping software. But then other teams want their own lines. Security knows which findings keep coming back, SREs know which alerts they handle the same way every week, and QA, data, and frontend teams each have their own repetitive work.

‍

Each line looks different. A security line starts from scanner findings, an incident line from pager alerts, and another might start from a failed pipeline or a labeled ticket. Teams also bring their own specialist agents and their own approvers, like a service owner signing off on a security fix or the on-call engineer deciding on a rollback. More lines means more agents, so a factory built around a single agent either leaves the others out or runs them outside its rules.

But if you look closely, every line has a lot in common. When the foundation is shared, building more factory lines actually becomes easier:

• SDLC context. The context one line adds about services, owners and dependencies is available to agents in every other line.
• Orchestration. Work can move from one line to another without starting over in a different tool.
• Gates and guardrails. A policy written once covers every line, so a new line doesn’t need its own rules.
• Human in the loop. Every line pauses for approvals through the same flow, with one record of who approved what.
• AI registry. An agent, skill or MCP server registered for one line can be reused by every other line.
• AI gateway. Agents in every line go through the same model and tool controls, so a new line is covered from its first day.
• Engineering intelligence. Every line is measured the same way, so you can compare lines and see which are worth expanding.

You want to be able to swap machines in and out

Each of the layers in AI infrastructure changes constantly. Models get better all the time, and agents switch between them, sometimes even using several models in a single task. Most vendors have responded by making their agents model-agnostic. That is useful, but it doesn’t help if you want to swap agents in and out.

Imagine you need to change your main coding agent, the one most of your factory runs on. Perhaps a competitor pulls ahead, or pricing changes and you want to switch. If the answer is that you would have to rebuild the whole factory to fit a new agent, that is a costly problem to have. The market moves fast, and the best agent today may not be the best in six months. So if the agent is hard-coded into each workflow, every workflow that uses it has to be edited before anyone can switch. 

In other words, your factory should always remain your factory even when the machines inside it, the agents, change. You should be able to, for example, start with built-in workers and preconfigured lines, then replace or extend them without replacing the factory.

There is also a compounding effect. As your factory runs, a lot of things build up around the agents: workflows, the context they rely on, approval rules, audit history, the baselines you measure progress against, and every decision and trace along the way. Over time, that accumulated knowledge about how to run and improve the factory becomes its most valuable asset. When you change agents, you want all of it to carry over to the next one rather than start from zero. That strengthens the case for keeping the factory layer separate from the agent layer, so the agent can be swapped and the factory stays.

Multiple harnesses and agents in one company

Using multiple agents and harnesses is the right way to go. The trouble is that each agent and harness does the same job its own way. A coding rule has to be written once as a CLAUDE.md file, again as a Cursor rule, and again as an AGENTS.md file, and the copies drift apart as soon as one of them changes. Each harness has its own permission settings, so a tool that is blocked in one can still be open in another. Each one keeps its own logs, so comparing how two agents handled the same task means stitching their records together by hand.

So you’re left choosing between standardizing on one harness and losing your developers’ preferences, or allowing all of them and losing a consistent way to govern them. A platform layer removes that choice. 

It gives you three things no single harness can:

• One permission model: Every agent gets its own identity, its permissions are capped at the user’s own, and risky tools are restricted per agent, whichever harness it runs in.
• One set of shared assets: Context, skills, prompts, and coding rules are published once and reach every harness in the format it expects.
• One record and one measure: Every agent writes to the same audit log and is measured the same way, so you can compare harnesses and see which ones justify their spend.

Your options for assembling the software factory stack

We see three ways to assemble a software factory:

• Build: assemble the intake, context, orchestration, and governance yourself from open-source pieces and your own code.
• Buy an agent-bundled factory: a vendor provides the whole factory, built around its own agent and harness.
• Buy agent-agnostic factory infrastructure: a layer that provides the factory and lets you plug in whichever agents you choose.

(You might be wondering about buying a few point solutions, like SRE agents or code review agents. They are often the first agents a team adopts outside the IDE, and they can look like a fourth option. One of them is easy to run on its own. But once you have more than a few, you end up building another factory just to connect them, because each one brings its own context and rules and the hand-offs between them are left to people or glue scripts. We see them as agents that fit into a factory, and the table at the end of this section shows how each approach handles them.)

‍

Option 1: Build a fully custom software factory

Building is where most teams start, because it looks deceptively easy these days. A typical setup is Claude Code or Codex for the agent, GitHub Actions to run it, n8n or Zapier to connect triggers, a few open-source projects, and MCP servers for context. You could probably put together a working demo in just a few days, and because you built it yourself, nothing is hidden in a black box.

Once the honeymoon period with the demo is over though, reality sets in. You now own all the glue between tools: state, retries, approvals, and the context store. Just governance on its own will take as much effort as the build itself, not to mention each new factory line repeating much of the work (because they don’t share the same foundation)

General pros

• Full control over each part of the factory
• No dependency on any single vendor
• Often the fastest path to a first demo
• Nothing in a black box

General cons

• You own the glue and logic between tools (state, retries, approvals, context store)
• Every new tool and line adds glue code you have to maintain 
• Scaling to multiple workflows or factory lines gets harder with each one
• Governance takes as much time and effort as the build itself
• Context needs its own solution unless connecting agents straight to MCP servers is enough

This might be the right call if

• You have a team that can own the build and the edge cases it will produce
• Your engineering org is small enough that one or two lines will cover it

If you had to swap the agent: you would change config in some places and rewrite the glue in others

Option 2: Buy an agent-bundled factory

The second option is a vendor that runs the whole factory on its own agent and harness. These products are still usually model-agnostic, so you can choose or route between models, but the agent is theirs. In exchange, you get the shortest path from a ticket to a PR, with most layers of the factory ready on day one.

The more complete products in this category cover intake, context, governance, verification and analytics, not just the agent. The limit is not missing layers. It is that every layer is built for one agent, so other agents, and the specialist agents your other lines will want, sit outside it.

General pros

• The fastest path to agents producing production-ready PRs
• One vendor to deal with, and most of the factory managed for you

General cons

• Every layer of the factory is tied to their agent, so switching agents means replacing the factory
• Other agents in your org need their own context, governance and measurement

This might be the right call if

• You are comfortable standardizing on one agent across your SDLC for the next year or more
• You plan to run one factory line, and want it running quickly with minimal setup

If you had to swap the agent: you would replace the factory along with it. Workflows, context, approvals and history live inside the vendor's product.

Option 3: Buy agent-agnostic factory infrastructure

The third option is a horizontal layer that provides the factory, with agents, models, and tools plugged into it. Intake, context, orchestration, governance, and measurement live in the infrastructure, and the agents are workers you assign to it.

You give up some speed at the start. You still design your workflows, and there is more to connect than with a bundled product. What you get back is a factory that does not depend on any one agent, so it can run several agents across several lines and keep its history when you change them.

General pros

• No lock-in at the agent layer
• Connects to the tools you already run
• Easier to manage context, governance and measurement across every agent 

General cons

• You build your workflows
• Slower to get going than a bundled agent

This might be the right call if

• You expect to run more than one agent, or more than one factory line
• You want to keep the option to change agents as the market moves
• You have a platform team, or similar, that can own the workflows and the context model

If you had to swap the agent: you would point the workflows at the new agent. Context, approvals, audit history, and measurement stay where they are.

‍

The three options at a glance

‍

What we recommend and why

All three options can produce a working factory, and each one can be the right answer for some teams. A small team running one line can get a long way by building. A team that wants PRs next week and is comfortable with one agent will get there fastest with a bundled factory.

The deciding question is this: do you want your factory to be married to one agent or stay agent-agnostic?

We believe that staying agent-agnostic is the safer, future-proof choice, for three reasons. 

1. Being model-agnostic no longer sets anyone apart. Almost every agent already lets you choose or route between models, so what locks you in is the agent, not the model. 
2. Agents are changing faster than your contracts. New coding agents ship every few weeks, the leader today may not lead in six months, and most large engineering orgs already run several at once. 
3. The valuable part of a factory is what builds up around the agents: the workflows, the context, the approval rules, the audit history and the baselines you measure against. If all of that lives inside one agent’s product, it leaves when the agent does, and every renewal becomes a negotiation you can’t walk away from.

For most engineering orgs planning past the first line, our recommendation is to keep the factory layer separate from the agent layer. That means agent-agnostic infrastructure for intake, context, governance and measurement, with agents, including point solutions, plugged in as workers. Start with one line (usually idea to production), and pick the agent that is best for it today. As other teams start building their own lines, or when a better coding agent comes along, the factory you have already built carries over.

Whichever way you go, make it a deliberate choice. Unfortunately, the pattern we see too often is a factory that was never chosen at all, assembled from whichever tool each team adopted first. At that point, it’s time to commit to one of the three ways to build a software factory.

‍