Claude Code Agent Teams vs. Antigravity Teamwork: how Codex and Copilot compare

AI coding tools are becoming team managers. Give them a job, and they can divide it among agents that investigate, write code, test, and review.

A helper can report back to one coordinator, or work as a teammate sharing progress with others. These two common arrangements explain the difference between subagents and agent teams:

Original EveryDev.ai diagram, informed by Anthropic's comparison. Both patterns can run in parallel. Some subagents can also message peers, and shared task features vary by product.

The difference is how they organize that work:

• Claude Code Agent Teams: teammates can talk directly, challenge ideas, and let you step into their conversations. Team guide.
• Antigravity Teamwork: supplies more of the project process—scoping, milestones, specialist reviewers, and final audits. Teamwork guide.
• Codex subagents: delegates focused jobs to specialists, follows up, and combines results. Subagent guide.
• Copilot's /fleet: dispatches independent tasks in parallel while tracking dependencies. Fleet guide.

Our take: try the tool you already use first. More agents help when work divides cleanly. The real win is reaching a result you can verify with less coordination effort.

These are recommendations based on official documentation checked on October 22, 2026. We haven't run a head-to-head benchmark of the four products.

What an agent team does

An agent is an AI assistant that can take actions toward a goal. A coding agent can read files, change code, run tests, and use the results to decide what to try next. It works through the tools and permissions you give it.

An agent team shares a larger assignment among several assistants. A lead keeps track of the goal, workers handle smaller jobs, and the system helps bring their results together. You could open several AI chats and pass answers between them yourself. These tools automate some of that organizing work.

Suppose you're updating the part of an online shop that receives orders. One worker changes the code. Another writes automated checks. A third makes sure the existing mobile app can still place an order.

In engineering terms, this could be an API migration: replacing the software behind the interface the mobile app uses, while preserving the behavior that app expects.

The division sounds straightforward. But the test writer could change what counts as a correct response to match the new code. Every check passes. Customers still can't place orders.

That is the challenge behind multi-agent coding: divide the work without letting the workers lose the original requirement.

Claude Agent Teams: let teammates discuss the problem

Claude's Agent Teams give you a lead and independent teammates that can message each other. The lead assigns work, manages dependencies, and combines findings. You can also talk to a teammate directly to inspect or redirect its work. How Claude coordinates a team.

For the shop, this is useful before you know what needs fixing. Orders sometimes time out. One teammate investigates database contention, another follows the request-handling code, and a third challenges their explanations.

Anthropic documents this competing-hypothesis approach. Instead of having everyone support the first plausible answer, give investigators different theories and ask them to try to disprove each other. Investigating competing hypotheses.

You also don't have to manually recruit every worker. Once the experimental feature is enabled, eligible named subagents become teammates, including when Claude chooses to name them itself. Teams can form during ordinary delegation. The behavior depends on the session and delegation path; it doesn't apply to every helper. How teams start.

You asked for a bug fix; your assistant has recruited colleagues. Claude handles their coordination, while you retain the ability to step in.

The trade-off is that the feature leaves more of the review process for you to define. You can assign independent reviewers and configure completion hooks—automated checks that can block a task from closing when tests fail. Anthropic also recommends monitoring teams and documents cases where workers or the lead stop too early. Completion checks, Team supervision.

Choose Claude Agent Teams when direct discussion between workers would help, especially for investigation, design review, and competing explanations.

Read next: The Race to Make Personal AI Work

Recommended

Recommended

The Race to Make Personal AI Work

I tried using the Instacart app in ChatGPT today. It didn’t really work. After spending more time on it than I wanted to, I gave up and did the shopping myself. I wanted it to work. Ordering groceries is exactly the kind…

Read next

Antigravity Teamwork: agree on the result, then work through milestones

Teamwork begins with a scoping interview. You clarify what should be built, how success will be checked, and what counts as finished. You review the resulting brief before execution starts. Teamwork's two-phase workflow.

For the shop migration, “replace the framework” isn't enough. The brief should also preserve order-confirmation responses, keep authentication working, and identify the compatibility tests the change must pass.

Google then supplies more of the delivery process. Its documented architecture includes workers, code reviewers, agents that probe failure cases, an auditor checking the integrity of test evidence, and a final success audit. Those roles address different problems: code can look reasonable, fail on an unusual input, or appear tested without the real behavior ever being exercised. Teamwork verification roles.

The process adapts to the job. Teamwork can distribute independent work across agents or use repeated implementation, testing, and revision for a tightly coupled problem. Google's engineering guide says team composition can change during execution; your prompt can also influence the selected approach. It isn't a fixed template that sends every assignment through an identical team. Adaptive patterns, Execution paths.

That structure helps when the assignment is substantial and you can define a convincing finish. The cost is more work agreeing on the brief. If you're still deciding what customers need, a detailed process can execute the wrong assignment thoroughly.

Choose Teamwork when you want a milestone-and-review process supplied, and the project is large enough to justify it.

Codex subagents: delegate specialist jobs and follow up

Codex can start specialist agents in parallel, send follow-up instructions, wait for their results, and combine their findings. You can request that division of labor in ordinary language. Custom configuration files aren't required to begin. Codex orchestration.

For the shop, ask one subagent to map the current order behavior, another to find compatibility risks, and another to review the migration plan. The main agent gathers their findings and carries the work forward.

Custom agents become useful when a role repeats. You might want the same security-review instructions or documentation-research specialist across projects, with an appropriate model and supported capability restrictions. That's a way to reuse your engineering process. Custom agents.

There is an important limit: custom agent files don't create an independent permission boundary. Codex documents that subagents inherit the parent's sandbox and approval settings. Asking a reviewer to avoid edits and technically preventing edits are different protections. Inherited controls.

Codex therefore already covers much of the basic coordinator-and-workers pattern. Calling its workers “subagents” doesn't make it a single-agent tool, or limit it to repetitive scripts.

Choose Codex subagents when you already work in Codex and want focused parallel investigation, implementation, or review, with reusable specialists where they help.

Copilot Fleet: dispatch independent work as it becomes ready

Copilot's /fleet lets the main agent break a request into tasks, track dependencies, and run suitable tasks in parallel. Planning first helps expose those dependencies, but /plan isn't mandatory for every Fleet request. You can invoke /fleet directly with a job. Fleet workflow.

For the shop migration, separate packages might be ready to update at the same time. A package that depends on a changed shared interface needs to wait. The useful feature is knowing which work can proceed and which work is blocked.

GitHub's SDK guide describes workers owning individual tasks and the parent dispatching work whose prerequisites are complete. It also advises avoiding overlapping file assignments and having the parent verify the combined result. Fleet coordination.

This fits a migration with independently testable pieces. It fits less well when several workers need to continuously debate one tightly coupled change; GitHub's guidance explicitly advises against Fleet for work requiring continuous shared reasoning. When Fleet fits.

The distinction is about how you divide the assignment. Copilot can use agents for research and review too.

Choose Fleet when you already use Copilot and can give each worker a clear, largely independent part of the job.

The same three problems follow every team

Different coordination styles still face the same engineering questions: did workers receive the right requirements, can their changes coexist, and does the finished result work?

Claude teammates and Antigravity subagents start without the parent's full conversation history, which helps keep investigations focused. It also means the old mobile client's requirements must reach the worker changing the service. Claude context, Antigravity context.

File ownership needs equal care. Claude's Agent Teams share the working directory; its separate worktree features aren't automatic teammate isolation. Teamwork makes exclusive file ownership part of its documented coordination. Fleet's guidance also warns about overlapping edits. Even with different files, two workers can disagree about the same interface. Claude file isolation, Teamwork ownership, Fleet practices.

For verification, return to the shop. Running the existing mobile client against the updated service is stronger evidence than letting the agents rewrite both the implementation and its definition of success. Google's systems-research examples use independent reference implementations for this reason. Those are provider-reported results, not a benchmark showing that Teamwork beats the other tools on your repository. Google's verification example.

An agent reviewer is useful. An unchanged compatibility test gives that reviewer something firmer to check.

Check the running conditions before handing off a long job

A busy screen doesn't establish stronger control, and a quiet screen doesn't establish cloud execution.

Claude's separate terminal panes are optional; its default view keeps teammates inside one terminal. Teamwork exposes progress and logs through its app and CLI. Google's original launch described Teamwork running on the local machine, which needed to stay awake. Check the execution mode before assuming work will continue after you close your laptop. Claude display modes, Teamwork monitoring, Original execution requirements.

Long work also needs a useful handover. Teamwork passes plans and progress to a fresh orchestrator between milestones. Claude Agent Teams keep the same lead, and resuming a session doesn't restore in-process teammates. That is a feature-specific limitation; Claude Code also offers other approaches to parallel and long-running work. Teamwork handoffs, Claude limitations, Other Claude approaches.

Permission and verification remain separate. Approving a Teamwork brief doesn't approve every tool action. Claude's teammate plans can be approved automatically or by the lead without human plan approval. Codex workers inherit the parent's permissions. None of those approvals establishes that the code is correct. Teamwork permissions, Claude plan approval, Codex controls.

Budget for the accepted result

Parallel workers do their own model work. Codex and Claude document increased token usage; GitHub warns that Fleet can consume more AI Credits; Google says complex tasks consume more quota. Finishing sooner can still use more resources. Compare total effort to an accepted result, including your review time. Claude usage, Codex usage, Fleet usage, Antigravity quota.

Access also differs. Claude Agent Teams are experimental, disabled by default, and require an interactive session. Teamwork remains a preview; Google's August announcement says it's available on all paid plans, broadening its original Ultra-only launch. Claude requirements, Teamwork availability.

For a small fix, ordinary delegation may be enough. Google also positions /boost for difficult interactive work, with Teamwork aimed at longer assignments. You don't need a project-sized process for every stubborn bug. Claude delegation choices, Boost versus Teamwork.

The verdict: start with the coordination you need

For our shop migration, we'd try Teamwork if the requirements are clear and we want milestones and independent verification built into the process. We'd try Claude Agent Teams if we're still investigating failures and want teammates to exchange and challenge explanations.

If we're already using Codex, its subagents are a sensible first choice for dividing investigation, implementation, and review. If we're already using Copilot and the work separates into independent packages, Fleet is a sensible starting point.

These are reasons to try each workflow, not proof that the others can't do the job. Documentation alone doesn't establish a universal speed, quality, or cost winner.

The migration succeeds when the existing mobile app can still place an order. Choose the process that makes that result easiest to establish.