02 Orchestration Patterns Across the Lifecycle

What You'll Learn

What you'll learn:

• Patterns don't belong to specific products
• Patterns belong to lifecycle moments
• The same system uses different patterns over time
• How patterns adapt as risk changes

Explicit teaching:"Patterns describe coordination behavior, not agent identity."

Example:A shopping system might use:

• Hub-and-Spoke for discovery (gather options from multiple sources)
• Sequential Handoff for commit (validate → process → confirm)
• Event-Driven for fulfilment (track → notify → deliver)

Same product, different patterns at different stages.

Title

Users should always feel like they are interacting with one unified assistant, not a swarm.

Why it matters:

• Multi-agent orchestration is backstage complexity.

• Users cannot track multiple autonomous actors.

• Fragmented personalities = loss of trust.

How to implement:

• Unify tone and voice across agents.

• Aggregate outputs into a single response.

• Never expose agent-to-agent conflict directly.

UX rule:

The system may be multi-agent.
The experience must be single-mind.

Title

Backstage = orchestration, coordination, retries, fallbacks.
Frontstage = what the user sees.

These must be intentionally separated.

Why it matters:

Backstage chaos (tool conflicts, re-planning, retries) is normal.
But if it surfaces to the user, it feels like:

• Bugs

• Glitches

• Inconsistency

• Lack of competence

How to implement:

• Mask retries behind concise status messages.

• Consolidate intermediate results.

• Avoid exposing internal failures unless action is needed.

UX rule:

Expose only what the user needs to see.
Hide everything technical, noisy, or irrelevant.

Title

A “smart” agent that behaves unpredictably is worse than a “dumb” agent that behaves consistently.

Why it matters:

Humans rely on mental models to interact safely with autonomous systems.
Multi-agent setups multiply unpredictability if not constrained.

How to implement:

• Enforce deterministic sequences where possible.

• Keep role boundaries strict.

• Prevent agents from improvising outside scope.

UX rule:

The user must always be able to predict the system’s next step.

Title

Users do not need to know internal orchestration mechanics — but they do need clarity about:

• What is happening

• Why it’s happening

• What will happen next

• Whether they can intervene

Why it matters:

Opacity leads to fear.
Over-explanation causes overload.

How to implement:

Provide:

• Short status messages (“Checking your calendar…")

• High-level action summaries (“Comparing travel options…”)

• Simple confirmations (“Should I book this?”)

Avoid:

• Technical agent role names

• Debug-style logs

• Tool invocation messages

UX rule:

Explain purpose, not mechanics.

Title

More agents = more automation = more risk.
Human override is non-negotiable.

Why it matters:

• Users must feel safe

• Designers must manage liability

• Automation can fail silently

• Multi-agent chains can escalate on their own

How to implement:

• “Stop” and “Undo” must be always visible.

• Ask confirmation before irreversible actions.

• Allow users to pause or reframe the task.

• Agents must yield when the user speaks or clicks.

UX rule:

Autonomy ends where user intention begins.

Title

Multi-agent systems fail in new ways:

• conflicting decisions

• state drift

• incomplete handoffs

• partial results

• silence

These must be planned for before designing any happy path.

How to implement:

Provide:

• graceful fallback (“Let me try another method”)

• safe decline (“I don’t know, here’s what you can do”)

• clear recovery (“Should I start over?”)

UX rule:

Errors should feel like detours, not disasters.

Title

You need to be honest without overwhelming users.

Bad transparency:

• “Worker agent #2 failed.”

• “The orchestrator retried 3 times.”

• “Tool call returned invalid JSON.”

Good transparency:

• “I wasn't able to complete that. Here are your options.”

UX rule:

Humans need context, not complexity.

Title

Accessibility must be designed into orchestration, not slapped on top.

Why it matters:

When multiple agents collaborate:

• Who handles alt text?

• Who ensures voice clarity?

• Who ensures safe phrasing?

• Who manages reading levels?

If not owned by anyone → nobody does it.

How to implement:

• Every agent must follow accessibility rules.

• Handoff must preserve accessibility metadata.

• Screen-reader experiences must not break on agent transitions.

UX rule:

Accessibility is a shared contract, not a feature.

Title

Multi-agent outputs can easily overwhelm users with:

• too many options

• too many intermediate steps

• too much information

Your job is to simplify, not impress.

How to implement:

• Collate results (e.g., show top 3 options)

• Summarize long-running orchestration

• Use progressive disclosure

UX rule:

Always give the user the minimum amount of information needed to act.

Title

Agents should not “freestyle.”
Each one must have:

• a clear scope

• a clear permission boundary

• a clear responsibility

Why it matters:

Role drift is one of the most common multi-agent failures.

How to implement:

• Define strict boundaries (“The payment agent never recommends products”)

• Use escalation instead of improvisation

• Apply the orchestration patterns consistently

UX rule:

Stable roles = stable experience.