Skip to content
Kiberon LabsAgentic Engineering

Software Dark Factory

4 min read

A software dark factory is an autonomous production system for software. Work enters as durable intent, agents turn it into verified changes, and the system operates the delivery line without requiring a human to supervise each intermediate step. Humans still set direction, define policy, approve high-risk actions, and retain the ability to intervene.

The term describes an operating model, not the absence of people or controls. The factory is “dark” because routine production does not depend on continuous human presence. It must remain observable, governable, and recoverable.

Why this is a separate stage

Section titled “Why this is a separate stage”

A self-improving system can learn from traces, corrections, and evaluations. That does not make it a factory. Learning improves capability; a factory applies capability to a standing production mandate.

The distinction adds several requirements:

  • Persistent demand. A durable queue holds work across invocations instead of waiting for one-off prompts.
  • Production flow. Enrichment, planning, implementation, verification, review, release, and recovery form one managed value stream.
  • Operational continuity. Triggers, schedules, and event subscriptions keep the system running when no human is actively prompting it.
  • Quality and economic control. The factory measures successful outcomes, rework, latency, and cost, then routes work according to policy.
  • Accountable authority. Every action is attributable, bounded by permissions, and recoverable by a human operator.

Part VI establishes the learning loop. This stage gives that loop a production environment and a reason to keep operating.

The factory loop

Section titled “The factory loop”
flowchart LR
    signals["Software-world signals"] --> queue["Durable work queue"]
    queue --> delivery["Enrich, plan, build, verify"]
    delivery --> artifact["Reviewed software artifact"]
    artifact --> observe["Outcome and telemetry"]
    observe --> learn["Governed learning loop"]
    learn --> delivery
    observe --> queue

Software-world signals include issue creation, pull-request state, failed tests, dependency updates, security findings, incidents, release events, service-level threshold breaches, and explicit human direction. The trigger layer converts those events into work. The Orchestrator dispatches it. The execution ledger preserves the evidence needed for recovery, governance, and improvement.

Entry conditions

Section titled “Entry conditions”

The Minimal Bootstrap defines the threshold for sustained autonomous operation. Its Minimum Goals belong to this stage and give the factory a bounded production identity before any broader business autonomy exists.

At minimum, the factory must pursue three goals:

  1. Deliver verified software. Turn authorised software demand into reviewable, releasable changes.
  2. Improve the factory. Invest in better delivery, routing, context, verification, recovery, and automation.
  3. Preserve continued operation. Protect the infrastructure, controls, observability, and recovery paths required for future work.

With that direction established, a software dark factory applies the remaining bootstrap conditions to software delivery:

  1. It can observe repositories, issue trackers, CI, deployments, and its own runtime.
  2. It can create and resume work from external signals.
  3. It can produce, verify, and promote changes through controlled delivery paths.
  4. It can learn from outcomes without promoting untested changes into production.
  5. A human can inspect, pause, override, and recover it.

The reference architecture is the current deployment design for this stage. Its agent runtime, orchestrator, tool boundary, telemetry, knowledge base, and GitOps surfaces exist to keep the factory continuously useful without making it unaccountable.

To see a software dark factory being built in practice, explore Kiberon Labs’ Ikidna system.

Boundary of the factory

Section titled “Boundary of the factory”

The factory owns software production. It does not decide what business should exist, which customers to serve, how capital should be allocated, or what risks the organisation is willing to accept. Those decisions arrive as goals, constraints, policies, and work signals.

Crossing that boundary leads to the next stage: an Autonomous Business Unit. At that level the system does not merely execute a software mandate. It must maintain a business identity, interpret a wider environment, choose work, and remain accountable for business outcomes.

Section titled “Related concepts”