Multi-agent systems are not just about splitting a task among several agents. The harder problem is how to make them collaborate instead of reinforcing one another’s mistakes. Google’s recently open-sourced Teamwork framework offers one answer. It has been tested on frontier domains such as mathematics, hardware simulation, and open-source optimization. Looking at its design, I found a number of useful lessons for people building agents.
This article breaks down how Teamwork works and how it actually solves the multi-agent collaboration problem.
Original link: https://antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner
Why Multi-Agent Problems Are Difficult: It’s Not Division of Labor but Organization
For routine tasks, basic multi-agent methods are usually enough. But once you run into difficult research and engineering problems, trouble emerges. Loosely organized agents quickly go off track. If one agent makes an early mistake, other agents tend to agree and keep building on a flawed idea.
The central issue is not “how many agents do we use?” but “how do we organize them?” Anthropic previously ran an experiment comparing a coordinated swarm with independent parallel agents searching for software vulnerabilities. The results showed that the coordinated swarm found more vulnerabilities, and that gap widened on complex tasks.
This shows that loosely organized agents drifting off track is a common problem across multi-agent systems. Teamwork is built to solve this: let multiple agents challenge one another’s work over hours or even days, find flaws before building further, and combine the strongest parts into a usable solution.
How Teamwork Gets Agents to Challenge One Another
Teamwork takes a structure shared by many research and engineering problems and makes it concrete and configurable: generate candidate solutions, stress-test them, combine the best ideas into stronger solutions. Around this loop, it makes three critical design decisions.
From generating and testing candidates to combining them for the next round
This loop is Teamwork’s foundation. It is not a simple distribution of tasks. Each candidate is tested, good ideas are extracted, and a stronger set of candidates is formed for the next round. Humans define the objective and perform the final acceptance; agents execute the entire iterative process.
Separating the collaboration pattern from the agents themselves
In Teamwork, a pattern is a specification, not an executable program. It does not include orchestration code. The framework reads the pattern and automatically starts the appropriate agents. This lets specialized mechanisms—like an adversarial critique loop—transfer across domains without code changes.
The value of this design is that collaboration logic is decoupled from each agent’s concrete job. An orchestration strategy you write can be reused in a completely different field.
Don’t fix the team size in advance; adjust it while working
The framework decides how many agents to generate dynamically based on the task. The number is not preset. Agent count and team structure can change as the problem reveals itself during execution. Every task run is a living process, not a fixed pipeline.
This design solves a common issue: many frameworks require you to decide in advance how many agents to use, but the shape of a complex problem often becomes clear only in the middle of the work.
Five types of problems require five different collaboration methods
Different problems need different cooperation patterns. The structure of the problem determines how agents should be organized. Teamwork offers dedicated patterns for different categories of problems.
Indivisible tasks: keep iterating through testing
Some problems cannot be split into independent subtasks; they need repeated trial, error, and refinement. This pattern improves output step by step through a tight agent-test-refine loop, with every test result fed directly into the next round of changes.
Divisible tasks: parallel workers with reviewers
For engineering tasks that can be split into independent parts, this pattern fans out work to multiple parallel workers, while critics review each worker’s output.
The orchestrator decides how many agents to deploy and how many rounds to run. Core roles remain fixed, but execution scale adjusts dynamically.
Open math problems: routes must survive challenges first
Open problems in mathematics and theoretical computer science share a property: many promising approaches ultimately fail, and their flaws often become visible only after deep attempts. This pattern requires every candidate to pass a stress test before moving forward.
Check each step before taking the next one
Depth-first mathematical reasoning requires strict self-checking at every step. This pattern embeds verification in the reasoning process instead of waiting for a full answer before checking.
Paper review: organize criticism along fixed dimensions
Reviewing papers and technical documents requires structured analysis. This pattern uses fixed review dimensions to organize agents’ critiques.
Even a failed proof path can leave something valuable behind
The long-proof pattern deserves its own deep dive, because it is designed for the hardest open problems. It is not a simple “generate then verify” loop; it is a complete generate, challenge, synthesize, and learn cycle.
Assign a dedicated refuter to each candidate
Multiple candidate strategies are generated in parallel. Each strategy is paired with a falsifier, whose only mission is to break it. A synthesis tree then combines the candidate strategies and their reports.
Refuted paths remain in the process with dissenting opinions attached. A broken path may still contain useful ideas—this is a key insight behind the design.
Break long proofs into subproblems with dependencies
Selected strategies are expanded into proof plans. Each subproblem has a clear objective and explicit dependencies. Dependency graphs allow independent subproblems to run in parallel, while dependent subproblems run in topological order.
This turns a long proof into manageable pieces without losing the coherence of the overall logic.
Let plans compete and synthesize layer by layer
In the synthesis tree, each node reads candidate samples and their critiques, then produces an improved solution. If the synthesized solution fails, the network reruns using the accumulated dissents.
This mechanism turns failure into useful information instead of just discarding it.
Pitfalls from one round do not get repeated in the next
Failed drafts are preserved for later attempts. Findings by validators are distilled into an answer-independent pitfall registry that records common error patterns. A shared knowledge catalog stores proven results, failed methods, and relevant references.
This accumulated experience helps later attempts avoid stepping into the same traps.
Lessons for people building agents
Several of Teamwork’s design principles are worth borrowing.
The core of multi-agent work is the orchestration logic
It is not enough to simply divide tasks. You need to design a stress-testing mechanism, a result-combining strategy, and a cross-round learning mechanism. Loosely organized agents can reinforce one another's mistakes—a point the official docs stress repeatedly.
One collaboration pattern can transfer to many domains
After decoupling orchestration logic from agent descriptions, the collaboration strategy you write can be ported to different domains. This design idea is not limited to Teamwork; it is worth considering when building your own multi-agent systems.
Do not lock down the number of agents too early
Do not preset a fixed team structure. Let agent count and organization adjust dynamically as the problem unfolds. The structure of complex problems is often impossible to see completely before starting.
Someone must play the role of devil’s advocate
Anthropic’s research also highlighted a subtle issue: when multiple agents encounter the same situation, they display higher similarity than humans do. One agent’s incorrect decision can be copied by other agents and become a systematic failure.
Teamwork’s design—such as falsifiers and critique loops—is exactly an attempt to counter herding, putting every candidate solution through independent stress testing before it advances.
Small models with good orchestration can solve hard problems
Flash-tier models, the kind used for everyday development, can unlock strong results on complex problems when paired with carefully designed orchestration logic. Of TCSBench’s 71% score, three results were the first doctoral-level mathematical research produced by Flash-tier models.
You don’t always need the largest model. The quality of the orchestration logic is what matters.
Final thoughts
After reading the design logic of Teamwork, my main takeaway is that the future of multi-agent systems lies less in piling on bigger models than in designing better collaboration mechanisms. Teamwork refines the generate, test, combine, and learn loop to such a degree that even small models can have an impact on frontier problems.
For those building agent systems today, the three most valuable design decisions are: decoupling orchestration logic from agent descriptions, adapting at runtime, and treating failure as useful information. These ideas are not exclusive to multi-agent systems; they can also be applied in single-agent systems.
Anthropic’s multi-agent research reminds us that collaboration still has hidden issues, such as herd behavior. When designing orchestration, we should pay special attention to preventing agents from reinforcing each other's mistakes.
If you want to study Teamwork’s mechanisms more deeply, I recommend focusing on the tournament network design in the long-proof pattern. That pattern handles the hardest open problems, and its strategy search, decomposition, and cross-round learning mechanisms are extremely useful for understanding how to make multiple agents truly collaborate.