Software Factory A journal of governed agents

Vol. I · No. 1 Package scope @factory 23 October 2026

The opening sentence

The agent proposes.
Policy authorizes.
Infrastructure enforces.

A software factory for agent-written change. Quality is decided by loops. Safety is decided by boundaries. Neither is left to the working agent’s judgment.

Agents are untrusted. Everything they read is untrusted. That is the first fact of a software factory, and the last one it is allowed to forget. The working agent may propose a plan, a patch, a merge. It may not grant itself scope, open the network, or declare the work done.

Software Factory — a neutral working name, package scope @factory — turns a prompt, a ticket, or a specification into tested change on an existing codebase. It is assembled from agents and harnesses, models, skills, tools, and versioned profiles. Each agent works under a profile: skills, tools, context, sandbox. The profile is a ceiling. The task may only narrow it.

Decisions are front-loaded so agents execute well-specified contracts. Governance lives in a catalog of agents, services, and scorecards. Autonomy is earned with evidence, not asserted in a prompt.

Watercolour of a quiet letterpress atelier: an iron press, stacked cream paper, an inking roller, and plans pinned to a wall.
Plate I. A press, not a prompt window. The factory is the room around the agent — the rails, the gates, the record.

Three verbs, in that order

Propose, authorize, enforce

Two control layers exist. Inside the loop, the agent reasons. Outside the loop, runtime enforces. This factory is about the outside.

  1. Proposes The agent may ask for a plan, a path, a merge.
  2. Authorizes Policy — versioned files, not another model — decides.
  3. Enforces Infrastructure the agent cannot reach holds the line.

Planner output is a request, never a grant. If an enforcement point is down, the agent does not start. High-impact actions need an approval the agent cannot give. The factory does not change underneath a run.

Plate II

The two loops

One loop makes a change true. The other makes the factory, and the running system, better. They share evidence. They do not share authority.

Inner loop

Until it passes

Inputs enter. Design sets the limits. The factory assembles a profile and a sandbox. Build happens inside that sandbox. Verify reads the evidence. If it fails, the loop repeats. The agent does not get a longer leash because it is taking longer.

  1. Inputs
  2. Design — sets limits
  3. Assemble
  4. Build, in the sandbox
  5. Verify

Outer loop

After it ships

Review, then deploy under an approval policy, then production signals that return to design. The same loop improves the factory: skills, tools, models, workflows. A signal is a new WorkItem. It is not a new permission.

  1. Review
  2. Deploy, under approval
  3. Production signals
  4. Back to design
  5. Factory improvement
Watercolour plate of two interlocking rings: a tight vermilion inner loop inside a wider Prussian-blue outer loop.
Plate II. Inner loop in vermilion; outer loop in Prussian blue. They touch. They do not collapse into one another.

Plate III

Four boundaries

An agent needs room to reason. Four walls decide what it can actually do, whether it cooperates or not.

01 · Sandbox

Where the work runs

Per task, destroyed after, isolation tested. The builder does not inherit yesterday’s files, credentials, or network.

02 · Network

What it can reach

Default-deny egress, operation by operation. Inference goes through a model gateway with budgets. The agent does not hold the proxy.

03 · Supply chain

What it may use

Approved components only, through an admission point. Provenance and an SBOM on outputs. Credentials stripped from inputs.

04 · Identity & access

Who it acts as

Each agent has its own identity. The profile is the maximum. Delegation only narrows. Credentials stay at the proxy. A runtime authorization service decides.

Watercolour architectural plan of a four-walled courtyard with a small vermilion door and a graphite compass rose.
Plate III. Four walls, one courtyard. The agent works in the open square. It does not choose the masonry.

How much the factory takes on

L1, L2, L3

The boundaries stay the same at every level. What grows is the share of supervision that infrastructure takes over from people.

L1

Human-orchestrated

A person chooses the next step and reviews what the agent produces. Useful for risky work, and as a floor the factory can fall back to.

L2

Workflow-orchestrated

A durable workflow chooses the next step. Fresh sandbox per run. Shared service, not a laptop session. This is where we work now.

L3

Agent-orchestrated

An orchestrator agent proposes the next step and a monitoring agent may flag, not grant. A dark factory auto-approves only bounded classes as evidence accrues. A person stays accountable. Later.

Plate IV · Interactive

Eight gated stages

Each stage has an entry gate. A stage cannot self-approve. Select a station, or light one of the two loops.

Inner loop · stages 01–06

Outer loop · stages 07–08, signals return

How to read the plate: vermilion is the inner loop; blue is the outer. Arrow keys move the station. A highlighted loop dims the stages that do not belong to it.

Plate V

Per-run evidence

Every run writes a tamper-evident record, linked by run ID. If the log cannot be written, the run fails closed.

The factory supplies facts a person can stand at a whiteboard and use: which agent, for whom, under which profile, with which components, which checks passed. That is provenance, not storytelling.

  • Run run_id, agent, model, cost, duration, retries, verdicts.
  • Bundle Tests, review verdicts, SBOM, attestation hash, policy version.
  • Decision The question, the options, who chose, under which policy.
  • WorkItem Spec, acceptance tests, risk, Definition-of-Ready, open questions.
Watercolour still life of a cream folio tied with vermilion tape and sealed in wax, beside a pencil and a brass weight.
Plate V. A bundle is a sealed folio. It is not a chat transcript with a bow on it.

Earned, not granted

Autonomy is a ladder

Promotion and demotion come from metrics on the evidence, per repository and per task class. A clean run is a fact. It is not a personality.

L0

Observe. The agent may look. It does not write.

L1

Pull request only, small by policy, a person approves. The starting rung for unproven work.

L2

Auto-merge for low-risk classes after a recorded streak of clean runs. Thresholds are policy, not folklore.

L3

Later. Bounded classes only, as evidence accrues. A kill switch remains: cancel the run, revoke tokens, revert the change.

Plate VI · The ledger

The measurement layer

Every metric is computed from per-run evidence bundles. There is no second telemetry path, and no borrowed score the factory cannot show its working for.

The shape of this layer is inspired by public engineering-intelligence practice: delivery measures in the DORA family, run-level operational telemetry, autonomy as a recorded state, and — if a team chooses — developer-experience surveys. Nothing here names a vendor as a partner. Live figures belong to the factory that produced the bundles.

Delivery, in the DORA manner

Deployment frequency, lead time for change, change-failure rate, and time to restore. Each one is rolled up from release and operate records already in the bundle: when the gate opened, whether the change had to come back, how long the rollback took.

Agent runs

  • Ready-check Share of WorkItems that pass Definition-of-Ready on first presentation.
  • First-pass gate Share of runs that clear verify without a retry.
  • Review rejection Share of reviews that return findings the builder must resolve.
  • Escaped defects Faults found after merge, joined to the run that shipped them.
  • Cost & time Spend and duration per merged pull request, from the run record.
  • Human time Steward hours recorded against the same run — saved only when the evidence says so.

Autonomy as a measured state

Level is stored per tenant and per agent, and it moves only when earned-autonomy thresholds in policy are met or missed. A tenant does not inherit an agent’s streak. An agent does not inherit a tenant’s optimism.

Optional surveys

Developer-experience surveys may sit beside the ledger. They are optional, dated, and never a substitute for a missing bundle. A feeling is not a verify gate.

The scorecard

A scorecard is a set of rules over Services and Agents. Every cell names the bundle field it reads. Fail closed if that field is absent.

Scorecard rules and the evidence-bundle fields they read
Rule Bundle field Reads as
Tests present EvidenceBundle.tests Held-out and first-party results recorded
CI green Run.verdicts Hard-mandatory gates passed
Owner set WorkItem / Service catalog A named accountable person
No secrets in context EvidenceBundle.scans Secret scan clean for the run
Licence clean EvidenceBundle.sbom Admitted components only
Autonomy in range Agent.autonomy + policy threshold Level matches earned evidence
Autonomy recorded per tenant and per agent
Scope Subject Level Moves when
Per tenant The accountable workspace Policy ceiling Aggregate clean-run streak across its agents
Per agent A single identity + profile Earned rung That agent’s own first-pass, rejection, and escape rates
Watercolour of a blank ruled ledger on a wooden desk with a brass ruler and a pencil.
Plate VI. The scorecard is a ruled page. It is filled from bundles, or it stays blank.

Waitlist

Join the waitlist

Name and email only. Sign up and log in are not open yet — they lead here until accounts exist.

Pressing the button does not join a list. We will say so again if you submit.

Coming soon: join the waitlist

Software Factory accounts are not open yet. Sign up and log in will land here when they exist. Until then, the waitlist is the door — and it is not collecting names yet either.

Join the waitlist