---
title: Topology selection
description: Which group topology, protocol, or ROMA solver to pick, and when team, hierarchy, or pipeline is a trap.
---

# Topology selection

`tnsai-coordination` ships eight `groups/` topologies. The trap is picking
the one that matches an org chart. For a **novel** problem that needs
continuous reasoning, that choice is usually wrong: each hop compresses
context, and the whole drifts even when every node looks fine in isolation.

The reasoning behind this page is in the wiki article
[Context Engineering vs Role-Based](https://github.com/TnsAI-Framework/TnsAI.Wiki/blob/main/Concepts/Context-Engineering-vs-Role-Based.md).
[Topologies](topologies.md) covers how each topology works. ROMA is a
recursive solver, not an organization spec; see
[Recursive task solver](recursive-solver.md).

## Decision matrix

| Task | Use | Avoid |
|------|-----|-------|
| Sequential deterministic stages (ETL, CI, triage) | `pipeline` | `network`, `matrix` |
| Independent parallel hypotheses (research, search) | `swarm`, `network`, or `RecursiveTaskSolver` (ROMA) | `pipeline`, `team` |
| One coordinator with known workers | `hubspoke` | `hierarchy` unless a supervision tree adds real gates |
| **Novel problem, reasoning must span the whole task** | **single agent + context engineering**, or ROMA | `team`, `hierarchy`, `pipeline` |
| Dynamic membership + consensus | [Council and voting](council.md) | `team` |
| Quality gate | [Judge](judge.md) | `team` with a reviewer role |
| Negotiation with incentives | [Negotiation](negotiation.md) | debate used as a market |
| Adversarial / sanity check | [Debate](debate.md) | council (council is consensus, not opposition) |
| Fixed steps with known dependencies | [Workflows](workflows.md) | a group topology |
| The same task sent to several agents | [Fan-out](fan-out.md) | `team` |

`coalition` and `matrix` are for dynamic alliances and multi-dimension
assignment. They are not a default for “we have several specialists.”

## When `team`, `hierarchy`, and `pipeline` fail

These three map onto the role-playing anti-pattern when the task is
**not** a repeatable workflow with deterministic stage boundaries.

- **Handoff compression.** A 50-line chain of thought becomes a 3-line
  summary at the next node.
- **Fake specialization.** `LEAD` / `REVIEWER` are prompt labels, not
  capacity splits. The same model sits behind each role.
- **Every node can pass while the whole drifts.** Isolated tests stay
  green, but the integrated answer wanders.

They are the right tool for ETL, approval chains, and other pipelines
whose stages have fixed contracts. They are the wrong tool for “figure
this research question out.”

For novel work prefer:

1. One `Agent` with tools, retrieval, and a verifier, with no group.
2. `com.tnsai.coordination.roma.RecursiveTaskSolver` when you need
   parallel decomposition plus a verification gate that is more than a
   handoff.

## When to choose ROMA

ROMA is the default multi-agent answer when:

- the task is **not** a pipeline with deterministic stages
- sub-problems can be explored independently
- you need a verifier that is not “the next role in the org chart”

Do not treat `RecursiveTaskSolver` as an org spec; the framework has no
organization type.

## Related

- [Topologies](topologies.md)
- [Recursive task solver](recursive-solver.md)
- [Workflows](workflows.md)
- [Auto team](auto-team.md)