From harness to software factory

The workshop ends with one repository, one harness and a scoreboard at 24 of 24. Every run in it still starts because a person typed something: a prompt, a droid exec in CI, a /missions brief. A software factory is what happens when the work starts without anyone typing. An alert, a new ticket or a pull request starts a Droid session on its own, and the harness you built decides what that session may do.

This page covers what Factory means by the term, how the Larkspur harness carries over, which automations Larkspur would adopt next and in what order, and how Ruth's three conditions still hold once nobody is at the prompt. Every product claim links to the Factory docs page it comes from. The docs were checked on 29 September 2026.

Private Preview

Software Factory, Triage, Release, Incident Response, Remote Delegations and Agent Effectiveness are all marked Private Preview in Factory's docs, and so are webhook triggers for automations. Access depends on your organization. Automated Code Review, Security Review, Automated QA, AutoWiki, Missions and droid exec carry no preview label. Check each page before you plan around it.

What Factory means by a software factory

Factory's Software Factory overview describes a 24/7 autonomous system that connects AI agents across the software development lifecycle, from intake and triage through planning, execution, validation, shipping, monitoring and recurring automation. In the Factory App, the Software Factory page is where you track it: live metrics, connected integrations, repository coverage, stage health and the persistent automations behind each stage.

The docs split the lifecycle into six stages. The first two columns are the overview's. The surfaces column is this page's mapping: the overview itself lists Slack and Linear delegation for Code-gen, and Code Review, QA and Security Audit for Validate.

Stage	What it covers	Factory surfaces
Triage	Classify inbound work, reduce duplicates, route items	Triage, which takes intake from Linear, Slack and GitHub
Code-gen	Connect requests from Slack or issue trackers to implementation sessions	Remote Delegations, Missions, Droid Exec
Validate	Code review, security review and QA before merge	Automated Code Review, Security Review, Automated QA, Droid Control
Release	Deployment gates, release checks, ship workflows	Release
Document	Keep repository knowledge current	AutoWiki
Monitor	Connect incidents, alerts and agent effectiveness back to engineering work	Incident Response, Agent Effectiveness

The unit of work in each stage is an automation: a trigger (a schedule, a Slack message, a GitHub event or an inbound webhook), instructions, a run identity (you or a service account), a run target (a Droid Computer, your own machine, or GitHub Actions for GitHub automations) and a visibility setting. Each time the trigger fires, the automation starts a Droid session. Droid Computers are the persistent machines many of those sessions run on: installed packages, files and configuration survive between sessions.

Delegating from Linear or Jira doesn't need an automation at all. The overview says to use the Remote Delegations guide for those apps instead.

The diagram maps the stages to the surfaces above. Orange marks what the harness enforces in configuration and code. The dark node is where a person decides.

The harness is the foundation

An automation is a Droid session nobody is watching. Everything the labs taught about headless runs applies to every one of them: nobody answers an ask rule, nobody reads the plan, and the session does what its context and its controls allow. That's why the harness comes first and the factory second.

Each artifact you built has a job in the factory:

What you built	Lab	What it does once work starts on its own	Source
AGENTS.md	2	The project briefing every session loads. Factory's AGENTS.md guide says project instructions belong in git "so every teammate and automation session gets the same operating context".	AGENTS.md
Permission rules and sessionDefaultSettings.autonomyLevel	4	Decide what a session may run. In droid exec, an effective ask can't be cleared by --auto high, so pushes and migrations stay human steps.	Permission rules, Droid Exec
Hooks	5	Deterministic checks at the tool boundary and before a session finishes. Hooks fire during Missions.	Hooks, Missions reference
Skills	6	The automations read skills by name. droid-action injects .factory/skills/review-guidelines/SKILL.md into every review run. Incident Response checks an incident-guidelines skill. /install-qa generates its own skills under .factory/skills/.	Automated Code Review, Incident Response, Automated QA
money-reviewer custom droid	7	Available to Mission workers. Its tools: read-only policy is enforced.	Custom droids, Missions reference
The change-control MCP server	8	Facts from a system of record. Automations and Incident Response on a remote computer configure their MCP servers per computer, so the server has to be set up there too.	Custom Automations, Incident Response
droid exec in CI, FACTORY_API_KEY	9	The same engine the factory's GitHub pieces use. The review action is built on Droid Exec. The QA workflow runs droid exec. The scheduled security audit runs droid exec --mission.	Droid Exec, Automated QA, Security Review
Missions	10	Code-gen for work too large for one session, and the recommended way to run a full-codebase security audit.	Missions, Security Review
The scoreboard	0	Your own measure of first-attempt success. Agent Effectiveness measures something different: cycle time and attribution across the organization. Keep both.	Agent Effectiveness

Two honest gaps sit under that table.

First, the docs say Missions inherit AGENTS.md, hooks, skills, custom droids and MCP. They don't say the same, in those words, for every automation or delegated session. A remote session runs on a Droid Computer, an execution template or a GitHub Actions runner, and project permission rules only apply in a trusted workspace. The docs don't say how workspace trust is granted on a remote computer. Before you rely on a project rule in a remote session, run droid rules check on that computer and look at the decision.

Second, a repository harness only protects the repository it's in. For controls that must hold everywhere, the docs point at organization-managed settings. That is the last section of this page.

What Larkspur adopts next, in order

Larkspur has one reviewed harness, a CI job and a nightly scoreboard. The order below follows the same rule as the labs: measure, then add the automation whose failure is cheapest to catch, then widen. Each step says what it needs and where it can go wrong.

1. Automated code review on every pull request

What it is. Factory-AI/droid-action reviews pull requests in GitHub Actions and posts inline comments. /install-code-review sets it up, or you copy the workflow from the action's repository. Lab 9 already runs it.

What it needs. A FACTORY_API_KEY secret, the Factory Droid GitHub App (or your own github_token), and the contents, pull-requests and issues write permissions plus id-token: write for app authentication. review_depth: deep is the default. Put Larkspur's invariants in .factory/skills/review-guidelines/SKILL.md, which the companion repo's harness-reference/ now includes.

Watch for. The docs say the review workflow submits an approval when it finds no issues. For Theo, a bot approval must not stand in for his. Make code-owner review a required check in branch protection, so the bot's approval can't be the one that lets a money change merge.

2. Security review on the same pull requests

What it is. Add automatic_security_review: true to the same action, and Droid runs a security pass alongside the code review: STRIDE, OWASP Top 10, OWASP Top 10 for LLM Applications and supply-chain checks, with findings graded Critical to Low (P0 to P3). A .factory/threat-model.md file, if you write one, is used as the attack-surface map.

What it needs. Nothing new for pull requests. A scheduled full-codebase audit is heavier: the docs run it as a Mission with droid exec --mission --auto high from a scheduled workflow, and upload the results as an artifact.

Watch for. --auto high in a scheduled job is the broadest authority anything in Larkspur's CI will hold. Run it on an isolated runner, keep the org-level block rules in force, and remember the Missions readiness recommendation below.

3. AutoWiki for documentation

What it is. /wiki generates a structured wiki for the repository, and /install-wiki creates a CI workflow that regenerates it on every push to the default branch. Droid opens the workflow as a pull request for you to review.

What it needs. The FACTORY_API_KEY secret. Sam, who joined in June, gets a current map of the codebase.

Watch for. Where the content goes. Generated wikis are stored in the Factory App through Cloud Sync, and for GitHub repositories can sync to the GitHub Wiki tab. An organization that must keep that content out of the Factory App can turn off AutoWiki Cloud Sync in Enterprise Controls. Ask Ruth before the first run, not after.

4. Triage and delegation from Linear or Jira

What it is. Remote Delegations let a teammate assign an issue to Factory in Linear or Jira, or mention @Factory in Slack, and Droid works it on a remote computer. Triage classifies and routes incoming work before anyone assigns it.

What it needs. Private Preview access, the Manager or Owner role, a service account with Git credentials and the connectors the work needs, and compute: an execution template or service-account-owned Droid Computers. Issues that name the repository, the outcome, acceptance criteria and how to verify. The Triage page suggests starting narrow: classify new bugs in one team queue and route only high-confidence matches.

Watch for. Who approves the pull request. For shared delegations, Factory is the pull request author, so the teammate who asked for the work can approve it alone if one approval is enough. The docs show how to require a second reviewer with a GitHub branch rule: two approvals on every pull request, or a required status check that enforces two human approvals only on pull requests opened by factory-droid[bot]. At Larkspur, that rule goes in before the first delegated issue.

5. Automated QA

What it is. /install-qa analyzes the codebase, asks questions, and generates a QA skill that runs on pull requests and tests the application the way a user would. For a backend service without a UI, it tests endpoints with curl.

What it needs. A reliable, scriptable way to start Larkspur's API against test data. In readiness terms that is the Development Environment pillar: an environment template and local services setup. The generated workflow needs GitHub secrets for any credentials in its config.yaml, and the setup lists which.

Watch for. Two settings. Point the default target at a development environment, never production. And keep failure learning on its default, Suggest in report. The other options commit to skill files or open pull requests on their own, which is a change to the harness that Ruth would want reviewed like any other.

6. Incident response

What it is. An Incident Response automation starts a Droid session when an alert bot posts a top-level message in a Slack channel. Droid works toward a root-cause analysis, can open a pull request for a fix when appropriate, and can update an incident-guidelines runbook skill.

What it needs. Slack connected, Factory invited to the channel, a Droid Computer with the repositories and observability tools, MCP servers for those tools configured on that computer, and ideally a service account so the computer and sessions belong to the team. Trigger on messages from defaults to Bots only.

Watch for. A fix pull request from an incident is still a pull request. It goes through the same review, the same protected-path check and the same two approvals. Put Larkspur's escalation rule in the automation's prompt: when the evidence is uncertain, summarize and hand off rather than act.

7. Release and measurement

Release tracks deployment gates, release checks and ship status. Its docs page describes tracking ship workflows "as they become available", and it lists manual approval points among the gates it tracks. At a bank, the approval to deploy stays with the change advisory process, so treat Release as visibility first.

Agent Effectiveness is what Imani takes to the board. It links sessions to issues, projects and pull requests and shows how cycle times change as agent spend is applied. It needs the Advanced Analytics enterprise control plus at least one issue-tracking or source control integration connected at the organization level. The numbers only cover the systems you connect, so connect every tracker for full coverage. It doesn't replace the scoreboard: the scoreboard says whether the harness makes Droid right on Larkspur's own tasks, and Agent Effectiveness says whether the organization ships faster.

Where Missions fit, and what readiness has to do with it

Factory documents one explicit readiness recommendation: for Missions, a repository should be at Agent Readiness Level 4 (Optimized) or above, because a Mission validates its own work by exercising the application. Larkspur is Level 3 after the workshop. The docs give no readiness level for the other automations, so use the readiness report to find the gaps each one depends on instead:

Automation	Readiness pillar it leans on	Why
Triage and delegation	Task Discovery	Triage reads issue titles, descriptions and labels, so issue templates and a labeling system give it something to classify.
Automated QA, Missions	Development Environment, Testing	They have to start and drive the app from a script.
Code and security review	Security, Style & Validation	Branch protection, CODEOWNERS and secret scanning are what make a review gate a gate.
Incident Response	Debugging & Observability	Droid can only investigate what logs, traces and metrics show.

/readiness-fix can work through the failing criteria from the latest report. Review what it changes the way you would review any agent's work.

Keeping Ruth's conditions in a factory

Ruth asked for three things: protected code protected by mechanism, every change traceable, and controls she can inspect. A factory adds sessions nobody started by hand, identities that aren't people, and computers that aren't laptops. Each condition needs a matching answer.

Protected by mechanism, everywhere. A project .factory/hooks.json protects one repository, and only where it loads. Organization-managed settings in Enterprise Controls apply across users and projects:

• Organization permission rules claim their rule IDs before any project or user rule, and block still beats ask beats allow.
• Managed hooks always load unless hooks are globally disabled. allowManagedHooksOnly: true ignores user and project hooks entirely.
• maxAutonomyLevel caps every session and subagent. mcpPolicy allowlists which MCP servers may connect. missionPolicy restricts who can start a Mission.
• The sandbox auto-denies violations in droid exec rather than prompting.

Factory's Agent Safety & Controls page recommends building enterprise security primarily on these deterministic controls, applied through managed settings across laptops, CI, VMs and airgapped environments. The CI protected-path check from Lab 9 stays as the backstop: it sees every change on a branch, whoever or whatever made it.

Every change traceable. Run shared automations and delegations as a service account, so sessions, computers, billing and audit events are attributed to that identity rather than to whichever engineer set it up. Keep Session privacy on Team so reviewers can open the sessions. Each automation's Events feed links every run to its session, and Incident Response posts session links back into the Slack thread. The organization audit log, available to Enterprise owners, records who changed org-managed settings (with before-and-after revisions), service accounts, API keys and integrations.

Controls she can inspect. Everything above is configuration: managed settings, project files, branch rules and workflow files. Ruth can still run droid rules check --command '…' --json and read the decision. What changes is where she reads it. For a factory, the first file she asks for is the organization's managed settings, not the repository's.

One thing doesn't change. A person still approves the merge. Factory's own Remote Delegations page shows how to require two human approvals on Factory-authored pull requests. That's the same position the workshop took on git push: the automation does the work, and a person decides what leaves.

Where to go next

• The regulated guardrails guide for the settings that belong at organization level.
• Droid in CI for the workflow patterns this page builds on.
• Next steps for taking the harness to thirty repositories as a plugin.