Best Claude Code Agentic Workflows: 2026 Playbook
Six repeatable Claude Code workflows for planning, subagent research, parallel worktrees, verification, and slash-command pipelines, with when to use each.
By Capital & Compute
Most people run Claude Code the way they ran the autocomplete tools before it: type a request, watch it edit, approve the diff, repeat. That works, and it is also the slowest way to use the tool. The developers getting ten-times leverage out of the same subscription are not writing better prompts. They are running different workflows: they plan before they let it touch disk, they hand the file-reading to a throwaway subagent, they run four sessions at once, and they wire a check the agent has to pass before it is allowed to stop.
None of that is a secret feature. It is the documented feature set arranged into repeatable procedures. This post is the playbook: six agentic workflows, each with the trigger that should make you reach for it, the exact commands to run it, and the token cost it adds, because on a metered plan every one of these workflows is also a line on the bill. It assumes you already know what the primitives are. If you do not, the companion Claude Code harness guide defines CLAUDE.md, skills, hooks, subagents, and MCP first; this post is about composing them.
What counts as an agentic workflow
A Claude Code agentic workflow is a repeatable way of sequencing the tool’s primitives so the agent completes multi-step work with minimal supervision. The primitives are plan mode, subagents, hooks, git worktrees, custom slash commands, and MCP connections. A workflow is the recipe that arranges them: plan first, delegate the noisy reading, run the work in parallel, and verify before stopping. The distinction that matters is repeatability. A good prompt solves one task; a workflow solves a class of tasks the same way every time.
The reason workflows outrank raw model quality is a point this site has made before and will keep making: the harness beats the model. Two engineers on the identical Claude Code subscription, pointed at the same repository, produce wildly different results depending on whether they plan, delegate, and verify or just chat. The model is rented and roughly fixed. The workflow is the part you own, and it is where the leverage lives.
Claude Code ships new versions near-daily, and as of July 2026 the default model is Sonnet 5 with a native 1M-token context window. That larger window changes the ceiling on these workflows but not the discipline: the best-practices documentation is built on the observation that model quality drops as the window fills, well before it overflows. A bigger context makes context hygiene cheaper to ignore and more expensive when you do.
The six workflows below are ordered by how much they hand off to the agent. The top of the ladder keeps you in the loop on every change; the bottom runs while you sleep.
| Order | Workflow | Lead primitive | When to reach for it |
|---|---|---|---|
| 1 | Plan mode first | plan mode | Any change worth reviewing before it touches disk |
| 2 | Subagent research fan-out | subagents | Questions that need reading many files to answer |
| 3 | The verification loop | hooks | Work where correctness must be checked, not trusted |
| 4 | Slash-command pipelines | skills | A prompt or playbook you have typed three times |
| 5 | Parallel worktrees | worktrees | Independent tasks that can run at the same time |
| 6 | Orchestration and scheduling | agent teams | Recurring or overnight work that runs without you |
Workflow 1: Plan mode first
The trigger: any change large enough that you would want to review the approach before code hits disk.
Plan mode is the single habit with the highest return, and it is one keystroke. Press Shift+Tab mid-session to toggle into it, or launch with claude --permission-mode plan. In plan mode Claude reads files and proposes a plan but, per the common-workflows documentation, “makes no edits until you approve.” You review the plan, edit it in your text editor if needed, and only then release the agent to implement.
The reason this works is counterintuitive: the effort you spend up front is not overhead, it is the thing that removes downstream churn. Anthropic’s power-user tips put it plainly: “Pour your effort into the plan so Claude can one-shot the implementation.” An agent that starts editing immediately makes a decision on line 3 that it has to unwind on line 300. An agent that plans first surfaces that decision while it is still a sentence you can correct.
The workflow in practice is three beats. Ask for a plan in plan mode. Read it as an engineer, not a rubber stamp: check that it identified the right files, that it is reusing existing code instead of inventing new code, and that its verification step is real. Approve, and let it execute against the plan it just committed to.
Cost note: plan mode is close to free. It spends reading and reasoning tokens but skips the write-test-rewrite cycles that a bad first draft triggers, so it usually lowers total spend on any task past trivial. It is the rare workflow that improves quality and cuts the bill at the same time.
Workflow 2: Subagent research fan-out
The trigger: a question whose answer requires reading many files, where the reading would otherwise fill your main context with material you will never reference again.
Context is the scarce resource in every session, and it degrades before it runs out. When you need to know how the auth system handles token refresh, the naive move is to have your main session read the fifteen files involved, which permanently costs you that window space. The workflow move is to delegate it. As the documentation frames the pattern, you say “use a subagent to investigate how our auth system handles token refresh,” and the subagent reads those files in its own context window and hands back only the summary.
The value is context hygiene. Your main conversation stays focused on the task and receives a paragraph instead of fifteen file dumps. This scales to fan-out: spawn several subagents in parallel, each investigating a different subsystem, and collect their summaries into one clean context. A review pass over a large diff is the same shape, one agent reading everything and returning the findings.
A subagent does the digging so your main session gets the conclusion, not the fifteen files it took to reach it.
Two details separate a working fan-out from a wasteful one. First, the built-in exploration agents skip loading your CLAUDE.md and git status, so a delegated task does not inherit your carefully tuned instructions; put anything the subagent must know into its prompt. Second, subagents are for reading, not deciding. Delegate exploration and review; keep the architectural calls in the main session where you can see the reasoning.
Cost note: a subagent spends its own input and output tokens, so total spend goes up even as main-context quality goes up with it. On a metered API plan that is a real line item, and the Claude Code cost-per-task analysis breaks down what a session actually bills. The trade is almost always worth it, because degraded output from a stuffed context is more expensive than the extra tokens.
Workflow 3: The verification loop
The trigger: any work where correctness must be checked rather than trusted, which is most work.
The strongest single recommendation in the best-practices documentation is not about prompting. It is this: “Giving Claude a way to verify its work will markedly improve the quality.” An agent that can run its own tests, read the failures, and fix them produces a different grade of output than one that writes code and stops. The verification loop is how you build that in.
The manual version is to tell the agent the command that reproduces the problem and let it iterate: write the code, run the tests, read the output, correct, repeat until green. The durable version wraps that loop in a hook so it happens every time without you asking. A PostToolUse hook runs your linter after each edit and feeds any failures back as text the agent reads and fixes. A Stop hook runs your test suite and blocks the agent from ending the turn until it passes, with a documented backstop: Claude Code overrides the hook and ends the turn after 8 consecutive blocks, so a broken check cannot trap a session forever.
That difference matters because a hook is the only part of the harness that guarantees anything. An instruction in CLAUDE.md that says “always run the tests” is a request the model can forget; a Stop hook that runs them is enforcement. For frontend work where “correct” is visual, the verification surface is different: point the agent at the running app so it can see what it built. And for a fast parallel quality read, the /simplify command reviews the diff on its own.
Cost note: the verification loop is the cheapest quality mechanism in the system. Hooks execute outside the conversation and add zero context unless they return output, so a passing check costs nothing and a failing check adds exactly the error message. What it does spend is the agent’s correction cycles, which is exactly the spend you want.
Workflow 4: Slash-command and skill pipelines
The trigger: you have typed the same multi-step prompt, or pasted the same playbook, three times.
The first three workflows are things you do in a session. This one is how you stop repeating yourself across sessions. When a sequence of instructions is stable enough that you keep retyping it, it should become a reusable artifact: a custom slash command or a skill. The power-user tips point at the mechanism directly, automating recurring workflows by saving them as skills in .claude/skills/<name>/SKILL.md.
The payback reading is the same one that governs the whole harness. A saved command costs a few minutes to write and pays back the third time you would have typed the prompt by hand. A skill for your release checklist, your incident runbook, or your test-writing conventions turns a paragraph of instructions you paste every time into a /name you invoke. The skills documentation adds the loading detail that makes this cheap: a skill contributes only its one-line description to context until you actually invoke it, at which point the full body loads.
This is also the workflow with the sharpest composition move. A custom subagent can preload a skill, so a security-reviewer agent that loads your security checklist is a specialist you spawn on demand. The pipeline is: encode the repeatable knowledge as a skill, wrap it in a subagent that preloads it, and invoke the whole thing with one command. That is a workflow you built once and now run in a keystroke.
Cost note: skills and slash commands are near-free until invoked. The description line rides in context; the body loads only on use. The cost is the discipline of writing a good description, because the agent picks skills by matching your task against that one line, and a vague description means the wrong skill loads or the right one never does.
Workflow 5: Parallel worktrees
The trigger: two or more independent tasks that could run at the same time, on the same repository, without their edits colliding.
Here is the productivity unlock the power-user tips single out: “The biggest productivity unlock is running 3–5 Claude sessions in parallel, each in its own git worktree.” A git worktree is a separate checkout of your repo on its own branch, so one Claude session can build a feature in one worktree while another fixes a bug in a second, and their file edits never touch. Launch one with claude --worktree feature-auth and run the same command with a different name in another terminal for an isolated parallel session, per the worktrees documentation.
The workflow is not just “open more terminals.” It has a shape that keeps parallelism from turning into merge chaos. Plan first and define the boundaries: each session owns a slice of the codebase, and the slices do not overlap. Give each its own worktree so edits are isolated. Run the verification loop inside each worktree independently. Then validate the merged result, because green-in-isolation is not green-together. Skip the boundary step and you get three agents fighting over the same files; respect it and you get three engineers’ throughput from one.
For batched, mechanical changes, this becomes true fan-out. The documented example is a migration: “Migrate all sync IO to async. Batch the changes and launch 10 parallel agents with worktree isolation.” Ten isolated agents each take a slice, each verifies its own slice, and you review the merge.
Cost note: this is the workflow to watch on the bill. Running five sessions in parallel spends roughly five sessions’ worth of tokens, concentrated into a short wall-clock window. The trade you are making is money for time, and it is often the right trade, but it is the one most likely to surprise you. Watch it live with the /cost command, and if the spend runs hot, the token-saving tools analysis covers what actually moves the number and what does not.
Workflow 6: Orchestration and scheduling
The trigger: recurring or long-running work that should happen on a schedule or overnight, without a human driving each step.
The top of the ladder is where the agent runs without you in the chair. Three mechanisms cover it, and they differ by where the work runs.
For non-interactive, scriptable work, Claude Code pipes like any Unix tool. git log --oneline -20 | claude -p "summarize these recent commits" runs it headless, per the common-workflows documentation, which makes it a natural fit for CI steps, pre-commit checks, and batch jobs. For recurring work, the scheduling options split by venue: Routines run on Anthropic-managed infrastructure so a task fires even when your machine is off, GitHub Actions ties a task to repo events, desktop scheduled tasks run on your machine with access to local files, and /loop polls within an open session. Anthropic’s own guidance on scheduled prompts is worth internalizing: because the task runs autonomously and cannot ask clarifying questions, “be explicit about what success looks like and what to do with results.”
The most advanced tier is agent teams: multiple full Claude Code sessions that share a task list and message each other directly, rather than reporting to one lead. The documented fit is competing hypotheses, parallel review, and feature work split by owner. The documented price is that each teammate is a separate full instance, making teams the most token-expensive primitive in the harness. They remain experimental and disabled by default as of July 2026, and the transition point is specific: reach for a team only when parallel subagents start hitting context limits or need to talk to each other.
Cost note: orchestration is the highest-variance spend in the playbook, because it removes the human who would otherwise notice a session burning tokens in a loop. The mitigation is the same discipline the scheduling docs prescribe: a crisp success condition, a hard stop, and a verification step so the run ends correctly instead of just ending. Model the economics before you automate; the subscription-versus-API tradeoff decides whether recurring autonomous runs belong on a flat plan or a metered key.
Which workflow for which task
The workflows are not a ladder you must climb to the top. Each one earns its place only against a matching task, and reaching past the match wastes tokens or, worse, ships unreviewed work. The mapping below is the fast version.
| Task | Reach for | Skip |
|---|---|---|
| One-line fix, obvious change | Just prompt it | Plan mode, worktrees |
| Feature with design choices | Plan mode first, then verify loop | Parallel worktrees |
| Understand an unfamiliar subsystem | Subagent research fan-out | Editing anything yet |
| Anything that must pass tests | Verification loop with a Stop hook | Trusting the diff |
| A prompt you have typed repeatedly | Slash-command or skill | Retyping it |
| Several independent tasks at once | Parallel worktrees | A single serial session |
| Large mechanical migration | Batched parallel agents with worktree isolation | One agent, one pass |
| Recurring or overnight job | Routines or headless pipe | Sitting and watching |
Two rules sit underneath the table. First, autonomy is a cost multiplier as much as a speed multiplier: every rung up the ladder hands the agent more rope and spends more tokens with less supervision, so climb only as far as the task needs. Second, verification is not optional at any rung. The more autonomous the workflow, the more it depends on a check the agent has to pass, because there is no human watching the diff go by.
The cost lens most guides skip
Every workflow in this playbook has a token cost, and the more autonomous ones have the kind of cost that arrives as a surprise at the end of the month. That is the part most Claude Code guides leave out, and it is the part that decides whether these workflows are an investment or a leak.
The pattern is consistent. Plan mode and the verification loop tend to lower total spend, because they replace expensive rewrite cycles with cheap reading and cheap hook output. Subagents, parallel worktrees, and agent teams raise it, because each one is spending additional tokens somewhere you are not watching: a subagent in its own window, five sessions at once, or a team of full instances talking to each other. None of that is a reason to avoid them. It is a reason to instrument them. Run the /cost command to see spend live, model the plan-versus-metered decision with the cost-per-task pricing analysis, and treat the autonomous workflows the way you would treat any process with an open-ended spend: with a budget and a stop.
The deeper point is the one this site keeps returning to in the 2026 coding-agent landscape: the workflow, not the model, is where both the quality and the bill are set. Two teams on the same subscription can differ by an order of magnitude in output and in spend, and the difference is entirely in whether they plan, delegate, verify, and instrument, or just chat and hope.
Anti-patterns that quietly cost you
The failure modes are as repeatable as the workflows, and each has a one-line fix.
- Skipping plan mode on anything nontrivial. The most common and most expensive mistake. The agent commits to an approach in its first edit and spends the rest of the session unwinding it. Plan first.
- Over-parallelizing without boundaries. Launching five sessions on overlapping slices produces merge conflicts, not throughput. Define ownership before you fan out.
- No verification step. An agent that cannot check its work will confidently hand you code that does not run. Give it a command to run and make a hook gate the stop.
- Delegating decisions to subagents. Subagents are for reading and review, not architecture. Keep the calls where you can see the reasoning.
- MCP tool-budget bloat. Connecting every server you have ever heard of fills context with tool schemas you never use. The MCP servers worth installing analysis covers the short list and the discipline.
- Automating before instrumenting. Scheduling an autonomous run without a success condition, a hard stop, and a live cost view is how a loop quietly bills all night.
The through-line is that every anti-pattern is a workflow run at the wrong altitude: too autonomous for the task, or not verified enough for the autonomy. Match the workflow to the work, and verify in proportion to how much you handed off.
Where to go next
The fastest way to raise your Claude Code output is not a new model or a longer CLAUDE.md. It is adopting these workflows in order of payback: plan mode first because it is one keystroke and lowers your bill, then a verification loop because it changes the grade of the output, then subagents and worktrees when a task is big enough to need them, and orchestration only once you have a workflow reliable enough to trust unattended.
For the primitives underneath these recipes, the Claude Code harness guide is the reference. For the general economics of wrapping a rented model in a harness, see the harness scaffolding guide. And for how Claude Code compares to the other agents on cost and capability, the AI coding agents hub is the map.
Frequently asked questions
- What is an agentic workflow in Claude Code?
- A repeatable sequence of Claude Code primitives (plan mode, subagents, hooks, git worktrees, custom slash commands, MCP) that completes multi-step work with minimal supervision. It differs from a single prompt in that it solves a class of tasks the same way every time, rather than solving one task once.
- What is the single most useful Claude Code workflow to adopt first?
- Plan mode first. Press Shift+Tab or launch with claude --permission-mode plan so the agent reads and proposes a plan before it edits anything. It costs one keystroke, catches wrong approaches while they are still a sentence you can correct, and usually lowers total token spend by avoiding rewrite cycles.
- How do I run multiple Claude Code sessions in parallel?
- Use git worktrees. Launch a session with claude --worktree feature-auth and run the same command with a different name in another terminal. Each worktree is an isolated checkout on its own branch, so parallel sessions do not collide. Anthropic recommends running 3 to 5 sessions at once, each owning a non-overlapping slice of the codebase.
- Do subagents and parallel workflows cost more tokens?
- Yes. A subagent spends its own input and output tokens on top of your main session, and running five parallel sessions spends roughly five sessions worth of tokens in a short window. Agent teams cost the most, because each teammate is a full instance. Plan mode and verification loops, by contrast, tend to lower total spend.
- How do I make Claude Code verify its own work?
- Give it a command that checks correctness (a test suite, a linter, or the running app for frontend work) and make a hook enforce it. A PostToolUse hook can run the linter after each edit and feed failures back, and a Stop hook can block the turn from ending until the tests pass. A hook enforces the check; an instruction in CLAUDE.md only requests it.
Sources
Anthropic. Common workflows. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/common-workflows
Anthropic. Best practices for Claude Code. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/best-practices
Anthropic. Claude Code power-user tips. Claude Help Center (vendor docs). https://support.claude.com/en/articles/14554000-claude-code-power-user-tips
Anthropic. Subagents. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/sub-agents
Anthropic. Worktrees. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/worktrees
Anthropic. Automate workflows with hooks. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/hooks-guide
Anthropic. Agent Skills. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/skills
Anthropic. Agent teams. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/agent-teams
Anthropic. Routines. Claude Code documentation (vendor docs). https://code.claude.com/docs/en/routines