Multi-Agent Teams

When a single agent isn't enough, the Multi-Agent tab runs many minds on one problem: a mix of cloud models, ACP peers, and hosted CLI tools working the same prompt together. Pick your participants, choose a subtype and a mode, and hit send — the run opens in a live discussion workspace with per-turn cards and a synthesized result. Approved plans can then execute as parallel fan-out across those same participants.

Two ways to go multi-agent. The Multi-Agent tab is for ad-hoc discussions, plans, and goals across a set of participants you choose per run. Teams (further down) are saved, named line-ups of specialized roles that collaborate in a fixed workflow — reach for a team when you want the same structured hand-off every time.

The Multi-Agent page

Open Multi-Agent and you get a composer much like the Dashboard's, with three extra decisions layered on top of the prompt box: who takes part, what the run should produce (the subtype), and how the turns flow (the mode). Attach files, folders, and images exactly as you would on the Dashboard — they're embedded as context lines that every participant sees on its first turn.

Pressing send opens a live discussion workspace. Each participant's contribution streams in as its own turn card, in order, and — if you set a moderator — a synthesis card closes out the run. The whole transcript is persisted on the parent task, so it survives restarts and reopens exactly where it left off.

Slash commands work here too: type / in the prompt box for a typeahead of built-in and custom commands, the same set available from the Dashboard and from listeners.

Choosing participants

Open the Participants dropdown and toggle the source button to build your line-up from three kinds of agent. Pick as many as you like — each is shown with its provider avatar.

Participant typeWhat it is
Cloud models Your full model catalog from every configured provider — searchable and filterable by provider. Put a Claude model, a GPT model, a Gemini model, and any OpenAI-compatible local server (Ollama, LM Studio, vLLM connected as a custom provider) in the same room.
ACP peers Other Aura instances — or any ACP-compatible agent — that you've discovered and enabled in Settings → ACP Agents. Peers are reached over the Agent Communication Protocol and contribute by delegation.
Hosted CLI tools Each coding-CLI tool Aura detects on the machine is surfaced as a peer with a slash-namespaced handle — e.g. aura-workshop/claude, aura-workshop/codex, aura-workshop/gemini, aura-workshop/cursor, aura-workshop/copilot, aura-workshop/qwen, aura-workshop/opencode, aura-workshop/kiro, aura-workshop/kilo, aura-workshop/vibe and more (17 auto-detected on PATH) — so you can drop a local coding agent into the discussion alongside cloud models.
Before peers show up. ACP peers only appear here once they've been discovered (over the local network on 18802/udp, or added manually) and toggled enabled in Settings → ACP Agents. Discovered peers start disabled by design, so you admit each one deliberately.

Subtypes — Discussion, Plan, Goal

The subtype decides what a run is for and what it produces.

SubtypeWhat it does
Discussion Participants exchange turns on the prompt. If a moderator is set, it synthesizes a summary at the end; otherwise the turns themselves are the output.
Plan Participants each contribute plan steps, and the moderator emits one approvable plan. You review it, and Start kicks off parallel fan-out execution (see below).
Goal The whole discussion re-runs until the moderator's verdict is ACHIEVED or BLOCKED, capped by the iterations cycler (default 5, clamped 1–8).

Goal here is the multi-agent cousin of the single-agent Goal mode on the Workspace: instead of one agent plus an LLM verifier, the entire roundtable repeats and the moderator renders the verdict each cycle.

Discussion modes

The mode decides how turns flow between participants. Roundtable, Debate, and Brainstorm are round-based (set the Rounds control, 1–5); Q&A and Research don't loop.

ModeBehaviour
Roundtable Each participant sees the prior turns and builds on them — collaborative, consensus-seeking.
Debate Same shared-history flow, framed as argument for and against so disagreement surfaces.
Brainstorm Same shared-history flow, framed for idea generation and breadth.
Q&A Independent answers — forced to a single round with no cross-talk, so each participant answers cold. Best for comparing unbiased takes.
Research Parallel fan-out: every participant researches at once, then the moderator's synthesis is the result. There's no round loop, so the Rounds control hides.

Rounds (1–5) apply only to Roundtable, Debate, and Brainstorm — the modes that iterate over shared history. Q&A is always a single independent round, and Research is a one-shot parallel sweep.

The moderator

The Moderator picker is single-select and optional. It can be a cloud model or an ACP peer — set it to None to skip synthesis entirely and keep just the raw turns.

What the moderator does depends on the subtype and mode:

  • Discussion — writes a closing summary that synthesizes the participants' turns.
  • Research — its synthesis is the deliverable; the parallel research turns feed straight into it.
  • Plan — reconciles everyone's proposed steps into the single approvable plan you then execute.
  • Goal — renders the per-cycle verdict (ACHIEVED / BLOCKED) that decides whether the discussion repeats.

Plan → parallel fan-out execution

A Plan run ends at a plan-review gate. Approve it and press Start, and Aura assigns the plan's steps across your participants and runs them in parallel batches: independent steps run concurrently, while steps that depend on earlier ones wait their turn.

  • How each participant runs a step — cloud participants run as child agent tasks with the full toolset; ACP participants run their step via delegation to the peer.
  • Pre-flight before executing — Aura checks every participant first (validates cloud credentials, pings peers) and surfaces any failures with fix links, so a misconfigured provider or unreachable peer is caught before the run rather than mid-way.
  • Per-step retry — a single failed step can be retried on its own, without re-running the whole plan.
Watching a wide run. When several steps execute at once, the workspace shows each running participant as its own card with live status and progress, so a five-wide batch reads as five parallel cards rather than one opaque spinner.

Fan-out execution is the multi-agent path to parallelism you drive by hand. For unattended, branching automation with approvals and backoff, use the visual workflow editor instead — its fan-out, merge, and acp_fanout nodes cover the same ground on a schedule or trigger.

Teams & the role library

A team is a saved, named line-up of specialized roles that collaborate in a fixed workflow. Where a Multi-Agent run is assembled fresh each time, a team is reusable: define it once, then run it (or target it from a slash command, schedule, or workflow) to get the same structured hand-off every time.

Roles

A role is a markdown system prompt with YAML frontmatter declaring its allowed tools, an optional dedicated model, expected outputs, and a max_turns cap. Roles resolve project → user → bundled, so a project can override a shared role. You attach a single role to any ordinary task via the composer's role picker, or compose several into a team.

Per-role model selection lets you spend deliberately — a small, cheap model for routine roles (initial research, formatting) and a stronger model for the critical ones (architecture, review). A role with no model set uses the globally selected model.

How team members collaborate

WorkflowBehaviour
Sequence Roles run one after another; each receives the previous role's output as context. Hand-offs are explicit — a role calls the role_complete tool to pass structured data (summary, files created, key decisions, constraints) to the next role.
Parallel All roles run simultaneously and their results are merged at the end.
Fan-out / merge A source role produces a list of sub-tasks, which are distributed to parallel worker roles, and a final role merges the results.

On file conflicts, parallel and fan-out results are combined by a configurable merge strategy: copy-on-write (safe, no data loss), last-wins (the last writer prevails), or an LLM merge that reconciles conflicting changes intelligently.

The role library

Aura Workshop ships a library of built-in roles you can drop into teams, grouped by discipline. Each carries a pre-written system prompt and a curated tool set.

CategoryRoles
SoftwareProduct Manager, Architect, Developer, QA Engineer, DevOps
ContentResearch Lead, Writer, Editor
BusinessBusiness Analyst, Marketing Strategist, Sales Copywriter
DataData Engineer, Data Analyst, Data Scientist
DesignUX Designer, UI Designer
OperationsProject Coordinator, Technical Writer, Security Auditor, Code Reviewer

Create, edit, duplicate, or delete roles under Settings → Roles & Prompts. Each has a name, description, system prompt, and a checkbox set of allowed tools; roles are stored as markdown files so they're easy to version and share across projects.

When to use which

  • Roundtable / Debate across a Claude model, a GPT model, and a local model → surface a design decision with real disagreement, then a moderator recommendation.
  • Q&A → get truly independent answers to compare, with no groupthink.
  • Research → split a literature or codebase survey across N agents and get one merged brief, fast.
  • Plan → let several models co-author a build plan, then execute it in parallel with per-step retry.
  • Goal → keep the roundtable going until the objective is verifiably met (or blocked).
  • A team → when you want the same specialized line-up and hand-off every time — a repeatable pipeline rather than a one-off discussion.
Related reading. Single-agent task modes live in Workspace & Tasks; self-paced loops in Autonomous Agents; triggers, workflows, and team-targeted slash commands in Automation & Workflows.