Agent Teams & Subagents

A subagent is Claude Code working on one specific task while you or another agent works on something else at the same time. Instead of building your website page by page, you could have one agent writing copy, another designing layout, and another setting up the contact form — all at once.

Think of it like hiring three freelancers. Each gets a clear brief, works independently, and delivers back to you. You're the project manager — not the one writing every line.

A task that takes 4 hours sequentially might take 1 hour in parallel. The moment a project has 3, 5, or 10 independent pieces, doing them one at a time becomes the bottleneck. Run them all at once and you only wait for the longest one.

This is how real engineering teams work — and now you can do it with AI agents instead of people.

Give AI a clear prompt that splits the work. Here's one you can try right now:

The pattern is always three parts: define the tasks, request parallelism, and set a review checkpoint. Works for anything — reports, research, code, content, planning.

What you've done today is not just build a website. You've learned to think like a director rather than a doer — from asking AI a question, to giving it a job, to managing a team of agents in parallel.

The most powerful thing AI gives you is not speed. It's the ability to manage more than one thing at once without losing quality or control. That's the real unlock.

Before the agent starts, define done in plain, checkable terms: not “build the login page” but “a user can sign in, a test confirms it, and the app still starts.” If you can’t state how you’d verify it, the agent can’t know when to stop — so it stops too early.

Maintain a simple list of features, each with its own “how to check it works” and a status. The rule that matters: a feature only flips to done when the check actually runs and passes — the agent records the proof, it doesn’t just declare it. This one habit kills the “I think that’s working” problem.

Give every project a single startup-and-verify command (a script, a test run, a smoke check). A fresh agent session should be able to run it and instantly know: is this in a good state, or already broken? Build on a broken base and you just pile mess on mess.

Check work in three layers, and stop at the first failure: does it read right (no obvious errors), does it run right (tests pass, the app starts), and does it work end-to-end (the whole flow actually completes)? “Code was written” is not done. “Verification passed” is done. A second agent that only checks — not the one that built it — catches what the builder talks itself past.

The truth lives in the project’s files — what it is, how to run it, what’s done, what’s next — not in a chat window that vanishes. The test: open a brand-new session with nothing but the repo. If it can’t figure out how to run and verify the project, the project is under-documented, and every session pays the cold-start tax again.

Keep a short scorecard: is each part of the project getting stronger or weaker? Per-task review asks “was this session good?” The scorecard asks “is the whole thing trending up or quietly rotting?” It’s how you catch decay before it becomes a fire.