{"id":153,"date":"2026-07-12T14:40:23","date_gmt":"2026-07-12T04:40:23","guid":{"rendered":"https:\/\/www.gokhanmeric.com\/blog\/ai-agents-multitasking-agile-single-piece-flow-hypothesis\/"},"modified":"2026-07-12T14:41:19","modified_gmt":"2026-07-12T04:41:19","slug":"ai-agents-multitasking-agile-single-piece-flow-hypothesis","status":"publish","type":"post","link":"https:\/\/www.gokhanmeric.com\/blog\/ai-agents-multitasking-agile-single-piece-flow-hypothesis\/","title":{"rendered":"Do AI Agents Break Agile’s Case Against Multitasking? A Hypothesis"},"content":{"rendered":"\n

Two ideas have been treated as settled truth in knowledge work for the better part of two decades. First, that multitasking is a productivity killer<\/strong> \u2014 that splitting attention across parallel tasks costs more than it gains. Second, that Agile is built on single-piece flow<\/strong> \u2014 limiting work in progress, finishing one thing before starting the next, and treating context-switching as waste to be eliminated. These two ideas reinforce each other, and they’ve shaped how nearly every modern software and product team organises itself.<\/p>\n\n\n\n

Here’s the hypothesis I want to put forward: the arrival of capable AI agents partially breaks both assumptions.<\/strong> Not because the underlying research was wrong \u2014 it wasn’t \u2014 but because that research measured a specific actor with specific limits: the human brain. When the thing doing the parallel work is no longer a human, the cost structure that justified single-piece flow changes fundamentally. This article lays out the argument, and \u2014 because a good hypothesis has to survive its own counter-evidence \u2014 the significant limits on it.<\/p>\n\n\n\n

Why Agile Rejected Multitasking in the First Place<\/h2>\n\n\n\n

The case against multitasking in Agile isn’t dogma \u2014 it rests on genuinely robust evidence about how human cognition works. The core mechanism is context-switching cost. Every time a person stops one task, unloads its mental context, loads another, and tries to resume, they pay a tax in time and accuracy.<\/p>\n\n\n\n

The numbers are stark. Research reported by Harvard Business Review found the average digital worker toggles between applications and websites roughly 1,200 times per day \u2014 about one switch every 24 seconds across an eight-hour day. The American Psychological Association’s research indicates chronic multitasking and frequent context-switching can consume up to 40% of a person’s productive time. Microsoft researchers found the typical knowledge worker spends less than three minutes on a screen before switching. The result isn’t true parallelism \u2014 it’s what one analysis aptly called “serial theft of attention.”<\/p>\n\n\n\n

This is precisely why Agile \u2014 and Kanban in particular \u2014 enshrined Work In Progress (WIP) limits<\/strong>. As the Kanban literature puts it plainly, WIP limits encourage focus and reduce multitasking; context-switching between work items carries cognitive costs that compound as the number of active items increases. A classic worked example from the WIP-limit literature: three sequential projects take an average of 60 days each to complete, versus 89 days each if multitasked \u2014 a 30%+ improvement in time-to-market from not<\/em> multitasking, before you even count the real-world context-switching penalty. The message was unambiguous: stop starting, start finishing.<\/p>\n\n\n\n

These principles are baked into how I’ve always described good governance in my own work, including Part 4 of my UI\/UX Playbook<\/a>. The evidence was, and remains, sound \u2014 for humans<\/em>.<\/p>\n\n\n\n

The Hidden Assumption: The Worker Is Human<\/h2>\n\n\n\n

Here’s the crucial observation. Every piece of evidence above measures the same actor: a human being with a single, serial attention system. The cost of multitasking is not a law of physics. It’s a property of human cognition \u2014 specifically, our inability to hold multiple rich task-contexts active at once and switch between them without penalty.<\/p>\n\n\n\n

Agile’s single-piece flow, then, was never really a statement about the nature of work<\/em>. It was a statement about the nature of the worker<\/em>. WIP limits are, at root, a workaround for a hardware limitation in the human brain. And that reframing is what opens the door to the hypothesis: if you change the worker, you change the constraint.<\/strong><\/p>\n\n\n\n

What AI Agents Change<\/h2>\n\n\n\n

AI agents \u2014 autonomous systems that pursue a goal across multiple steps rather than answering a single prompt \u2014 don’t share the human attention architecture. Several agents can run genuinely in parallel, each holding its own full task-context, none paying a switching penalty to exist alongside the others. Where a human “doing three things at once” is really one attention system thrashing between three contexts, three agents doing three things is genuine simultaneity.<\/p>\n\n\n\n

This is already visible in how modern agentic work is being structured. The professional’s role increasingly shifts toward direction, quality review, and refinement<\/strong> rather than production from scratch \u2014 a human orchestrating multiple parallel workstreams that agents actually execute. The cognitive overhead of maintaining situational awareness across parallel workstreams, historically a persistent drain on human focus, is substantially reduced when an agentic layer tracks progress, surfaces blockers, and reports back.<\/p>\n\n\n\n

If that holds, it genuinely does overturn the two starting assumptions \u2014 with an important restatement. Multitasking isn’t suddenly good for humans; rather, a human can now orchestrate<\/em> parallel work without personally performing<\/em> it in parallel. And Agile’s single-piece flow stops being the universally optimal pattern, because the actor it was designed around is no longer the only actor on the team. I’ve explored the mechanics of how this orchestration works in practice in the article on agentic AI workflows<\/a>.<\/p>\n\n\n\n

The Counter-Evidence: Where the Hypothesis Breaks Down<\/h2>\n\n\n\n

A hypothesis worth publishing has to state the conditions under which it’s wrong. And there’s a genuinely important finding that constrains this one sharply.<\/p>\n\n\n\n

Research from Google in 2026 found that multi-agent coordination improves performance by 81% on parallelizable tasks \u2014 and degrades it by up to 70% on sequential ones.<\/strong> This is the single most important number in this whole discussion. Parallel execution is not universally superior; it is superior only when the work is genuinely parallelizable<\/em>. When tasks have dependencies \u2014 when task B needs the output of task A \u2014 running them in parallel doesn’t just fail to help, it actively harms the outcome.<\/p>\n\n\n\n

Notice what this means: the old Agile wisdom doesn’t vanish \u2014 it relocates<\/strong>. The discipline of sequencing dependent work, of not starting what can’t yet be finished, remains exactly as valid for agents as it was for humans on truly sequential tasks. What’s changed is that a whole category of work previously forced into sequence by human limitation<\/em> can now be genuinely parallelised. The skill shifts from “limit WIP” to “correctly classify which work is parallelizable and which is sequential” \u2014 and the penalty for misclassifying is severe in both directions.<\/p>\n\n\n\n

There are further constraints. Parallel agents introduce coordination overhead: a multi-agent pipeline can consume roughly three times the tokens of a single-agent approach, and each added agent introduces measurable coordination latency. And they introduce a subtler failure mode \u2014 context fragmentation, where parallel agents each operate on a slightly different slice of organisational knowledge and quietly diverge. Quality collapses not from the parallelism itself but from agents no longer sharing the same understanding.<\/p>\n\n\n\n

A Revised Synthesis<\/h2>\n\n\n\n

So where does this leave the two original assumptions? Neither is simply “true” or “false” any more. A more precise formulation:<\/p>\n\n\n\n