The first time Claude Agent Teams really “clicked” for me was also the first time it got chaotic.

You spawn a few teammates, work starts moving in parallel… and then you realize you don’t actually have a simple answer to:

• who is working on what?
• who is waiting on me?
• where should I send the next message?

If you don’t solve that, teams don’t feel like leverage. They feel like scrolling.

This guide is the workflow I use to make Claude Agent Teams feel clear and predictable: clear routing, predictable check-ins, and a tight “attention loop.”

TL;DR

1. Treat Claude Agent Teams like a message routing problem, not a transcript problem.
2. Keep three “targets” in mind:
   • Lead (default)
   • a specific teammate
   • Broadcast (one message to the whole team)
3. Don’t guess where your message went: make routed sends explicit.
4. If you want a phone-friendly way to monitor teammates and send routed messages, Happier is one option that helps because it exposes a “Send to” recipient chip (Lead / Broadcast / teammate) and keeps a dedicated Agents roster.

The problem

Claude Teams is not hard because Claude can’t do the work.

It’s hard because humans lose track.

Once you have multiple teammates:

• the lead transcript is no longer the whole story
• you can miss the one teammate that’s blocked
• “send a quick correction” becomes ambiguous (to whom?)

So the real problem to solve is attention + routing.

What I tried first (and where I bounced off)

• Only talk to the lead: safe, but you lose most of the benefit of teammates.
• Scroll up and find the right teammate output: works, but it doesn’t scale.
• Use separate windows/tabs for each teammate: better, but it’s still easy to send the next instruction to the wrong place.

If you’re new to Happier

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) for coding sessions.

In this guide, the relevant part is simple: it gives you a UI for Claude Agent Teams where:

• teammates are visible as a roster ("Agents")
• the composer has a "Send to" recipient chip (Lead / Broadcast / teammate)
• routed sends are displayed as cards (so you can see where you sent the message)

Get set up:

• GitHub: https://github.com/happier-dev/happier
• Install/download: https://github.com/happier-dev/happier#how-it-works
• Discord: https://discord.gg/W6Pb8KuHfg

The Claude Teams mental model that keeps me sane

Lead

The lead is the default conversation.

If you send a message with no routing, it goes to the lead.

Teammate

A teammate is a specific Claude team member. Messages sent to a teammate should be explicit.

Broadcast

Broadcast is the “tell the whole team” channel.

In Happier’s implementation, broadcast is derived from your Claude team id and shows up as a routing target when a team is present.

A workflow that works

1) Pick 2–3 teammate “roles” you reuse every time

Teams get messy when every teammate is a one-off snowflake.

I keep a small set of reusable roles, and I reuse the same prompts each time.

My defaults:

• Reviewer (diff-focused, conservative)
• Tester (runs tests, tries to break assumptions)
• Refactorer (does the mechanical code movement)

You can absolutely add more roles (docs, triage, release-notes), but I’ve found that starting small makes teams easier to manage.

2) Create teammates with copy/paste prompts (so behavior is predictable)

When I launch a teammate, I give it:

• a role
• a scope
• a stopping rule
• and a checkpoint format

Here are prompts I’ve actually reused.

Teammate prompt: Reviewer

You are my reviewer. Your job is to find risks and inconsistencies.

Rules:

• Don’t make changes. Only review.
• Always start by summarizing what you think the goal is.
• Then list: (1) risks, (2) missing tests, (3) suggested diff improvements.
• If you’re unsure, ask one clarifying question.

Teammate prompt: Tester

You are my tester.

Rules:

• Don’t refactor. Focus on failure modes.
• Propose a minimal test plan first.
• Then run the plan (or explain exactly what you would run).
• If something fails, paste the exact failing command + error.

Teammate prompt: Refactorer

You are my refactorer.

Rules:

• Before changing anything, propose a 3-step plan.
• After each step, summarize what changed.
• Don’t touch migrations or auth unless I explicitly say so.
• If you need a risky change, stop and ask.

3) Use broadcast for global constraints (one message, everyone hears it)

Broadcast is great for constraints that should apply to the whole team:

• “Don’t touch migrations.”
• “Stop after the next step and summarize.”
• “If you’re about to run an install, ask first.”

Broadcast is not great for detailed tasks (“change file X, then Y”) because it creates mixed responsibility.

4) Route detailed tasks to one teammate at a time

When you want a teammate to do something specific, send directly to that teammate.

A tiny habit that helps: end the message with a required acknowledgement.

Example:

Ack with: what you’re doing now + what you’ll do next.

That makes it obvious if the message landed on the wrong target.

5) Use the Agents sidebar as your roster (this is the whole point)

Here’s the Happier-specific part that actually makes Claude Teams usable for me.

In a Claude team session, Happier surfaces an Agents roster in the session UI.

It gives you:

• Launch (spawn a new teammate)
• Active (currently running)
• Recent (finished / idle)

And each agent entry is a real “thing you can open,” not just a line in a transcript.

That means your workflow doesn’t start with scrolling. It starts with a roster.

The habit: when you open the session, open the Agents sidebar/pane first.

6) Open a teammate to see what it’s doing (without losing context)

From the Agents roster:

• tap/click a teammate

Happier opens that teammate’s view so you can see:

• its transcript
• its tool activity
• whether it’s waiting on you

This is what stops Claude Teams from turning into “find the right message in a long scrollback.”

7) Send a message to a specific teammate (not the lead)

In the message composer, Happier has a Send to recipient chip.

You can route the next message to:

• Lead (default)
• a specific teammate
• Broadcast (to the whole team)

Once you select a teammate, the message goes to that teammate.

This is the single biggest “teams UX” win in Happier: routing is explicit.

8) Use a “2-minute check-in” loop (especially on a phone)

The best phone workflow I’ve found is intentionally simple:

1. Open the session.
2. Open the Agents roster.
3. Find the one that needs attention.
4. Route one message (or broadcast one constraint).
5. Close the app.

If I try to do more than that on a phone, I start making low-quality decisions.

9) Learn how to verify routing after the fact

You want to be able to prove where your message went.

In Happier, routed sends are displayed as message cards with a clear recipient label (e.g. “To: Lead”, “To: Broadcast …”, “To: reviewer”).

That tiny UI detail is what prevents “I think I told the reviewer…” confusion.

Troubleshooting

A teammate is silent

Common causes:

• it’s still working (ask for a checkpoint)
• it’s blocked waiting for permission/input
• it went down a rabbit hole (send a stop + summarize)

A good rescue message:

Stop. Summarize what you did, what you were about to do next, and what you need from me.

Two teammates are doing the same work

This usually happens when:

• tasks were sent via broadcast instead of targeted routing
• the lead forwarded a task ambiguously

Fix:

• assign one owner (“reviewer owns review, refactorer owns edits”)
• broadcast the ownership rule once

Broadcast feels noisy

Broadcast should be constraints and coordination, not task assignment.

If you find yourself putting “do X” into broadcast, pull it back into targeted teammate messages.

FAQ

Should I always use three teammates?

No. Start with one.

Most of the value comes from:

• one reviewer teammate catching risks, or
• one tester teammate preventing fragile changes.

What should the lead do?

The lead is best for:

• coordination
• resolving conflicts between teammate outputs
• writing the final “do this” instruction for the main implementation thread

Common mistakes

• sending a targeted task to broadcast
• sending a global constraint to one teammate
• never asking for checkpoint summaries

Related guides

• How to tell which session is stuck