Factory roles and pipeline

How orchestrators, workers, and validators move work through a staged production pipeline.

Orchestrator, Worker, Validator

The structural pattern a factory is built on is Orchestrator-Worker-Validator, itself a composition of two documented workflows: orchestrator-workers, where an orchestrator decomposes work and dispatches it, and evaluator-optimizer, where an evaluator checks each result. Each of the three roles is its own scoped harness with its own context, tools, prompt, loop, and guardrails, not a bare agent. The Orchestrator is the cognitive center: it turns a high-level goal (an epic, an issue, a product requirements doc) into a dependency graph of atomic tasks and never writes production code, because a planner that also implements is a single point of failure that undermines the whole factory. It holds pipeline state in the issue tracker the team already uses, which is how the factory survives a crash, a restart, or a two-week vacation without losing its place.

Workers are the implementation agents, often domain-specialized (a Frontend Worker carrying React docs, a Database Worker carrying the Prisma schema), each receiving one atomic task plus only the relevant slice of the harness and operating in a sandboxed git worktree; bounded context is the critical design principle, since loading a Worker with the whole codebase adds noise and raises the chance of distraction hallucinations. The Validator is the factory’s immune system, and crucially it does not re-run the Worker’s own tests: it verifies the output against what the specification requires (contract compliance, regression integrity, security scan, architectural rules), and on failure emits a structured rejection report the Orchestrator uses to re-queue the task with added context.

Parallel versus serial execution turns on shared state. Domain partitioning lets Workers on genuinely isolated bounded contexts run in parallel (a Frontend and a Database Worker rarely touch the same files), but the moment two domains share state, a cross-domain foreign key or a table both write to, the parallel-safety guarantee is gone even when the file paths look separate, and the Orchestrator must sequence them. Two shapes of parallelism follow: a fleet runs one task across many repositories at once (a dependency bump or security patch replicated everywhere, each harness owning its own repo, no merge step), while a swarm points many harnesses at one outcome (each owns a facet of the same feature or migration, and their results must reconcile into a single deliverable).

A production case study grounds these roles in Git itself: every action is triggered by and recorded as a Git event (issue, comment, PR), so the repository timeline is the source of truth and nothing happens off the record; each model lane runs under its own credential, making every comment attributable for audit; and the review stage separates a read-only analysis phase from a write phase with idempotency markers, because mixing “analyze” and “post comment” in one agent step produced non-deterministic, duplicate-prone behavior. The same run treats partial results as a design requirement: when a lane hits a rate limit the pipeline still synthesizes the completed lanes and records which ones contributed, so a degraded run stays useful rather than blocked (The Agentic Software Factory (opens in a new tab), 2026); the multi-model debate that produced its specifications is a multi-agent mechanic.

The five-stage production pipeline

The factory’s scope is the full software development lifecycle, run as five stages by named always-on automations rather than a single agent, each a specialized harness firing on a trigger or schedule (the public software-factory.dev model is a concrete reference for the named-automation-per-stage shape). Planning: a Feature Planner validates the intake specification for completeness before it decomposes anything, returning a clarification request when required fields are missing, because an ambiguous requirement produces the failure mode of building the wrong thing perfectly. Build: Feature Builder Workers execute the planned issues under a defined time budget, and a Worker that exceeds it signals either a non-atomic task (an Orchestrator calibration failure) or a runaway loop. Review: the Validator runs its full contract suite, deliberately not fast, proving the work met the specification rather than merely that the code compiles, and re-queues on failure.

Deploy: a mature factory ships via canary rollout to 5-10% of production traffic while monitoring agents watch error rates and latency percentiles, halting and rolling back automatically on a threshold breach, reacting in seconds on the technical signals though business KPIs still need a soak period. Operate: an Incident Responder watches production, routes known error patterns back through the factory as new tasks, and escalates only novel ones to the human, while the resolution is captured as an updated ADR reloaded into future Workers’ context.

The handoffs between stages are deterministic scripts, not agent decisions. Staging an approved diff, opening a PR, running the contract suite, posting a rejection report, merging on green: each is a deterministic operation, faster and more reliable than asking an agent to decide how to do it. The same hooks that block a bad commit inside one harness become the glue between harnesses in a factory, and that wiring is precisely what separates a factory from a lone harness.

A single-machine version gives each deterministic gate its own role. One practitioner runs five agents in sequence. A specifier turns a human-written story into Gherkin acceptance tests and a QA procedure, written as a human operating the UI who must prove the system works. A coder writes the unit tests and the code until the Gherkin passes. A cleaner runs the CRAP analysis and a general review over the coder’s mess. A hardener runs mutation testing toward full coverage. A QA agent turns the written procedure into an executable script against the running system with a deterministic result. Each agent starts with a clean context, does its one task and ends, so the few rules at the top of its prompt hold better. The costs are 10 to 15 seconds of startup per agent, rebuilding context each time, and the handoff overhead. A task one agent finishes in five minutes with doubtful results takes the chain about an hour, against roughly half a day for a person. The account puts that at four to five times faster at higher quality (self-reported, LIVE: Uncle Bob on Software Fundamentals in the Age of AI (opens in a new tab), August 2026).

The Review and Deploy stages have concrete governance instances. Ona codified a Low-Risk Change Policy where an automation, not the author, classifies every PR against six objective criteria (under 1,000 lines, and no protobuf, migration, infra/CI, auth, or audit-logging changes) and auto-approves the review for those that qualify while a human still clicks merge; four weeks in, median time to first approval fell from 2 hours 49 minutes to 3.8 minutes, lead time dropped 74 percent, and weekly deploys tripled with no change in team size. Their stated lesson is that the governance model matters more than the AI model: automated classification, explicit criteria, audit trails, and human merge authority as the traceable approval event are what keep it SOC 2 compliant, and swapping the model leaves the system standing (Ona – Auto-Approving Low-Risk PRs (opens in a new tab), 2026).

A podcast conversation adds the effect such a policy has on authors. In an anecdote relayed secondhand, a founder piloted a rule for pull requests under a line limit that touch none of the monorepo’s core modules. Such a pull request merged without human review, while an AI review still ran. The share of pull requests meeting the rule rose from about 10 to about 80 percent. Engineers began making smaller pull requests and splitting the critical part of a change out. One host’s team enforces the other side of the line. Its ownership rules are code that runs on each changed file, either a plain pattern match or a prompt-based detector. A pattern can be as plain as an environment-variable read in the Rust source. A rule that fires blocks the change until the named person has explicitly approved that file. As of October 2026 that team sends anything serialized or persisted to a human, because it does not yet trust agents with stored state (Boundary - How to Build an AI Software Factory That Ships Faster (opens in a new tab), October 2026, practitioner and vendor).

Enterprise practice describes the same end-to-end shape as a “Simultaneous SDLC” where agents test while they code and document while they implement, with a Requirements Synthesis Agent turning transcripts into structured tickets upstream and human-in-the-loop approval reserved for “Red Zone” tasks (The Evolution of the Autonomous Software Factory (opens in a new tab), 2026).

The pattern reaches even the most conservative brownfield stacks. An SAP ABAP pipeline built on the “Git / off-stack with read-only MCP” pattern keeps code, PRs, CI, and review in Git while an MCP server gives the LLM read-only context from the live system and no write path, on the reasoning that “the client can change. The governed SAP access layer stays the same”; capability keys are scoped per role (a reviewer profile carries read, preview, diagnostics, and lint tools and explicitly excludes the write tools), and the PR review ladder runs four layers, static lint, deterministic unit-plus-ATC gate, diff-only AI review, and an MCP-backed AI review whose distinguishing power is the drift check a diff reviewer cannot do, confirming the activated object in the live system matches the pre-PR source.

Its operations side uses a two-tier cost model, cheap shallow triage of every runtime dump into an issue, expensive deep investigation only when a human applies a label, with GitHub labels as the entire orchestration UI (ABAP CI/CD with ARC-1 (opens in a new tab), 2026). At the supply-chain layer, Red Hat’s “trusted software factory” argues trust must be built in before the first line is written rather than scanned in at the end, running applications and AI agents down the same governed path: SLSA provenance, sigstore signatures, SBOMs, hermetic builds, curated dependency catalogs so AI-generated code uses trusted building blocks by default, policy-as-code admitting only approved images and libraries, and reachability-based exploit intelligence (with NVIDIA) that narrows hundreds of nominal vulnerabilities to the small fraction actually reachable at runtime (Red Hat – A Trusted Software Factory for the Agentic AI Era (opens in a new tab), vendor, 2026).

The merge step itself is being redesigned around agent-scale throughput. Namespace’s argument is that the pull request is “the unit of work designed for human review”, built on delayed feedback and handoffs, and it breaks when change volume runs at four times the pre-agent rate; their replacement treats merging as a database serialization problem against the single ledger of the repository. The flow runs intent and plan (a spec in the tracker), an agent-harness loop, internal validation that builds and tests against a well-known commit, external validation with no humans (a security-focused LLM and an API-conformance LLM feeding findings back into the loop), and a pre-merge queue that reconciles parallel changes for serializability; the human grants “external approval” by reviewing intent and result, a video of the feature plus the validators’ output, possibly grouped across several commits and agents, not the code.

Agents working multiple candidate commits simultaneously (“step into the multiverse”) blow up resource usage and demand stateful, incremental loops rather than from-scratch runs; CI does not disappear but shifts, validation runs on every iteration and governance lifts into the harness (Namespace – Why CI/CD Is Dead and Continuous Compute Is Next (opens in a new tab), 2026).

The Build stage inherits a harder constraint at long horizons: sessions are memoryless. Anthropic frames a long-running build as engineers working in shifts, each arriving with no memory of the last, bridged by an init.sh, a claude-progress.txt file, and git history, with a one-feature-at-a-time rule that stops a fresh agent from surveying prior progress and prematurely declaring the job done, and a “clean state means mergeable” bar so each shift leaves the branch fit to hand off (Anthropic – Effective Harnesses for Long-Running Agents (opens in a new tab), 2025). Open-source implementations now package that pattern directly: AutoForge wraps Anthropic’s reference design in a kanban and dependency-graph UI, an initializer agent that builds a SQLite feature database, one to five parallel coding agents gated by the graph, and dedicated regression-testing agents that repair or mark failed features, self-testing through the Playwright MCP (AutoForge walkthrough (opens in a new tab), 2026).

The Operate stage has a production-scale instance in PostHog’s self-building product, which turns observability signal into PRs off trillions of events a month: an LLM safety classifier first drops malicious signals (an attacker can inject error text on a public site), signals are normalized with a weight and an embedding and grouped into reports that promote over a threshold, a research agent (Claude Agent SDK in a Modal sandbox, with MCP access to logs, replays, and the tracker) classifies actionability, and immediately actionable reports flow to an execute step that writes the fix, opens the PR, picks the reviewer by git blame, and on CI failure snapshots and rehydrates the sandbox to rerun until green.

Two of its lessons generalize: off-the-shelf embeddings cluster signals structurally (all errors together) rather than semantically, fixed by having an LLM generate queries from each signal and matching those in embedding space; and treating “tokens are free” as a productive mistake, running the expensive agent a hundred times to find the pattern, then collapsing that step into a one-shot LLM call or a trained model (What If Your Product Built Itself? (opens in a new tab), 2026).