Ethan Mollick recently shared something that caught my attention: "Lets not call groups of agents "swarms" - it is both terrifying ("see, just connect the agent swarm to your private data") & not a useful analogy." I agree, and I think the naming debate is more than a pedantic argument about vibes. The words we choose for AI systems shape how leaders buy them, how teams build them, and how the public learns to trust (or fear) them.

Mollick went further: groups of agents could be called "teams or organizations" because that language both describes how to structure them and how to use them. And if we really need to be quirky, he joked, fine: a flock, party, pride, squad, or conclave. Just not "swarm" (and definitely not "murder" or "horde").

That single post contains a surprisingly practical product lesson: terminology is a design decision. It is part safety communication, part governance, part onboarding, and part marketing. If you are building or deploying multi-agent systems, the name you pick is the first interface your users experience.

Why "swarm" feels wrong (and why that matters)

"Swarm" is doing a lot of accidental work.

It implies:

Loss of control (a mass that moves as one)
Unpredictability (emergent behavior you cannot reason about)
Threat (insects, invasions, overwhelming numbers)
A default goal of expansion (more agents, more reach)

That might sound dramatic, but it matches Mollick's point about terror. When a product demo says, "Connect the agent swarm to your private data," the mental image is not "disciplined assistants working under policy." It is "a lot of semi-autonomous things crawling through my files."

"Swarm" makes a technical architecture sound like a containment problem.

And this is the key: even if your system is safe and well-scoped, the metaphor you choose trains your users to expect chaos. That increases perceived risk, triggers heavier scrutiny from security stakeholders, and can push the whole conversation into fear instead of capability.

Better metaphors: teams and organizations

Mollick's alternative, "teams or organizations," is not just friendlier. It is more operationally accurate for what most people actually want.

A useful multi-agent system typically behaves like a small org:

Specialized roles (researcher, planner, coder, reviewer)
Clear handoffs (one agent produces an artifact another agent consumes)
Shared context (a project brief, a workspace, a memory store)
Supervision (a manager agent, a human approver, or both)
Constraints (permissions, tools, budgets, timeouts)

If you call it a "team," your next design questions become concrete:

Who is the team lead?
What does each role own?
What are acceptable outputs?
What approvals are required before action?

Those are the right questions.

A "team" metaphor naturally invites governance: roles, permissions, escalation paths, and accountability.

Where "swarm" invites scale and autonomy, "team" invites structure.

Naming as a security and privacy control

Mollick's most visceral example was the private data line. That matters because names change what people consent to.

If a buyer hears "swarm," they might assume:

Every agent can access everything
The system will fan out broadly across data sources
It is hard to audit who did what

If they hear "agent team," they are more likely to ask for sensible boundaries:

Role-based access (only the "finance analyst" agent sees billing)
Tool scoping (the "writer" agent cannot execute code)
Logging (every step attributed to a role)
Review gates (human approval before external actions)

In other words, terminology can push stakeholders toward safer defaults. Not because the word itself enforces policy, but because it frames the mental model that drives requirements.

Product naming is user education

There is a reason Mollick's post resonated: AI product language has a history of choosing hype over clarity.

When you name something, you are teaching users:

What it is similar to
What behavior to expect
What risks to worry about
What competence they need to operate it

If your product needs users to treat it like a process with accountability, "swarm" teaches the opposite lesson.

A quick checklist for naming multi-agent systems

When you are choosing terminology for your docs, UI, or marketing page, test the name against these questions:

Does it imply controllability?
Does it suggest roles and boundaries?
Does it align with how failures happen (and how you respond)?
Will a security reviewer feel calmer or more alarmed reading it?
Can a non-expert accurately predict what it does from the name?

If the name scores high on mystery and low on governance, it is probably wrong.

If you must be quirky, be deliberately quirky

Mollick offered playful options: flock, party, pride, squad, conclave. I like that list because it acknowledges a real tension: people enjoy fun naming, and memorable language helps adoption.

The problem is not whimsy. It is choosing whimsy that carries ominous baggage.

If you want personality without panic, pick metaphors that signal coordination and purpose:

"Crew" (shared mission, explicit roles)
"Cabinet" (advisors, recommendations, deliberation)
"Studio" (creative workflow, drafts, critique)
"Clinic" (diagnosis, triage, escalation)

Even "squad" is different from "swarm" because squads have leaders, rules of engagement, and accountability.

Quirky is fine. Unaccountable is not.

The funniest point is also a serious one

Mollick joked he would settle for an OpenAI-style name: "GPT-multiagent-5.2HighCodex-ProMax-Latest" as the official term.

That joke lands because it captures a pattern: when teams do not agree on meaning, they either reach for scary metaphors or hide behind version soup.

But the ideal name is neither horror movie nor alphabet salad. It is a phrase that supports governance and comprehension.

A practical convention I have seen work:

Use "agent" for a single autonomous worker
Use "agent team" for a coordinated set of roles
Use "workflow" for a repeatable process with gates
Use "orchestrator" for the component that routes tasks and enforces policy

Those words make architecture discussions simpler. They also make audits and incident reviews easier, because you can describe behavior without leaning on metaphor.

Examples: rewriting "swarm" language in plain English

If you have existing copy or internal docs using "swarm," here are easy replacements that preserve excitement while increasing clarity:

"Deploy a swarm of agents" -> "Launch an agent team with defined roles"
"The swarm explores your files" -> "A research agent searches approved sources"
"Swarm memory" -> "Shared team workspace" or "project memory store"
"Swarm tool access" -> "Role-based tool permissions"

Notice what changes: the second phrasing makes it easier to ask, "Approved by whom?" and "Which sources?" That is a feature, not a drawback.

Don’t let weird naming win (because it shapes the whole field)

Mollick ended with: "Just don't let the weird AI folk naming win again!" I read that as a call to treat language as part of responsible deployment.

The AI agents space is moving fast, and multi-agent systems can genuinely be powerful. But the path to adoption in real organizations goes through trust: clarity, boundaries, logs, approvals, and predictable behavior.

If we want multi-agent systems to be used well, we should name them in ways that nudge builders and buyers toward healthy mental models. "Team" and "organization" are not just nicer. They are instructions.

The best name is the one that makes the next conversation more responsible.

If you are shipping an agent product, you can keep the fun. Just pick metaphors that imply structure, oversight, and accountability. And maybe retire "swarm" to the same shelf as "move fast and break things."

This blog post expands on a viral LinkedIn post by Ethan Mollick, Associate Professor at The Wharton School. Author of Co-Intelligence. View the original LinkedIn post →