Make the work buildable.
PRD analysis and remediation, ticket specifications, decomposition, prechecks, specification review, and repair turn an ambiguous request into a controlled obligation.
What the working base contains
A controlled delivery system, not an empty agent harness.
Buildfactory supplies operational components that work together: workers, phase managers, deterministic gates, procedures, evidence, recovery, model routing, and integration patterns.
A precise category
A delivery system that fits your workflow—not a replacement for it.
Buildfactory works alongside the planning systems, coding CLIs, repositories, sandboxes, schedulers, and providers you already use. It adds the controlled delivery layer around them.
Buildfactory isIt is not
A self-hosted delivery control system
Coordinates PRD analysis, specification, test, code, review, evidence, recovery, and decisions.
A coding CLI or coding assistant
A CLI performs a task. Buildfactory controls the delivery line around that task.
A working base you install and adapt
Workers, rules, profiles, gates, procedures, and integrations arrive as operating components.
A blank agent harness or workflow canvas
You do not begin by inventing the roles, proof model, controls, and repair routes.
The controlled execution side of the SDLC
Takes approved intent and turns it into test-backed, evidenced delivery work.
A planning method or PRD generator
Use your planning system; Buildfactory starts where the plan needs controlled delivery.
A control layer inside your workflow
Uses the planning systems, coding CLIs, repositories, sandboxes, schedulers, and providers that fit your environment.
A replacement for your workflow or tools
Keep your stack. Buildfactory coordinates the controlled AI step around it while people retain engineering authority.
Workers with bounded roles
Not one general agent with the keys to everything.
Specialized roles separate production, review, adversarial challenge, remediation, and managerial coordination. The system makes it harder for a worker to create a result and approve its own passage.
Separate proof from production.
Test builders establish missing behavior. Implementation workers own the change. Both are subject to review and re-verification.
Challenge known and unknown failure.
Reviewers check a stated contract. Inquisitors search for assumptions, gaps, reward hacking, fabricated proof, and weak tests that ordinary review did not find.
Repair the cause, not the appearance.
Remediation, stall detection, provider switching, re-entry, and factory tickets route a failure to the station that can correct it.
Coordinate work without doing customer changes.
Managers supervise phase state, call the appropriate workers, check required artifacts, and route exceptions under procedure.
Keep critical passage outside ordinary worker control.
Scripts and deterministic checks hold state and transitions where a badly performing worker or manager cannot simply declare success.
Working component inventory
What you get is an operating library—not a collection of prompts.
Every group below represents real workers, scripts, gates, procedures, or integration tools that operate in the factory. The exact subset and integration depth varies by edition and selected Build Profile.
Phase managers and chain control
pipeline-chain · phase managers · watchdogs
Workers and agents
PRD analysts · spec generators · Test + Code builders · reviewers · inquisitors
Bounded specialist roles produce, challenge, remediate, and coordinate delivery work.Phase initialization, review, and evidence
Phase setup · review managers · evidence checks
Creates the required workspace, artifacts, review steps, and proof trail.Requirements, specifications, and planning
tdd-prd-analyst · spec generator · cross-validator
Build, review, discovery, and recovery
Test + Code workers · implementation review · discovery
Builds, challenges, finds late gaps, and routes work back to the right cause.Independent inquisitors
Specification · Test · Code · Discovery challenge
Searches for assumptions, weak evidence, drift, and omissions beyond ordinary review.Preflight and scope gates
Artifact checks · identity checks · scope checks
Stops known-bad inputs and missing required conditions before expensive inference.Specification gates and repair
Structured review · deficiency reports · remediation
Tests whether specifications are usable, then repairs them before build work advances.Remediation and stopping conditions
Repair loops · stall detection · process recovery
Prevents infinite retry and sends faults to a bounded repair, decision, or stop path.Decomposition system
Spec maps · parent/child coverage · delivery waves
Splits work without losing coverage, dependencies, contracts, or ownership.Worktree and source controls
create-worktree · compare-files · translation verification
Queue, state, and operator tools
Queue tooling · pipeline status · monitoring
Makes active work, ownership, phase state, and stalled runs observable.LLM provider support
OpenAI · Anthropic · Cursor · OpenCode · OpenRouter · local models
Model Profiles route individual stations and switch providers without discarding the delivery contract.Third-party tool support
Git + worktrees · Gitea · Docker · Proxmox · Rundeck · Dagu
Connects the factory to repositories, isolated execution, scheduling, jobs, and source-control workflows.Engineering rulebook and procedures
Core principles · phase procedures · safety hooks
Makes authority boundaries and operating expectations consistent across the line.These are working components, not a future roadmap graphic.
They are routinely operated and revised as the factory evolves. A technical evaluation can inspect the relevant workers, controls, procedures, artifacts, and boundaries for the edition under consideration.
Build and Model Profiles
Select the rigor and model route for the work in front of you.
Profiles are product components. A Build Profile states what the delivery must prove; a Model Profile assigns suitable models and effort to individual stations without giving a provider ownership of the process.
Make the required proof—and the limits—explicit.
- PoCProve requested behavior and visible result for an idea.
- MVPEstablish core behavior, integration path, acceptance evidence, and named baseline scope.
- Team + OrganizationSet shared engineering, ownership, and cross-team operating obligations.
- SaaS + Mission CriticalIncrease operational, security, reliability, and authority requirements by consequence.
- Pipeline CriticalProtect inference-driven control machinery from worker-led changes to its own evaluation path.
Route the job, not the entire factory, to a provider.
- Station routingAssign planning, Test, Code, review, remediation, and decisions independently.
- Provider flexibilityOpenAI, Anthropic, Cursor, OpenCode, OpenRouter, and local models can be mixed or changed.
- Effort by taskUse the right model and effort level for the station instead of overspending everywhere.
- Stable contractRequired artifacts, gates, evidence, and process boundaries remain as routes change.
Start with supplied profiles, then keep, modify, or design the profiles your application needs.
Profiles can apply to a feature or delivery slice—not just an entire product. A PoC feature can become a source artifact for a later SaaS or high-consequence delivery.
Why the machinery reduces cost
Spend inference on judgment, not repeated avoidable failure.
The system uses deterministic checks where a fact can be verified mechanically. It narrows context, repairs malformed instructions, detects repeated stalls, and changes a model route without replacing the process.
Precheck before expensive judgment
Validate structure, required artifacts, identity, and known conditions before paying a model to reason about a broken input.
Repair before retry
Fix a weak PRD, specification, XML artifact, or instruction instead of repeatedly prompting the same defective input.
Route by station
Use a Model Profile to match capability and effort to a particular job, while retaining the same engineering contract.
Stop and escalate
When a loop stalls, surface a decision or recovery path rather than spending unbounded inference on a non-improving retry.
The controlled line
View the process →See how the working base moves from incoming PRD to accepted evidence.
Every component exists for a reason: it addresses a known failure, reduces repeat work, or establishes a boundary that models should not own.