The problem: an AI coding agent does different work every run. Ask it to fix a bug twice and you may get a plan one time and a rushed patch the next. A one-person agency cannot supervise every step of every agent, so either quality slips or you become the bottleneck.
The solution in today's radar: coleam00/Archon is an open-source factory builder: you write your delivery process once as a YAML workflow, and Archon runs it the same way every time — agents supply judgment inside each step, scripts make the mechanical decisions, and a run pauses and comes to you only when it needs a decision you own (approvals, scope changes). It ships with a working software factory (the sdlc pack): issue in, merged pull request out, with approval gates, a full event log and per-run costs stored in your own database.
Format note: single-featured-factory layout (standing focus set Oct 25, 2026); the Ethiopia business-opportunity section remains removed. Prior reports were available through Nov 1 (cromford-ai/cromford, KbWen/agentic-os, nexu-io/looper, jmanico/grim-prompter, coleam00/ai-software-factory, obra/superpowers). Archon itself has not been featured before — note that the previously featured coleam00/ai-software-factory is built on top of Archon, so today is a look at the engine underneath it. All facts below verified today from the repo's README, commit history and LICENSE via GitHub. This is a large, fast-moving project — expect churn.
archon-intake decides what it needs, the build queue runs archon-ship (plan, implement, review through specialist lenses, fix findings, wait for CI), the merge queue lands clean, review-ready PRs, unclear questions become single "attention items" with recommendations, and side discoveries get filed instead of lost.irm https://archon.diy/install.ps1 | iex (PowerShell), alongside macOS/Linux (curl … | bash) and Homebrew. A Sep 1, 2026 commit specifically fixes Windows console handling ("hide the console for every subprocess exec on Windows"), so Windows is an actively maintained target — but full-factory behavior on Windows is plausible, untested by us. Prerequisites: git, and at least one coding-agent CLI (Claude Code or Codex) installed and signed in; SQLite by default.Workflow names, artifacts and gate behaviors verified from the repo README today.
| Agency OS stage | Factory module | Artifact it produces | Which gate consumes it |
|---|---|---|---|
| LEAD / PROPOSAL | — not covered | — | — (issues must already exist; client-facing work stays with Agency OS) |
| DISCOVERY / PROBLEM_DEFINITION | archon-intake — checks the issue against the code and decides: plan, investigation, straight to delivery, or a maintainer's look | Classified issue with a chosen route | Build queue only claims "ready" issues |
| SPECIFICATION | plan node of archon-ship — brief + written implementation plan | Implementation plan | Implementation node depends on the plan; loop runs until the test command passes |
| ARCHITECTURE | — no dedicated stage (absorbed into planning) | — | — (gap) |
| DEVELOPMENT | archon-ship implement + build queue; each repository run gets its own git worktree so several can work at once | Implementation on an isolated branch | Loop node runs until your test command passes (until_bash) or max_iterations stops it |
| QA | Review through specialist lenses, fix-the-findings rounds, wait for CI; archon-validate runs project checks | Review verdict, CI status | Stops at a PR whose review says Ready; merge gate re-checks verdict and CI at the head commit |
| SECURITY | — no dedicated security stage in the pack (no secret scanning / dependency auditing gate) | — | — (gap — see Honest Gaps) |
| CEO_REVIEW | Approval gates — any node can wait: the run pauses as one attention item with a recommendation and choices; your answer is written back into the issue as the new scope | Approve/reject decision, resolved scope | Reject cancels the run; approve continues it — the decision is a logged event |
| RELEASE | archon-merge-queue — merges cleanly-merging, review-ready PRs whose verdict and CI pass at the head commit and whose base branch is not red; conflicting PRs go back to the build queue | Merged pull request | Deterministic merge gate; binds to schedules/issue events only if you configure a trigger (pack binds nothing by default) |
| MAINTENANCE | archon-discoveries — files what runs noticed outside their task, tracks it on an existing issue, or drops it; full event log, transcript and per-run cost per run | Discovery issues, audit trail | Nothing found along the way is lost — it re-enters through intake |
| REUSABLE_COMPONENT | Workflows are shareable packs (YAML + commands + scripts); plugin contract for providers, forges, chat; install with archon plugin add owner/repo | Reusable workflow packs | Partial — processes, not business components |
gh); other hosts go through the plugin route.project-state.json being authoritative. It complements, never replaces, your gate engine.gate_engine.py / PowerShell stack on your Windows PC; the integration proposal below stays additive.max_iterations: 10 can make many model calls before it stops. Set iteration caps and start with cheap models/tiers; treat per-run cost reports as mandatory reading.irm … | iex). Read the install.ps1 first — the same rule you already apply to never execute untrusted code blind.https://archon.diy/install.ps1 (never pipe a remote script straight into a shell without reading it); then run irm https://archon.diy/install.ps1 | iex in PowerShell and pick your providers when asked; then archon workflow list to confirm the SDLC pack is available.archon workflow run archon-investigate "Why does the login test fail?" (the README's own first-run example), then archon serve to watch the run in the web console. Add one trivial two-node workflow from the README example (plan → implement loop with until_bash set to your test command → an approval wait) and reject the approval on purpose to see the run stop cleanly.max_iterations: 3); do not bind schedules/triggers; do not connect Slack/GitHub webhooks during the test; read the event log afterward to see exactly what the run did.gate_engine.py.project-state.json; the project's real test command. Outputs: a machine-decided loop outcome (test command exit code, iteration count), a full run transcript, per-run cost, and a single approval item with a recommendation.until_bash) — the agent's claim is irrelevant; the approval decision is a logged event; the gate engine still consumes project-state.json exactly as before.max_iterations → the run fails with a categorical failure class and the transcript shows which node failed; a rejected approval cancels the run and nothing advances.build-feature.yaml (plan → implement loop with until_bash = your pytest command, max_iterations: 3 → approve wait). Run it once, approve it, run it again and reject it. Compare the two transcripts against what gate_engine.py records for the same work — then decide whether the loop pattern is worth adopting.until_bash loop runs the actual test command each round and records the result in the run's event log. In Agency OS today, the same failure class is caught by your precommit/prepush scripts re-running checks — and the fix to copy from Archon is binding the QA exit to a recorded exit code, not the agent's sentence.until_bash loop pattern — "done" decided by your test command's exit code with an iteration cap, plus a logged approval item for every human decision. It removes the most common agent self-report failure. (Security scanning remains a gap — keep your own stage.)install.ps1, install Archon on Windows, and run archon workflow run archon-investigate "Why does the login test fail?" in a scratch repo — then write the example build-feature.yaml and watch the approval gate pause for you.