In February 2026 Justin McCarthy published Software Factories And The Agentic Moment. Simon Willison wrote it up the next day. BCG Platinion published The Agentic Software Factory in March. Factory.ai shipped a Factory 2.0 manifesto in June. By August the pattern had reached LaunchDarkly, Cloudflare, Vercel and Uber, and by September Will Larson was writing up his own trial of it.

The proof points came with the vocabulary. Spotify reports more than 1,500 agent-generated pull requests merged. OpenAI ran an internal beta that produced on the order of a million lines of code with three engineers steering. 8090 raised a $135M Series A led by Salesforce Ventures to sell regulated enterprises a software factory of their own.

That is enough adoption to stop arguing about the word. The software factory is the frame the market chose for 2026, and it is a better frame than the ones before it, because it describes a production system rather than a technique.

The term is settled. What matters now is what almost every article in the wave does in its second half: it names a governance gap, and then it stops.

The ladder

The vocabulary arrived in rungs, and each rung absorbed the one below it.

Prompt engineering asked how to phrase the request. Context engineering asked what the model has in front of it. Loop engineering asked how the agent retries, recovers and keeps going without a human restarting it. Graph engineering, which became real vocabulary around July 2026, asked how agents and gates are wired together.

Each rung added a layer of production reality, and each made the previous one look like a detail.

The software factory is the fifth rung. It asks what production system surrounds the graph: how work arrives, how a run is isolated, how output is verified, who reviews it, and what record survives. Underneath sits a utilities layer that nobody markets and every deployment needs, covering model supply, credential custody, quality control, telemetry and metering.

The graph is not the factory

Graph engineering is a real discipline, with real literature behind it. The idea is also no longer anyone's differentiator. Igor Ostrovsky, co-founder and CTO of Augment, put the shared model plainly in September 2026: a software factory can be modeled as a graph, where nodes are the artifacts - requirements, issues, pull requests, alerts - and edges are the agent-driven processes that transform one artifact into another.

He is right, and the concession costs us nothing. A graph is a topology. A factory is a production system built around that topology. You can draw a perfect graph and still have no idea which of last week's changes were approved, by whom, against which rules, or whether the gate that was supposed to catch a bad migration actually ran.

The graph answers how. The factory answers what happens around the how. Governance answers whether any of it was allowed to happen.

Two gaps the wave leaves open

The first gap is reliability data, and the category named it against itself. A post on Hashnode in July 2026, written by Syed Fazle Rahman of Buildful, argued that no vendor in the space publishes reliability data: no first-attempt merge rate, no benchmark, no comparable number of any kind. A vendor in the category counting itself inside the gap was an unusual thing to publish. It is also correct.

So the buyer is asked to trust a factory on the strength of a demo, and then asked to trust that factory's own record of its own work. Which brings the second gap.

Each factory emits evidence in its own format, under its own identity, in its own console. While you run one factory, that is workable. The normal state after a year of adoption is three: a vendor factory, something the platform team built, and a legacy path nobody wants to touch. Then the record of what shipped and who approved it is spread across three consoles, three identities and three definitions of done, and in each case the party holding the record is the party the record describes.

The price has to follow the volume

A hosted factory carries a marginal cost for every unit of work it runs: seats for the people reviewing output, agent compute, metered model calls, a fee per pipeline run. The vendor pays for that compute on your behalf, so the price it charges has to track the volume you produce. That is a sound business, and every vendor in the category runs on some version of it.

The arithmetic has a second consequence. A vendor whose income rises with the number of changes merged has a standing interest in more changes being merged, and every judgment about whether a particular change should have been blocked happens inside that interest. The pull is built into the model, and no amount of good intent removes it.

So the question a buyer should ask is narrow. When my factory ships twice as much next year, what happens to the invoice? If the answer is that it goes up, the vendor's revenue and the vendor's governance are pulling in opposite directions, and one of them has to give.

Farna Control is a software factory, self-hosted under a flat annual license priced once for the deployment. Seats, pipeline runs and model calls carry no separate charge, and the model calls run under your own provider contract and keys. Our revenue is the same whether your factory merges ten changes this year or ten thousand.

That property is what gives the governance claim its weight. The party recording the decisions earns the same amount whether there are ten of them or ten thousand, so it has no stake in the count. A buyer can check it against our published pricing in a minute.

What built-in governance has to do

Governance built into a software factory needs a specific set of capabilities, and the list is short enough to check against any vendor.

Take work in, from the triggers you already use: webhooks, cron, a manual fire, an upstream pipeline.
Bound what each agent can reach with scoped credentials, so reading the repository does not imply production access.
Define acceptable output at the boundaries you choose, with checks that either pass or fail.
Put a human decision where it matters, at a point an agent cannot satisfy on its own.
Record every decision in a form that survives the tool that made it, including the evidence the reviewer saw.
Cap spend per pipeline and per trigger, so a looping agent cannot run up an invoice overnight.
Stay portable, so the record outlives any one model or runtime you swap out.

None of these are exotic. The hard part is that they have to survive the tools that produced them, which means the record has to live somewhere the tool cannot revoke.

What we built

Governance is part of the floor, not a layer sold on top of someone else's factory. Work arrives through the triggers a team already uses, and Farna Control dispatches it to the agent runtimes that team runs, owning what happens around each call: auth, audit, cost, gates and human review. When a run starts, the pipeline definition is frozen into an immutable snapshot, so a run can be reproduced and inspected afterwards. Decisions are recorded as append-only, hash-chained audit events, and on a human-only gate no agent can approve its own change. The instance is self-hosted, so the record lives on infrastructure the customer owns.

We are also early. Farna Control is pre-GA, and the honest version of this post says so plainly rather than burying it. We do not publish a first-attempt merge rate either. We publish our own delivery numbers, which is a smaller thing than a category benchmark, and we would rather say that than dress a vendor figure up as evidence.

What closes the category's reliability gap is a pipeline you can measure yourself: checks that fire where you placed them, decisions that are recorded as they happen, and a run history you can read without asking anyone's permission.

Built-in governance is buildable, and it is the part that decides whether a software factory is a delivery system or an expensive demo.

Everyone's building a software factory. Farna Control is one whose revenue does not depend on you producing more.