Read this as a different arrangement of the working day rather than a list of tools: where the work lives, what counts as a unit of work, who writes the code, who reviews it, and what a manager can see without asking anyone. The tools underneath are replaceable. The arrangement is the idea, and it is the part that will look unfamiliar.
On the left, how a development cycle is usually arranged. On the right, how it is arranged here. Neither column is about a product.
| the cycle everyone knows | the cycle on a loop | |
|---|---|---|
| where the work lives | On laptops. It stops when they close. | On a server, in named sessions anyone can address. |
| a unit of work is | A ticket, described well enough for a person who will ask questions. | A spec, merged as its own pull request, described well enough for something that will not ask. |
| who writes the code | Developers, with an assistant helping them type. | The machine. Developers write the specs and approve the result. |
| who reviews it | Colleagues, and increasingly an assistant from the same house as the author. | A model from a different vendor, then a person. |
| where knowledge lives | In heads and chat threads. It leaves when people do. | In a journal and a written canon the loop reads before it works. |
| what a manager sees | Status reports, assembled by the people being reported on. | A queue, and numbers anyone can recount. |
| what a person is for | Typing, and being available to be asked. | Deciding. The human is the gate, and only the gate. |
| coordination | Stand-ups, and a team lead holding the state in their memory. | One session that writes no code and holds the state on disk. |
The moments below are taken from real runs and assembled into one day. The day is illustrative; the timings are not invented.
Rather than restate them here, each links to the page that shows it working.
The agent's life is the developer's laptop. Close the lid and the context goes with it. Walk into a meeting and the work stops. The second developer cannot see what the first one's agent is doing, and neither can anyone else.
What you get is a productivity feature, one per person, with nothing to measure and nothing to hand over.
The session runs on a machine that is always on, and the laptop becomes a remote control. Work continues through the night. A colleague can address the same session by name in the morning, and the transcript is on disk either way.
What you get is a shared service with a queue, a review gate and a journal: the thing a number can be put on.
One consequence is worth designing for rather than discovering. A session's transcript exists on disk, and again through the bridge when it is remote-controlled. So a session holding client code never runs on the bridge, and secrets never enter a transcript. That is a rule from the start, not a patch after an incident.
The tempting version of this section is a table scoring the routes on offer. We are not publishing one, for a reason that is the same reason anything here is worth reading: we cannot recount someone else's product, those products change monthly, and being wrong about a competitor reads as spin rather than as a mistake. So here are the four questions instead, answered only where we can prove the answer. Ask them of anything, including this.
If the answer is no, everything downstream is per-person: no queue, no handover, nothing to schedule and nothing to measure across a team.
A reviewer built by the same vendor as the author agrees with it. That is not a suspicion; it is measurable, and worth measuring before trusting a review pipeline.
Not on the plan, not on the review: on the merge. It is the only place where a person is cheap to insert and expensive to omit.
A dashboard nobody can reproduce is decoration. The test is whether a sceptical person can arrive at your figure without asking you.
Any substrate can carry this. The loop is the part none of them ship: a spec in, a rival review, a person on the button, and a journal afterwards.
Three failures from these systems, none of them hypothetical.
It rolled back a working tree each time. Half a million log lines, and not one alert. It was found by accident during a cleanup, which is the worst way to find anything.
Hundreds of graphics allocations failed and the work degraded to the processor without an error. A leaking neighbour was holding a fifth of the card.
It was running the whole time, under a second name nobody could map to the first. Same session, two identities, no way to tell.
Every one of these was caught by a second system with its own memory, never by the one that made the mistake. That is the whole argument for the shape, and the same reason the reviewer comes from another vendor. The weakest block is not the model. It is observability.
Three small steps, each reversible, none of them a platform decision.
Read-only, at the agent-assisted pull requests you already merged, and count what comes back. If it is near zero you have learned something worth knowing too.
reversible: nothing is written
Well described, through the loop, pull requests back. Your engineers keep the merge button. Measure cycle time and review findings against whatever you do today.
reversible: stop after ten
Not an agent per laptop. Learn what a shared agent actually needs from you before anyone has to choose a vendor.
reversible: it is one machine
Everything on this page runs on systems you can look at, with the command to recount each number. If the shape is interesting, the first step is a process review: one of your processes walked end to end, and a written spec you could hand to anyone, including someone other than us.