# Two ways to build software: on your laptop, and in a Software Factory
> Source:
> Published: 2026-11-06 00:00:00+00:00
# Two ways to build software: on your laptop, and in a Software Factory
The factory paused for approval. The laptop did not have to stay open. The same development loop becomes a different way to work when identity, isolation and memory stop depending on your machine.
**TL;DR**
On your laptop, a coding agent acts as you. In a factory, a board item moves through the same plan, build, review and merge loop in isolated sandboxes, with agents acting as an App and people deciding at the gates. The difference is **identity, isolation and durability**, not a smarter model.
One file defines either a local or a cloud factory. We proved the lifecycle locally first, then carried it into the cloud without moving people out of the decisions that matter.
## The local loop: your agent is you
Most engineering teams that use coding agents today work like this. One person, one agent, one checkout. The agent reads the code, writes a change, runs the tests and opens a pull request. It does all of this under the person’s own repository host login and API keys.
We call this a **federated identity**, and locally it is the right design. When your agent adds a label or approves something on repository host, repository host records you, because it was you, acting through a tool. You told it what to do and you are watching.
That makes the local loop a natural fit for exploration, when the goal shifts as you learn. It also suits work that needs your credentials, your machine or your judgement every few minutes, and short tasks you can watch from start to finish.
It stops scaling in three places. The first is **your attention**: one person can supervise only so many agents. The second is **your identity**: everything the agent does carries your name, so it cannot be the independent check on its own work. The third is **your uptime**: when the laptop lid closes, the session ends.
## What changes in a factory
A Software Factory takes the same loop and moves it off your desk. An ordinary issue on a project board becomes the work queue. A person adds `factory:pickup`, and the factory gives that item its own isolated sandbox and agent session. Planner, developer and reviewer work as lanes inside it, one after another.
In the cloud, those agents act only as the factory’s repository App. Personal repository tokens are removed from every factory sandbox, so an agent’s action cannot count as your approval. When the plan or pull request needs a decision, the factory stops and waits for a person.
*The factory runs the work between gates. People decide at the gates.*
The lifecycle itself is short. Approval gates are the points where the factory waits for a person:
``` php
Issue -> Pickup -> Plan -> -> Build -> PR -> Review -> -> Merge -> Done
a person a person
```
Review is done by a fresh agent that is never the builder, and CI is read by the server on the exact commit under review. Part 2 of this series covers who may say yes at each gate, and why.
## One file defines the factory
A factory is a single YAML file. It names the board, the repositories, the labels, the models each role uses, the limits and the merge policy. The definition separates the work, the roles and the rules that control them:
*Validate before activation. Running work keeps the version it started on.*
The file is strict because a silently ignored rule would let the factory run something other than what you wrote. The server refuses unknown keys. Each role also names an exact `provider:model`, checked on push against the models your workspace is authorised to use. If that model is missing at launch, the run fails visibly rather than substituting another.
Every push creates an immutable stored version. New items pin the newest version; work already in flight keeps the one it started on. Rolling back means pushing the old file, not deploying the server again.
## The same lifecycle on two runtimes
Where the agents run is a separate layer from what they do. A local sandbox serves local and development factories and can run with no network at all. In production, a managed cloud runtime gives each sandbox its own microVM. That means choosing the configured runtime for the work.
This separation matters when you change where the work runs. The workflow and its approval rules should stay recognisable. Moving to the cloud should add independent workspaces and continuity, not require a different development process.
## Durability is what makes the cloud work
The hard part of moving agents to the cloud is not running them. It is **waiting**. A person approves a plan long after the agent wrote it. You don’t want to pay for a sandbox that sits idle all night, and you don’t want an agent that wakes with no memory of its own plan.
So a factory workspace sleeps and wakes as the same session:
- **Idle.** With no input and no agent turn in flight, the workspace is marked idle.
- **Park.** The platform saves first, then stops: a checkpoint of the conversation, the workspace files, the settings and any queued work. The rule is “no save, no stop”.
- **Wake.** A message, an answer or a gate decision brings back the same session, with the same helpers.
- **One live copy.** The record it replaced is marked superseded, so there is never a second copy of the same session.
The useful proof is continuity: the same job can pause at an approval, return with its saved work and continue through review. A restart should not become a new task with no memory.
## The proof path we used
We did not move straight to the cloud. We proved the lifecycle locally first, then moved the same lifecycle to the cloud.
**The factory keeps its team intact.** The agents check the saved work records, identify continuity issues and file actionable bug reports. The factory preserves the connection between the job, its agents and their earlier work.
Improvements go through the same factory: plan, approval, build, independent review and revision. After approval, the factory ships the reviewed change.
The factory also records recovery decisions. When it uses a replacement agent, it discloses that choice in the pull request. Recovery stays visible in the work record.
## When to stay local, and when to use the factory
| Your work looks like… | Use |
|---|---|
| Exploring, spiking, or the goal changes as you go | Local |
| It needs your own credentials, machine or accounts | Local |
| You want to watch every step and steer live | Local |
| A queue of well-described board items | Factory |
| Each change should get an independent review and a recorded approval | Factory |
| Several items should run in parallel, each isolated from the others | Factory |
| A person should only decide at the gates, possibly hours later | Factory |
Most teams use both: local for the work that needs a person in the loop all the time, and the factory for the queue.
## Keep the laptop. Move the queue.
You do not have to choose one way of working forever. Keep the local agent for work that needs you close by, and let the factory carry a well-described queue through the loop you already know. Prove that loop on a real item in a local sandbox before moving it to a managed cloud runtime.
The factory file deserves the same care as code: it is strict, versioned and immutable once pushed, with each run pinned to its version and rollback handled by another push. Decide where people must answer, too. Plan and PR approval remain human gates; cloud agents acting as an App cannot answer for you.
And expect more than a green result. The factory records its work and recovery decisions in the pull request. That record is what lets you step away without losing sight of the work.
*Next in this series: Governing a Software Factory, on who may say yes.*