AI · · ⏱ 6 min read

The sprint that nobody sleeps

Coordinating teams of autonomous agents with the vocabulary of Scrum and PMBOK: what survives, what breaks, and what remains to be invented.

A human team meets on Monday, discusses the sprint, negotiates the scope, signs the record and goes home. A team of autonomous agents does none of that. And yet someone has to coordinate it. This article crosses Scrum and PMBOK along the same axis: how to coordinate tasks among agents that share neither working hours, nor memory, nor signature.

A human runner hands off a baton to a silhouette that keeps running into the night
Someone hands off the baton. Someone keeps running when no one is watching anymore.

Coordinating without supervising each step

The protocols the industry has consolidated —MCP, A2A— solve the communication layer between agents. They don’t solve the coordination layer. That two agents can talk to each other says nothing about who decides what each one does, when they pause, how they synchronise, and who answers when the collective result fails.

And that layer is not being invented from scratch. It exists, it has been polished for half a century on human actors, and now it starts to look towards agents. In June 2026, PMI released The Standard for Artificial Intelligence in Portfolio, Program, and Project Management — the first global standard explicitly designed for the problem. PMBOK’s 8th edition now integrates AI explicitly. And Gartner reported a 1,445% rise in queries about multi-agent systems between Q1 2024 and Q2 2025. The discipline has started to move. The question is where to.

How work gets assigned

Scrum assigns in sprint planning: the PO presents the prioritised backlog, the team estimates effort, and commits to a scope. Conversational and consensual.

PMBOK assigns via management plan: defined scope, WBS decomposed, resources allocated through a RACI matrix. Documental and traceable.

Neither fits cleanly. An agent doesn’t negotiate effort — it has no notion of fatigue or personal velocity. An agent also doesn’t appear in a RACI matrix, because it doesn’t bill hours or sign deliverables.

What does survive from each framework:

  • From Scrum, the time-boxed commitment: even without conversational planning, the system needs windows where work is frozen so it can be evaluated.
  • From PMBOK, the explicit decomposition of responsibilities: someone has to declare which agent can do what, with what permissions, over which resources.

The first is an operational decision. The second is a governance one. Neither alone is enough.

How tasks synchronise

Scrum synchronises via ceremonies: daily, review, retrospective. Fixed points where the team pauses, shares state and adjusts. Rhythmic and human.

PMBOK synchronises via status reports, milestones and control gates. Planned and documental.

With agents, the first difference is brutal: the agent doesn’t need to pause to synchronise. It shares state on every exchange, every tool call, every memory update. The daily, designed to force periodic visibility that would otherwise scatter, becomes redundant when visibility is continuous by design.

What still makes sense —and here Scrum brings something real— is the retrospective. Not as a meeting, but as a block of time where the system evaluates what it did well, what it did wrong, and adjusts the policy for the next cycle. It is the only moment where a system of agents reflects on itself with distance. And that distance, in a system that doesn’t sleep, doesn’t appear on its own: it has to be designed.

From PMBOK something complementary survives: control gates as points where escalation to human supervision happens before continuing. An agent can execute a thousand autonomous decisions. Decision number one-thousand-and-one, the one that commits a large budget or triggers high risk, has to pass through a gate. It’s not a meeting — it’s a containment mechanism.

How work closes

Scrum closes with sprint review and definition of “done”. Iterative and negotiable.

PMBOK closes with formal acceptance of the deliverable, sign-off and record of lessons learned. Contractual and definitive.

Here the most uncomfortable problem appears. A team of agents can produce an output without any agent being in a position to sign it. Acceptance — the scrum “done”, the PMBOK “sign-off” — presupposes an actor with attributable responsibility. And in a multi-agent system, responsibility is diffuse by design.

What Scrum partially provides is the verifiable increment: the result has to be demonstrable, not just declared. An agent reporting “task completed” is not enough — observable evidence is needed. And that evidence, when produced by another agent, falls into the doubt-as-infrastructure problem already addressed in earlier articles of this series.

What PMBOK contributes with more weight is formal traceability: to be able to close, there must be a record of what was decided, who authorised it, and on what basis. That record, in a system where agents don’t sign, becomes the only way to reconstruct responsibility after the fact. It doesn’t locate it — it makes it reconstructible.

What each framework brings when the team isn’t human

FunctionSurvives from ScrumSurvives from PMBOK
AssignmentTime-boxed commitmentExplicit decomposition of responsibilities
SynchronisationRetrospective as designed reflective pauseControl gates as escalation points
ClosureVerifiable increment with observable evidenceReconstructible formal traceability

The two frameworks don’t compete — they solve different layers. Scrum brings cadence and cycle. PMBOK brings governance and traceability. Neither one as-is, both with what survives of each.

What remains to be invented

Mechanically adapting Scrum or PMBOK to agents is an insufficient answer. Both frameworks were designed for human actors, and those actors had three properties an agent does not have: working hours, personal memory, and individually attributable responsibility.

An agent operates 24/7, without fatigue. Its memory is shared and vectorised, not personal. And when it fails, responsibility does not fall on it but on the diffuse chain of human decisions that authorised its deployment.

This doesn’t invalidate the frameworks. It limits them. They give us vocabulary, structure and precedent. They don’t give us the specifically machine-native discipline this moment demands. And that discipline is not yet written.

The reasonable answer is not to abandon Scrum or PMBOK. It is to recognise that they are the scaffolding available while what comes next is built. And that scaffolding needs three things neither brings as standard:

  • Adapted cadence to the real frequencies of each actor, not to human biology.
  • Continuous observability that replaces intermittent supervision.
  • Reconstructible responsibility shifting from individual signature to structural traceability.

Open questions

  • If Scrum works because there is a human team that learns in retrospectives, what remains when actors learn in the training cycle and not in the sprint one?
  • When PMBOK demands an identifiable responsible party for every decision, what do we ask of it when the decision emerges from the cooperation of several agents without a locatable author?
  • Is it still a “sprint” when the team does not sleep, or are we giving a human name to something else?

The questions don’t have closed answers. But one final idea is worth stating: coordinating machines is not coordinating humans faster. It is a different problem we have started to address with the vocabulary at hand — that of classical project management. It helps us name the obvious. The vocabulary for what is specifically new is still missing. And that discipline, when it is written, will be carried by those who build the systems.

References