Agent View + Dynamic Workflows: Claude Code No Longer Forces You to Manage Parallel Agents

If you’ve ever run more than one Claude Code session at the same time, you know the situation: one terminal tab for the migration, another for test coverage, a third for that refactor you started and forgot about. Add a tmux grid on top and suddenly half your brain is just tracking which agent is doing what, which one is waiting for you to respond, and which one finished quietly twenty minutes ago.

Claude Code just shipped two features that tackle this problem from opposite angles. Agent view gives you a single screen to see all your sessions at a glance. Dynamic workflows lets Claude spin up and coordinate dozens — or hundreds — of sub-agents on its own, so the work you used to split across tabs gets handled by a single orchestration script. One solves visibility. The other solves coordination. Together they change what “running agents in parallel” actually feels like.

Agent view: one screen for everything you’ve got running

Run claude agents and you get a dashboard of every Claude Code session you have active. Instead of cycling between tabs trying to remember where each one left off, you see the full picture in one place: what’s running, what’s blocked waiting for your input, and what’s already done.

From that screen you can spin up new agents, send them to the background, and jump into any session to reply inline or open the full conversation. Status indicators do the mental tracking for you — a session that’s processing looks different from one that needs your decision, which looks different from one that already produced a pull request and is ready for review.

The shift is subtle but real. Before, parallel agents meant you were the orchestration layer — the one holding the map of who was doing what. Agent view takes that burden off you. You stop being the dashboard.

Dynamic workflows: when a single conversation isn’t enough

Agent view handles the sessions you start. Dynamic workflows handles the ones you’d never want to start by hand.

A workflow is an orchestration script that Claude writes for your task and then runs across many sub-agents in the background. It’s for work that’s simply too big for a single conversation to coordinate: a codebase-wide audit, a large migration, a research question that needs cross-checking from multiple angles. Instead of you breaking down the work and tending to each piece, Claude breaks it down, spins up the sub-agents, and runs them — scaling from dozens to hundreds depending on the task.

You manage runs with /workflows. That’s your control surface: spin one up, check the progress, see what the sub-agents are producing.

The right mental model: agent view is for parallelism you manage, a handful of sessions you’re actively directing. Dynamic workflows is for parallelism Claude manages, where you delegate a big goal and let the orchestration happen underneath. Most real workflows will mix both — a few hands-on sessions in agent view while a big workflow grinds through a migration in the background.

Why this matters for how you work

Honest truth: neither feature makes your agents smarter. What they change is the overhead of running many at once — and that overhead was the real ceiling on parallel work, not the models.

If you’ve been limiting yourself to one or two sessions because three felt like too much to track, agent view raises that ceiling. If you’ve been manually breaking a large migration into pieces and feeding them in one at a time, dynamic workflows is the tool you were missing.

A couple practical notes. Agent view landed first (it’s been around since mid-May); dynamic workflows showed up alongside the switch to Opus 4.8 by default and is the newer of the two. Dynamic workflows is built for genuinely large tasks — using it for small work is overkill, and you’ll get more out of a normal session. And as always with background and autonomous runs: the bigger and less supervised the work, the more it pays to define clear termination conditions from the start, so you’re reviewing results and not untangling a long run that went off track.

For teams that ship fast, the win is operational. Less time spent context-switching between terminal tabs, and more of the heavy lifting — audits, migrations, test expansion — handled in parallel without a human playing traffic controller.

Have you tried running multiple agents in parallel with agent view, or do you stick with a single session because of the mental load? What kind of task would you spin up a dynamic workflow for?


Docs: