A software factory gradually removes the human from the software development life cycle so work can move from development to production automatically.
2
Agent swarm infrastructure has workable runtimes, orchestration, and triggers, but agents still lack a good way to coordinate tasks and verify progress.
3
A coordination layer could package workflows and development-life-cycle gates behind a CLI that local coding agents can invoke.
Summary
Lou Bichard argues that teams building software factories need infrastructure for fleets of coding agents, not just individual agent runtimes. He defines a software factory as a gradual move toward removing the human from the loop, with work flowing from development to production automatically. The runtime and orchestration pieces are mostly available, including virtual machines, triggers, schedules, and fleet management. Coordination is harder. Agents need to pass tasks between one another, exchange messages, follow the smaller steps inside the software development life cycle, and know when they can move forward. GitHub and Linear expose human-oriented workflows that become noisy when agents create many changes. Bichard proposes state-machine workflows, durable execution, compliance gates, and a CLI gateway that any local coding agent could call to check whether it has completed a stage. He is also direct about the limits: context rot causes agents to lose track of their work, and agents may skip steps such as tests.
A software factory removes the human from routine development work
Bichard defines a software factory as a commitment to move the human out of the loop over time. The human should not have to proactively interact with a computer for every change. Work should flow from development into production in an automated way. This differs from a setup where one engineer manually manages many parallel coding agents. Bichard says the industry is still very early, even though many teams are beginning to apply coding agents across the software development life cycle.
Agent workloads fall into swarms, fleets, and event-triggered flows
Bichard describes a swarm as one intent being sent to several agents and then funnelled back into one pull request or task. A fleet fans agents out across multiple repositories in an organization. Events determine when agents come online, such as when a pull request is raised or a Linear ticket is created. These patterns let teams run coding agents at scale and reduce the need for a person to start each task manually.
Stripe and RAMP built internal systems because agent fleets need their own infrastructure
Stripe calls its internal system Minions. It plugs coding agents into existing infrastructure and drives thousands of pull requests inside Stripe. RAMP calls its system Inspect, another internal platform for running background agents. Bichard says both examples show large companies building this infrastructure themselves. He argues that this recurring work points to a missing shared primitive for agent fleets.
Harness engineering encodes development knowledge into the repository
Bichard describes harness engineering as an extension of context engineering. Repository content such as skills, agents.md files, and unit tests gives the agent information and feedback about how to work. The process is iterative: let an agent run, find where it gets lost, then encode that knowledge back into the repository or its context. The goal is to help the agent move through the software factory without relying on a person to explain every step.
The infrastructure has three parts, and coordination is the unsolved part
The first part is a runtime where an agent can run. Bichard considers this mostly solved. The second part is orchestration, which covers scaling agents up and down and triggering them. Coordination is the difficult part. Agents need to interact, pick up tasks from one another, collaborate, and pass messages. Bichard prefers virtual machines for proper development tasks because containers are not a bulletproof security boundary and can create noisy-neighbor problems when agents compete for compute.
Owner can run process sub-agents inside one VM or fleets across many VMs
In the Owner demo, one task asks an agent to implement Symphony using process-based sub-agents inside a VM. Another task runs a fleet in which an agent creates additional virtual machines. The parent agent gives sub-agents smaller tasks and receives messages back to control the overall work. Bichard shows two user interfaces for this: isolated VMs that scale out, and process-level sub-agents that appear within one agent window with separate contexts.
Software factories must break the development life cycle into smaller steps
The familiar high-level stages of the software development life cycle hide many smaller steps. Agents do not reliably understand or respect those broad boxes. Bichard says a factory therefore needs to break stages such as planning into micro-steps and make agents follow them in more deterministic ways. Context makes this difficult. As a context window fills, context rot causes an agent to lose track of its direction. Agents may also skip requested work, such as some tests, in order to finish.
GitHub and Linear become noisy when used to coordinate large agent fleets
GitHub can receive pull requests from agents, but a person still has to understand what needs intervention, resolve merge conflicts, and fix failing CI. At fleet scale, this becomes too noisy for a human to manage. Bichard says Symphony, an example he discusses, uses Linear but runs into the same problem because a human-oriented tool is being reused for agent coordination. The missing layer needs to track agent state and progress directly.
A CLI gateway could let any coding agent check its workflow state
Bichard proposes packaging coordination as a CLI that a local coding agent can invoke. The agent could ask whether it has completed its current stage of the development life cycle and whether it can proceed. The underlying workflow might be expressed as a state machine or graph, with durable execution and gates for compliance. He says his prototype is not currently built on ACP, and he is more interested in agreeing on a standard than preserving one implementation.
"I think that if you have a local running agent, cloud code, whatever, any local running CLI, I think that now needs to have something that integrates with its tool so it can invoke this to say, "Hey, have I achieved this part of my SDLC and can I now proceed to the next part of it as a CLI?""16:39
Who should watch
You are building a system that runs coding agents across many repositories and need to decide which infrastructure belongs in the platform layer.
Your agents can execute tasks but lose track of workflow stages, skip checks, or leave humans sorting through a large queue of pull requests.
You are designing a coordination protocol or CLI for local and remote coding agents and want a concrete view of the problem from an existing platform team.
