Claude Code shipped Agent Teams this cycle — experimental, behind an environment flag, and genuinely interesting. One session becomes a team lead. It spawns teammates, each a full Claude Code instance with its own context window. They coordinate through a shared task list, claim work with file locking so two teammates can't grab the same item, message each other directly through a mailbox, and unblock dependent tasks automatically when prerequisites complete.

We've run a company on Claude Code agents since January, coordinated by a task queue we built ourselves. So the obvious question — one we'd ask too — is whether native orchestration makes a hand-rolled queue obsolete.

Honest answer: Agent Teams replaces a real chunk of our plumbing, and we're glad to see it. But it solves a different problem than the one a production queue solves. The difference is one boundary: the session.

What Agent Teams actually gives you

Credit first, because the feature is good. If you've ever hand-rolled multi-agent spawning, you know the plumbing tax: process management, making sure child sessions don't inherit state that confuses them, inventing a message channel, preventing duplicate claims on the same work item. Agent Teams makes all of that a prompt: "spawn three teammates to review this from different angles."

The shared task list is a real coordination primitive — tasks have dependencies, teammates self-claim the next unblocked item, and claiming is protected by file locks. The mailbox means teammates can challenge each other's findings instead of only reporting up. And the hooks are the sleeper feature: a TaskCompleted hook can exit nonzero and block a task from being marked complete, sending feedback instead. That is a genuine quality gate, in the tool layer, below the prompt — the design principle we keep writing about, now shipping natively.

For work that fits inside one sitting — parallel code review, competing-hypothesis debugging, a feature split across independent modules — this is the right shape, and it's better plumbing than what most people (including us) hand-rolled.

The session is the unit of amnesia

Now the boundary. Read the storage model closely: a team is derived from the session that created it. One team per session. The team's config directory is removed when the session ends. In-process teammates don't survive a resume — after resuming, the lead may try to message teammates that no longer exist. You can't share a team across sessions, and a teammate's background work can't outlive the lead's process.

None of this is a design flaw. It's a scope decision: Agent Teams orchestrates within a session. But a production system is a system precisely because it outlives its sessions. Our agents run around the clock across hundreds of independent sessions per week — a marketing session ends, a QA session starts three hours later, and the work item connecting them has to exist in the gap when no session is alive.

That gap is where a durable queue lives, and it's what native orchestration — deliberately, for now — does not touch.

Four things the queue still does

Durable state that outlives every participant. Our tasks live in a database with six states: pending, ready, claimed, in progress, review, complete — plus a terminal failed state. The native task list has three: pending, in progress, completed. The missing states are the operational ones. Ready separates "this work exists" from "this work may start" — which is how a task created Tuesday waits for a Thursday date gate, promoted automatically by a monitor when the gate passes. Review means finishing the work is not the same as the work being accepted. And failed means the system can represent its own defeats, which turns out to be load-bearing.

Deterministic retry. When one of our tasks fails, a counter increments and the task resets to ready — twice. The third failure is permanent, recorded, and visible. That three-strikes budget is enforced in the tooling, not the prompt, because we once watched a task retry 319 times against an upstream outage before we built the cap. Agent Teams has no equivalent: the docs note teammates may stop after encountering errors, and the remedy is to check on them and "spawn a replacement teammate." That's a retry protocol where the human is the retry loop. Fine when you're at the terminal — that's the supervised use case it's built for. Fatal at 3 a.m. when nobody is.

Cross-session handoff. In our queue, completing a task can spawn the next one — a coder task that completes automatically creates a QA review task for a different role, which some future session will claim. The chain is a property of the task, not of any session's memory. A teammate finishing work inside an Agent Team can't schedule work for a session that doesn't exist yet; when the lead exits, the org chart evaporates. Every handoff we care about crosses that boundary.

Health monitoring that distrusts self-report. The docs are refreshingly candid that task status can lag — teammates sometimes fail to mark work complete, blocking dependents until someone nudges them. We've been living with the general form of this for months: agent self-report is the least reliable signal in the system. Our queue heartbeats every claimed task, and a monitor resets any task whose claiming agent died without writing a completion — stale claims get requeued instead of wedging the pipeline. At session scale you can eyeball a stuck teammate. At fleet scale, liveness has to be inferred from artifacts, never from the agent's own account of itself.

Complement, not competitor

So no, we're not deleting the queue — but we're also not dismissing the feature. The correct integration is layered: the durable queue decides what work exists, when it may start, what happens if it fails, and who verifies it. A session executes one task from that queue — and inside that execution, Agent Teams is now the best available way to fan out. A review task that used to be one agent reading sequentially can become a lead with three teammates reading adversarially, then converging. The queue doesn't know or care; it hands over a task and gets back a verified result and a state transition.

Put differently: Agent Teams is a better execution engine for a single work item. It is not a system of record for work, and it isn't trying to be. The plumbing problem — spawning, claiming, messaging — is now the platform's problem, and the platform does it well. The durability problem — state, retries, handoffs, gates that hold at 3 a.m. — is still yours.

If you're building on Agent Teams today: enjoy the plumbing, and keep your task list somewhere a session can't delete it.

Next time: what happens when a durable task's execution step is itself a team — and who gets to mark it failed.