Run the Workflow on Yourself First - Reflection on Claude Dynamic Workflows

I watched a video from Mark Kashef this week, and I wanted to pass it on, because I think a lot of people in my network would get something out of it too. It is about Claude Code's new dynamic workflows, and about a use for them that I had not considered.

What dynamic workflows are

A quick grounding first, in case you have not seen the feature.

Dynamic workflows are a research preview in Claude Code. You ask Claude for a workflow in a prompt, and instead of working through your task in one long conversation, it writes its own orchestration script and spins up a fleet of subagents that run in parallel and, importantly, check each other's work. Cat Wu, who works on Claude Code, describes it as Claude creating an orchestration plan that it then follows strictly, so the stages happen in the right order even across hundreds of agents. They run outside your main context, so they do not bloat the session you are in, and a single run can reach up to a thousand agents.

The part that matters to me is in how Anthropic describes it: the agents refute each other's findings, and the run keeps iterating until the answers converge. That is the difference between "one agent told me" and "a group of agents argued, and only the claims that survived made it through."

The obvious move is to point all that horsepower at a big external task - a migration, an audit, a research sweep. That is where most of the attention has gone.

Mark's idea: point them inward

What caught my attention is that Mark turned the fleet around and aimed it at his own history.

Your Claude Code conversations are stored locally as .jsonl files. He pointed a workflow at all of his, roughly 1'500 of them, and had the agents work out how he actually uses the tool: his patterns, how he prompts, where he repeats himself. What he got back was not a generic "how to use the new model" tutorial. It was an honest read on how he works, and where he was leaving value on the table. Then he saved the whole thing as a skill he can run again for the next model.

That last part is what stuck with me. He did not just get an answer. He turned the analysis into something he can repeat.

The thought it left me with

The same idea works on more than chat logs. Any time you build up a record of how you worked, you can point the analysis at that.

In the Shipwright projects I run, that record happens to be unusually rich. Every iteration leaves a small document of what it did, and an event log keeps the rest - what ran, when, in what order. That is exactly the kind of material Mark mined in his chats, except it is about the actual work, not only the conversation around it.

So the experiment I want to run is simple. Point the same kind of analysis at those documents. Where does my time actually go? Which features and implementations were worth the effort, and which were not? Where did a piece of work take three attempts when it should have taken one? I do not want a dashboard. I want an honest read on how I spend the time, and a short list of what I could do better next time. The same thing Mark did with his chats, applied to the record of the work itself.

Why I want to start on the inside

There is a reason I want to begin here, with my own work, rather than with something flashier.

The inward version is the one I can still judge. I know this work. I can look at what the agents tell me about it and say, yes that is right, or no, you have missed the point. That matters more than it sounds. The natural next step from here is more automation - letting the agents not just analyse the work but act on it. I want to get there. But I want to get there in that order, starting from the things I can still evaluate, so that I do not end up building something I no longer understand well enough to keep under control.

That gut feeling - wanting to start where I can still understand what I am doing - matches something Mitchell Hashimoto described recently. He left an agent in a loop for four hours and about 350 dollars to optimise a renderer, and it produced an impressive-looking result that was still roughly seventy-five times slower than what an expert would write by hand. What we have to make sure of in this phase is exactly that: if we do not understand the system, we will accept mediocrity as a breakthrough. The fleet does not replace your judgment. It scales your attention.

There is a practical limit too. The parallelism that makes this powerful also burns tokens fast - Mark's deep-research version spun up close to 200 agents to check 170 claims - so I treat the whole thing as a once-a-fortnight tool, not a daily reflex.

That, in the end, is why the inward use case appeals to me more than the flashy external one. The most valuable thing I can ask a fleet of agents to do right now is not to build something new at speed. It is to help me see how I work, and to make the next piece of work a little better than the last.

 

---

Sources:

• Mark Kashef - "3 AMAZING Claude Code Dynamic Workflows (Opus 4.8)" - YouTube - 2026 - https://www.youtube.com/watch?v=9_ExDZFlaNc
• Claude Code - dynamic workflows (research preview) announcement - ClaudeDevs / Anthropic - X - 2026 - https://x.com/ClaudeDevs/status/2060044853279617150
• Cat Wu - Dynamic workflows announcement - X - 2026 - https://x.com/_catwu/status/2060054180379689074
• "Claude Code Dynamic Workflows Coordinating Up To 1,000 Subagents" - InfoQ - 2026 - https://www.infoq.com/news/2026/06/dynamic-workflows-claude-code/
• Mitchell Hashimoto - On agents, judgment and "agent psychosis" - X - 2026 - https://x.com/mitchellh/status/2060088112257372610