Staff Writer
Published August 18, 2026 · Updated October 1, 2026last updated dates

Agile Is Broken for AI Agents. Here's What I Use Instead.
Scrum was designed to fix how humans build software together. AI agents break in a completely different way, so I rebuilt the methodology, not the rituals.
I've spent the last two years running engineering work through teams of AI agents, and one question keeps coming up from the founders and CTOs I work with: "Is there a Scrum for agents yet?" There isn't. And the more agents I run, the more convinced I am that there shouldn't be.
The mismatch
Scrum exists to solve a specific set of human problems. Context-switching is expensive, so we limit work in progress. People drift out of sync, so we hold a daily standup. Estimation is unreliable, so we use story points. Teams burn out, so we hold a retrospective.
Agents have almost none of those problems. They fail in entirely different ways, and Scrum never anticipated any of them.
| Problem Scrum solves | What agents actually need |
|---|---|
| Context-switching is expensive → WIP limits | Spawning is cheap; agents run in parallel instead |
| People drift out of sync → daily standup | A structured digest replaces the meeting |
| Estimation is unreliable → story points | Cost, latency, and model quality are the real variables |
| Burnout → retrospective | No morale, but silent, repeating systemic failure |
The bottleneck has moved. Agile optimizes human attention. Agent systems optimize three things instead: verification (did it actually work?), context budget (how much does each run cost to think?), and cost per outcome. Once you see that, copying Scrum onto agents is obviously wrong. The checks are the methodology.
The three values, translated
Working software over documentation becomes verified outcomes over self-reported claims. A coding agent telling you "it's done" is not evidence. A green CI run, a live URL returning 200, and a checksum that matches: that's evidence. Every "done" in my system is a machine-checkable predicate, not a promise.
Individuals over processes becomes capability contracts over personas. Agents shouldn't be organized around named roles that go stale. They're organized around what each can do and the contract it must satisfy: inputs, steps, validation, artifact, safety boundary. The role fades; the contract is the thing that matters.
Responding to change over following a plan becomes event-driven dispatch over fixed timeboxes. Agents don't need sprints. They need triggers. Something fires (a ticket, a schedule, an anomaly), and that creates one occurrence that runs once and settles.
The loop I run
- Intake: work arrives as a trigger or ticket.
- Claim: one agent takes it, with a time-to-live so stalled work gets reclaimed.
- Isolate: the work happens in its own branch or environment, never on a shared checkout.
- Work: with a hard budget reserved before anything runs.
- Verify: the CI gate is the definition of done.
- Merge and deploy: automatically, once it's green.
- Log: an automated digest replaces the standup.
- Improve: the part everyone forgets.
The missing piece: a retrospective that runs itself
Every human-team framework ends in a retrospective, and nearly every agent framework I've seen drops it, because agents don't have morale and people assume they don't need one. They do. Agents accumulate systemic failure silently: the same class of bug, the same expired-key loop, the same stale credential, repeated forever unless someone writes it down and feeds it back.
So my retrospective isn't a meeting. It's a scheduled job that reads the work log, classifies every failure by signature, dedupes against what's already known, and turns anything new into a durable rule that gets patched back into the workers. The same failure can't recur silently, because the system learns from itself.
That's the part none of the "Scrum-shaped" agent frameworks built. They encode org charts. They skip the verification gate and the learning loop, which are the only two parts that actually matter.
What this means for you
If you're starting to hand engineering work to agents, stop looking for a Scrum-for-agents you can install. Look for two things in whatever system you build or buy: a machine-checkable definition of done, and a loop that turns every failure into a lesson. Get those two right and the rest is plumbing. Get them wrong and you'll have a very fast, very expensive way to make confident mistakes.
About the Author
I'm Brian Marvin, an AI-native Fractional CTO with 30 years in technical leadership. At empowered.guru, I help startups hand real engineering work to AI agents without losing control of the outcome.
