Let me show you how to build an army of AI agents to do your work. By the end of this email you'll know how to hand an entire feature to a team of AI agents and get back something you'd actually ship.

Quick recap of the week:

• Day 1: why AI only gets you 80% of the way
• Day 2: our AI toolbox
• Day 3: forcing quality out of those tools with deterministic checks
• Day 4: permissions, sandboxing, and autonomous AI

Free 5 Day Course - Agentic Workflows and Subagents

Here's the thing about yesterday though, even if you give AI complete free reign, it's gonna produce slop if you don't tell it exactly what to build. So today is mostly about being clear up front about what you want, which sounds obvious until you watch what happens when you skip it.

Spec First, Always

When an agent runs for hours it's gonna hit questions mid-run, and if you're not there to answer them, it guesses. Multiply a few hours of guessing and you can see where the slop comes from.

So before any code gets written, I try to answer as many questions as possible up front. My flow looks something like this:

• Describe the feature and literally tell the AI to interview you before starting (edge cases, design choices, what's out of scope). It'll come up with questions you didn't think of.
• Have it write the answers in to a spec file in the repo, and that spec becomes the authority.
• The agents that build it implement, test, and verify against the spec, not against their own guesses.

Front-loading the design questions is what lets an agent run for hours without me, most of the decisions are already made by the time it starts.

For the questions that still come up mid-run, have the agents triage them: every decision gets weighed as go (just do it), log (pick a sensible default and write it down), or bubble up (actually stop and ask me). And you can adjust those thresholds depending on how freaky you're feeling that day.

A spec also sets you up for TDD. Before building, have an agent review the spec and call out any pure logic that can be isolated and tested against, then write those tests first. Now the implementer is making tests pass instead of interpreting prose, way less room to drift.

Bundles: A Small Team for One Feature

For bigger features I take this further with something I call launch bundles. Full disclosure, I literally just made this structure up, you'll see all types of variations online, this is just the one that stuck for me.

The rule that makes it work: my main chat never does the work itself. Its instructions are to delegate, always. When I describe a feature it hands the whole thing to a bundle orchestrator running in the background, and THAT agent does the delegation and coordination across the bundle:

• A planner turns the request in to the spec
• A test writer takes the spec, isolates the pure logic, and writes the tests
• An implementer writes the code
• A UI/Mobile agent for anything visual, builds mobile-first and screenshots its own work to verify
• A verifier checks the result against the spec and pushes back if we overcomplicated it

YOU DON'T HAVE TO USE ALL OF THEM. Start with one implementer, add a role when you feel the pain it solves.

Two details from my setup that make this actually reliable:

Schema'd responses. Workers don't report back in prose, they return JSON matching a schema. My verifier for example has to return:

{ "status": "pass" | "fail",
  "issues": [ { "file": "x.ts", "kind": "security | smell | bad-pattern", "detail": "...", "fix": "..." } ] }

So the orchestrator reads fields, not vibes, and a malformed response gets rejected and retried instead of misread.

The channels stay open. Background agents stay resumable, you message the same agent by its ID and it picks up with its full context intact, no redone work. The actual instruction in my skill reads roughly:

Never stop your turn to wait for an answer. Either keep working, or return your
current state as a structured report. When the blocker is resolved, you'll be
messaged on the same agent ID and auto-resume with full context, exactly where
you stopped.

That's also how mid-task course corrections happen, I can redirect a half-done bundle without restarting it.

All of this keeps the main thread free, so while one bundle grinds away I can launch another in parallel or answer whatever clarifying questions bubble up. A feature takes an hour or a few to build and verify on its own, so running several at once is not as crazy as it sounds.

I wrote this whole workflow up as a skill I called launch, and at this point it's how most features on my platform get built.

One caveat though, autonomous doesn't mean walk away forever. You still point it at the right problem and check the result when it's done, it just takes the babysitting off your plate. If you're lazy about that part, it will happily spend 3 hours building something you didn't want, and now you're out of credits, you have a bunch of code to deal with, and you're really sad. Let's skip that ok, put real effort in to the spec (like hours, sometimes days, depending on the depth).

The Right Model for Each Role

The other half of orchestration is matching the model to the job. The heavyweight thinking models are the smartest and most expensive, and most of the work in a bundle doesn't need them.

Here's roughly how the assignments look in my launch skill:

Basically spend the expensive model on decisions and the cheap one on typing.

Fair warning from running this for months, done poorly this structure just adds bureaucracy. The agents go back and forth changing each other's work and burn credits without ever converging. So get Days 1 through 4 working first, then maybe reach for orchestration when a feature is too big for one agent.

The Week, Tied Together

So that's the system, checks that can't be skipped (Day 3), boundaries so the dangerous stuff can't happen (Day 4), and specs plus orchestration so all that freedom actually produces something worth shipping (today).

If you gained any value at all from this series, I would be doing you a disservice by not encouraging you to join Agentic AI today. We've talked about a lot of concepts, approaches, and ideas, but Agentic AI is really where we put it to work building real world systems for both operations and software engineering. This is a program built on months of working with AI from morning to night, and it's the foundation for a profitable SaaS and business.

Inside we go deep on:

• The full spec-first planning process
• The launch bundle setup: orchestrators, worker agents, and how they report back
• Running fleets of agents in parallel without them stepping on each other

You can check out the course here: https://codebreakthrough.com/agentic-ai

This is a LIMITED TIME offer and closes soon. So please don't miss it. I won't be extending the date.

Or if you have questions, just reply to this email, I read them.

Thanks for spending the week with me. Now go kick something off and let it run.

Caleb