Subagents, hooks, slash commands, and recurring tasks—put Claude Code on autopilot and multiply your productivity.
Learn to delegate complex tasks to parallel subagents and multiply Claude Code's capacity without increasing wait time.
A subagent is a Claude Code instance launched by the main agent to perform a specific task in isolation. It receives a well-defined prompt, works independently, and returns a summarized result to the orchestrator.
With subagents, you can parallelize work—while one researches docs, another writes tests, and a third reviews the code. What would take hours in sequence happens in minutes.
Not every task deserves a subagent. Delegation makes sense when the task is independent, has a clear scope, and its result can be consumed atomically by the orchestrator.
Delegating poorly increases cost without any benefit. Knowing when to delegate is the difference between efficient automation and unnecessary overhead.
Fan-out is a pattern where an orchestrator launches N subagents simultaneously, each solving part of the problem. The results are collected and integrated at the end.
Fan-out is the most powerful automation pattern with Claude Code. Research that would take 1 hour in sequence can be completed in minutes when parallelized with 4-8 subagents.
Claude Code supports different subagent profiles: the Explore type focuses on reading and analysis (no writing); General can run any tool. The choice determines permissions and risk.
Using the wrong subagent type can create security risks (a research agent with write permission) or limit functionality (a coding agent without exec permission).
A subagent's result returns to the orchestrator as compressed text — a summary of what was done, not the full execution log. This preserves the main agent's context.
Understanding how the result is returned helps you write better prompts: specifying the expected output format (JSON, markdown, list) ensures the orchestrator can consume the result without rework.
Each subagent uses tokens: the instruction prompt + execution + result. With multiple subagents running in parallel, costs can scale quickly without controls.
Poorly planned automation can cost more than equivalent manual work. Calculating ROI before implementing subagents is an essential professional practice.
Configure event hooks to automate actions before and after each tool—linting, security, and context injection without touching the agent’s code.
Hooks are external scripts run by the harness at specific points in the agent lifecycle: before a tool (PreToolUse), after one (PostToolUse), when a session starts (SessionStart), or when it stops (Stop).
With hooks, you can add behavior without modifying the agent's prompt or code. It's the cleanest way to enforce policies: lint always runs, and prohibited commands are blocked automatically.
Hooks are configured in the key hooks of the file settings.json (global in ~/.claude/ or local in .claude/). Each hook is an object with an event, a tool matcher, and a shell command.
Declarative configuration in settings.json lets you version hooks alongside the project. Entire teams inherit policies automatically without manual onboarding.
A PreToolUse hook can return a nonzero exit code to abort the tool before it runs. This lets you create command blacklists — for example, block git push --force.
Destructive commands like rm -rf or force-pushing to main can cause irreversible damage. A blocking hook is the last line of defense.
A PostToolUse hook can run linting or formatting automatically whenever the agent saves a file. The lint output is injected back into the context, allowing the agent to fix errors in the next iteration.
Without automatic linting, the agent may generate code with formatting errors that only show up in CI. With the hook, every save produces clean code — an instant feedback loop.
The SessionStart hook runs when a new session begins. Its output is injected as an initial message into the context — ideal for loading project metadata, the current branch, environment variables, or relevant memories.
Instead of repeating the project status in every new prompt, SessionStart injects it automatically. The agent starts each session with context already in place—fewer tokens spent, more focus on the work.
By default, if a hook fails (timeout, script error), the harness continues execution — a "fail-open" behavior. For critical security hooks, you can configure fail-closed to stop everything.
Relying too much on fail-open can leave security gaps. Understanding hooks’ failure model lets you design more robust systems where critical policies are never silently ignored.
Create reusable shortcuts and deterministic pipelines that orchestrate multiple agents sequentially or in parallel with a single command.
Slash commands are text shortcuts that expand into complete prompts. When you type /review in Claude Code, the harness expands this into a preconfigured code review prompt.
Instead of repeatedly rewriting the same long prompt, you type 3 characters and get consistent results every time. Entire teams use the same patterns without memorizing complex instructions.
Custom commands are defined as files .md inside the folder .claude/commands/. The file name becomes the command. Its contents are the prompt that will be expanded.
Each project has unique needs. A React project might have /component, one for data has /migrate. Customizing is part of a professional setup.
A deterministic workflow is a predefined sequence of steps — each step can be an agent, a shell command, or a data transformation. The output of one step feeds into the next, with no random variation.
When the process needs to be auditable and reproducible (CI/CD, releases, mandatory reviews), consistency is more valuable than creativity. Workflows ensure that every step always happens.
Pipeline: chained steps where A's output is B's input. Parallel: multiple agents running at the same time without depending on one another. Many workflows combine both patterns.
Choosing the wrong pattern can double execution time (when you should parallelize) or produce inconsistent results (when you should serialize). Workflow design matters as much as content.
Workflows are better suited when a task is repeated often, involves multiple agents, or needs to be auditable. One-off, creative tasks are better handled with free-form prompts.
Over-engineering workflows for simple tasks is wasteful. Under-engineering for critical tasks is risky. Knowing the right balance is the most valuable skill in automation.
A meta-agent (or higher-level orchestrator) can invoke entire workflows as subtasks. This creates a hierarchy: orchestrator → workflow → subagents — each level with clearly defined responsibilities.
For large projects, a single monolithic agent gets lost in complexity. The orchestrator hierarchy divides the problem into manageable layers—each layer well-tested and replaceable.
Schedule agents to run at set intervals — daily reviews, automatic reports, and continuous monitoring without human intervention.
Cron lets you schedule tasks to run at specific times (daily, weekly, hourly). Claude Code integrates with cron via the /schedule skill to create agent routines.
Recurring tasks are developers' biggest time sink. Daily code reviews, dependency updates, metrics reports — all can run without human intervention.
The command /loop repeats a task at set intervals while the session is active. It’s ideal for status polling, build monitoring, or continuous system observation.
/loop is simpler than cron for short-lived tasks. It requires no infrastructure setup — it runs in the current session and stops when you close the terminal.
Remote agents run on Claude's infrastructure without needing an open local terminal. They're triggered by events (webhook, cron) and run completely autonomously.
Remote agents are the boundary between local automation and production automation. When you don't want (or can't) keep a laptop on 24/7 to run tasks, remote agents are the solution.
A daily review agent runs via cron every day at 9 a.m., analyzes code committed the previous day, generates a quality report, and sends it as a notification or saves it to a file.
Automated code review doesn't replace the human reviewer—but it catches 80% of mechanical errors before human review. The human reviewer can focus on what matters: architecture and business logic.
Asynchronous agents don't return results immediately. The output can be collected via PushNotification (webhook), a generated file, or polling with Monitor — depending on the configured delivery mechanism.
Automation without observability is blind automation. Knowing where and how the result arrives is essential to trusting the automation — and to debugging when something goes wrong at 3 a.m.
Recurring agents accumulate costs over time. Idempotency ensures that running the agent twice produces the same result — crucial when failures lead to reruns.
A cron task that fails and is rerun 5× can create 5 identical PRs or incur 5× the expected cost. Idempotency isn’t a detail — it’s a production requirement.