Overlooked Components of the Software Factory

(Or: What we learned turning agent work into a unsupervised software factory)

Primitives to create your own self-driving software factory

fp: local-first issue tracking for humans and coding agents.
drift: Bind docs to code and check for drift.
Tarmac: a light software factory inspired by Symphony
rv: evidence review tool (coming soon!)

Links:

Fiberplane issue board showing Switchboard work moving through todo, in-progress, and done

Everyone Is Talking About Software Factories

OpenAI: "An open-source spec for Codex orchestration: Symphony."
StrongDM AI: "Software Factories And The Agentic Moment."
Simon Willison: "How StrongDM's AI team build serious software without even looking at the code."
exe.dev: "Everyone is building a software factory."

"A Dark Software Factory is an autonomous software production loop where agents turn intent into shipped code, validated by scenarios, and evidence, instead of human line-by-line review."

OpenAI's Symphony

OpenAI Symphony before-and-after matrix showing more work delegated to agents across ambiguity and complexity

What We'll Cover

Issue Tracker (fp)
Orchestrator (Tarmac)
Cursor Agents

What We Won't Cover

Planning
Review / Verification
Factory Observability

What’s overlooked about them?

How they connect to each other
- How the orchestrator picks up and dispatches work to implementer
- How code gets pulled in/out of sandboxes
  - Pulled down from GitHub?
  - Local worktree scp’d or mounted?
- How work on dependent tasks gets merged together
Responsibilities of orchestrator versus the implementer
- Who updates tickets?
- Who files new tickets? (If out of scope bug found)
The interface
- Issue tracker?
- Slack?

Teaching the Agent to Drive

Premise: Before handing over the keys, you can keep a long running agent session that knows how to use fp to coordinate work with cloud agents and monitor them.

fp becomes a stateful scratchpad of what's in flight, and how to find the in-flight work in Cursor Cloud. You direct the agent on how to dispatch work to Cursor Cloud. fp keeps notes in the tickets about what worked and didn't work, becoming all the learnings you want to bring to a self-driving orchestrator.

Long running sessions are becoming more practical
- Codex and Claude Code teams make regular use of them
- Compaction has gotten better
- But you still want some form of durable memory
Drive work with the agent, and bake in reflection
- This gives you the basis for what skills a self-driving orchestrator would want to have

A Factory Is A State Contract

A software factory is not mainly an agent launcher. It is a consistency contract between four layers:

Layer	Question
Tracker	what work is eligible?
Orchestrator	what work is picked up?
Worker	what is happening now?
Human	what can a human trust?

Correct means these layers agree. Safe means disagreements are visible before they become silent wrong behavior.

Prescribing Workflows for Cloudy Agents

Premise: In order for the agent to work in the cloud it needs some specific prompting and/or skills.

Subagent review with Cursor's thermonuclear code quality review
Instructions on running the app and verifying