What caught my eye in Claude Code this time was not the fact that it shipped another command. It was that it finally started treating orchestration as something worth caring about.
/workflows looks like a feature toggle on the surface, but it feels more like a boundary line. It moves agents from “helpers that answer questions” toward “execution units that run by rule.” The change is quiet. It is not flashy. But I think it matters.
For a long time, the way people talked about agents was pretty simple: can it think, can it write, can it save me time? Claude Code is now asking a different set of questions: how do several agents work together, who goes first, who produces structured output, who validates, and who keeps the budget under control?
At that point, you are not really chatting anymore. You are running a workflow.
Why I think it matters
I have always been a little skeptical of the idea that one perfect prompt will suddenly make AI feel “unlocked.” Most of the time, the real difference is not a magic phrase. It is whether the system can break work into steps that are stable, reusable, and accountable.
That is exactly where this Claude Code change lands.
It is not teaching you to ask better questions. It is giving you something much closer to an engineering model:
CLAUDE.mdhandles rulesSkillshandle reusable capabilities/workflowshandles multi-step orchestrationRoutineshandle cloud-triggered execution
Put together, those layers start to look like a way of encoding a team’s SOP into something machines can actually run.
I like that direction. It feels more grounded than “the model got smarter,” and a lot more restrained than “AI will replace everything.”
The four layers are not the same thing
CLAUDE.md answers a simple question: what should the agent know?
It is the project’s rulebook. It tells the agent the repository’s constraints, habits, and boundaries.
Skills answer a different question: how should the agent handle a repeatable kind of task?
They wrap multi-step actions into reusable blocks. They are light, practical, and easy to load when needed.
/workflows is where things get interesting. It answers: how do several agents work together?
Once you define order, branching, parallelism, and verification, agents stop being isolated capabilities. They become workflow nodes that you can organize into a system.
Routines answer the last question: who keeps it running after you walk away?
That starts to look less like a one-off AI chat and more like automation.
If you only look at the surface, all of this can look like “new AI features.” Structurally, it is different. The first two layers package capability. The last two layers orchestrate execution. The first pair makes AI easier to use. The second pair makes it look like something that could survive outside a demo.
What I care about most is determinism, not parallelism
When people hear “multi-agent,” the first reaction is usually: great, now I can run a bunch of things at the same time.
That helps, but it is not the main point.
What matters is that Claude Code gives workflows a real programming model:
- JavaScript defines the control flow
pipeline(),parallel(), andagent()define how execution is organized- schema enforces structured communication
- verification steps catch bad outputs before they spread
- budgets keep token burn from going off the rails
Put those together and you get something that feels like an actual delivery system.
I especially like pipeline(). A lot of tasks are not “run everything in parallel and inspect the pile later.” They are closer to: once step one has produced enough signal, step two can start. That is closer to real work, and usually easier to wait on.
Schema matters too. It sounds technical, but the idea is plain enough: do not let agents pass vague natural language back and forth if you can force structure instead. If the format is wrong, retry. In other words, stop hoping the next agent will understand your prose.
The real shift is where humans stand
Once workflows can actually run, the human role changes with them.
Before, people mainly executed. They wrote, edited, checked, and watched everything themselves.
After that, people start acting more like designers.
You define the rules, split the tasks, design verification, set boundaries, and read failure logs. Human value moves away from repetitive labor and toward judgment.
I think that is a good thing. The part humans should keep is not the copying and pasting. It is the ability to decide.
What a workflow can look like
Concepts are useful, but code makes it clearer.
export default workflow("review-issue", async ({ agent, pipeline, parallel }) => {
const plan = await agent("planner", {
prompt: "Read the request and output a JSON plan with only steps / risks / budget",
schema: {
type: "object",
properties: {
steps: { type: "array", items: { type: "string" } },
risks: { type: "array", items: { type: "string" } },
budget: { type: "number" }
},
required: ["steps", "risks", "budget"]
}
})
const result = await pipeline(
agent("researcher", {
prompt: `Gather context based on this plan: ${JSON.stringify(plan)}`
}),
parallel(
agent("writer", {
prompt: "Draft an execution plan from the prior results"
}),
agent("reviewer", {
prompt: "Check the draft for missing risks and boundary conditions"
})
),
agent("verifier", {
prompt: "Check whether the previous output matches the schema. If not, return the error reason."
})
)
return result
})
Do not get hung up on whether this is the only valid way to write it. The point is the shape: plan first, split the work, verify, then close the loop. The valuable part is not a function name. It is finally being able to treat agents as nodes in a workflow.
If this connects to Skills, Routines, sandboxes, connectors, and verification chains, a lot of things that used to live only in SOP documents suddenly have a path toward becoming executable systems.
How I would frame it
If I had to cut it down to one sentence, I would say this: /workflows does not make Claude Code better at chatting. It gives it the ability to orchestrate work.
That is a bigger deal than it sounds.
It pushes agents from “smart assistants” toward “programmable workflow nodes.” Once that sits next to Skills, Routines, sandboxes, connectors, and verification chains, a lot of actions that used to live only in SOP documents suddenly have a path toward becoming executable systems.
I do not think it will change everyone overnight. But I do think it will quietly change some of the most important questions:
Who designs the process? Who verifies the result? Who owns the boundary? How far should machines be allowed to automate?
Those changes usually do not show up in the loudest part of a launch. They happen deep inside the tool.
This time, Claude Code feels like it is cutting there.