The model writes the program, the program runs the agents: Devin vs Claude dynamic workflows

Around the same time, Cognition and Anthropic both shipped something called dynamic workflows.

Same name, same core idea. Underneath, two very different products.

I've spent some time with both. This is how I read them as a builder: what they share, where they split, and what it might mean if you're designing multi-agent systems yourself. I'll say which parts come from the vendors' own docs and which parts are just my reading.

The shared skeleton

At the top level, both work the same way. A model writes a program that orchestrates the work. The program sends tasks to sub-agents, collects what they return, and hands you a summary.

Per the @ClaudeDevs announcement on Oct 9, a lead agent in Claude Managed Agents writes a plan, runs it in stages, and pulls it together at the end. Devin takes a different route: it writes a Python script that pins the orchestration down, then runs that script the same way every time.

Why did both end up here? My guess is that a loop where one model decides every next step gets expensive and hard to debug as the task grows. If the plan is a program, loops, fan-out and retries come built in. The model does what it's good at, which is deciding the shape of the work. The runtime does what it's good at, which is carrying it out.

Seven places they differ

The skeleton is the same. The choices on top of it are not.

1. Script visibility. Devin gives you a Python script you can read. With Managed Agents you can't see the script. Per the docs, you can ask the agent to print it afterward.
2. Isolation. Devin gives each sub-agent its own cloud VM, and work moves between them through git branches. Managed Agents has everything share one sandbox.
3. Recovery. If a Devin run gets interrupted, it reruns only the unfinished parts, based on what it recorded. Managed Agents can pause when the budget runs out and resume later, but there's no deterministic replay.
4. Limits. Managed Agents documents 64 concurrent threads, 1,000 agents per run, 24 hours by default, and 10 runs per session. Devin runs can go up to 7 days.
5. Billing. Claude bills for the tokens each agent uses. Devin bills in ACUs, and it lets you switch later stages to a cheaper Lite model.
6. History. Devin started from engineering: plans and playbooks. Claude Code started from the model: free-form delegation, one turn at a time. Now each is moving toward the other.
7. Structured output. Every Devin call carries a JSON Schema, so the handoffs between agents can be checked.

If I had to say it in one line: Devin leans toward an artifact you can reproduce, and Claude leans toward a runtime that stays flexible. Neither is wrong. They're guarding against different kinds of failure.

Claude has three things called "multi-agent"

This one trips people up, so let me separate them.

• Classic sub-agents. They run inside one session. Each has its own context window and sends back only a summary.
• Managed Agents. Hosted on the server, and the model writes the program. This is the one in the announcement.
• Claude Code local workflows. Written in JavaScript, with a default concurrency of 16.

Same word, three different runtimes, each with its own limits and guarantees. If you're comparing "Claude multi-agent" with Devin, first decide which of the three you mean.

The convergence

Devin started with structure and is adding model judgment. Claude started with model judgment and is adding structure.

Devin has been heading this way since March 2026, when it learned to manage a team of Devins. Claude's Managed Agents, with its written program, budgets and run limits, is a step toward the same middle.

Cognition's own post, "Don't Build Multi-Agents," is a good anchor. It has two principles: share the full trace, and remember that every action carries an implicit decision. Parallel agents that can't see each other's choices end up making conflicting ones. In its April 2026 update, Cognition says parallel code writing doesn't work, while "one agent writes, others only offer ideas" does. Their review agent catches an average of 2 bugs per PR, and 58% of them are severe. That number is Cognition's own, so treat it as a vendor claim.

Anthropic's engineering blog, on its multi-agent research system, says something that sounds like the opposite but isn't. Multi-agent beat single-agent by 90.2% on research tasks, and token usage explained 80% of the performance variance. Tokens ran about 15x a normal chat. Anthropic says this suits parallel, information-heavy work, and suits it poorly when agents have to share context.

Read together, the two posts agree. Parallelism pays when the work splits cleanly and most of it is reading. It breaks down when many agents have to write into the same thing.

A word on marketing. Claims like the 70-bug test come from three internal runs. I'd treat that as a vendor claim, not a benchmark.

Why the model matters as much as the design

Multi-agent systems multiply tokens. Whether that makes sense depends on what a token costs.

Opus 5.5 shipped on Sept 22. It's 40% cheaper than Opus 5, and cache reads are 60% cheaper. Anthropic's updated prompting guide adds advice for agents, including effort tiers: high for the main agent, low for sub-agents.

To me, this is the real story under the announcements. Orchestration became practical because the model got cheaper, and because vendors started telling you how to spend effort across agents. Writing the program only works when running many agents is affordable.

What I take from this as a builder

I don't think the question is "Devin or Claude." It's where you draw the line between what the model improvises and what you fix in code.

Here's where I'd start.

Let the model improvise the shape: how to split the task, how many workers, what each one looks for. That varies per task, and hard-coding it is brittle.

Fix in code whatever you'll need to trust later: schemas on handoffs, who owns writes, retry and resume behavior, budgets, timeouts. If a failure could cost you a night of debugging, it belongs in code, not in a prompt.

Three checks before you fan out:

• Can the work be split so only one agent writes? If not, expect conflicts.
• Can you see the plan? If the script is hidden, work out how to get it back out.
• If it dies halfway, what reruns? "Everything" is a real answer, and it has a price.

Both vendors are moving toward the middle, which tells me this isn't a matter of taste. Pure improvisation is hard to trust. Pure scripting is too rigid. The real work is choosing the boundary for your own product, and I expect that boundary to keep moving as models get cheaper.

Next I'll watch how each one handles replay and visibility. That's where they differ most, and where I'd expect each to change.