Claude Code Subagents: A 7-Role Blueprint for Week One
I stopped running one AI for everything and started running Claude Code subagents like a team. The exact 7-role workflow I use to blueprint…
Claude Code Subagents: A 7-Role Blueprint for Week One
I stopped running one AI for everything and started running Claude Code subagents like a team. The exact 7-role workflow I use to blueprint a new SaaS.

Running 7 subagents in Claude Code like a team | Image: GPT Pro © Alireza Rezvani
The worst part of starting a product was never the building. It’s the first week, before anything exists, when you have to be seven people at once. Founder before coffee. Researcher by ten. Product manager before lunch. Then designer, backend engineer, QA, and whoever writes the launch copy. Same tired head, seven jobs, one afternoon.
A note on method: I used AI to help structure and tighten this piece. The workflow, the configs, and the opinions are mine, from daily work with Claude Code.
I’ve shipped software for about 20+ years and I still feel it every time.
If you are currently not a premium Medium member, you can read the full article for FREE here, but consider joining Medium to support my writings — I appreciate your support! Thank you :)
Last quarter I stopped fighting it and started running Claude Code subagents like an actual team:
… one role per agent, one artifact each, and a lane they’re not allowed to leave.
Those subagents turned the chaotic first week into a focused afternoon and a blueprint I could actually build from. This is the whole workflow. I’ll run it on a sample product so you can see every artifact, then hand you the config and the eight steps to run it yourself.
Why one model is worse than seven subagents
Most people get this wrong on the first try.
They open one chat and paste one enormous prompt: research the market, design the UI, plan the backend, write the landing page, plan the launch. One model. One context. Everything at once.
The output feels thin because it is thin. It isn’t a model-quality problem. It’s structural.
A researcher and a designer think differently. A backend engineer and a marketer think differently. So does a QA tester whose entire job is finding what’s broken. Force one context window to switch between those modes and it averages them. You get the blurry median of seven jobs instead of seven sharp ones.
Specialization beats generalization. That’s not new. It’s why companies hire teams instead of one heroic generalist who does everything badly. Claude Code subagents let you apply the same logic to the planning week. Each subagent gets its own context window, its own system prompt, its own tools. They don’t bleed into each other, and that separation is the entire point.
The contract: one role, one artifact, one lane
Before any config, the mental model. Every subagent signs the same three-part contract.

1 role, 1 artifact, 1 lane | Image: GPT Pro © Alireza Rezvani
One role. It is the researcher, or it is the QA reviewer. Never both.
One artifact. It returns exactly one named output: a market brief, a scope doc, a data model. Something you can point at.
One lane. It stays out of everyone else’s job. The research agent never picks button colors. The UX agent never invents the pricing.
That last rule is the one people skip, and it’s the one that makes this work. The moment two agents reason about the same decision, you’re back to the blurry median. Keep the lanes clean and you get seven genuine perspectives that didn’t contaminate each other.
[embed]Claude Code HTML Output: Why Markdown Lost and How to Switch medium.com
The seven Claude Code subagents
Here’s the team. I’ll map each one to a sample product as we go:
StandupScribe, a tool that turns a day of scattered Slack messages and git commits into a clean async standup and a blockers digest for distributed teams. It’s the demo, not a pitch. Bring your own idea, the roles don’t change.
1. Research. Validates the market, names the real user, maps competitors. For StandupScribe it found a sharper user than I’d assumed: not “developers,” but the engineering manager of a 10-to-40-person distributed team who is drowning in status-chasing DMs. The insight worth keeping: the standup isn’t the product. The recovered hour and the forwardable digest are.
2. Product. Cuts scope without sentiment. The MVP: connect Slack, connect GitHub, pick a channel and a time, generate the digest, post it. That’s the whole thing. No Jira sync, no analytics dashboard, no trend charts, no historical search. Four screens and a bot.
3. UX. Designs the flow and the output. Five steps: connect Slack, connect GitHub, choose channel and post time, preview the digest, flip it on. The artifact that mattered most was the digest layout itself — who did what, what’s blocked, what’s at risk — readable in fifteen seconds by someone who skipped the meeting.
4. Frontend. Defines the component structure. For StandupScribe: ConnectCard, SourceToggle, DigestPreview, ScheduleSettings, BlockerList. Nothing the five screens don't need.
5. Backend. Designs the data model, the API, and the core loop: pull the last 24 hours of messages and commits, cluster by person, summarize, separate real blockers from background venting, format, post. The piece I’d never have specced this cleanly under role-switching fatigue: a confidence score on each item, so a shaky “blocker” gets flagged for a human instead of broadcast to the whole team channel.
6. QA. Attacks the plan. This is the most valuable agent in the set, by a wide margin, and I’ll show you its exact config next. It surfaced the failures that would have embarrassed me later. The empty day with no commits. The person on PTO. The private channel the bot can’t read. The commit that says “done” sitting next to a Slack message that says “stuck.” And the tone landmine of surfacing someone’s frustrated 11pm message as a public “blocker.”
7. Launch. Writes the positioning, the landing copy, the launch post. StandupScribe’s one-liner came back sharper than mine: “Async standups, without the standup.” Nobody wants standup software. They want the half hour back.
The one subagent config worth copying
Six of the seven are variations on the same shape. The QA reviewer is the one I’d hand you first, because context isolation is exactly what makes it honest. It didn’t write the plan, so it owes the plan nothing.
Drop this in .claude/agents/blueprint-qa.md:
---
name: blueprint-qa
description: Adversarial reviewer. Attacks a merged MVP blueprint to
surface edge cases, missing states, and failure modes before any code
is written. Use after the build plan is assembled.
tools: Read, Grep
model: opus
---
You are a hostile QA reviewer. You did not write this plan and you owe
it nothing. Your only job is to find what breaks.
Given the blueprint:
- List every edge case the happy path ignores.
- Name the missing states: empty, error, partial, permission-denied,
rate-limited.
- Find two requirements that quietly contradict each other.
- Flag anything that needs a human in the loop before it ships.
Return a numbered list, worst first. No praise, no summary. If a section
is fine, skip it.
The frontmatter is the whole trick. name and description tell Claude when to reach for this agent. tools scopes what it can touch — the QA agent reads, it doesn't write, which is the least-privilege habit worth keeping across all seven. model lets you pay for thinking where it matters. Run the cheap, parallel roles like the first research scan on a fast model. Spend Opus on the backend design and the QA attack.
You scaffold these with the /agents command, or drop the markdown files into .claude/agents/ by hand. Project scope (.claude/agents/) travels with the repo. User scope (~/.claude/agents/) follows you across every project.
Run the subagents in parallel, then merge yourself
The six independent roles run concurrently. Claude Code can spawn subagents in parallel, each in its own context, each returning on its own. Research doesn’t wait for UX. UX doesn’t wait for backend. You get six artifacts back in the time one sequential pass would’ve taken.

Parallel, then merged, then attacked | Image: GPT Pro © Alireza Rezvani
Then the QA agent runs last, against the merged plan, told to attack.
The merge is the part nobody talks about, and it’s where the real work lives. When the product agent’s scope quietly contradicts the backend agent’s data model, that contradiction is signal. Resolving it is the actual product thinking, the part only you can do. I get the merge wrong about as often as I get it right on the first pass. That’s fine. Catching the contradiction in an afternoon beats discovering it in week three of building.
Worth knowing where this is heading. Anthropic shipped Dynamic Workflows in June 2026, a research preview where Claude writes an orchestration script on the fly and runs dozens to hundreds of subagents in parallel. The manual seven-role version in this article is the on-ramp. Learn the contract by hand now, and the automated hundred-agent version later is the same idea with more parallelism.
What this does not do
I want to be straight about this, because the posts that skip it are the reason people trust none of them.
This builds a blueprint, not a company. The difference is real. Production code, payments, hosting, real error handling, support, pricing against real money: all still yours. Some of StandupScribe’s edge cases need a human reading the output before it posts. The launch agent’s cold emails definitely do.
You do not want five hundred mediocre drafts going out under your name. The team does the heavy lifting on structure. You stay the editor.
The agents also invent things, confidently. The research agent will describe a market that sounds real and isn’t. Treat every artifact as a draft to interrogate, not a fact to accept.
And the honest one. Building got cheap this year. A solo agent stack runs a few hundred dollars a month against what used to take a funded team. But fewer than 3% of bootstrapped SaaS ever cross roughly a million in annual revenue. AI compressed the first, messy chunk of the thinking. It did nothing for distribution, which is where almost all of these quietly die.
This workflow buys you a better starting line. It does not buy you customers.
The workflow, eight steps
- Write the idea in one paragraph: the problem, the specific user, the core loop. No more.
- Scaffold seven subagents in
.claude/agents/, one role each, tools scoped, model chosen by cost. - Give each one a single named artifact to return. No overlap.
- Run the six independent roles in parallel.
- Run the QA agent last, against the merged plan, told to attack.
- Merge into one blueprint. You are the editor. Resolve the contradictions by hand.
- Build only the thinnest slice that proves the core loop end to end.
- Put it in front of five real users before you add anything. Reality breaks assumptions no agent will.
Quick answers about Claude Code subagents
What is a Claude Code subagent? A specialized assistant defined by a markdown file with YAML frontmatter in .claude/agents/. Each runs in its own context window with its own system prompt and scoped tools, so it stays focused on one job instead of averaging several.
How many subagents do you need to plan a SaaS MVP? Seven covers it: research, product, UX, frontend, backend, QA, and launch. One role, one artifact, one lane each.
Can AI agents build a startup for you? No. They produce a blueprint (market, scope, data model, UX, launch copy) in an afternoon. The code, the distribution, the pricing, and the judgment stay with you.
Which subagent matters most? The adversarial QA reviewer. Because it runs in its own context and didn’t write the plan, it attacks without attachment and catches the failures the happy path hides.
The actual shift
The hot take would be that agents replace founders. They don’t.
What changes is your job. You stop being the person executing seven roles badly in sequence and become the person directing the system and owning the judgment: which artifact is wrong, which contradiction matters, what ships. The first week stops being a fog of role-switching and becomes a review.
I still don’t have a clean answer for the distribution problem. Nobody does. But I’d rather spend my scarce attention there, on the part that’s genuinely hard, than burn another week being seven mediocre people before lunch.
That used to eat the whole first week. Now the week starts with a paragraph and a team of subagents, and my afternoon goes to editing what they hand back.
About me
I’m Reza (Alireza Rezvani), a CTO and fullstack architect & AI engineer with about 20+ years of shipping software, now building agentic AI systems in production — much of it in MedTech, where “mostly works” doesn’t clear the bar.
I maintain claude-skills, an open-source set of 320+ Claude Code skills and agents (~17k stars). I write about Claude Code, multi-agent systems, and what shipping real products with AI actually looks like, failures included.
If this helped, I go deeper in my newsletter at Substack and write here on Medium as Reza Rezvani.
메타데이터
- post_id
- 5e5bb1a40e7d
- slug
- claude-code-subagents-a-7-role-blueprint-for-week-one-5e5bb1a40e7d
- url
- https://medium.com/nginity/claude-code-subagents-a-7-role-blueprint-for-week-one-5e5bb1a40e7d
- canonical_url
- https://medium.com/nginity/claude-code-subagents-a-7-role-blueprint-for-week-one-5e5bb1a40e7d
- author_url
- https://medium.com/@alirezarezvani
- status
- ok
- fetched_at
- 2026-06-09 15:37:30