Antigravity Teamwork vs Boost: Choose the Right Agent Workflow

Antigravity’s /boost is for difficult, bounded engineering problems. /teamwork is for projects that need milestones, an agreed specification and sustained coordination. Both use multiple agents, but choosing between them should start with the shape of your task rather than how impressive a research demonstration looks.

Google’s November 13 research update describes scientific and engineering work supported by Teamwork, alongside human experts and external checks. It is not the feature’s first announcement. The practical lesson is narrower than “agents can do research”: a candidate solution needs something capable of proving it wrong.

This is a documentation-based selection guide, not a hands-on comparison or a claim that either workflow will solve your repository’s problem.

Choose by task shape, not agent count

The Boost documentation distinguishes three workflows:

Workflow	Suitable task	How it starts
/boost	A subtle bug or tightly coupled refactor	Starts an iterative implementation and verification pipeline
/swarm	Work that splits into independent tracks	Starts coordinated parallel workers
/teamwork	A migration or research project with multiple milestones	Begins with a scoping interview

Boost and Teamwork are documented for paid plans in the Antigravity app and CLI; the comparison lists Swarm for Google AI Pro and Ultra. Boost works in the current workspace through separate agent contexts, so use an isolated branch or copy when you want to protect ongoing work.

For example, a cache occasionally returning another tenant’s result is a bounded but difficult investigation. Running several independent feature workers would not necessarily help: they could all misunderstand the same shared-state bug. Start with a precise reproduction target and ask for investigation before authorizing a fix.

By contrast, migrating the cache interface across several services involves ordering decisions, compatibility checks and a final integration pass. Even if each edit is simple, coordinating the whole change is a separate problem.

Make the Teamwork interview do useful work

The current Teamwork guide describes a reviewable prompt artifact before execution. The interview establishes requirements, independent checks, acceptance criteria and a dedicated working directory, normally under ~/teamwork_projects/. After approval, the team works through milestones with separate review and audit roles.

Do not rush through that interview by saying “use your best judgment” to every question. Decide which externally visible behavior must survive, which dependencies may change and what evidence would justify merging the result. Those decisions are much more expensive to recover after dozens of files have changed.

Here is an original starting brief for the cache migration example. It is a suggested prompt, not a tested run:

/teamwork Plan a migration of our cache wrapper to the new interface.
Preserve tenant isolation, expiration behavior and public responses.
Start by identifying callers and existing regression coverage.
Propose milestones and acceptance checks before changing code.
Keep production credentials and deployment outside this project.
Do not change the reference tests merely to make the migration pass.
Report separately what was tested, inferred and left unverified.

The useful output of that first conversation is a set of decisions you can inspect. “All tests pass” is too vague if nobody has established whether those tests cover expiration and tenant isolation.

Stricter verification can change the assignment

Teamwork documents three integrity modes: development, demo and benchmark. They constrain acceptable shortcuts differently; the strictest requires an independent implementation using only the language standard library. The selected mode is recorded in the prompt artifact.

That makes “choose the strictest mode” a poor default for ordinary product maintenance. If the intended migration relies on your existing libraries, prohibiting them changes the task rather than simply making its review more rigorous. Describe the shortcuts you want forbidden, and inspect the resulting constraints before execution.

For a performance claim, keep a benchmark outside the implementation’s control. For a migration, preserve a reference behavior test. For an exploratory design, ask a reviewer to identify unsupported assumptions rather than declaring a numerical score that nobody measured. The check should match the claim you plan to make.

Review the evidence, not the role names

A critic and an auditor are useful roles, but their presence does not guarantee that the chosen test measures the right thing. Before accepting a patch, inspect the changed files, executed commands and remaining failure cases. A second agent repeating the first agent’s conclusion is weaker evidence than a reproducible test that would fail on the original bug.

Use the lightest workflow that fits the problem. Escalate to Teamwork when coordination and acceptance gates become necessary, not merely because the task sounds important. More agents are worthwhile when they produce better evidence, not a longer account of how hard they worked.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain agent workflows and engineering decisions without turning them into marketing claims.

Book a 30-minute call