skip to content
$empowered.guru

Engineering

Agile Is Broken for AI Agents. Here's What I Use Instead.

Scrum was built to solve human problems: context-switching, drift, morale. AI agents fail in entirely different ways, so copying agile onto them breaks down. Here's the method I use to run a fleet of AI agents: verified outcomes, event-driven dispatch, and a retrospective that runs itself.

August 18, 20264 min read
S

Staff Writer

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

Agile Is Broken for AI Agents. Here's What I Use Instead.

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 solvesWhat agents actually need
Context-switching is expensive → WIP limitsSpawning is cheap; agents run in parallel instead
People drift out of sync → daily standupA structured digest replaces the meeting
Estimation is unreliable → story pointsCost, latency, and model quality are the real variables
Burnout → retrospectiveNo 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

  1. Intake: work arrives as a trigger or ticket.
  2. Claim: one agent takes it, with a time-to-live so stalled work gets reclaimed.
  3. Isolate: the work happens in its own branch or environment, never on a shared checkout.
  4. Work: with a hard budget reserved before anything runs.
  5. Verify: the CI gate is the definition of done.
  6. Merge and deploy: automatically, once it's green.
  7. Log: an automated digest replaces the standup.
  8. 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.

Filed under

AI AgentsAgileScrumSoftware EngineeringEngineering ManagementAI Engineering
$empowered.guru --book-session

Keep exploring

Turn the next insight into a shipped product.

Bring us the product, architecture, or delivery problem you are working through. We will help you find the clearest path forward.