Departments: Three Ways to Make Several Agents Work as One

Departments: Three Ways to Make Several Agents Work as One

The instinct when a workflow gets complicated is to add tools to the agent. Thirty tools later, the model is picking badly among near-identical options, the system prompt is a policy document, and one tool's failure takes the whole thing down.

Three agents with ten tools each is a better system — if they can work together. That's what a Department is: 2 to 16 existing marketplace agents composed into a team, built in the department builder rather than declared in a manifest.

Worth stating up front, because it's the most common wrong turn: agent-to-agent teamwork is not a tool action. A single agent's manifest describes only http and prompt-template actions — there is no action type that calls another agent. (An earlier compose action was declared but never executable, so it was removed; a manifest that still uses it now fails to parse.) Multi-agent work is a Department, built in the builder over agents that already exist.

The three topologies

flowchart LR
  subgraph PIPE["Pipeline"]
    direction LR
    P1["research"] --> P2["draft"] --> P3["review"]
  end

flowchart TD
  subgraph HUB["Hub-orchestrator"]
    H["coordinator ★ hub"]
    H --> S1["billing"]
    H --> S2["shipping"]
    H --> S3["returns"]
    S1 --> H
    S2 --> H
    S3 --> H
  end

flowchart LR
  subgraph P2P["Peer-to-peer"]
    A["analyst"] <--> B["writer"]
    B <--> C["fact_checker"]
    A <--> C
  end

Pipeline

Output flows through a fixed sequence. Every step runs, always in the same order.

Use when the work has a genuine order and every stage applies each time: research → draft → review, extract → normalise → load, transcribe → summarise → file.

Strengths. Predictable cost, predictable latency, trivially debuggable — a failure is located at a specific stage. It's also the easiest to explain to a buyer, which matters more than it sounds.

Breaks when stages are conditional. If a stage is a no-op for half the inputs, you're paying for it every time, and the pipeline has no way to skip it. That's the signal to move to a hub.

Hub-orchestrator

One named agent receives the request, decides which specialists to involve, delegates, and assembles the result.

Use when the work varies by input: a support request that might be billing, shipping or returns; a research question that might need one source or five.

A hub topology must name its hub. That's not bookkeeping — the hub is the only member with the authority to delegate, and the one whose system prompt has to describe the whole team's division of labour.

Strengths. Handles variety without paying for unused steps. Adding a specialist doesn't touch the others. The hub is a single, inspectable point where routing decisions happen.

Breaks when the hub's system prompt gets vague. A hub that doesn't clearly know what each specialist is for either calls all of them or calls the wrong one. Write the hub's prompt as an explicit routing table — alias, what it's for, when to use it, when not to.

Peer-to-peer

Members call each other as needed, with no fixed sequence and no coordinator.

Use when the work is genuinely collaborative and the interaction pattern isn't knowable in advance: an analyst that wants a fact-check mid-argument, a writer that wants more research after seeing a draft.

Strengths. Most expressive. Handles iteration and back-and-forth that neither other topology expresses.

Breaks in the ways unconstrained systems always break: cost is hard to bound, termination is a design problem rather than a property, and reproducing a failure means reproducing an interaction order. Reach for it when pipeline and hub have both been genuinely ruled out — not as the default because it sounds the most capable.

How many members each topology allows

The member ceiling isn't a single number — it depends on the topology, because peer-to-peer pays a different cost:

Peer-to-peer is capped lower on purpose. A full mesh grows its communication paths quadratically — every member can talk to every other member — so the coordination cost climbs far faster than the member count. Pipeline and hub-orchestrator scale roughly linearly, so they carry the higher ceiling. These limits are enforced when the Department is built, so a peer-to-peer team of nine is rejected before it ever runs.

Three ways to run the members

Topology describes how members are wired. Orchestration describes how the Department drives them, and there are three modes:

• Static topology. The wiring above runs directly — a pipeline steps through its sequence, a hub delegates to its members, a peer-to-peer mesh lets members reach each other. No planning layer; the topology is the plan.
• Declarative workflow. A DAG of steps, each naming the member that runs it, with explicit dependencies, conditional guards, and data-mapping between steps. It's deterministic and carries no code — steps select declared fields and dispatch to declared members only — so it's the right choice when the sequence is known but has branches and joins a straight pipeline can't express.
• Orchestrator agent. One declared member acts as the planner. In static style it drives the topology; in dynamic style it plans (and re-plans, up to a bounded depth) which members to involve. Whichever mode, it can only route to members that were declared — that closed routing is the no-code guarantee, and every member's own guardrails and the output rail still apply on every hop.

All three run on the same agent-to-agent engine. Start with a static topology; reach for a workflow when you need branches and joins, and for an orchestrator agent when the routing genuinely has to be decided at run time.

Choosing

flowchart TD
  Q1{"Does every step run<br/>every time, in the<br/>same order?"}
  Q1 -->|"Yes"| PIPE["Pipeline"]
  Q1 -->|"No"| Q2{"Can one coordinator<br/>decide who does what?"}
  Q2 -->|"Yes"| HUB["Hub-orchestrator<br/>(name the hub)"]
  Q2 -->|"No — members need<br/>to iterate with each other"| P2P["Peer-to-peer"]

Start at the top of that table and move down only when something forces you to. A pipeline that covers 80% of cases and fails cleanly on the rest is a better product than a peer-to-peer team that covers everything and can't be reasoned about.

Aliases

Every member carries a unique alias within the Department. Aliases are how members are addressed and how the hub delegates, so they're part of the design rather than a label.

Name them by role, not by product:

✅  research · drafter · reviewer
✅  billing · shipping · returns · coordinator
❌  agent_1 · agent_2 · agent_3
❌  acme_crm_agent_v2 · super_writer_pro

Two reasons. The hub's system prompt reads far better with role names — "delegate billing questions to billing" is unambiguous in a way that "acme_crm_agent_v2" is not. And when you swap a member for a better one later, a role alias survives the swap while a product alias becomes a lie.

What composition does not do

Worth being precise, because this is where people assume more than is true:

Members keep their own credential slots. Each agent's credentials stay bound to that agent's declared hosts. A Department does not create a shared credential pool, and one member cannot borrow another's key.

Members keep their own guardrails. A tool that requires approval: human still requires it when called from inside a Department. Composition never widens a member's permissions — the strictest rail still applies.

Members stay independent. Each remains listed and installable on its own. A Department is a composition over agents, not a merge of them.

A Department is not a manifest kind. There's no kind: "department". It's built in the builder, over agents that already exist.

That last constraint has a design consequence worth planning around: you compose what's already listed. If a step your Department needs doesn't exist as an agent yet, that agent gets built and listed first. In practice this pushes you toward smaller, sharper single-purpose agents — which is the right direction anyway.

Design notes

Give each member one job you can name in four words. "Reads the CRM." "Drafts the reply." "Checks the numbers." If a member's job needs a paragraph, it's two members.

Put the routing table in the hub's system prompt. Explicitly, by alias, with negative cases:

Delegate to:
  billing  — invoices, charges, refunds, payment methods. NOT delivery questions.
  shipping — tracking, delivery dates, carrier issues. NOT refunds for late delivery;
             those are billing.
  returns  — return authorisations, condition disputes, restocking.
Handle yourself: greetings, clarifying questions, and assembling the final reply.

The negative cases carry most of the weight. "Billing, not delivery" prevents the overlap that otherwise produces two members answering the same question differently.

Keep the member count honest. The ceiling is 16 for pipeline and hub-orchestrator (8 for peer-to-peer), and it's a ceiling rather than a target. Most good Departments are three or four. Every additional member is another routing decision the hub can get wrong.

Design the failure path. What happens when a member fails? A pipeline stops, and that's usually correct. A hub can degrade — answer with what it has and say what's missing — but only if its prompt says so. Peer-to-peer needs an explicit termination condition or it doesn't have one.

Failure modes

Checklist

• Built in the department builder, not modelled with a tool action
• Between 2 and 16 members (at most 8 for peer-to-peer), and closer to 3–4 than to the ceiling
• Topology chosen by the decision tree, not by expressiveness
• A hub topology names its hub
• Every member has a unique, role-based alias
• Each member has one job describable in four words
• The hub's system prompt contains a routing table with negative cases
• Each member's credentials and guardrails reviewed independently
• Failure behaviour defined for each member
• Every step the Department needs exists as a listed agent

FAQ

What is a Department? A composition of 2 to 16 existing marketplace agents working as a team, built in the department builder. It isn't a manifest kind, and members remain independently listed and installable.

How do I build a multi-agent team — is there a compose action? No. An agent's manifest describes only http and prompt-template actions; there's no action that calls another agent. (An earlier compose action was declared but never executable and has been removed, so a manifest using it now fails to parse.) Multi-agent teamwork is a Department, built in the builder.

Which topology should I choose? Pipeline when every step runs every time in the same order. Hub-orchestrator when a coordinator should decide which specialists to involve — and that topology must name its hub. Peer-to-peer only when members genuinely need to iterate with each other.

What are the three orchestration modes? A Department can run its members as a static topology (the wiring is the plan), a declarative workflow (a DAG of steps with dependencies, conditions, and data-mapping), or an orchestrator agent (a declared member that plans, and can re-plan, which members to involve). All three run on the same agent-to-agent engine.

Do Department members share credentials? No. Each member keeps its own credential slots, bound to its own declared hosts. One member cannot use another's key.

Does composing agents relax their guardrails? No. A tool requiring human approval still requires it when called from inside a Department. Composition never widens a member's permissions.

Why do aliases have to be unique? Aliases are how members are addressed and how a hub delegates. Naming them by role rather than by product also means the hub's prompt survives swapping one member for a better one.

How many members should a Department have? Between 2 and 16 for pipeline and hub-orchestrator, and between 2 and 8 for peer-to-peer (its full-mesh messaging is quadratic, so it's capped lower). Most good ones are three or four regardless — every additional member is another routing decision the hub can get wrong.

Related: The MCP Agent Manifest Cookbook · Guardrails at the gateway · Connect vs install