CAST part3: Building the team: from 17 role-based agents to task-based Agent Teams

Somewhere in Phase 4 of this build, my job changed. I stopped prompting an assistant and started managing a team — one you can't see, that never sleeps, and that will confidently agree with itself right off a cliff if you let it.

In Part 2 I walked through the four phases and the wall each one hit. The Phase 4 wall was coordination: multiple agents in parallel means merge conflicts, duplicated effort, and agents stepping on each other's work. The fix was organizational, not technical. This post is that org — how it started, how it failed, and what it looks like now.

Version 1: 17 role-based agents

My first instinct came straight from how human teams are built: give everyone a job title. So I did. Seventeen agents, each with a role — an architect, feature developers, reviewers, a test engineer, a docs writer, and more. On paper it looked like a real org. In practice, it behaved like a company with seventeen job descriptions and no manager.

What broke.
Three things, mostly:

Roles duplicated context. Every agent needed the same project background loaded in, and keeping seventeen copies of "here's how BowSmith works" consistent was a job in itself. When the architecture shifted, some agents got the memo and some didn't and the ones that didn't kept confidently building against the old world. Roles invited scope creep. A "senior iOS developer" agent doesn't just implement the ticket — it acts like a senior iOS developer, opining on architecture, refactoring things nobody asked about. The persona did more work than the task definition. Roles don't map to work. Real tasks cut across roles. A feature needs design, implementation, tests, and docs — so either one role-agent does work outside its role (why have roles?) or four agents hand off to each other (coordination overhead, again).

Version 2: task-based Agent Teams

The redesign flipped the axis. Instead of asking "who should exist?", ask "what needs to be done?" — and assemble a small team per task, drawn from a few standing functions:

An architect owns decomposition — breaking a feature into bounded, verifiable tasks. Feature devs implement exactly one bounded task each, in parallel where the boundaries allow. Reviewers check the work — more on who reviews whom in a second. Test/docs agents produce the evidence: tests that pin behavior down, docs that record what changed and why.

The teams are ephemeral. There's no standing "database agent" waiting for database work; there's a task, and a team sized to it. Context is engineered per task instead of per persona — each agent gets what this task needs, not everything a role might someday need.
(The templates and context discipline behind that will be next part post)

The result: less context to keep synchronized, no personas free-styling outside their brief, and parallelism that composes because the boundaries are drawn around the work.

The review problem nobody warns you about

Here's the finding I'd put on a slide if I had only one: same-model review barely works. My first review setup was the obvious one have the model review the model. It looked rigorous. It approved almost everything. The reviewer shared the writer's blind spots, so review became an echo chamber with extra steps: the same model that chose an approach found the same approach reasonable. Every time.

The fix is boring and effective: cross-model review. Have a different model — different training, different biases, different failure modes — review the work. If you take one thing from this post: diversity in a review chain isn't a nice-to-have, it's the mechanism. That's true of AI teams, and — QA people are nodding along here — it was always true of human ones.

Managing a team you can't see

What did this shift actually demand from me? Less coding than ever, and more of the things engineering managers get paid for: decomposing work into tasks with crisp boundaries, deciding who reviews whom, defining what evidence "done" requires, and noticing when two workstreams are about to collide.

The uncomfortable truth from Part 1 keeps compounding: the scarce skill in this workflow isn't writing code. It's structuring work so that code — from wherever it comes — can be trusted.

Next week: the method that keeps this team honest. Research → Plan → Implement grew a fourth stage, and the prompt templates around it cut my context drift by roughly 80%.

This is the build I'm taking apart, live and in full, at CAST 2026 (CAST26), Aug 3–5, Cocoa Beach, FL. The team structure, the review chains, and everything that failed on the way — that's where the whole story gets told.