CrewAI, AutoGen, and role ontologies

CrewAI, AutoGen, and role-catalog runtimes like Swarm 357 all coordinate multiple model-backed workers. They differ in where the roles come from. CrewAI and AutoGen let you define agents when you define the task. A role ontology declares the roles up front, in configuration, and the task selects from them.

That sounds like a small distinction. It changes what you can govern.

The three shapes

Task-scoped crews. You describe a task, name the agents that will work on it, give each one a goal and a backstory, and run the process. Coordination is a property of the crew you assembled. This is CrewAI's centre of gravity, and it is genuinely fast to get moving with.

Conversation graphs. Agents exchange messages. Coordination emerges from who talks to whom and when, and the framework gives you the primitives for structuring that exchange. AutoGen is strongest here, especially for problems where the right sequence is not known in advance.

Role catalogs. Roles exist before any task does. Each carries a soul template with its standards, a tool grant, a model default, and a budget ceiling. A task routes to roles rather than instantiating them. That is what the 357 roles across six layers are in Swarm 357.

Criteria table

Read that table as a fit question, not a scoreboard. I use conversation-style coordination for research spikes where I do not know the shape of the answer. I use a catalog for the work that repeats.

The case for declaring roles first

Three things get easier when the role exists before the task.

Tool grants stop drifting. In per-task definitions, the same conceptual role gets defined a dozen times across a codebase, and the twelfth copy has one extra tool because somebody needed it once. With a catalog, research/market-analyst has one tool list, in one file, and changing it is a reviewable diff.

AgentConfig(
    name="research-market-001",
    layer=LayerType.RESEARCH,
    role="market_researcher",
    soul="templates/soul/research/market-analyst.md",
    tools=["WebSearch", "Read", "Write"],
    model="sonnet",
    budget_limit_usd=1.00,
)

Budgets attribute to something durable. Per-run cost tells you a task was expensive. Per-role cost tells you which function is expensive, which is the number you can actually act on.

Standards live in one place. The soul template carries how that role does its job. Improving the market analyst improves every market analysis, not just the next one someone writes.

The case against

I would be selling you something if I stopped there.

Catalogs are slower to start. You write configuration before you see output. For a weekend prototype that is the wrong trade, and I would reach for a crew.

A catalog can encode the wrong org. 357 roles is an opinion about how business work decomposes. If your work decomposes differently, you are fighting the ontology, and fighting an ontology is miserable.

Declared roles do not help open-ended problems. When you do not know which roles the problem needs, selecting from a list is a worse tool than letting a conversation find its own shape.

Nothing here removes review. No framework makes agent output trustworthy. It only makes it attributable.

The concurrency point that applies to all three

Whatever you pick, the failure mode is the same: unbounded fan-out. Crews, conversations, and layers can all spawn more workers than the problem needs, and every framework makes it easy.

Swarm 357 defaults to one agent per selected role under a hard agent cap, with full fan-out behind full_fanout or SWARM_UNSAFE_FULL_FANOUT, and a reserve-and-commit budget ledger underneath. If you use a different runtime, find its equivalent controls before your first production run. More detail in cost control for LLM agent fleets.

How to choose in five minutes

Ask three questions.

1. Do the same roles recur across tasks? If yes, a catalog pays for itself. If every task is bespoke, it does not.
2. Do you need per-role budgets and tool grants for a security or finance review? If yes, declare roles up front. Reviewers cannot audit definitions that only exist at call time.
3. Is the problem shape known? If no, use a conversation-first framework and come back to catalogs once patterns emerge.

There is a fourth answer that is often right: use one agent. If the task does not decompose, orchestration is overhead in every framework listed here.

Look at the catalog before you commit

pip install techtide-swarm
swarm init
swarm demo

Then read the roster overview to see how the six layers divide the work, core concepts for the vocabulary, and the comparison doc for the maintained version of this table. The status and maturity page says which parts are Stable before you rely on them.