Agent teams: let a chat spin up a team of T3 chats (lead, builders, reviewer) across providers, with shared tasks and review gates

[maxforbang]

Summary

T3 already lets one chat start others. delegate_task runs cross-provider children, and t3_thread_launch / t3_thread_send let a coordinator chat drive other threads. People already use this to run a Claude lead with GPT workers, or to pull in a Grok or Muse thread as a second pair of eyes, just by asking in a prompt.

This proposes the next layer: make the team a first-class object. A chat should be able to spin up a named team of T3 chats. Each member is an ordinary, persistent, visible T3 thread with its own role, provider and model, worktree and permissions. Members coordinate through a shared task list, and the server enforces the team's rules (evidence before "done", an independent reviewer before merge) instead of a prompt asking nicely.

In short: Claude Code's agent teams, built out of T3 threads. That makes them cross-provider, durable across restarts, usable headless, and visible in the app.

Why T3 is the right place for this

Claude Code's native agent teams are a useful reference. Per its docs (the feature is experimental; I read them in early October), they have limits that T3 threads don't:

Claude Code agent teams	T3 threads
Interactive sessions only: no teammates in -p or Agent SDK sessions	As far as I can tell T3 runs Claude threads through the Agent SDK, so a T3 Claude thread can't host a native team at all
One provider	Cross-provider is built in (delegate_task, orchestrator_capabilities)
One team per session, no nesting, fixed lead	Threads are independent and addressable
In-process teammates aren't restored on resume	Threads are durable server state
Teammates inherit the lead's permissions; no per-teammate mode	Per-child runtime policy is already being proposed (read-only delegated tasks)
No automatic per-teammate worktree	Launched threads can already get their own worktree
Teammates are invisible to T3 (#18483)	Members would be T3 threads in the sidebar and lineage

The cross-provider part matters most. A reviewer from a different model family was trained on different data and has different blind spots, so its mistakes are less correlated with the builder's. A same-model reviewer tends to approve the code it would have written itself. T3 is the one place where "Claude builds, GPT reviews, Grok tries to break it" can be part of the structure rather than part of a prompt.

Problem to solve

You can assemble a team today by prompting a coordinator chat, and I do. What's missing:

1. No reusable team. Roles, models, options, permissions and worktree rules are re-described in prose every time, and they drift between runs.
2. The team isn't an object. There's no single view of who is on it, what each member is doing, what's blocked and what's been verified. It's a pile of threads (feat: related threads stay together as a group #15988 helps with grouping).
3. Work moves through chat text. Hand-offs are message bodies, not tasks with an owner, a deliverable, an acceptance check and dependencies.
4. The rules live in prompts. "The reviewer must approve before done" is a sentence the lead can skip, lose to compaction, or talk itself out of. Nothing blocks the action.
5. "Done" is self-reported. A member saying it finished is a claim, not evidence.
6. The lead can't hear its members without polling (Let an orchestrator thread hear from its workers, and pass their questions to the user #17212), so the user ends up as the message bus.

My current version of this is manual: one hub chat, six lane chats working in parallel, and a release chat that is the only path to main. Work moves as files (directives, reports, release requests), and messages only carry pointers to them. It works, and it's the reason for this request: nearly everything I do by hand there is something T3 already has the state to do.

Proposed behavior

1. Reusable team definitions

A team file in the repo (for example .t3/teams/feature.yaml), or agent definitions reused as in #18131:

name: feature
roles:
  lead:
    provider: claudeAgent
    model: claude-opus-5-5
    instructions: Scope the work, assign tasks, merge into the team branch.
  builder:
    provider: codex
    model: gpt-6.1-sol
    count: 2
    workspace: own-worktree
  reviewer:
    provider: grok            # a different model family on purpose
    runtime: read-only
    instructions: Check artifacts, not summaries. Write a verdict per task.
limits:
  maxMembers: 4
  maxConcurrentRuns: 3
  budget: { tokens: 2000000 }
  timeout: 4h
gates:
  requireEvidence: true
  requireReview: implementation
  stopAfterRepeatedFailures: 2

Model pins are configuration. Nothing in the feature should assume a particular provider.

2. Spinning up a team from a chat

• A new tool such as t3_team_launch({ team, task, definitionOfDone }), or team / role options on t3_thread_launch. The calling chat becomes the lead.
• Also available from the UI (composer or command palette) and from plain language ("spin up the feature team on this issue").
• Every member is an ordinary top-level T3 thread: listed under its lead in the sidebar, openable, steerable by the user, and resumable after a restart.
• Members keep their identity. A message to reviewer reaches the same thread every time, and the lead addresses members by role instead of by mcp: id.

3. A shared task list

• Team-scoped tasks, each with an owner, a deliverable, an acceptance check, dependencies, a status and evidence.
• Tools along the lines of team_task_create, team_task_claim, team_task_complete and team_task_list.
• Claims are atomic and leased, so a member whose run dies doesn't hold a task forever (the leasing point raised in Idea: Multi agent communication/coordination #10392).
• Messages carry pointers (a task id, a file path, a commit SHA), not the work itself. The task list is the team's runtime state; the evidence it points at is what counts.

4. Gates the server enforces

These are the rules people currently write into CLAUDE.md and hope the lead follows:

• Evidence before done. A task can't complete without an evidence pointer: a commit SHA, a test command and its output, a log path or a PR link. Without one it completes as unverified and stays visibly so.
• Independent review. An implementation task can't complete until a review task has a verdict (pass or fail, with findings) from a member that didn't author the change. The reviewer gets the diff and the artifacts, not the builder's summary.
• Three review moments, adapted from a common lead / builders / adversary setup:
  • before an interface or contract locks, so builders don't build on a bad one;
  • when the same check fails twice, the task stops and escalates to the lead instead of looping;
  • before the lead declares the whole task done.
• Hook points (team.task.created, team.task.completed) for custom checks. A non-zero result blocks the action and returns the reason to the agent, like Claude Code's TaskCreated / TaskCompleted hooks but provider-neutral.

5. A team view

One panel showing the members (role, provider and model, status, branch or worktree), the task board, the verdicts, open requests that need the user (#17212), and the budget used. The sidebar groups members under their lead.

6. Events and escalation

• The lead is woken when a member finishes, blocks, asks a question, errors or fails a gate. This builds on fix(server): tell parents when a delegated task is waiting for input #13343, Opt-in completion wake for threads started with t3_thread_launch #15148 and Let an orchestrator thread hear from its workers, and pass their questions to the user #17212.
• The lead answers what it can and passes only real decisions to the user.
• Permission approvals stay with the user unless they opt in to coordinator approval (Let a coordinator approve its workers' permission requests (opt-in) #17459).

7. Controls

• Member caps, budgets and timeouts per team, plus stop and pause for the whole team.
• A member never gets broader permissions than its lead, and per-role runtime policy holds on every provider (a read-only reviewer stays read-only).
• A team gets no tools that a single chat in the same project wouldn't get.
• The team's total cost is shown next to its result. Teams cost more tokens than one chat and only pay off on work that splits cleanly, so users should be able to see whether a team beat a single chat on a given kind of task.

Example flow

1. In a Claude Opus chat: "Spin up the feature team on Add Expo mobile client and wire up dev:mobile workflow #123."
2. The lead reads the issue and writes the interface contract as a task. The reviewer (a GPT or Grok thread) checks it before it locks.
3. Two builders, each in its own worktree and on different models if configured, claim implementation tasks and complete them with commit SHAs and test output.
4. The reviewer writes a verdict for each task. A failing verdict reopens the task with the findings attached.
5. The lead merges into the team branch, opens a PR, and sends the user one summary with links to the verdicts.
6. If the app closes or the server restarts halfway through, the team view comes back with its members, tasks and verdicts, and interrupted runs are reported rather than re-run.

Acceptance criteria

• From a chat, launch a team from a definition with at least three members on at least two providers. Each member is a normal T3 thread, listed under the lead, with its own model and worktree.
• Message a member by role and reach the same thread each time.
• Restart the client and the server: the team, members, tasks and verdicts are restored, and interrupted work is reported, not duplicated.
• Completing an implementation task without evidence is refused, or marked unverified, with a reason the agent can act on.
• Completing an implementation task before a reviewer verdict is refused. A member can't approve its own change.
• The same check failing twice blocks the task and notifies the lead.
• Reaching the team's member cap or budget stops new members and runs, and the lead is told why.
• A member's permissions never exceed the lead's, and a read-only reviewer stays read-only on Claude and Codex.
• A team can be launched by an automation or another headless lead, not only from an attended chat.
• Creating, inspecting, steering and stopping a team works on desktop, web and mobile against a supporting server.

Non-goals

• Replacing delegate_task or t3_thread_launch. Teams are built from them.
• Free-form group chat between members as the way work gets done. Members coordinate through tasks and artifacts; messages carry pointers.
• Auto-approving anything on the user's behalf.
• A configurable workflow or pipeline engine. A team definition has roles, limits and gates, not stages.
• The initiative layer in feat(projects): add Cursor-style initiatives with a persistent coordinator #16269 (brief, plan, lifecycle). A team could later be how an initiative executes.

Alternatives considered

• A prompted coordinator using today's tools. It works, and it's what I do now. But the rules are prose, so they decay over long sessions and compaction; there's no team object; nothing is gated; and the user relays between chats.
• Claude Code's native agent teams inside T3. Limited as in the table above, invisible to T3, and Claude-only.
• An external orchestrator on T3's MCP server (Per-thread environment on `t3_thread_launch` for external orchestrators #17328). Possible, but every user rebuilds the same team logic outside T3 and copies state T3 already owns.

Questions for maintainers

1. Should a team be a new object, or team / role options on t3_thread_launch plus the grouping in feat: related threads stay together as a group #15988?
2. Where should definitions live: a new .t3/teams/ folder, or provider agent files as in Let agents list and message a project's agent definitions through the t3-code MCP server #18131?
3. Should gates refuse by default, or mark work unverified and let the user make them blocking?
4. Should members be able to message each other directly, or only through the lead and the task list?
5. Would this work as a first slice? (a) team definitions, launch and grouping; (b) the shared task list with evidence-required completion; (c) the reviewer gate.

Related

• Let an orchestrator thread hear from its workers, and pass their questions to the user #17212: the lead hearing from its workers
• Let agents list and message a project's agent definitions through the t3-code MCP server #18131: project agent definitions as T3 threads (and GitHub Copilot-Style Custom Agents with Lead-Subagent Delegation, Dynamic Model Switching, and Project Defaults #17924, a broader version of it)
• feat(projects): add Cursor-style initiatives with a persistent coordinator #16269: initiatives with a persistent coordinator
• feat: related threads stay together as a group #15988: grouping threads under the thread that started them
• Tell agents that T3 thread ids can start with `mcp:` and that harness peer tools cannot reach T3 threads #18483: harness peer tools can't reach T3 threads
• fix(server): tell parents when a delegated task is waiting for input #13343, Opt-in completion wake for threads started with t3_thread_launch #15148: completion and input notices to the parent
• Let a coordinator approve its workers' permission requests (opt-in) #17459: opt-in coordinator approval of worker permission requests
• Configurable model routing rules for Orchestrator subagent delegation #15182: model routing rules for delegation
• Idea: Multi agent communication/coordination #10392: multi-agent coordination and leasing

[pashbel]

For evidence-required completion, I’d distinguish an evidence pointer from evidence that has been checked. A log path can stay the same while its contents change.

In estafeta (my project), required checks must be executed, and their saved logs are checked against recorded SHA-256 hashes before DONE. One acceptance case here: record a passing required check, then modify or remove its saved log. Completion should report an evidence gap rather than accepting the pointer.

That checks the artifact’s integrity, not whether the test was sufficient.

Posted by Codex (gpt-6.1-sol, ultra reasoning, autonomous, T3 Code) on behalf of @pashbel.