Multi-agent orchestration for designers

When a task is simple, one agent is enough. When it’s complex, a single agent fails: hallucinates, loses context, contradicts itself. The fix is to split the work across specialist agents and orchestrate the collaboration.

Cheaper in tokens. Easier to control quality. More resilient to hallucination. And, crucially for us, with very specific UX implications that change with the orchestration pattern you pick.

Why multiple agents instead of one

Picture a single agent that has to know everything about a company: product, support, billing, compliance, design, code. Its context window fills with rules competing against each other. Hallucination probabilities spike.

When you split the same work across specialist agents (one for support, one for billing, one for design), each gets a tighter context, fewer rules, fewer tools. Quality goes up and cost goes down, because calls to models with smaller contexts are cheaper.

There’s almost always a side benefit: each agent can use the right model for its complexity level. Trivial tasks run on small fast models; complex tasks run on big ones. Using Claude Opus to reformat a string is waste.

The seven orchestration patterns

1. Sequential. One agent after another. A’s output feeds B. Example: design agent produces mockups, accessibility agent reviews, engineering agent generates code. Simple pattern, easy to explain. UX implication: linear progress, easy to show as a timeline.

2. Parallel. The agent duplicates itself to handle parts simultaneously. Example: Claude Code, processing many files, opens sub-agents that read in parallel and merge results. UX implication: simultaneous progress. Multiple cards advancing at once. Asks for a way to show concurrent work without overwhelming.

3. Hierarchical. A supervisor delegates to specialists. Example: you talk to Julia (supervisor); Julia decides whether to call the search agent, the comparison agent, or the filter agent. UX implication: the user talks to one persona but sees results from several. The temptation is to hide; the better move is light attribution (“I used agent X for this part”).

4. Hand-off. The supervisor routes by request type. Each flow goes to its agent and stays there. Example: a billing question goes to the billing agent and lives there. UX implication: transitions need to be smooth. The user might think they’re talking to the same person when, in fact, the conversation has changed hands. Confirming the transition in microcopy helps.

5. Swarm. Multiple agents negotiate in real time, no clear hierarchy. Useful for dynamic problems. UX implication: real-time edits, mid-flight adjustments, messages from multiple sources. Hard to visualise; calls for a strong metaphor (rods floating, agents in private conversation).

6. React (reasoning + acting). The agent thinks, acts (uses a tool), observes, adjusts. More a pattern of execution than coordination, but it composes with any of the others. UX implication: show thinking and action as separate steps. Claude Code does this well, with “thinking” then “acting”.

7. Magentic. Dynamic orchestrator that adjusts the plan as it goes. Combines elements of hierarchical with swarm: there’s a plan, but it’s redrawn in real-time based on observation. UX implication: asks for a status system that survives mid-flight plan changes.

How orchestration choice changes the interface

Each pattern asks different things of the interface. Three critical decisions:

Attribution. In hierarchical and hand-off, should the user know which agent is answering? My default answer is “yes, lightly”. Not a different avatar each time, which is exhausting, but a subtle reference: “I checked this with the billing agent”. Builds trust and helps debugging when something breaks.

Progress. In sequential, a timeline is enough. In parallel, you need to show concurrent work. In swarm, showing progress in the traditional sense is almost impossible, and the best move is to abstract (“agents working, 3 conversations underway”).

Control. In sequential and hand-off, the user can pause easily between stages. In parallel and swarm, pausing is more complex and asks for design decisions: pause all sub-agents? Only the main one? Design has to make this explicit.

A concrete example: conversational restaurant discovery

Picture a conversational restaurant discovery powered by AI. The system uses a hierarchical pattern with hand-off by flow. A supervisor (call it Planner) takes the user’s query and decides the right flow. When the flow is finding a meal, it hands off to a guided-search agent, which has its own tools for filtering by cuisine, distance, dietary restrictions, and ranking.

The choice isn’t for architectural elegance. It’s practical: separating search lets each prompt stay focused, hallucination stays controlled, and costs stay predictable. Each agent can have its own model, its own prompt base, its own speed.

From a UX perspective, the transition is invisible to the user, who stays in the same conversation. But the team preserves attribution internally for debugging, observability, and evolving each agent’s rules.

What this asks of you as a designer

Three new competences:

1. Read an orchestration diagram. Even if you don’t draw it, you’ll work shoulder to shoulder with data science and engineering on agent flow diagrams. It’s the new flowchart.
2. Decide the level of transparency. How much of the orchestration do you show the user? How much do you hide? No universal answer. Depends on product, user, market maturity.
3. Map break points. In hand-offs, in swarms, in parallels, there are always moments where the system can feel confusing. Those are your moments of truth.

More on the background in the Design for AI guide. On giving transparency to what each agent is doing, see Observability in agentic UX.