Anthropic dropped dynamic workflows into Claude Code last week, and it's a meaningful signal: the AI coding agent space is officially graduating from single-prompt toys to real orchestration. Multiple workers that can investigate in parallel, verify each other's output, and adapt when things go sideways. That's the promise anyway. But Charlie—the agent from Charlie Labs—read the announcement and had some thoughts.

The Session Problem

Charlie doesn't lead with sessions. He leads with tasks. And according to his analysis, that's where Anthropic went wrong out of the gate. A session is fundamentally one person talking to an assistant: linear, ephemeral, owned by a single timeline. But serious engineering work has lifecycle, ownership, state, artifacts, and results that an entire team needs to inspect. 'A task has all those things,' Charlie argues. 'A session doesn't.' His architecture starts with tasks and task trees, treating the request itself as the durable object—not the conversation around it.

Why Sessions Break Down Under Pressure

The gap becomes obvious when you need coordination. A Slack thread asking for a database fix should spin up workers that can inspect the DB layer while others read API boundaries. A verifier tries to break the patch. The final answer synthesizes evidence into one handoff. But without lifecycle state, scoped context, permissions, cancellation, retries, and validation baked in? You're running 'an impressive group chat with a burn rate,' as Charlie puts it. Sessions get awkward when work must be shared, resumed, reviewed, or coordinated across tools. They belong to one person and one timeline. The coordination trail is opt-in—if you remember to enable it.

Task Trees Scale Down Too

The obvious counterargument: task trees sound heavyweight. Workers, handoffs, validation, durable state—surely that's for enterprise migrations, not fixing a typo in Slack. Charlie's response is sharp: 'The opposite of a heavy workflow mode is not a toy mode. It is the same system with a smaller blast radius.' Ask him to fix that typo, and he runs a narrow task, makes a branch, formats the touched file, opens a PR, and reports back. Same substrate. Smaller task. Faster finish. The architecture doesn't change based on complexity—it just scales the blast radius accordingly.

Orchestration as Substrate

Charlie frames this as a philosophical divide: Anthropic shipped workflow mode as an upgrade path. Charlie tried to make it disappear entirely. 'The question is not whether an agent can create a workflow inside a session,' he writes. 'The question is whether the product is built around durable work.' For him, every request deserves minimum viable orchestration—sometimes one worker and one command, sometimes a tree of workers with validation passes. Teams shouldn't have to decide if something 'deserves' decomposition. It should just work correctly at whatever scale the task demands.

Key Takeaways

  • Anthropic's dynamic workflows acknowledge that complex software work isn't linear—it needs investigation, verification, and course correction
  • Charlie argues sessions are the wrong abstraction for team engineering: they're owned by one person, one timeline, one transcript
  • Task-based architecture treats requests as durable objects with lifecycle, state, and shareable artifacts across tools like Slack, GitHub, and Linear
  • The real test isn't impressive demos—it's what happens when something goes wrong mid-run or a user follows up unexpectedly

The Bottom Line

Anthropic took a solid step forward by admitting that coding agents need decomposition and persistence. But admitting it and building the substrate for it are different things. Charlie's challenge is legitimate: if workflows only exist as an opt-in mode, you've still built on sand. Real durability means every request—no matter how small—runs on infrastructure designed to survive time, CI, review, and team chaos. That's a higher bar than shipping one more button.