Building Production Software Factories with Autonomous Agent Workflows

software_factory · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous software-development factories

The team wanted software factories that could plan, build, review, deploy, monitor, and improve applications with minimal human intervention while still preserving quality, auditability, and safe escalation points.

Constraints:

• The factory must cover the full SDLC rather than a single coding step.
• Human input should move upstream into planning, product taste, and factory maintenance.
• Generated code needs automated review, testing, CI, deployment checks, and operational feedback.
• Agents need enough state and task structure to coordinate multi-step implementation work.
• Autonomous code generation creates security, merge-conflict, and trust-calibration risks.
• Different organizations may prefer either a managed platform or a custom deterministic implementation.

Architecture

The transcript describes two production-oriented software-factory designs. The Owner-based factory decomposes SDLC work into planning, building, review, deployment, and operations automations, using Owner sessions, feature planners, PR review/shepherd agents, GitHub Actions, Vercel, Storybook checks, Sentry incident loops, and an automation auditor. The custom Rust factory takes the opposite path: a monolithic EC2-hosted binary with a Bedrock conversation manager, tool registry, state-machine/DAG orchestration, task blueprints, adversarial plan/code/test agents, commit-based state, Jujitsu conflict tracking, and a nightly overseer that mines agent traces for factory improvements.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  human-planner[Human planner] --> owner-planning-automations[Owner planning automations]
  owner-planning-automations --> owner-building-automations[Owner building automations]
  owner-building-automations --> storybook[Storybook]
  owner-building-automations --> review-automations[Review automations]
  review-automations --> github-actions[GitHub Actions]
  github-actions --> vercel[Vercel]
  vercel --> operations-automations[Operations automations]
  storybook --> operations-automations
  operations-automations --> sentry[Sentry]
  sentry --> owner-planning-automations
  human-planner --> factory-dashboard[Factory dashboard]
  factory-dashboard --> rust-factory-binary[Rust factory binary]
  rust-factory-binary --> bedrock-conversation-manager[Bedrock conversation manager]
  rust-factory-binary --> tool-registry[Tool registry]
  rust-factory-binary --> task-dag-orchestrator[Task DAG orchestrator]
  task-dag-orchestrator --> adversarial-agent-reviewers[Adversarial agent reviewers]
  task-dag-orchestrator --> jujitsu-state-history[Jujitsu state history]
  rust-factory-binary --> nightly-overseer[Nightly overseer]
  nightly-overseer --> tool-registry

Components

Data flow

In the Owner implementation, a human planning input or feedback digest feeds Owner planning and building automations, which generate code changes, pass them through PR review and GitHub Actions, deploy through Vercel, and then send production exceptions or UI regressions back through Sentry, Storybook, post-merge verification, and the automation auditor. In the Rust implementation, a short human requirement becomes a blueprint DAG; the orchestrator schedules dependency-unblocked tasks to coding agents, adversarial reviewers and test agents challenge each step, the factory commits accepted states into Jujitsu, and the nightly overseer mines the day of agent traces to suggest tooling or process fixes.

Why this architecture

The Owner-based design uses platform abstractions to move quickly and focus optimization effort on prompts and process. The custom Rust design chooses determinism, control, and horizontally replicable monolithic workers so organizational best practices can be encoded in a state-machine DAG instead of only in prompts. Both designs add review, verification, and feedback loops because autonomous factories are useful only if their output can be checked, traced, and improved.

Models used: LLM-based coding agents · LLM-based plan agents · LLM-based reviewer agents · LLM-based test agents · LLM overseer agent · Amazon Bedrock-hosted models · Owner agent loops

Scale

• The Owner factory produced over 50,000 lines of code and more than 300 merged pull requests over about two weeks.
  “the last two weeks using owner and owner automations running agent loops and seeing I think over 50,000 lines of code now being written, over 300 pull requests”transcript, stated
• The custom factory reached an initial functional implementation in roughly 72 hours.
  “not 72 hours of a coffee-fueled rage um of just typing it all out, right? Um it would have been it would have probably worked a little bit better”transcript, stated
• The custom factory demonstrated task decomposition with a 23-step dependency graph.
  “you can see that this like 23-step task is broken down in like 23 23 tasks are broken down and very clearly defined”transcript, stated
• The operator describes trusting the adversarial factory roughly 70-75%, enough for low-stakes autonomous applications.
  “I don't trust it 100% but it gives me like maybe 70 75% trust against the system so that I can basically fire off these really really trivial tasks”transcript, stated
• The custom factory was maintaining three applications at once.
  “right now it's it's maintaining about two internal apps itself and one green field project all at the same time.”transcript, stated
• The overseer found a repeated inefficiency where coding agents spent 10-15 iterations trying to run Python.
  “coding agents were spending about 10 to 15 iterations um on just trying to run Python.”transcript, stated

Alternatives considered (roads not taken)

Use a managed software-factory platform

Rejected because: The custom Rust implementation prioritized control, determinism, and the ability to encode workflows directly in a state machine.

Build a hyper-production event architecture with EventBridge, listeners, producers, and webhooks

Rejected because: The custom builder chose a simpler monolithic approach to ship quickly, accepting some bugs instead of tripling implementation time.

Let agents rely only on prompt instructions

Rejected because: The custom factory uses DAG/state-machine constraints to encode organizational practice more reliably.

Have humans write detailed technical fixes for bugs

Rejected because: The Owner-based workflow shifts humans toward describing intent and improving the factory rather than specifying code-level fixes.

Trust agents to self-grade their own output

Rejected because: The discussion notes that agents can grade themselves optimistically, so external gates and adversarial review remain necessary.

Patterns

multi-agent-orchestration (agent-architecture)

The factories coordinate planner, builder, reviewer, test, incident-response, auditor, and overseer agents across the SDLC.

tool-use-orchestration (agent-architecture)

The custom factory controls LLM behavior through a Bedrock adapter, tool registry, custom tools, and a DAG-driven orchestrator.

durable-execution (orchestration)

The custom factory records every state as a commit, uses a dependency DAG for scheduling, and preserves conflict history for recovery.

observability-tracing (operations)

Operations automations, Sentry, metrics collection, and the nightly overseer inspect production and agent traces to improve the factory.

human-in-the-loop-gate (governance)

Humans remain in planning, UI/UX verification, factory maintenance, catastrophic failure handling, and high-risk governance decisions.

eval-driven-development (quality)

The factories use CI, database migrations, post-merge checks, UI comparison, code review agents, test agents, and future formal verification concepts to control quality.

Tradeoffs

Managed Owner platform versus custom Rust factory

Chose Both approaches are shown: Owner for platform abstraction, Rust for deterministic control over A single universal factory architecture.

Rationale: The transcript frames factory design as a spectrum between operational abstraction and low-level control.

Monolithic state-machine binary versus event-heavy production architecture

Chose A single Rust binary with a state machine and custom tools over EventBridge-style listeners, producers, and webhooks for every event.

Rationale: The monolith shipped faster and encoded deterministic workflows, at the cost of bugs and less production polish.

Autonomous low-risk operation versus heavy human review

Chose Let the custom factory operate autonomously on low-stakes internal applications over Insert humans into every code-writing or pull-request decision.

Rationale: The operator accepts partial trust because the applications are low stakes and failures can be observed or escalated.

Use Jujitsu for auditability

Chose Jujitsu conflict-preserving history over Git conflict resolution that loses some information.

Rationale: The factory needs detailed audit trails of autonomous state and conflict decisions.

Improve the factory instead of micromanaging code fixes

Chose Spend engineering effort on process, prompts, specs, verification, and factory maintenance over Directly specifying every implementation-level bug fix.

Rationale: The factory can handle implementation if humans give intent and improve the mechanisms that generate future output.

Gotchas (what bit them)

Autonomous factories can change the systems that govern them.

Root cause: Application code and workflow definitions are often coupled in the same repository, giving agents a path to alter factory behavior.

Resolution: Separate workflow definitions from application code and apply stricter controls to factory behavior changes.

Agents can waste many iterations on missing environment capabilities.

Root cause: The coding agents tried repeatedly to run Python in an environment where it was blocked or unavailable.

Resolution: Use overseer feedback to add an explicit tool wrapper that exposes the needed capability safely.

Merge conflicts can exceed autonomous recovery limits.

Root cause: Concurrent autonomous tasks can produce file conflicts that the factory's rework loop cannot resolve alone.

Resolution: Persist every state and conflict in version control, then escalate catastrophic conflict failures to a human or a focused single coding agent.

Agent self-assessment can be overconfident.

Root cause: The discussion notes an agent grading its own quality quickly as an A despite human skepticism.

Resolution: Use external verification, adversarial review agents, and explicit gates instead of relying on self-grades.

Autonomous code generation introduces real security incidents.

Root cause: Factories can ship quickly and repeatedly, expanding the need for layered security review and clear responsibility.

Resolution: Tailor security reviews, risk gates, and sign-off policies to the organization's risk appetite.

Evaluation

The transcript reports production-oriented scale and operational checks rather than formal benchmark results. Evaluation relies on merged PRs, active app usage, automated CI/database checks, post-merge verification, UI comparison against Storybook, Sentry incident loops, adversarial reviewer/test agents, commit-history auditability, and overseer-driven process improvements.

Metrics: Over 50,000 lines of generated code · More than 300 merged pull requests · CI and database migration checks · Post-merge deployment verification · UI comparison against Storybook · Sentry exceptions and bugs · Agent-review trust estimate of 70-75% · 10-15 wasted Python iterations detected by overseer · Operational usage of maintained applications

Outcomes

• The Owner-based factory built Memo with over 50,000 lines of generated code and more than 300 merged pull requests.
• The custom Rust factory maintained two internal apps and one greenfield project at the same time.
• The teams shifted engineering effort toward factory maintenance, prompt/process improvement, verification, and product direction.
• The nightly overseer found a repeated Python-tooling inefficiency and led to a tool-wrapper improvement.
• The transcript does not report formal defect-rate, latency, cost, or user-satisfaction benchmarks.

Concrete scale includes over 50,000 lines of code, more than 300 merged pull requests, a roughly two-week Owner build, a roughly 72-hour custom factory build, a 23-task dependency graph example, three concurrently maintained applications, and a 70-75% subjective trust estimate.