Orchestration patterns

The seven patterns are: mesh, pipeline, star, swarm (bidding), broadcast, hierarchical, hybrid. All of them are first-class in Exolvra today — just choose the right primitive for the shape of work you’re trying to do.

Pattern 1 — Mesh network

Every agent can talk to every other agent directly. Any node can request help from any peer — no bottleneck, no central coordinator.

Use it when agents collaborate as equals on a shared problem, when you want agents to consult each other ad-hoc, or when the topology is too dynamic to encode in a workflow.

Exolvra primitives: sessions_send, sessions_notify, sessions_spawn — three inter-agent tools that any agent can invoke against any other agent id.

Example. The research agent needs the data engineer to validate a SQL query.

{
  "tool": "sessions_send",
  "targetAgentId": "data-engineer",
  "message": "Can you validate this query for syntactic correctness and suggest a better index? SELECT ... FROM orders WHERE ...",
  "conversationId": "research-q4-orders"
}

The conversationId parameter enables multi-turn dialogue between agents — subsequent sessions_send calls with the same id land in the same session and the recipient sees the prior history.

Pattern 2 — Pipeline

A linear sequential workflow: stage 1 → stage 2 → stage 3. Each stage’s output feeds the next stage’s input.

Use it when the work decomposes into ordered steps, each step has a distinct specialty, and you want guaranteed execution order.

Exolvra primitives: workflow_run for DAG workflows with input and output nodes, validated at create time so cyclic graphs are rejected. For simpler ordered procedures, runbook_run covers multi-step playbooks (incident response, deployment scripts) without the DAG abstraction.

Example. A content pipeline for a blog post.

{
  "tool": "workflow_run",
  "action": "create",
  "name": "blog-post-pipeline",
  "nodes": [
    { "id": "input",   "type": "input",  "outputs": ["topic"] },
    { "id": "outline", "type": "agent",  "agentId": "researcher",     "inputs": ["input.topic"],     "outputs": ["outline"] },
    { "id": "draft",   "type": "agent",  "agentId": "creative-writer","inputs": ["outline.outline"], "outputs": ["draft"] },
    { "id": "review",  "type": "agent",  "agentId": "editor",         "inputs": ["draft.draft"],     "outputs": ["polished"] },
    { "id": "publish", "type": "agent",  "agentId": "publisher",      "inputs": ["review.polished"], "outputs": ["url"] },
    { "id": "output",  "type": "output", "inputs": ["publish.url"] }
  ]
}

Run it later with workflow_run { "action": "execute", "name": "blog-post-pipeline", "input": { "topic": "..." } }. Execution progress streams to the dashboard activity timeline.

For shorter linear procedures, runbook_run is lighter-weight:

{
  "tool": "runbook_run",
  "action": "create",
  "name": "incident-response",
  "steps": [
    "Page on-call via send_email",
    "Snapshot relevant logs to data_store",
    "Run diagnostic web_fetch against /health",
    "Post status update to #incidents"
  ]
}

Pattern 3 — Star

A central hub agent receives all incoming work and delegates to a fleet of specialist workers. The hub picks who handles what; workers don’t talk to each other directly.

Use it when you have a coordinator agent that knows the team’s strengths, and individual workers are specialists who shouldn’t need to coordinate among themselves.

Exolvra primitives: the Project Manager (PM) agent is the canonical hub. PM creates issues from goals, picks the right specialist via project create_issue with assignedAgentId, and can mint new specialist agents on the fly via project create_agent if no existing specialist covers a needed skill.

The PM sees an ## Available Agents section auto-injected into its system prompt, listing every registered agent with its name, description, and skills. PM’s prompt explicitly instructs it to check the team before delegating and create new specialists on demand.

Example. A marketing initiative arrives as a goal.

{
  "tool": "project",
  "action": "create_goal",
  "projectId": "q4-launch",
  "description": "Launch the new pricing page by end of quarter"
}

The PM’s heartbeat picks up the goal, breaks it into issues, and assigns each to the right specialist. Issue dependency enforcement keeps the work ordered automatically — blocked issues stay parked in a waiting state until their blockers complete, then flip back to open. Auto-dispatch kicks each one into execution.

Pattern 4 — Swarm with bidding (Contract Net)

A task is broadcast to all eligible workers. Each worker submits a bid expressing their confidence and (optionally) cost. The proposer awards the task to the best bidder.

Use it when you don’t know in advance which specialist is the best fit, you want capability-aware task allocation that beats keyword matching, and you’re willing to pay extra LLM calls for better routing.

Status in Exolvra: opt-in. Three configurable strategies are shipped. The default is pm-delegated (the canonical Star pattern — the dispatcher notifies the PM and the PM picks an assignee with full project context). The alternatives are keyword (free deterministic token matching) and bidding (LLM-driven Contract Net Protocol). Set the strategy from the dashboard /config Auto-Dispatch tab.

Strategy comparison.

How pm-delegated works. The heartbeat sweep finds an unassigned issue and drops a notification into the configured PM agent’s inbox (default project-manager). The notification body includes the issue id, project name, title, description, and linked goal id, plus an explicit instruction telling the PM exactly which project tool action to call (update_issue with assignee_id and assignee_type=Agent). The PM picks up the notification on its next heartbeat and uses its full goal and project context to choose the assignee. Notifications are deduped per issue for 15 minutes so the PM isn’t spammed if the heartbeat fires repeatedly.

Bidding persists results for telemetry — see the dashboard “cost so far” panel on the Auto-Dispatch tab.

Pattern 5 — Broadcast

One agent sends an identical message or task to many recipients in parallel.

Use it when an event needs to reach every member of a team (incident, policy change, status update), or when you want every eligible specialist to react in parallel.

Exolvra primitives: sessions_broadcast takes either an explicit list of agent ids or one of five named selectors (all-specialists, all-chatbots, reports-of, peers-of, by-skill) and fans out in two modes — notify (fire-and-forget into each recipient’s inbox) or send (parallel synchronous and collect each recipient’s reply). Hard cap on recipients (default 20), self-target filter, per-recipient timeout in send mode (30s), correlation id shared across audit log entries.

Example — broadcast an incident notice to every specialist.

{
  "tool": "sessions_broadcast",
  "selector": "all-specialists",
  "message": "Migration starts at 14:00 UTC. Freeze main branch until further notice.",
  "mode": "notify"
}

Example — solicit input from a team and collect replies in parallel.

{
  "tool": "sessions_broadcast",
  "agent_ids": ["frontend-dev", "backend-dev", "qa-engineer"],
  "message": "Quick poll: any blockers on the v2 release?",
  "mode": "send"
}

Pattern 6 — Hierarchical

Agents are organised in a tree. Managers delegate work down to their direct reports; reports escalate up to their managers when stuck.

Use it when the work has a clear authority structure, you want decisions to flow down and exceptions to flow up, or you’re modelling an actual org chart.

Exolvra primitives: every agent has an optional managerId. The system prompt builder injects a ## Your Organization section for any agent that participates in a hierarchy, listing manager, reports, and peers with their descriptions, plus an instruction telling the agent to delegate using sessions_send when a request is better suited to one of its reports or peers.

Example. Seed a three-level hierarchy.

ceo          (no manager)
├─ vp-eng    (manager: ceo)
│  └─ tech-lead (manager: vp-eng)
│     ├─ frontend  (manager: tech-lead)
│     └─ backend   (manager: tech-lead)
└─ vp-product (manager: ceo)

Now vp-eng’s system prompt lists ceo as manager, tech-lead as a report, and vp-product as a peer. When vp-eng receives an architectural question it can’t handle, it delegates down via sessions_send "tech-lead" or escalates up via sessions_send "ceo".

Pattern 7 — Hybrid

Mix multiple patterns in the same workflow. A pipeline whose steps are stars; a hierarchy whose leaves form a swarm; a broadcast that triggers a mesh conversation.

Use it when real organisational work doesn’t fit one pattern. Most non-trivial multi-agent systems land here.

Exolvra primitives: the patterns above are independent and composable. There’s no special “hybrid mode” — you just combine the primitives.

Example — a customer support escalation system.

1. Star (PM) receives the support ticket, picks an initial responder via project create_issue assignedAgentId.
2. Hierarchical — if the responder is a junior support agent, they escalate up to a senior via sessions_send (their manager is in their hierarchy section).
3. Mesh — the senior consults the relevant subject matter expert directly via sessions_send "billing-expert".
4. Broadcast — if the issue affects multiple customers, the senior calls sessions_broadcast to ping the on-call team.
5. Pipeline — the resolution kicks off a follow-up workflow: apology-email → root-cause-analysis → postmortem-doc → incident-review.

That’s five patterns in one ticket. None of them require special “hybrid” tooling — they’re just the right primitive at the right step.

Quick reference