The film follows agents from four providers through one sprint, from the brief I speak to the release. It shows what keeps that parallel work trustworthy: no change merges until its checks pass and an agent from another provider has reviewed it.
Seven chapters
One sprint, from brief to release
In seven short chapters, the agents plan the work, share it out, build and review it, and ship a release into a year of further sprints.
Your device asks for reduced motion, so I show the film as stills, one for each chapter. Choose a chapter by its number to see it.
Pixie is in development. This scene is an illustrative simulation, not telemetry.
Every project starts with a brief I say out loud: what to build, who it is for and when it has to ship. Here it is a propagation forecast service with live space weather ingest and a dashboard, due this quarter.
The words of the brief that name the work become the project’s title, and that title stays on the project row for the rest of the run.
The planners run in the same harness as every other agent, and each one carries its role and its provider, so I can see who argued for what. Most of their messages are about order: what has to exist first, and what can safely run in parallel.
The ledger records each decision as it is reached, and the memory layer keeps the ones that will matter later in the project.
The schedule has twenty tasks in four workstreams: eight in the Forecast API, five in Ingest, four in Operations and three in the Dashboard. Operations starts on the first day alongside the API, the Dashboard starts once the API contract lands, and Ingest starts later because it needs the data model and the deploy pipeline first.
Each curve is a dependency between workstreams. The accent line is the critical path, the longest chain of estimated work through those dependencies, so a delay anywhere on it moves the release date.
Each task goes to Claude Code, Codex, Cursor or Gemini based on the work that model family handles best, and the reason is recorded with it.
Mixing providers is deliberate. An outage or a rate limit at one of them slows the project instead of stopping it, and every change can be reviewed by an agent from a different provider than the one that built it.
An agent picks up a task as soon as its dependencies have merged. Each one works inside a harness that reports to the ledger, and the ring around it fills as it gathers context, uses its tools and produces evidence. When a task’s own provider is busy, another provider’s builder takes it, and the ledger records why.
Every finished task is checked against its exact revision. When a check fails, the task goes to a fixer with the failing evidence attached, and the repaired revision is checked again and then approved by a reviewer from a provider that neither built nor fixed it.
Lessons, decisions and conventions go into the memory layer as the work happens, so the next agent on the project starts with what the last one learned.
One sprint is only part of the picture. Pulled back to the quarter, the earlier sprints show as done, and this sprint’s workstreams turn green one by one as their last tasks merge.
When the final workstream completes, the whole quarter is green, which is the state I plan every quarter to reach.
When the last task merges, the release is tagged on the project row and promoted to production. Across the year, the finished sprints and releases are green, and the ones still ahead are drawn in outline.
A release does not end the work. The agents move straight on to the next sprints, and the film comes to rest with that work still running.
All of it runs on Linux and Mac machines in my studio, in containers, with Microsoft Azure and Google Cloud for the work that belongs in the cloud.
This is the flow I run today, directing the agents myself, mostly by voice. I am building Pixie, a Rust runtime, to automate it on my own machines. It is in development, and nothing in this film runs on it yet.
If you want a fleet like this working on your product, tell me what you are building and where it has to run.