What is an agentic software factory?

An agentic software factory is a way of delivering software in which AI coding agents do the building. They plan, write and test the changes along a defined assembly line, while people set the intent, own the acceptance criteria and approve what ships. The agents are the workers. The factory is everything around them: how work comes in, which stations it moves through, the checks it has to pass, and the record of what came out.

Most engineering teams we talk to already have capable coding agents. Far fewer have anything around them that you could call a factory.

Where the idea came from

The phrase is older than most people using it. Robert Bemer proposed a “software factory” in 1968. System Development Corporation tried one in 1975, and Microsoft shipped a model-driven version in 2004. Every attempt wanted standard inputs, a fixed assembly path, automated quality control and predictable output. Every attempt hit the same problem, which was that the workers were people, and people don’t standardise well.

This year’s version swaps out the workers. A few pieces of writing shaped how people talk about it:

• January 2026. Dan Shapiro published The Five Levels, a ladder borrowed from self-driving cars. It runs from “spicy autocomplete” at level 0 up to level 5, where nobody reviews the code an AI writes. Simon Willison picked it up a few days later and called level 5 the dark factory, after the manufacturing plants that run with the lights off because no one is on the floor.
• February 2026. Willison wrote up StrongDM’s AI team, still the example everyone cites. Their rules are that humans don’t write the code and humans don’t review it. They check the work with end-to-end scenarios the agents never see, much like a held-out test set, and with working copies of the third-party services their software talks to. It isn’t cheap. The team budgets over $1,000 a day per engineer on tokens, which is exactly where Willison has doubts.
• March 2026. BCG Platinion described an enterprise version built on five pillars. One of them, harness engineering, is the factory’s operating manual: the rules and hooks that tell every agent how the company builds software.

By the summer, most writing on the subject agreed on the basic shape. Agents staff the stations, people own the intent and the gates, and what you engineer is the system rather than each piece of code.

How it differs from a pipeline or an assistant

Three different things get sold as “AI for software delivery”.

	A coding assistant	A CI/CD pipeline	An agentic software factory
Who does the work	A developer, with help	Scripts, after someone commits	Agents, inside the commit process
Scope	One repository, one session	One change, one path	Many changes across many services at once
Where it slows down	Typing and context	Build and test time	Checking whether the change is right
What it keeps	A chat transcript	Build logs	The work, every attempt, and the evidence

The third row is the one to watch. A factory produces changes faster than a team can read them. Once people can’t review every line, the system has to hold the structure, the evidence and the decisions for them. Nearly every requirement below comes from that.

The stations

Descriptions of these factories keep landing on the same five stations:

1. Intake. Issues, alerts, requests and schedules become structured work an agent can pick up.
2. Specification. Planning happens before building, and a person agrees the plan.
3. Build. Agents make changes in parallel, each in its own isolated environment.
4. Verification. Automated checks and human judgement decide whether the change is right.
5. Ship. One last gate before anything reaches production.

Underneath sit the utilities: access to models, credentials, a record of what happened, and cost tracking. Running through all of it is the harness, the written method each agent follows. Its prompts, skills, hooks and connectors are what make a general-purpose agent build the way your company builds.

Most enterprises keep the lights on

The dark factory is an interesting place to end up. It’s a hard place to start. Accountability doesn’t go away because a model wrote the change. A regulated change still needs a named person who approved it, and an auditor still wants to know why. Most of the EU AI Act’s obligations started applying in August 2026. In May, Gartner warned that governing every agent the same way is its own kind of failure, because what an agent is able to do and what it has been given access to are separate questions.

So the useful question for an enterprise is where the people should stand and what the system handles everywhere else. We call the answer a lit factory. Agents do the work, the platform keeps the record, and people make the calls at the gates they chose.

Twelve requirements for an enterprise factory

This is the checklist we’d use to judge any platform, including ours. Each row says what the requirement means and where PlatformSmith is today. Some rows say “partly” or “not yet”. We’d rather you read that here than find it out during an audit.

#	Requirement	What it means	PlatformSmith today
1	Intake from where work lives	Nobody learns a new place to ask for things.	Shipped Slack, GitHub, Jira, Linear, schedules, the API and MCP clients. Every request is checked against your roles, and your tracker keeps priority, assignee and sprint.
2	Splitting work across services	One request becomes a structure of work instead of a to-do list.	Shipped Work items carry their own dependency graph, and a run can fan out across every repository in a workspace.
3	An assembly line that lasts	It survives retries, restarts and people going home for the weekend.	Shipped A durable workflow engine with retries and exactly-once steps. A run can wait at a human step for up to seven days and pick up where it stopped.
4	Coordination between stations	Agents working in parallel converge instead of colliding.	Shipped Playbooks assign one agent per service. Every message between agents goes through the platform and can be replayed, and a barrier holds the group until the services agree on their contract.
5	A written harness	The company’s way of working, written once and used everywhere.	Shipped Agent definitions (prompts, subagents, skills, hooks and connectors), layered from company down to project.
6	Stations that use the real thing	Changes are proven where they will run, not in a clean room.	Shipped The runtime goes inside your own container image with your service running under it. Fixes are rebuilt and swapped in without restarting the pod, and the build finishes before anything stops.
7	Clear approval points	A named person decides at the points that matter.	Shipped Approval gates are explicit steps, and you approve the agents’ outputs rather than a transcript. A run the system starts by itself can’t change anything.
8	A mix of agents	You aren’t betting everything on one vendor’s agent.	Shipped Claude Code and Codex, mixed in the same run, one per service.
9	Identity, credentials and access	Non-human workers get the least access they need.	Partly Access is denied unless granted, with roles down to workspace level. Credentials are encrypted, tied to the person who connected them and handed over when a session starts. Controllers connect out and never hand over cluster credentials. There’s no SSO, SCIM or per-environment role yet.
10	Evidence and audit	Every change traces back to a request, an agent and an approver.	Partly Work items, attempts, outputs and full session transcripts, plus an audit trail for workspace, environment, runtime, token and git actions. No export to a SIEM yet.
11	Isolation and network access	Agents can’t reach what they shouldn’t.	Partly Every agent runs in its own runtime on your infrastructure, so your network rules apply. Limiting what a runtime can reach is still your network’s job, though, not ours.
12	Cost tracking and limits	Parallel agents can burn through a quarter’s budget in weeks.	Not yet There are no per-run budgets in the platform. Model spend sits on your own provider account, and that provider’s limits apply.

That’s eight of the twelve fully covered. The four gaps are also the ones buyers ask us about most, which is why they’re on this page.

The three that matter most

Most of the list is the minimum you’d expect. Three items decide whether the factory produces changes you can actually merge.

Coordination. Tools built around one agent stop at the edge of a service. A change that touches the gateway, billing and the web app is really a negotiation, because one service’s contract has to settle before the others build against it. When every agent message goes through the platform, and the group waits at a barrier until the contract is agreed, that negotiation leaves a record instead of a merge conflict.

Realistic testing. StrongDM built working copies of Okta, Jira and Slack so its agents had something real to test against. Few companies can afford to do that. Running the agent inside your own image, against your real service in your dev environment, gets you most of the same realism without building a second copy of the world.

Evidence instead of reading. When nobody reads every line, what gets reviewed has to change. Agents produce specific outputs, such as a contract change, a migration plan or a test plan. Each one is tied to the agent that made it and the definition it worked from. Approving those outputs becomes the compliance record: who asked, which agent did the work, what changed and who signed it off.

How to start

Nobody buys a whole factory in one go. The teams we’ve seen get one working usually go in roughly this order:

1. Pick one kind of change that crosses services and keeps coming back, such as a contract migration, a dependency upgrade or a common class of incident fix.
2. Write the harness for it. What does good look like, what has to be checked, and what must never be touched?
3. Put the gates where accountability actually sits, and nowhere else.
4. Watch it run. Follow every run from start to finish before you trust any of it unattended.
5. Count accepted changes, not lines of code. Time to merge, rework, and review effort per change tell you whether it’s working.
6. Widen one station at a time.

Where PlatformSmith fits

PlatformSmith is a control plane for this kind of factory. It runs the assembly line, coordinates the agents, holds the gates and keeps the record, while the agents themselves run on your infrastructure. We built it to run with the lights on, with people watching rather than the factory running unattended, because that’s what an enterprise can sign off on today.

It’s also a free beta, and the gaps in the table are real. The quickest way to judge the rest is to watch it run a change across several services on your own stack.