Software factory governance
Farna Control is a software factory you own and run. Agents take work from intake to merge, and the governance that decides what ships is built into the factory floor, on infrastructure you control.
What a software factory is
A software factory is the production system a team builds around its agents. It takes work in, isolates the run, has agents implement it, checks the result, routes it for review, and emits a record of what happened.
That is a larger thing than a graph of agents. The graph is the topology, the wiring between nodes and gates. The factory is everything around the graph that turns a topology into delivery: intake, isolation, verification, review and evidence, plus the utilities underneath it such as model supply, credential custody, quality control, telemetry and metering.
Vendors now sell whole factories, and the market has names for the pattern: agentic software factory, the software factory pattern, the factory model. The names differ. The shape is the same.
You can rent that factory from a vendor, or you can run one you own. Farna Control is the second: the whole production system, including the governance, on your infrastructure.
A graph is a diagram. A factory is the plant built around it. Governance is what decides what leaves the plant.
A rented factory is not a factory you own
A vendor factory answers "how does work get done". It does not answer "who owns the record, and can you prove what shipped".
Three symptoms show up once a team runs more than one rented factory, which is the normal state after a year of adoption:
Each rented factory keeps its own record
The vendor factory emits its evidence in its own format, under its own identity, in its own console. Your platform team's pipeline emits something else. A legacy path emits nothing. Nobody can answer "what shipped this week and who approved it" across the set.
The record is held by the party being measured
When the vendor that sold you the factory is also the only source of your audit trail, the control function has moved to that vendor. The trail still exists. It is just not yours.
The category does not publish reliability data
The loudest criticism the software factory wave makes of itself is that no vendor publishes a first-attempt merge rate or a benchmark. Buyers are asked to trust a factory without a number, then asked to trust its internal record of its own work.
Execution is the part that got solved. Ownership is the part that did not.
What the factory governs
Farna Control is the factory floor and the control function in one system. It dispatches to the agent runtimes you already use and owns everything around the call: auth, audit, cost, gates and human review.
| What it governs | What that means in practice |
|---|---|
| What agents may do | Capability scopes and scoped credentials bound each agent's reach to the work you granted it. |
| What counts as acceptable output | You can place deterministic gates (regex, JSON Schema, a custom function) and scored-eval gates between steps. Gates are opt-in per edge, so you choose the boundaries that matter. An eval warns by default and blocks when you set it to block. |
| Where a human decides | Human-in-the-loop gates pause a run until a person approves. On a human-only gate no agent can approve, reject or deliver, and every denial is recorded. |
| What a run actually ran | Farna Control freezes the pipeline definition into an immutable snapshot at run-start, including agent versions, schemas, connectors, model backend and prompts, so a run is reproducible and inspectable afterwards. |
| What happened and who approved it | Decisions are recorded as append-only, hash-chained audit events: approvals, rejections, claims, denials, expiries, guardrail events and blocking evals. Audit is a product output, not a log file. |
| What it costs | You can set a monthly spend circuit breaker per pipeline, and a per-trigger daily limit. Volume stays bounded by the concurrency caps and ceilings you configure. |
| How much autonomy a pipeline has | Autonomy is set per pipeline with a ceiling, and both are frozen into the run snapshot. You raise it as the evidence builds. Human-only gates stay human whatever the autonomy level. |
Farna Control produces the change, decides whether it is allowed to move, and keeps the record either way.
The evidence
We run our own delivery on Farna Control, and we publish the numbers, so you can check whether the process catches problems before merge. The same pipeline that governs our changes is the one we sell.
We do not ask you to trust a vendor benchmark. What replaces it is a governed pipeline you can measure yourself: gates that fire where you placed them, decisions that are recorded as they happen, and a run history you can read.
The audit trail is the product, not a report about the product.
Why it runs on your infrastructure
A control plane that lives in a vendor's cloud puts a second dependency between you and the record. Farna Control is self-hosted only. You run it, you own the audit trail, and there is no telemetry by default, opt-in only.
It is source-available under BUSL, so you can read the code and run it without us. It is agnostic across code host, CI, model backend and agent runtime, so adopting it fits the toolchain you already have and swapping a binding does not require rebuilding a pipeline.
For a self-hosted software factory, that means the audit trail lives inside your perimeter and survives a change of vendor.
Choosing a factory you own
If you are evaluating a factory vendor, compare on two dimensions the demos skip: governance depth and hosting model. Ask which controls are in the tier you can actually buy, where the audit record lives, and whether the vendor can survive being the party under audit.
Factory.ai is the closest comparison on outcome, and it is a strong product. The differences that matter for a buying decision are whether you own the factory, the governance depth, the hosting model, and who holds the record. We compare the two dimension by dimension, without the sales theatre.
Related terms
Graph engineering
Graph engineering is the topology layer: how agents and gates are wired into a graph. It is the mechanism inside a software factory, and a partial view of the system. See the graph engineering framing in our docs.
Agent governance
Agent governance is the control function applied to agents generally. In a software factory it is a built-in property of the factory floor, not a separate product you bolt on. For the broader definition, see the self-hosted agent governance guide.
Workflow automation
Workflow automation sequences tasks and manages state. It does not decide whether an agent's output is good enough to ship. For that distinction, see agent governance versus workflow automation.
FAQ: the canonical set of questions is at /control/docs/faq.
Try Farna Control
Farna Control is self-hosted. You can evaluate it without talking to anyone.
Prefer to look first? The read-only demo runs on sample data at /demo. Questions go to the discussion board on GitHub.