Multi-agent systems are the dominant architecture for serious agentic products in 2026. A single LLM call cannot reliably plan, execute, and verify a complex task. The pattern that works is a parent agent that delegates to specialised sub-agents, gathers their results, and reasons over the aggregate. The architecture is sound. The UX is not solved.

Most teams shipping multi-agent products in 2026 default to one of two failure modes: surface every sub-agent in the conversation and overwhelm the user, or hide every sub-agent and force the user to trust a black box. The right answer is in between, and it is a design problem, not an engineering problem.

This guide walks through eight UX patterns for multi-agent systems, scored on a four-dimension rubric. Use the patterns to design your orchestration surface; use the rubric to grade what you ship.

TL;DR, the eight patterns are parent surface primacy, sub-agent cards, role labels, shared scratchpad, dispatch budget, parallel progress, aggregation transparency, and explicit handback.

The 8 patterns: a brief overview

• Pattern 1, Parent surface primacy: the parent agent owns the conversation, sub-agents never speak directly to the user.

• Pattern 2, Sub-agent cards: each sub-agent task is a collapsible card on the parent's plan with status and outputs.

• Pattern 3, Role labels: every sub-agent has a named role visible at a glance (researcher, writer, reviewer, executor).

• Pattern 4, Shared scratchpad: a visible artifact where agents post intermediate state, citations, and decisions.

• Pattern 5, Dispatch budget: a visible budget (time, tokens, cost) per dispatch, with a soft and hard ceiling.

• Pattern 6, Parallel progress: when sub-agents run in parallel, show their status side by side, not stacked.

• Pattern 7, Aggregation transparency: when the parent combines sub-agent outputs, show which input shaped which part of the result.

• Pattern 8, Explicit handback: when a sub-agent stalls, the handback to the parent is named, with context preserved.

Scoring matrix: grade your multi-agent UX on four dimensions

Score each pattern 1 to 5 on legibility (can the user see it), control (can they steer it), trust (do they believe it), and recovery (can it bounce back from failure). Sum out of 20.

1. Pattern 1, Parent surface primacy

Parent surface primacy is the rule that only the parent agent speaks to the user. Sub-agents do their work, return their result, and their outputs are surfaced through the parent's voice, not posted directly to the chat. This is the single most important pattern in multi-agent UX because violating it produces the "who is talking now" confusion that kills retention.

Claude Code is the cleanest reference. When the parent dispatches a sub-agent (a Task or Skill), the sub-agent's full conversation is folded into a single card on the parent's plan. The user sees a summary and can expand to see the detail. They never have to context-switch between agents.

Design moves

• One conversational thread: the parent's.

• Sub-agent outputs surface as cards or sections, not chat messages.

• Parent attributes sub-agent contributions in its own voice ("the researcher found X").

• Expandable detail for users who want to inspect a sub-agent's full trace.

• No "agent A, agent B, agent C" parallel chat tabs.

When to break the rule: simulation or debate-style products where the multi-agent dialogue is the point. Even then, label every speaker explicitly and constrain the surface.

2. Pattern 2, Sub-agent cards

A sub-agent card is the UI primitive that represents a single sub-agent dispatch on the parent's plan. It has a name, a role, a status, a result summary, and an expandable detail view. Cards are how you scale the conversation to N sub-agents without overwhelming the user.

Devin's session view is the strongest reference. Each parallel sub-task lives in its own card with live progress, and the parent agent's summary stitches them together. The card model also fits asynchronous patterns: dispatch, do other work, return to the card when it is done.

Design moves

• Card per dispatch with name, role, status, duration.

• One-line result summary visible without expanding.

• Full transcript on expand, including tool calls.

• Inline retry, cancel, and re-dispatch controls.

• Cards link to the artifacts they produced (file, doc, query result).

Anti-pattern: rendering every sub-agent's full transcript inline in the parent conversation. Even with N=3 sub-agents, that pattern doubles the message count and obliterates scannability.

3. Pattern 3, Role labels

A role label is a named function assigned to each sub-agent (researcher, writer, reviewer, executor, planner, critic). Role labels collapse "which agent is this" into a single chip the user reads instantly. LangGraph Studio is the canonical developer-facing example; for end-user products, the labels should be plain language rather than internal IDs.

Roles also constrain expectations. A "researcher" role implies retrieval and citation. A "reviewer" implies critique and accept/reject. A "writer" implies prose output. Users learn the vocabulary in one session and trust the system more because they can predict what each agent will do.

Design moves

• Limit roles to 4 to 7 named functions per product.

• Use plain-language names, not internal model IDs.

• Render the role as a chip on the sub-agent card.

• Tie tool access to role (the researcher has search; the executor has writes).

• Document each role in a one-paragraph spec the user can read on hover.

4. Pattern 4, Shared scratchpad

A shared scratchpad is a visible artifact (a doc, a sidebar, a workspace) where agents post intermediate state, citations, partial work, and decisions. It is the multi-agent answer to memory: instead of opaque internal state, the agents externalise their thinking into something the user can read.

Replit Agent's project workspace is a strong example. As the parent agent and sub-agents work, files appear in the file tree, the database schema updates, and the user can inspect the in-progress state at any point. Perplexity's Deep Research mode uses a similar pattern, surfacing retrieved sources into a panel as the agent gathers them.

Design moves

• Persistent scratchpad visible alongside the conversation.

• Agents post citations, partial outputs, and decisions to the scratchpad.

• User can edit the scratchpad mid-run and the agents incorporate the edit.

• Scratchpad persists across sessions as a project artifact.

• Distinguish agent-authored entries from user-authored entries with a chip.

5. Pattern 5, Dispatch budget

A dispatch budget is a visible ceiling on cost, time, or token spend per sub-agent dispatch. The budget is set per role (a researcher might get more retrieval calls than a writer) and surfaced as a progress bar or numeric counter. The pattern prevents runaway sub-agent loops, which is the most common cost surprise in production multi-agent systems.

The Anthropic Console exposes the primitives developers use to enforce dispatch budgets (max tokens, max iterations, timeout). For end-user products, the budget should be visible but not intrusive: a soft ceiling that warns at 80%, a hard ceiling that halts the dispatch with a routed handback.

Design moves

• Per-dispatch budget defined per role.

• Visible budget meter on the sub-agent card.

• Soft warning at 80% with the option to extend.

• Hard ceiling that halts and routes back to the parent or user.

• Aggregate session budget visible at the top of the conversation.

6. Pattern 6, Parallel progress

When sub-agents run in parallel, the UI should make the parallelism visible. The default vertical chat-style log hides parallel work behind sequential rendering, which makes a fast parallel system feel slower than a sequential one. The fix is a horizontal or grid layout when more than one sub-agent is active.

Devin shows parallel sub-tasks in side-by-side panels with live status. The user sees five things happening at once, which both communicates speed and lets the user dive into whichever sub-task is interesting. Replit Agent uses a similar pattern when running tests, building, and deploying in parallel.

Design moves

• Detect when more than one sub-agent is active.

• Switch to side-by-side or grid layout for parallel runs.

• Show per-sub-agent status indicators (running, complete, failed).

• Let the user collapse parallel cards back to a single summary when all complete.

• Animate the dispatch fan-out so the parallelism is felt, not just shown.

7. Pattern 7, Aggregation transparency

Aggregation transparency is showing the user which sub-agent's contribution shaped which part of the final result. Without it, the parent's synthesis feels like an opaque vote: three sub-agents researched, the parent decided, and the user has no idea who said what.

Perplexity Deep Research is the closest consumer reference. When the final answer is composed from multiple sub-searches, the citations link back not just to source URLs but to the sub-query that retrieved them. For multi-agent products, the equivalent is attributing each section of the parent's output to the sub-agent that contributed it.

Design moves

• Tag sections of the final output with the contributing sub-agent.

• Inline chips on hover ("from the researcher", "from the reviewer").

• Drill-down from the final output to the sub-agent's full trace.

• Show disagreement when sub-agents reached conflicting conclusions.

• Distinguish "synthesised by the parent" from "lifted from a sub-agent".

8. Pattern 8, Explicit handback

Explicit handback is the named, deliberate return of control from a sub-agent to its parent (or from the parent to the user) when the sub-agent cannot finish its task. Without it, sub-agents stall silently, hit a token ceiling, or loop until cancelled. The right pattern is to detect the stall, name it, and hand control back with full context.

Aider's coding agent and Cody's search routing both implement variants of this. The general rule: every sub-agent dispatch can resolve in one of three ways, complete, route to peer sub-agent, or hand back to parent or user with a reason.

Design moves

• Define stall conditions per role (no progress, repeated failures, low confidence, budget exceeded).

• Name the stall reason in the UI ("the researcher could not find sources for the claim").

• Preserve the sub-agent's full state on handback.

• Offer routed options: retry with broader scope, escalate to user, route to a peer.

• Aggregate stall reasons into product telemetry to identify role weaknesses.

Putting the patterns together: a worked example

Imagine a multi-agent product that helps a sales rep prepare for a discovery call. The parent agent dispatches three sub-agents: a researcher that pulls company data from web search and CRM, a writer that drafts a one-page brief, and a critic that flags missing or weak points in the draft. The whole workflow takes 90 seconds.

Pattern 1 says the conversation stays with the parent: the rep never sees three separate chat threads. Pattern 2 says each sub-agent surfaces as a card on the parent's plan, expandable on demand. Pattern 3 labels the cards "researcher", "writer", "critic" so the rep does not have to remember which model is which. Pattern 4 surfaces the shared scratchpad as a live brief that updates while the sub-agents work, with citations appended as they land. Pattern 5 caps the researcher at 30 web requests and the writer at 4,000 output tokens, visible as meters. Pattern 6 renders the three cards side by side because they run in parallel, and the rep sees fan-out animation when the dispatch fires. Pattern 7 attributes each bullet in the final brief to the sub-agent that produced it. Pattern 8 fires when the researcher cannot find a source for a claim and hands the gap back to the parent, which surfaces it to the rep as "this needs your input".

The product feels fast, legible, and trustworthy. The same architecture with no UX investment produces a long opaque loading state followed by a wall of text. Same model. Same tools. Same time. Completely different product.

How to apply this guide to your product

1) Are you running one parent agent or a flat agent committee?

Parent-and-sub-agent architectures are easier to design around because there is one conversation primacy point. Flat committees, where N agents debate as peers, are intellectually interesting but rarely scale to consumer UX. If you are committee-style, expect to invest twice as much in legibility patterns 1, 3, and 7.

2) Synchronous or asynchronous dispatch?

Synchronous dispatch (the parent waits for each sub-agent before continuing) is the simpler UX surface and maps to the eight patterns above directly. Asynchronous dispatch (the parent fires off sub-agents in parallel and aggregates later) requires patterns 5, 6, and 7 to land cleanly. Most multi-agent products start synchronous and graduate to asynchronous when latency forces it.

3) How many roles do you really need?

Four to seven roles is the working range. Three feels under-differentiated, ten feels like a taxonomy users will not learn. If your product needs more than seven, the right move is usually to collapse roles into broader categories with internal specialists, not to expose every specialist.

4) Where is your trust ceiling?

Trust ceiling is the maximum action the user lets the agent take without confirmation. For research and writing agents, the ceiling is high. For action-taking agents that mutate production systems, the ceiling is low. Pattern 5 (dispatch budget) and pattern 8 (explicit handback) are how you encode the ceiling into the UI.

If you are designing a multi-agent product and want a partner to translate these patterns into a shippable UI, that is what AY Design does. We have shipped orchestration surfaces for AI products that pass legal review and earn user trust on the first session. Book a design audit to see what to fix first.

FAQ

What is a multi-agent system?

A multi-agent system is an architecture where multiple LLM-powered agents collaborate to complete a task, usually with a parent agent that dispatches subtasks to specialised sub-agents. Claude Code, Devin, and Replit Agent are all multi-agent under the hood, even when the user only sees one conversation. The pattern is the dominant architecture for serious agentic products in 2026.

How is multi-agent UX different from single-agent UX?

Multi-agent UX adds three problems that single-agent UX does not have: which agent is speaking, who contributed to the final result, and how to manage parallel or async dispatch. The eight patterns in this guide are the working solutions. Single-agent UX can ship without any of them.

What is sub-agent dispatch?

Sub-agent dispatch is when a parent agent spawns a child agent with a scoped subtask, waits for the result (synchronously or asynchronously), and folds it back into its own plan. Claude Code, LangGraph, and Devin all implement this primitive. End-user UIs should render each dispatch as a single expandable card on the parent's plan.

Should I show every sub-agent to the user?

No. Surface sub-agents as collapsible cards on the parent's plan, not as parallel chat threads. The user should be able to drill into a sub-agent's full trace if they want, but the default view should be the parent's summary. This is parent surface primacy.

How do I prevent multi-agent systems from running up cost?

Set per-dispatch budgets defined per role (researcher gets more retrieval calls, writer gets more output tokens), show the budget as a visible meter on the sub-agent card, and define soft and hard ceilings. The Anthropic Console exposes the primitives for enforcing budgets at the API level; the UI primitive is the meter.

What is the best framework for building multi-agent systems?

LangGraph and the Vercel AI SDK are the strongest frameworks for multi-agent systems in 2026. LangGraph excels at complex graph orchestration with time-travel debugging via LangSmith. The Vercel AI SDK is lighter and better suited to web-app integrations. Choose LangGraph for orchestration complexity, the AI SDK for shipping speed.

How do I communicate parallel execution to users?

Switch from a vertical chat log to a side-by-side or grid layout when more than one sub-agent is active. Show per-sub-agent status indicators (running, complete, failed) and let the user collapse the parallel cards back to a single summary when all complete. Devin's parallel sub-task panels are the cleanest reference.

How do I handle disagreement between sub-agents?

Surface disagreement explicitly in the aggregation step rather than letting the parent silently pick a side. Show the conflicting conclusions, attribute them to the contributing sub-agents, and either let the parent resolve with stated reasoning or route the decision to the user. Hidden disagreement is the fastest path to lost trust in a multi-agent product.