Most AI-adoption stories in software delivery start from the same premise: take an existing workflow and make it faster. Keep the sprint, keep the stand-up, keep the sign-off chain, just hand a few seats to software.

Consider two agent suites built around this problem. The first simulates a thirteen-role Scrum team moving work through seven gated stages, built on established frameworks like BMAD and MetaGPT. It works well. It doesn't get tired, doesn't lose context, and moves stories through reliably.

The second throws most of that out. Sprints become a convergence process. Stories become executable specs. Pass/fail gates become a Pareto front across competing qualities, speed, simplicity, security. Retrospectives are replaced by a running diff between prediction and outcome, with dissenting opinions kept on file in case they turn out to matter later.

The distinction is really about coordination costs versus coordination mechanisms. Scrum's ceremonies exist to manage a specific, expensive resource: human attention and memory, both of which degrade over a two-week cycle. Agents don't burn that resource, so a coordination system built to conserve it is solving a problem they don't have.

There's evidence behind this, not just intuition. A 2025 Google/Cambridge paper found that optimizing an agent population's topology and prompting beat fixed role-based setups by a wide margin. Anthropic's own research systems allocate agents dynamically rather than deploying the same fixed roster regardless of task difficulty. That matters for organizational design generally: role specialization in firms is partly a response to the fixed cost of hiring and training people, and once someone's hired into a role, work gets routed to that role even when a different allocation would suit the task better. Agents without hiring costs don't carry that incentive.

None of this makes the second approach simply "better." It costs roughly five times the tokens of the first, since it builds several competing implementations at once and scores them against an eval suite. Whether that's worth it depends entirely on whether the eval suite captures what "correct" actually means, a wrong eval doesn't cause a bug, it causes confident selection of the wrong output. It also needs a spec precise enough to generate from, which makes it a poor fit for exploratory work where nobody's yet agreed on what "done" looks like.

So the real claim isn't "strip ceremony out of all coordinated work." It's narrower: ceremony that exists to manage human fatigue, memory, or trust is worth redesigning once the people doing the work no longer have those limits, but only where the task can be specified precisely enough to evaluate mechanically, and only where the humans watching don't need familiar words like "sprint" to trust what's happening.

There's a decent historical parallel here. Early factories that electrified kept the same layout steam power required, motors arranged around a central drive shaft, and productivity barely moved for a couple of decades. The real gains came once factories were redesigned around what electric motors actually made possible. The split between these two delivery approaches looks like a small version of the same lesson: bolting a new capability onto an old structure is the easy first move. Asking whether the old structure was ever really about the task, rather than about the people who used to do it, is the harder, more useful one.

Neither approach has settled the question. Both are live, ongoing experiments. That seems like the right note to end on.

---

Refrances:

Cannon, R. "Actually, the shape of the work does change." July 2026. https://www.robin-cannon.com/p/actually-the-shape-of-the-work-does Delivery suites repo: https://github.com/shinytoyrobots/agentic-delivery-suites