03 Two Architectures: Role-Based vs Handoff-Based (CRITICAL)

What You'll Learn

This resolves architectural confusion and sets your positioning.

What you'll learn:

ARCHITECTURE 1: ROLE-BASED (1 agent, multiple roles)

Shopping Agent:
├─ Discovery role: "Search for products"
├─ Evaluation role: "Compare options" 
├─ Commit role: "Execute purchase"
└─ Support role: "Handle returns"

Characteristics:

• Same agent, different modes/capabilities
• Context stays within one system
• Faster, more fluid
• Tradeoff: No natural boundaries, harder to audit

When to use:

• Low-risk tasks across lifecycle
• Speed is critical
• Single domain of expertise
• Trust in the agent's judgment

ARCHITECTURE 2: HANDOFF-BASED (Multiple agents, explicit handoffs)

Discovery Agent → Evaluation Agent → Purchase Agent → Fulfilment Agent

Characteristics:

• Different agents for different lifecycle stages
• Explicit context passing between boundaries
• Clear audit trail
• Tradeoff: Slower, requires coordination overhead

When to use:

• High-risk tasks (especially commit phase)
• Regulatory compliance required
• Professional accountability needed
• Multiple domains of expertise
• Accessibility critical

The Tradeoffs:

This course's position:

"We prioritize handoff-based architecture because that's where UX, safety, and accountability matter most.

At commit phase - where money moves, data changes, and legal liability kicks in - explicit handoffs provide:

• Clear decision points for human approval
• Audit trails for accountability
• Boundaries that prevent unauthorized actions
• Accessibility checkpoints for inclusive design

Role-based architecture has its place (discovery, evaluation), but this course focuses on explicit handoffs because that's where professional responsibility cannot be automated away."

This positioning gives you permission to:

• Not teach everything equally
• Focus on high-risk, high-stakes coordination
• Emphasize commit-phase patterns
• Position yourself in regulated industries (healthcare, finance, government)

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.