A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.

hey Boris, with multi-agent work, e.g. Agent Teams, following other agents is not possible because they work so fast. (my tmux panes are just matrix)

do you think something like a /speed config can be introduced to adjust agent working speed and let people adjust?

This isn't related to Dynamic Workflows, but more on the telemetry / observability side of things.

Why'd you guys not want to allow the traceparent in hooks, but allowed the session.id? Any plans on changing that?

How granular is the control over the internal process?

In my experiments I've had some success modeling the work to be done as a DAG of typed artifacts with a combination of code + LLM doing decomposition, transforms, synthesis, and fitness checking to generate the output. It took me a lot of tries to arrive at that formula and it would be cool to have something more general. I also run part of it against local compute because it would be far beyond my budget to do it all on Opus, so something for that would be nice too.

Thanks to you and the anthropic team for developing such exciting tools! The blog post seems to position workflows for “breadth”: generating fixes / refactors against large code bases. What about for “depth”: developing specific new features and functionality end-to-end? I’ve struggled to make this work reliably using the current experimental agent teams. Does this replace or augment that functionality?

How much overlap do you feel like dynamic workflows have with RLMs?

Hi Boris. Love the velocity of features. Are you planning on adding a secrets manager? Enterprise workflows almost always require an encrypted parameter or calling a secret.

Will you document how to (AI-)author and share reusable workflows between team members, to ensure some consistency of quality?

Maybe blasphemy, but will workflows be able to use non-Anthropic LLMs (e.g., delegating some steps to local models, but design and review by Claude)?

I have my own version and the workflow keyword conflicts with it rather heavily. Will there be a way to disable that prompt section/keyword?

Hi Boris! Thanks for Claude Code.

Is there an example of how y'all use Dynamic Workflows internally that you could share with the rest of us here so that we can mimic something similar?

Will workflows be reusable? I have a big use case of sharable and repeatable workflows for projects. Especially if this comes to Cowork.

What language are the workflows in? Curious what you settled on. And are they running in the cloud or locally?

just wanted to say thank you, just did a 2 days "ai computer use" workshop - think a virtual desktop on hetzner with claude code in yolo mode, a github account, vercel and logged in into a google account and claude had all the credentials and then let a mix of marketing / product manager / sales / customer support let loose. 2k token budget ... and just let them see do magic again and again.

thx for all that amazing tec and save ai

Can you please fix the issue where like 99.99999% of the time Claude tries to launch a subagent on its own accord it gets "Prompt is too long" and tries several more times, then gives up and does it without the subagent. Big waste of time and tokens and not getting almost any subagent advantages. Not kidding that this happens about 100 times a day.

I tried creating a workflow in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z

and got

API Error: 400 messages.3.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

Tried again in

Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z also but may need a new chat

How do you guys plan feature support between the CLI and Claude Desktop?

This is really dissapointing release for such a promising technique. Long walks with fanned vectors can actually be token optimizing vs token burning when combined with self grading each agent along the walk and compared to manual long coding walks to solve first pass problems. But instead this frames it (assumptively) as a tokenmaxxing strategy. There are also many other strartegies that can prove effeciency and wider solution consideration with consensus, but none of this is explained why its an improvement or better than other technqiues.

Its like you guys aren't even aware of the primary problem you are all facing: your token burns aren't paying off anyore against standard coding -- and looking net negative. I have to ask, are you this unaware of your core problem set here?

There are no any examples, proofs, or scenarios that show why there is improvement either in complexity or reliability of the solution or effeciency to the path of the solution. I'm baffled.

[dead]