Introduction
Managing complex workflows becomes much easier once you understand that Claude Code subagents should be used to create capacity rather than just more processes. The most common mistake founders make is over-complicating their setup by splitting every single task into a different specialist role. Within a week, they often find the infrastructure is harder to manage than the manual work it was supposed to replace.
The real goal of running multiple AI workers in parallel is bandwidth. If dividing a project across different agents doesn’t give you back several hours every week, you have likely over-engineered the solution.
In this post, I will walk through what these subagents actually are, the specific scenarios where splitting work genuinely helps, and when one well-briefed agent is actually the faster choice. I will also share the patterns I use in my own business to keep the configuration sane, giving you a clear test for any task you are thinking of automating.
Key Takeaways
- Claude code subagents are specialised AI workers spawned by a main agent to handle a single bounded job and report results back.
- Split work across subagents when tasks are independent, can run in parallel, or pollute the main agent’s context window if combined.
- Keep it as one agent when the workflow is short, sequential, or needs shared context that breaks if you partition it.
- Most useful Claude code subagent examples in a small business are research, code review, content audits, and inbox triage that run while you sleep.
- The GitHub community has thousands of Claude Code subagent templates, but borrowed templates fail unless you adapt them to your business context first.
- Claude code subagents vs skills is not an either-or choice. Skills teach an agent how to do a job. Subagents are those who do the job.
- The honest rule for Claude Code subagents’ best practices is to start with one, prove the bandwidth gain, then add the next one only when the first is paying back hours.
- A subagent that needs more supervision than it saves you is a tax, not an asset. Kill it, do not improve it.
I built my first subagent setup six months ago and ran straight into the over-engineering trap. I had eight specialist workers covering research, content, customer outreach, code review, design, finance, ops, and content moderation. After three weeks, I had used three of them. The other five sat idle because the moment I had to remember which agent did what, I gave up and asked the main agent instead. That is the lesson I am writing this post to save you from. Less, but used. Not more, sitting idle.
What Claude Code Subagents Actually Are
A subagent is a separate AI worker that the main Claude Code session can call, brief, and wait on. The main agent stays the orchestrator. The subagent gets a single task with a clean context window, does the work, and returns a summary or artefact. The main agent then carries on without having absorbed all the noise of the subtask.
That last part is the bit most founders miss. Context windows are finite. If you run a single long session and ask one agent to read fifty files, review the code, write a report, and then plan the next sprint, the context fills up with file contents and tool output. By the time the agent gets to planning, it has lost the early reasoning. A subagent isolates the file-reading job. The main agent never sees the fifty files. It just sees the subagent’s three-paragraph summary. The main context stays focused on what matters.
This is also why subagents matter for parallelism. You can spawn three or four subagents at once, give each a different research question, and they all run at the same time. What used to be a forty-minute sequential research task becomes a ten-minute parallel one. The bottleneck stops being the agent and starts being how fast you can read the consolidated results.
The other thing worth saying upfront is that this is not magic, and it is not new conceptually. Software engineers have been running parallel processes for forty years. The difference is that the agent itself can now decide when to spawn a subagent, what to brief it with, and how to combine the results. You are not writing the orchestration code by hand. You describe the job in plain English, and the main agent handles the splitting.
When to Split Work Across Multiple AI Workers
This is the question that matters, and it has a simple answer. Split when at least two of these three conditions are true.
Condition one. The tasks are genuinely independent. If subagent A’s output is the input to subagent B, you are not really running parallel work. You are just adding handover overhead. Independent means three research questions about three different topics, not three steps of the same workflow.
Condition two. The tasks would pollute the main context. Reading a forty-thousand-line repository, processing a hundred customer emails, auditing every page on a website. These eat context. A subagent reads them, summarises them, throws the raw content away, and hands the summary back. The main agent stays clean.
Condition three. The tasks need different specialisations or different instructions. A code reviewer subagent has a different system prompt from a content writer subagent. If you brief one agent with both sets of instructions, it will be worse at both. Splitting gives each worker a tight role.
If only one of these three is true, you are usually better off with a single well-briefed agent doing the work sequentially. Two-out-of-three is the threshold. Three-out-of-three is a no-brainer split.
Here is what this looks like in practice. I had a research task last month. I needed to understand how three competitors structured their proposal documents, what their pricing pages looked like, and what their onboarding emails said. Three independent topics. Each requires reading a lot of source material. Each needs the same specialisation (competitive research). That hits two of three conditions. I split it into three subagents running in parallel. Total time: eight minutes. Doing it sequentially in one session would have been a minimum of thirty minutes, and the main agent would have been so full of competitor content that the next task in the session would have suffered.
Compare that to a task last week where I was writing a sales email. I needed the agent to pull context from my CRM (one customer), draft the email, and then check the tone against my voice guide. That is sequential. Each step’s output is the input to the next. Splitting it into subagents would have meant the main agent briefing three separate workers, waiting on each, then assembling. One agent did the whole thing in two minutes. No split needed.
The rule I now use, if I am considering a split and I cannot describe the parallel tracks in one sentence each, the split is wrong. Split where the boundaries are obvious. Stay sequential where they are not.
Claude Code Subagents Best Practices for Founders
The GitHub community has produced a lot of opinionated takes on this, and most of them are written for engineering teams shipping software full-time. For a founder running a business, the best practices are different. Here is what I have found actually works.
Start with one subagent before you build two. Pick the single highest-bandwidth task in your week that hits the two-of-three test. Build a subagent for that. Use it for a fortnight. If it is paying back hours, build the next one. If it is not, kill it and try a different task. The biggest failure mode is starting with five or six subagents from a GitHub template and never proving any of them work.
Brief them like you would brief a contractor. A subagent gets one shot. It does not have your full business context the way the main agent does. The brief needs to include what the task is, what good output looks like, what constraints matter, and what to do if it gets stuck. Vague briefs produce vague work. The same as humans.
Decide what comes back, not what goes in. The main agent only sees what the subagent returns. So, design the return format first. A summary in three bullets. A markdown report with specific sections. A pass-or-fail verdict with reasoning. If you have not decided what the output looks like, you will get long, rambling returns that defeat the point of using a subagent in the first place.
Run them on a clear trigger. The best subagents I have built are ones with an obvious “when to call this” rule. Code review subagent runs before every commit. Research subagent runs when I am about to write a strategy document. Inbox triage runs at 7 am every morning. If the trigger is fuzzy, the subagent does not get used. If it has a clear trigger, it becomes part of the routine.
Kill underperformers fast. I have built six subagents in the last six months. Three are alive, three are dead. The dead ones either took longer to brief than to do the task manually, produced output I could not trust without checking, or sat in a corner of the workspace never being called. No shame in killing them. The bandwidth gain comes from the live ones.
The honest version of best practices for Claude Code subagents is this. The setup that wins is small, used, and trusted. Not the one with the most agents.
Claude Code Subagents vs Skills
This comes up a lot, and the answer is that they are different things solving different problems.
A skill is a teaching mechanism. You give an AI agent a skill so that when a certain kind of task shows up, the agent knows how to do it. A skill for writing proposals contains the structure, the voice guide, the examples, and the rules. Any agent can pick up that skill and apply it. The skill is the recipe.
A subagent is a worker. The subagent is the person you call to actually cook the meal. It is a separate instance with its own context, briefed for one job. The subagent might use skills to do the job, but the subagent itself is not a skill.
The cleanest way to think about it. Skills are the playbook. Subagents are the players you call onto the field.
So when you see content debating Claude Code subagents vs skills as if you have to pick, the framing is off. You use both. You teach the main agent a skill for proposal writing, you teach the subagent a skill for code review, and the architecture of who does what stays separate from the question of how they know what to do.
In practice, for a small business, you will end up with a small number of subagents (three to six) and a larger collection of skills (ten to thirty). The skills cover the recurring tasks. The subagents cover the moments where you need parallelism or context isolation.
Real Examples of Subagents in a Business Context
Let me show what this looks like in a real business rather than in an engineering team. These are Claude Code subagent examples I either run myself or have built for clients.
Inbox triage subagent. Runs at 7 am every day. Reads my email overnight, classifies each one (urgent, can wait, needs a draft reply, can be ignored), and produces a one-page summary. The main agent never sees the raw emails. I read the summary on my phone before getting out of bed. The bandwidth gain is forty minutes a day. Build effort, one afternoon.
Lead research subagent. When someone books a call, this fires automatically. Reads their website, checks their LinkedIn, summarises what their business does, what they likely need, and what I should ask them. By the time I open the call notes, the prep is already done. Used to take me twenty minutes per booking. Now takes zero.
Content review subagent. Before I publish any blog post, I read the draft, check for the things I always get wrong (em dashes that slipped in, banned AI words, tone that drifts corporate, missing internal links), and either return “ready to publish” or a list of fixes. Lives separately, so the main writing agent does not get distracted by the QA brief while writing.
Daily metrics subagent. Pulls numbers from my data warehouse, my CRM, my accounting tool, my analytics, and my project tracker. Writes a five-paragraph daily brief that lands on my phone at 7 am with the email triage. The main agent stays clean of all the API noise.
Competitive research subagent. Spawned on demand when I am writing strategy. Takes a competitor and a question, does the research, and returns a structured report. I run two or three of these in parallel when I need to compare multiple players.
Code review subagent (for my own builds). Reads the diff before I commit, checks it against my style rules, and flags anything risky. Lives in the background of every coding session.
These six are alive in my workspace right now. Three others have been killed in the last six months. One was a customer support drafting agent who produced replies I could not trust. One was a financial analysis agent that needed so much context every run that briefing it was slower than the analysis itself. One was a meeting follow-up agent that got replaced when I started using a meeting transcription tool that already did the job.
None of these is revolutionary, and that is the point. Each one solves a specific recurring task that was eating up my time. Each was tested for two weeks before earning a permanent slot. Each has a clear trigger and a clear output format. Nothing fancy.
How I Use Subagents to Run a Solo Business
The bigger picture is that subagents are one piece of how I run my own business with very little manual operational work. The pattern is the AI brain and the AI workforce.
The AI brain is the thinking layer. Context files about what my business does, my team, my clients, my strategy. A data layer that sees every number in real time. An intelligence layer that briefs me daily on what changed and what matters. That is the main Claude agent, running with full context, used for strategy, decisions, planning, content, and communication.
The AI workforce is the doing layer. Subagents handle the recurring jobs. Some run on a schedule (inbox triage, daily brief, weekly reports). Some run on triggers (lead research when a call is booked, code review before a commit). Some run on demand (competitive research when I am writing strategy, content review before publishing).
The split between the two is the thing that matters. The brain thinks. The workforce works. If you put thinking inside a workforce subagent, the subagent has to be briefed too heavily and gets confused. If you put working inside the main agent, the main context fills up with operational noise and the thinking suffers.
Most of my time is now spent on the brain side. Decisions, strategy, conversations with prospects, building new products. The workforce handles the rest. That is not a magic trick. It is just the systematic separation of what needs my judgement from what does not.
If you are not running this split, your business is running through your head. Every question, every decision, every recurring task. That is the operator trap. You started a business to do interesting work, and now you are the highest-paid admin in your own company. Subagents are one of the practical ways out. Not the only way, but a real one.
A Note on Templates and Borrowed Setups
There is a growing Claude Code subagents collection on GitHub and a few public Claude Code subagents lists circulating in the community. They are useful as inspiration. They are dangerous as starting points if you do not adapt them.
The reason borrowed templates fail is the same reason borrowed processes fail in any business. A subagent built for another founder’s workflow has context, assumptions, and decisions baked into it that may not apply to yours. Pull the structure, throw away the assumptions, rewrite the brief from scratch using your own business context.
A Claude Code subagent template is a starting skeleton. The skin and the muscle have to be yours. I have made the mistake of dropping in a fully formed agent from someone else’s collection and then wondering why it produced strange output. The output was strange because the agent was solving someone else’s problem perfectly. It just was not my problem.
If you are looking at GitHub repos or community lists, treat them like recipe books. Read for ideas. Cook your own version. Do not copy-paste a setup and expect it to work in a business you did not design it for.
The other piece, the Anthropic documentation on subagents is a better starting point than most community collections because it is written by the people who built the system. Read that first, then look at community examples for inspiration on specific use cases.
Conclusion
Claude Code subagents are useful when you split for the right reasons and a liability when you split for the wrong ones. Split for parallelism, context isolation, or specialisation. Stay sequential for everything else. Build one at a time, prove each one pays back hours, kill the ones that do not.
The bigger picture is that subagents are part of the doing layer of a properly run business, and the doing layer only works if the thinking layer is in place first. Get the AI brain working. Then start adding the AI workforce, one role at a time, until the business runs without you in it for most of the operational hours of the week. That is the outcome that matters. Not the number of agents in your setup.
If you read this and you are at the stage where you have one or two subagents working, and you are thinking about the next layer, you are doing it right. If you read this and you have not built one yet, build one. Pick the most painful recurring task in your week; that is the candidate.
Try This Next
If you want to talk through how this would actually apply to your business, the fastest way is a 30-minute Discovery Call. Bring one task that is eating your week, and we will work out whether a subagent is the right answer or whether something simpler would do the job. Book the call here: 30-minute Discovery Call.
If you want to read more before booking, the AI Operating System overview covers the bigger picture of how the brain and the workforce fit together, and the AI Agents for Small Business post goes deeper on the workforce side specifically.
Frequently Asked Questions
What is a Claude Code subagent, and how is it different from a normal Claude session?
A subagent is a separate AI worker spawned by a main Claude Code session to handle one specific job with its own clean context window. A normal session is one continuous conversation where everything stays in the same context. The subagent does the task, returns a summary, and the main session continues without absorbing the full detail of the subtask.
When should I use multiple Claude Code subagents instead of one agent?
Use multiple subagents when the work is genuinely independent and can run in parallel, when one task would pollute the main context with too much detail, or when different tasks need different specialisations. If only one of those is true, stay with a single well-briefed agent. Splitting work that is sequential or shared-context usually slows things down rather than speeding them up.
Are there good Claude Code subagent examples for non-engineering use cases?
Yes. The most useful ones in a small business are inbox triage that classifies email overnight, lead research that runs when a call gets booked, content review that checks drafts before publishing, daily metrics briefs pulled from multiple data sources, and competitive research that runs in parallel when comparing multiple players. Each saves a specific recurring task from eating your time.
What is the difference between Claude Code subagents and skills?
A skill is a recipe that teaches any agent how to do a specific kind of task. A subagent is a worker called to actually do the job. They solve different problems, and you use both. A subagent might use a skill to do its work, but the subagent itself is the player on the field while the skill is the playbook. Choosing between them is the wrong question.
Should I use Claude Code subagent templates from GitHub?
Treat them as inspiration, not as drop-in solutions. A template built for another founder’s workflow has assumptions, context, and decisions baked in that probably do not match your business. Read the structure, throw away the assumptions, and rewrite the brief from your own context. Copy-pasting from a community collection without adapting it is one of the fastest ways to end up with a subagent that produces strange output.
What are the best practices for setting up Claude Code subagents for the first time?
Start with one. Pick the highest-bandwidth recurring task in your week. Build a single subagent for it with a clear brief, a clear trigger, and a defined output format. Use it for two weeks. If it is paying back real hours, build the next one. If not, kill it and pick a different task. The biggest mistake is starting with five or six agents from a GitHub template before any of them are proven.
How do I know when a Claude Code subagent is not working and should be removed?
If the subagent takes longer to brief than the task would take you manually, kill it. If you cannot trust the output without checking it carefully each time, the subagent is a tax, not an asset. If it sits in your workspace, never being called, it is dead already. The bandwidth gain is in the live ones. Three working subagents beat ten unused ones every time.
About Octavius
Titus Mulquiney is the founder of Octavius AI, where he builds AI brains and AI workforces for founder-led businesses stuck running everything out of their own head. Twenty years in marketing, ex-Sony product manager, ex-GM Zeal NZ. Based in Auckland, working with operators across NZ, Australia, and the US. Connect on LinkedIn.