Actually, the shape of the work does change

Bolting AI agents onto sprints only makes the horse run faster.

Jul 14, 2026

So many of the approaches to AI in software delivery are about making our existing workflows faster. We take sprints, stories, gates and bolt agents into the seats. Work moves quicker.

The shape of the work doesn’t change.

It’s faster horses.

I know, because I built one of them.

I made a Claude skill suite called delivery-team. Thirteen role-shaped agents; scrum master, devs, QA, conservative and aggressive project managers - all moving stories through a multi-stage pipeline.

It’s good, too. Fast, tireless, it never lost the thread. It moved “vibe coding” to something with much more rigor around it. It wasn’t something I was looking to replace.

But a couple of months ago I had the chance to sit down with some of the staff at Obvious.ai to talk about their autobuild solution. And an idea got stuck in my head.

It wasn’t “how do I make this faster?”

I wondered if we were looking at things the wrong way. That speeding up human processes is the least interesting things we can do with the power of AI.

Scrum exists because humans get tired, change their minds, need ceremony to keep coordinated. Agents have none of those problems.

So I built a second suite of skills. It’s called flow, and it keeps almost nothing from the first. It trades sprints for convergence. Stories for detailed, executable specs (something Obvious.ai highlighted), pass/fail gates for a Pareto front of competing implementations. No retros, but preserved dissents that reactivate when the conditions come true.

This piece is two things. I’ll talk about the practicalities of each suite - the repo is public, there’s a website explainer, you’re welcome to run either. But it’s also an argument about the underlying thoughts: about the difference between speeding up human workflow or asking what delivery can look like when humans don’t have to coordinate inside it.

Respect to the horse

I built the horse first. And I built it with care.

delivery-team simulates a thirteen person Scrum team, with seven gated stages. They coordinate with documents - agents reading and writing artifacts with clear schema. QA can veto but not write code. Architects lay down high level skeletons that are sharded into stories, and that avoids drift. It uses recognized foundations: BMAD, MetaGPT, Team Topologies.

I can point it at a codebase, or work with it to build from scratch. It goes fast, and it’s good. It never gets tired, never waits for a calendar, and never forgets where it’s at.

But that’s also a problem.

It’s accelerating workarounds that we made for humans. It’s not doing AI-native delivery.

Hell, it still asks me “do you want this to be a 3-day, 5-day, or 10-day sprint?”, even when I know the work will be done in about an hour and a half.

Role abstraction is a crutch.
The suite has thirteen fixed agents. Hand-tuned. But those roles exist because hiring humans is expensive and so we specialize and we commit. That’s payroll, not architecture.
Google and the University of Cambridge’s paper on Multi-Agent Design found that optimizing topology and prompts beats fixed roleplay by nearly 80% on agentic tasks. Anthropic’s own research system dispatches dynamically - one agent for something simple, ten or more for something hard. It’s not using the same org chart every time.
Sprints are a backstop for risks in human commitment.
We time-box sprints because calendar coordination is costly, and if we put things into two-week boxes then it’s safer. An agent doesn’t have any of those uncertainties, and it doesn’t need a calendar.
Sprint boundaries are arbitrary lines we use to manage people. Not the work.
Heuristics for humans.
Story files locked at eighty percent test coverage. That’s a number to trade human effort for human risk. It’s not a property of LLM code. But our stories start drifting the moment we start work.

Rituals aren’t features. And if we put them in the AI loop, they start to become obstacles.

What if nobody gets tired?

flow is designed for agents instead of trying to design around them.

I took some insights from Cognition AI’s 2025 engineering post.

Actions carry implicit decisions, and conflicting decisions carry bad results.
Agents can read in parallel safely. But they cannot write in parallel safely, because they all made decisions and accumulate a pile of them that aren’t reconciled.

flow lets multiple agents read, score, search and dissent - but only one of them commits. Intelligence works in parallel, but writing is serial.

Not my invention, but it’s what I built around. It shapes everything that happens downstream of it.

Specs are the source of truth.
I think this is a concept fast getting traction. Take the whenwords library, which shipped in February. More than seven hundred conformance tests, no hand-written code, and all the maintenance is in the spec.
The code is the build artifact of the spec.
Stories become generations.
We build a wide population of implemented variants. They’re scored against an eval suite. It’s not one attempt that we choose to accept or send back.
Acceptance gates become a Pareto front.
We treat quality as a vector. We’re trading speed against simplicity, simplicity against security, and so on.
Retros become diffs, reviews aren’t forgotten.
We maintain a running diff between predictions and productions, rather than the ceremony. And dissents are saved as objects that get reactivated under certain conditions. If a reviewer warns “this will break if we introduce X,” they might be right later.

The bit that still feels like AI being “magic” is what happens next. flow doesn’t build one implementation and refine it. It builds five (or six, or seven - it decides how many it needs) at once, all from the same spec. It scores against different evals, and each build focuses attention on a different metric. Then it converges, keeps what’s good, regenerates and converges again.

That’s five parallel takes being iterated in tandem. If that was a human team, that’s five engineers, five branches, a month of time we probably don’t have. An agent population does it in one afternoon.

It’s a weird way to work. It burns a lot of tokens. But watching it happen convinced me it’s a question worth chasing after.

But we all know the price of gas

None of this is perfect.

flow costs about five times the generation tokens of delivery-team. That signal might be worth every cent. Or you might have spent fifteen dollars when three dollars would have told you what you need.

It fails in different ways, too.

Sometimes it will try to game its own metric. Generators tend to satisfy the eval as much as solve the problem. Goodhart’s Law lives in the same system I built to avoid Goodhart’s Law about old threshholds!

Eval suites can be wrong, and wrong evals aren’t a bug, they’re a problem with the spec. So we might confidently reward the wrong variant.

It’s not fully automated yet (although neither is delivery-team), which is already leaving opportunities for acceleration on the table.

Perhaps most importantly, flow needs that spec, so you need to be able to write it. If it’s doing exploratory work, or you don’t know what “correct” even means, it’s going to flail. And its flailing gets expensive.

The horse is still valid. delivery-team might still be the right tool. When the spec can’t be pinned down. When stakeholders need a recognizable word like “sprint” to trust the machine. You can reach for different skills at different times.

My curiosity has resolved into a much better set of questions. Not yet a verdict.

Curiosity killed the cat

Curiosity is a great reason to build something. But a bad reason to trust it.

So run the same effort through both. You can write the same problem statement. Define the same set of evals. And look at the metrics; time to ship, token spend, human review time, defect count, etc. flow should beat the delivery-team horse, and it certainly shouldn’t regress.

This is still a live test. It isn’t a launch.

Both suites are open-source.

The repo is at github.com/shinytoyrobots/agentic-delivery-suites.
Further documentation at shinytoyrobots.github.io/agentic-delivery-suites.

Clone them, run them, apply them to your work. Tell me what’s wrong.

The fork

It’s not really about the specific skill suites.

It’s about the problem. Can you write the spec? Can you instrument the evals? Do stakeholders need a specific vocabulary to instill trust.

One of these is the better horse. The other one might be a car.

Robin Cannon

Ready for more?