Key takeaways
- An agent team: agents that message each other, not just a lead.
- Claude Code shipped it first, still experimental and feature-flagged.
- OpenCode and Codex have no shipped equivalent yet.
- Use a team only when parallel tracks must talk mid-task.
You keep hearing "agentic teams" and you have to decide whether to turn one on. The honest answer is narrower than the marketing. One harness ships this today, in an experimental state. The rest are catching up or silent. And a team is only worth the overhead in one specific case. Here is the map, and the rule you keep.
What an agent team actually is
"Agentic" just means software that plans and takes its own steps toward a goal, using tools, instead of answering one prompt and stopping. An agent team is narrower than that, and it is a vendor-defined term, not an industry standard.
In Claude Code, a team gives each teammate three things: its own persistent context window, a shared task list, and direct peer-to-peer messaging. Teammates claim tasks on their own and self-organize. They do not route every exchange through a single lead. That is the whole idea in one sentence.
This trips people up because the search results mix two layers. Questions like "what are the top 10 agentic frameworks" or "who are the big 4 AI agents" are asking about framework libraries, a different layer of the stack. There is no settled ranking or agreed "big four," so this page does not rank them. And "is ChatGPT agentic?" is a model question, not a team one: a chat model can act agentically when you give it tools or an agent mode, but plain chat just replies and stops. None of that is what an agent team means here. A team is a coordination feature inside your coding harness.
Agent teams vs subagents: where the bottleneck is
Most harnesses already let you fan out subagents. You give the main agent a job, it spawns helpers, each helper does a slice and returns a result. That works well when the slices are independent.
The limit is communication. Subagents cannot talk to each other. Every piece of coordination has to flow back through the main agent. For independent phases, that is fine. The moment your parallel tracks need to share a discovery, challenge each other's assumptions, or agree on a shared interface, the main agent becomes the bottleneck. Everything has to serialize through one mouth.
A team removes that specific bottleneck. Because teammates message each other directly, two tracks can settle an interface between themselves while a third keeps building. That is the one thing subagents structurally cannot do. If your work never needs it, a team is just more moving parts.
Which harness supports agentic teams right now
Here is the cross-harness picture, filled from primary sources and left blank where nothing is established.
| Harness | Agent teams shipped? | Run in parallel? | Peer messaging? | Shared task list? | Status |
|---|---|---|---|---|---|
| Claude Code | Yes | Yes | Yes | Yes | Experimental, feature-flagged, arrived early Feb 2026 |
| OpenCode | No | No | No | No | Sequential subagents today; proposals in flight |
| Codex | Not established | Not established | Not established | Not established | No published equivalent found in primary sources |
| Aider / Cline | Not established | Not established | Not established | Not established | No published equivalent found in primary sources |
Two of those rows are blanks on purpose. There is no primary evidence that Codex or Aider/Cline ship an agent-teams equivalent either way, so the honest entry is "not established," not a guessed row. If you rely on either, check its own docs before you assume a team feature exists. For a closer look at how these harnesses differ in day-to-day use, see how OpenCode stacks up against other harnesses and where Aider and Cline land.
Claude Code agent teams: what shipped, and the setup reality
Claude Code is the one harness with a real agent-teams feature today. It arrived in early February 2026, and it is experimental and feature-flagged, not a stable or generally available capability. Turn it on knowing it can move under you.
People have already put it on real work. One practitioner ran a team on an actual OAuth implementation the day the feature landed, treating each teammate as a full session rather than a throwaway helper. That is a fair example of the intended shape: several persistent agents working one codebase at once.
Two honest gaps. First, this page will not pin an exact version number. Version pins from secondary write-ups go stale fast and get misreported, so the responsible move is to check Anthropic's own release notes before you rely on the feature. Second, there is no separate "agentic teams login" and no published step-by-step setup here. Because teammates are full Claude Code sessions, they run inside the session you already signed into, not behind a new account. If you are searching GitHub or the web for a setup walkthrough or a Claude Code agent-teams example, the canonical thing to watch is Anthropic's release notes, which is where the flag, the state, and any config will be documented as they settle.
OpenCode agent teams: sequential today, proposals in flight
OpenCode does not have this yet, and it is worth being precise about why. Its task tool spawns subagents that run one at a time, return a result, and terminate. There is no built-in way for several agents to run in parallel, message each other, or coordinate on a shared task. On complex work, a multi-file refactor, research plus implementation, or review across concerns, you are limited to one agent at a time.
The demand is real and it is on the record. The project's own tracker carries a standing request for a Claude Code Agent Teams equivalent, alongside related issues #9649 and #6478, plus PR #7756, which proposes subagent-to-subagent delegation with a tree hierarchy. These are open proposals, not merged features. The tracker moves quickly, so treat this as the picture as of mid-2026 and expect it to change.
When a team is worth it, and how to tell it worked
Here is the rule to keep. Choose a team only if your parallel tracks must share discoveries, challenge each other's assumptions, or agree on interfaces while the work is running. If the tracks are independent and never need to talk, stay on subagents. They are simpler, cheaper, and easier to reason about.
A team is not free. It costs more context, more tokens, and real coordination overhead. Adopting one you do not need is a net loss, more output to review, not more done. So run a quick retrospective check after a job: did the teammates actually message each other and settle something between themselves, or did every decision still route through the lead? If it all funneled through one agent anyway, the work did not need a team, and subagents would have finished it with less noise.
One limitation to hold onto: this whole area moves monthly. Every capability and availability claim above should be re-checked against primary docs before you build a plan on it. A feature that is experimental today can graduate, change its flag, or ship a new interface next month.
Where rifty fits this decision
The harness-engineering read underneath all of this: adding autonomous teammates only helps if you keep control and reversibility. Otherwise a team is not leverage, it is a bigger pile of output for you to review. Real leverage is carrying your judgment forward intact, not generating more for you to check.
That is the work rifty does. It builds the harness layer that keeps agentic work legible, steerable, and reversible by default, so a team of parallel agents stays under one operator's control instead of drifting. When teammates can message each other and self-organize, the control layer is exactly what decides whether that is power or chaos.
Be clear on the fit. Rifty is by introduction only, built for operators running several companies from one seat, not for a solo developer who just wants Claude Code's feature flag turned on. If that is you, the vendor release notes are your next stop. If you are the operator who needs autonomous teams to stay reversible and under your hand, that is the conversation rifty is built for.