Claude Code's New Workflow Tool Changes

Anthropic didn't send a press release. There was no launch post, no tweet thread, no countdown timer. The workflow tool for Claude Code just... appeared. And if you blinked, you missed it.

Developer Ray Amjad caught it a few hours after it dropped and put out a video walking through the whole thing before Anthropic had said a word publicly. The feature is off by default—you have to set an environment variable to even see it. Which makes it either a soft beta, a quiet rollout, or Anthropic just doing that thing where they ship and let engineers find the edges before the blog post comes out. Probably all three.

So what actually is this thing?

The old way was slow and forgetful

To understand why this matters, you need to picture how Claude Code handled multi-agent workflows before this update. The setup looked roughly like this: you'd have a main Claude session acting as the orchestrator, and it would spin up sub-agents to handle individual tasks—implement a feature, run a review, verify a fix. Each sub-agent would complete its work, hand the result back to the main session, and then the orchestrator would pass relevant information along to the next sub-agent.

The problem is that every one of those handoffs went through the main context window. Which means if you had 10, 15, even 20 agents running in sequence, the orchestrator's context window was accumulating all of that intermediate state. Tokens piling up. And as Amjad describes it: "eventually it just starts forgetting and acts more sloppy and lazy, which is not what you want from an orchestrator."

There's also a visibility problem. Before workflows, running a long multi-agent job looked like watching a wall of text scroll by for 30 minutes with no real sense of where things stood or whether anything had gone wrong.

The core issue is that a language model was being asked to do a job that's fundamentally better suited to code: remembering state, routing data, managing conditionals, keeping things on rails.

What the workflow tool actually does

The fix is conceptually clean. Instead of the LLM orchestrating everything and touching every intermediate result, a JavaScript file does that job. The model never sees the data passing between sub-agents unless you explicitly put it in a prompt.

As Amjad puts it: "What if we just had a workflow file, some kind of code that could pass a result directly without ever entering the main conversation? Which means that you can have like 20, 30, 100 agents run one after another and the context of the main orchestrator never actually filling—because the orchestrator is now code instead."

Your workflow lives in .claude/workflows/yourworkflow.js. You define phases, schemas for structured outputs, arguments you can pass in at runtime, and you can mix plain JavaScript between agent calls. Loops, conditionals, early exits—all of it is just code. The agents handle the fuzzy, judgment-heavy work; the JavaScript handles the plumbing.

The /workflows command lets you browse running and completed workflows, drill into any stage, see which tools each agent called, check token counts, pause and resume, or skip and retry individual sub-agents. Compared to the wall-of-text experience, that's a meaningful operational upgrade.

Three examples worth sitting with

Amjad demos three workflows that illustrate how flexible this gets.

The first is a Sentry triage workflow. It pulls unresolved issues, filters down to ones affecting more than 20 users (configurable via argument), and runs a two-stage pipeline: one sub-agent investigates and fixes each issue, another verifies the fix actually worked. Only three sub-agents spun up in his demo because only three issues cleared the threshold—the JavaScript filter handled that before any model was involved. Final result: 25 issues loaded, 3 fixed, all verified. Token cost: 400,000, which sounds like a lot until you think about what 7 sub-agents coordinating across a real codebase with an MCP server actually involves.

The second is a "dead code sweep"—a while loop that hunts unused code across up to 8 rounds, removing dead code each time and exiting early if a round comes up clean. The whole thing is maybe 30 lines of JavaScript wrapping agent calls. Clean and repeatable.

The third is a personalized outreach pipeline. Load leads from a CSV, research each one in parallel (one agent per lead), then write a personalized message. The pipeline primitive is doing something interesting here: as soon as one research agent finishes, the corresponding writing agent starts immediately, without waiting for all eight research agents to complete. That's a meaningful throughput gain when you're running dozens of agents.

The cost-optimization angle is also interesting—Amjad's outreach workflow tries a cheaper model first for research, then falls back to a heavier one if the cheap model couldn't find what it needed. That's real, practical cost management baked into the workflow logic itself.

The deeper shift here

What Anthropic is doing with this—and it connects directly to their broader push around agent communication—is separating concerns more cleanly than before. Language models are good at judgment: reading code, understanding context, making decisions about quality. They're not great at being stateful routers over long sequences of operations. Code is great at that. The workflow tool just... puts each thing in the right place.

There's a budget parameter worth noting too. You can set a token budget for a workflow and have your logic check the remaining budget before spinning up another iteration. It's a guardrail against runaway costs in long-running loops, and the fact that it's in there suggests Anthropic is thinking carefully about what happens when these workflows run unsupervised.

The automatic retry behavior matters for the same reason. If a sub-agent fails—MCP server flakes out, network hiccup, whatever—Claude Code retries it up to three times before flagging it. For workflows that might run for 30+ minutes, that resilience isn't a nice-to-have.

What's still unclear

A few open questions that don't have clean answers yet.

Cost at scale. The Sentry demo used 400k tokens for 7 agents. That's manageable. What does a 50-agent workflow look like? The token tax for inter-agent communication is gone, but the agents themselves are still running on Opus by default, and Opus isn't cheap.

Debugging experience. The /workflows inspector looks useful, but Amjad's walkthrough was on relatively well-behaved workflows. What happens when a workflow fails mid-pipeline in a way that leaves state inconsistent? Is the resume behavior reliable in those cases?

Official support. This feature shipped without documentation or a blog post. Amjad explicitly notes: "I think once a feature is officially announced, then maybe Anthropic will add their own official workflow creator skill—in which case you should use that once it is released." For now, the ecosystem is user-generated. That's fine for early adopters, but it means the API surface might shift before it stabilizes.

Model selection strategy. The demos show Opus as the default, with Haiku/cheaper models for specific tasks. There's no obvious guidance yet on how to make those tradeoffs systematically across a complex workflow. That's mostly a "figure it out yourself" situation at this point.

Amjad's heuristic for when to use workflows is sensible: reach for one when the task is repeatable, when you need to fan out agents based on conditionals or data, or when the job is long enough that a mid-run failure would be painful. For one-offs, just run Claude directly.

The bigger thing this represents—code-as-orchestrator replacing model-as-orchestrator—feels less like a feature addition and more like an architectural opinion Anthropic is baking in. Whether that's the right call for every use case, or whether the community will eventually want escape hatches back toward more dynamic, model-driven orchestration, is a question that a few weeks of real-world use will answer better than any demo can.

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent.