When Agent Teams shipped, the thing I'd built started to feel obsolete.

Someone dropped the Agent Teams announcement in a channel I'm in, with a one-word comment: "finally." I read the post over my first coffee and felt two things at once. The first was the obvious excitement. Multiple Claude sessions, running at the same time, coordinating with each other, splitting up work. Of course that's where this was going. The second feeling took longer to name, and it was closer to dread.

Because I'd spent months building the opposite. I have two frameworks I use every day at BetaCraft. One is vibe-*, 27 skills that carry a software project from the first brief to client handoff. The other is pm-*, 16 skills that run the project-management side, from a call transcript through to a Jira ticket and a status dashboard. That's 43 skills, and every one of them runs in a line. Brainstorm, then spec, then build, then review. Transcript, then brief, then estimate, then SOW. One thing finishes, hands its output to the next thing, and only then does the next thing start.

And here was Anthropic telling me the sessions didn't have to wait for each other anymore. My first honest thought wasn't strategic. It was just, "great, so the thing I built is already the old way." I've felt a version of it before, as a developer, when something I'd built real fluency in slid quietly out of date. There's a particular sting to it when the tool being retired is one you made yourself.

So I did what I usually do when I'm tempted to rewrite something that works. I made myself wait a week before touching anything, and I went and re-read my own reasons for building it the slow way in the first place.

Here's the part that's easy to forget when a shiny parallel version shows up. The sequence is the product. I didn't chain the skills together because I hadn't figured out how to run them at once. I chained them because the order is where the safety lives.

Take the dev side. vibe-review can't run until vibe-build has finished, because there's nothing to review before then. That's obvious. Less obvious is that the review is a gate, not a step. If it finds a P0 issue, the next phase doesn't start. The whole point is that work can't sprint ahead of the thing that's supposed to catch it. On the PM side it's the same shape. The skill that drafts a statement of work reads the decisions log first, on purpose, so it can't quietly commit the client to something nobody agreed to. I wrote about that failure mode in another post, a passing "maybe" on a call turning into a line item. The fix was ordering. The SOW step waits for the human-checked decision.

When you draw it out, the pipeline isn't really a list of tasks. It's a series of checkpoints, and the sequence is what makes each checkpoint mean something:

• Every step reads before it writes. A skill looks at the real project files, the spec, the decisions, the git history, before it proposes anything. It can only do that if the earlier steps have already written those files.
• Gates block, they don't warn. A failed review stops the line. If two things ran in parallel, the second one would already be halfway done by the time the first one failed.
• There's one place a human steps in. Before anything client-facing goes out, I look at it. A single line is easy to stand guard over. Four lines running at once is a lot harder.
• Each output is the next input. The brief feeds the estimate, the estimate feeds the SOW. Nothing gets invented halfway down because everything downstream is standing on something that already exists.

So the honest question wasn't "is parallel better." Parallel is obviously faster. The question was whether the thing I'd actually get faster was the thing that mattered, or whether I'd just be racing to the point where I couldn't tell what had gone wrong.

Once I stopped panicking and actually used it, the picture got clearer. Agent Teams is genuinely good at a specific shape of work: things that are independent of each other and don't share a source of truth. It's less useful, and sometimes actively risky, for work where step two depends on trusting step one.

The clearest way I can put it is the difference between things that are parallel by nature and things that are sequential by nature. A lot of what I do is the second kind, and no amount of clever orchestration changes that. You can't estimate work you haven't scoped. You can't review a build that doesn't exist yet.

That third row is a real project. I'm running a three-system integration right now, a marketing site, a HubSpot automation layer, and a checkout handoff, and those three genuinely don't depend on each other day to day. Each one has its own owner and its own surface. That's exactly the kind of thing where sessions running side by side, each holding its own context and reporting back, would save me actual coordination overhead. I don't need those three to wait in a line. I invented the line because a line was all I had.

So the thing I learned is that I'd been treating "sequential" as a property of my whole system, when really it's a property of each task. Some of my work is a chain. Some of it is a fan. I'd been forcing the fans through the chain because the chain was the only tool in the drawer.

The part nobody warns you about

One caution, because I hit it in the first afternoon. When sessions run in parallel and can write, they can also step on each other. Two of them editing the same file, two of them updating the same decision, two of them each convinced they hold the current version. This is the same problem I've spent years managing between people on multi-party projects, where three teams each have a different account of what was built. Parallel agents don't remove that problem. They recreate it, faster, and without anyone in the room to notice the two stories have drifted apart. The fix is the same as with people: one owner per thing, and a single place that holds the truth.

No. And also, a bit, yes.

I'm not rewriting the whole set to be parallel, because most of it shouldn't be. The gates, the read-before-write, the one human checkpoint, those aren't legacy baggage. They're the reason I trust the output enough to put my name on a client deliverable. Speed was never the constraint that was hurting me. Trust was. Agent Teams doesn't fix trust; if anything it asks more of it.

What I am doing is smaller and, I think, more honest. I'm going through them one at a time and asking one question of each: is this task a chain, or is this task a fan? The chains stay exactly as they are. The handful of fans, research spread across sources, independent tracks on a multi-system build, the boring stuff that only sits in a line because I put it there, those get to run as a team. The sequence stays the default. Parallel becomes something I turn to deliberately, for the handful of cases that actually fit it, not a new default I move everything onto.

If there's a lesson in this beyond my own two frameworks, it's that a new capability shipping is not the same as your existing thing being wrong. It's tempting to read every release as a verdict on what you already built. Usually it's just a new tool, with its own grain, and the work is figuring out which of your problems actually match it. Most of mine didn't. A few really did. That's a good outcome, and it's a much calmer one than tearing the whole thing down because a Slack message said "finally."

So here's what I keep asking: when a release makes your own work feel like the old way, do you rebuild on the spot, or go back and check why you built it that way in the first place?