Anthropic shipped Claude Opus 4.8 yesterday. The feature that grabbed the headlines is called Dynamic Workflows: Claude Code plans the job on its own, then spins up hundreds of parallel subagents (a thousand per run, sixteen at a time) that execute, refute each other, and verify the result before they hand it back to you.

The easy reading landed in my inbox this morning, in a newsletter headlined “finish your projects in days instead of months.” It’s true. And it misses the point.

What changed isn’t that you can execute faster. It’s where the bottleneck went once execution stopped being the limit. It moved to two things a thousand agents won’t do for you: decide which problem is worth solving, and own the result once it’s done.

That’s judgment. And judgment doesn’t parallelize.

That’s the thesis. The IQ Source piece that lives in the first half, deciding what to build, is AI Maestro. The one that lives in the second, owning what stays in production, is our technology partner service. The rest of this post is about why no swarm of agents absorbs either one.

What Anthropic actually shipped, minus the hype

Strip the marketing and here’s what’s left. A dynamic workflow is a script Claude Code writes from your prompt. A runtime runs it in the background while your session stays responsive. Subagents attack the problem from independent angles, other agents try to refute what they found, and the run iterates until the answers converge. Anthropic puts it in one line: Claude Code “verifies its outputs before reporting back.”

The number that tells you the scale: code migrations across hundreds of thousands of lines, from kickoff to merge, with your existing test suite as the bar. This isn’t an assistant that suggests. It’s a crew that runs until the green tests give it permission to stop.

And it didn’t arrive alone. The same model is, per Anthropic, roughly four times less likely than its predecessor to let flaws in its own code slip by unremarked. Fast mode dropped to a third of the price. So: cheaper to run, and a runner that checks itself better. Not a demo trick. It’s a research preview on the Enterprise, Team, and Max plans, and we run Claude Code in our own operation every day, so I’m not reading this off an announcement. I’m watching it on the monitor.

All of that is real and useful. And none of it touches the problem this post is about.

The bottleneck moved again

When execution was the limit, the scarce thing was capacity. Hands, hours, people who knew how. That’s why a technical project took months: not because deciding it was hard, but because doing it was expensive.

Dynamic Workflows erases that constraint. Capacity now rents by the thousand. And when the scarce thing stops being scarce, the constraint doesn’t vanish, it moves upstream. The new expensive question is: which problem deserves a thousand agents pointed at it?

The most honest thing in that newsletter was a single line, almost thrown away: the bottleneck moved from team capacity to deciding which problem to solve first. That line is a confession. It admits the value no longer lives in doing. It lives in choosing.

Most companies have no process for choosing. They have a backlog and they aim the AI at whatever’s loudest that day. That worked when execution was expensive, because the cost itself forced a sort. Remove the cost and you remove the forced sort. Now you can launch a thousand agents at the wrong module, carry it clean to merge with the test suite green, and have burned a thousand agents’ worth of compute on something nobody asked for.

Passing tests doesn’t mean it was worth doing. That gap, between “done well” and “worth doing,” is exactly what discovery is for. I made the same point from the security side, when Anthropic found ten thousand vulnerabilities in a month and the question became which ones to patch: the bottleneck had moved from finding to deciding. Dynamic Workflows moves it again, now across all technical work, not just security.

A thousand agents own nothing. A person does.

There’s a second job that doesn’t parallelize either, and it’s more uncomfortable than the first.

In the comments under that same newsletter, a strategy advisor wrote the right question: when agents review valuations and documents at this scale, who owns the outcome of those reviews? Not the agent. The named human who authorized the deployment and answers for what it produced.

That’s the part the word “verifies” hides. The verification layer in Dynamic Workflows, agents refuting each other until they converge, catches internal contradiction. It catches one subagent disagreeing with another. What it doesn’t catch is the wrong premise. Walk in with the question framed badly and a thousand agents won’t save you; they’ll agree faster on the wrong answer and hand it to you with the confidence of something that survived a thousand reviews.

Another commenter, an engineer, put it more bluntly: what if the implementer’s assumptions are wrong, or the data changed because the business is dynamic? At scale, that error doesn’t dilute. It compounds. Garbage scales too.

Which changes what “verify” means. It isn’t that the system won’t fail. It’s that the odds of a failure being contained go up, while the odds the question was the right one don’t move an inch. Those are two different things, and the swarm only solves one of them.

So you still need a human who can read the result, know whether it’s right, and put their name on it. That role doesn’t split across sixteen subagents. It belongs to one person, and it’s the role most mid-sized companies haven’t staffed by the time the agent is already in production.

Is this new? Yes and no.

It’s worth taking the skeptic seriously, because he’s half right. In those same comments, a Chief Innovation Officer wrote: this was possible two years ago with any orchestrator, a Zapier, an n8n, a Make. It’s just packaging.

He’s right that orchestration isn’t new. I’ve been at this since 1990, and I’ve watched orchestration get repackaged more than once, with a different name every five years. Coordinating pieces that work in parallel is an old idea.

Where he’s wrong is on what got repackaged. Three things happened at once, and none of them existed in the Zapier of two years ago: execution got cheap, the system checks itself, and Claude writes its own orchestration script. The n8n version needed you to design the graph, node by node. This one designs its own from a sentence.

But, and here’s the honest half, none of those three changes touches the decide-and-own problem. Zapier never decided which workflow mattered either. What got automated is the part that was already cheap-ish: the wiring. The part that was always scarce, the judgment, is untouched. So “just packaging” misses what changed, and “this changes everything” misses what didn’t.

A month ago I argued the opposite end of this: that the runtime had become a commodity and the moat was the workflow you built on top. Well, Dynamic Workflows just started writing that workflow itself. So the moat climbs one more rung: it’s no longer in designing the flow, it’s in deciding which flow deserves to exist and owning what it produces. Every time the tool climbs a step, judgment climbs with it. Not the other way around.

What IQ Source does about it

The two things that don’t parallelize happen to be the two we work on.

AI Maestro is the discovery that decides which problem earns the agents. Two months of consulting where we map the real processes in your operation, not the ones on the org chart, score each with an AI Opportunity Score, and end with a Go/No-Go gate, process by process. It’s the piece that separates the module that deserves a thousand agents from the one that will just burn tokens and leave you with green tests on something nobody needed.

Our technology partner service is the other role: the owner of the workflow once it’s live. The person who reads what the swarm produced, catches that the premise was wrong even though the tests passed, and puts a name on the result in front of the board. It’s the role a good CTO would cover, and the one most mid-sized B2B companies don’t have in-house.

Notice neither one is “implementing.” Implementation is exactly what Anthropic just made cheaper. What it didn’t make cheaper, what it may never make cheaper, is the judgment going in and the responsibility coming out.

Before you close out the week, ask your team one question. If you could launch a thousand agents at any problem in your operation tomorrow, which one would you pick, and who would put their name on the result? If they don’t have a quick answer to both, your company’s limit was never the capacity to execute. It was judgment. And that just got more exposed than ever.

Decide which problem earns the agents