ChiralityCase study
How we build software with dozens of agents.
We build Chirality App and SWBPIPE with teams of AI agents working at once, on assignments that run for weeks. This is how the work is organized. The record is public.
Write down what you’re building
Each product starts from a requirements document: what it’s for, who will use it, its limits, and what it must do. People and agents draft it together; the person directing the project accepts it. Both are public: the App’s and SWBPIPE’s.
Divide it into assignments
The requirements are split into deliverables. Each gets a scope of work: its purpose, inputs, outputs, how it will be checked, and what it needs from other deliverables. The App’s rebuild started from 41 deliverables in 11 packages. An agent given one of them has enough to do the work, and the others have enough to use the result.
Run the work in loops
Agents pick up the next useful piece of work, carry it through its checks, and hand the result to the work that depends on it. Each assignment keeps an owner through review and repair. A coordinating agent brings the contributions together. The person directing the project makes the consequential choices.
Independent work runs in parallel. Work that depends on something unproven waits while agents investigate what’s missing. The project’s files carry its state from one session to the next, so a long assignment continues from where it actually is.
Review the project at set points
Three reviews mark how mature the work is: when it is ready to assign, when the design is stable enough to build out in parallel, and when the assembled result is ready to examine in use. They measure maturity, not effort spent. A late finding can reopen one part of the design without restarting the project. The management manual explains them.
Release on a person’s decision
A merged change or a passing test doesn’t release anything. The responsible person accepts the result and authorizes it for a stated use, with its limits written down.
From the record
In the App, tests with interrupted writes and large histories exposed recovery and performance problems. Later changes repaired the recovery and cut unnecessary reads and copying.
In SWBPIPE, a change to nonlinear supports added checks that calculated forces and movements agree with the support state used, backed by independent reference cases and separate reviews.
Then it starts again
When a version is done, what we learned goes into new requirements, and the cycle repeats. The next App is being built this way: a clean rebuild from its specifications, not an upgrade of the old code.
New to this? Start with the manual.