1. Sequential Handoff

Sequential Handoff is the simplest coordination pattern: Agent A completes its task, then hands off to Agent B, which completes its task and hands off to Agent C.

It's a linear flow where each agent completes its task before handing the result to the next agent in sequence.

Each step depends on the previous one.

This pattern is deterministic and predictable. You always know what happens next.

Agent A → Agent B → Agent C → User

When to Use It

Use Sequential Handoff when:

  • Each step depends on the previous step completing
  • You need predictable, ordered execution
  • Each agent has a clear, distinct responsibility
  • The process has a natural linear flow
  • You want simple, easy-to-understand coordination

Examples:

  • Shopping → Payment → Delivery
  • Document upload → Processing → Storage → Confirmation
  • User request → Authentication → Authorization → Action
  • Booking → Confirmation → Notification
  • You want simple, easy-to-understand coordination

When NOT to Use It

Don't use Sequential Handoff when:

  • Steps can happen simultaneously (use Parallel Coordination instead)
  • The order might change based on conditions (use Conditional Handoff instead)
  • You need different agents for different request types (use Hub-and-Spoke instead)
  • Speed is critical and steps are independent (parallel is faster)
  • One slow agent will block the entire process

Wrong use cases:

  • Searching multiple travel sites (should be parallel)
  • Routing to different specialists (should be conditional)
  • Real-time bidding (should be auction pattern)

Frontstage: What the User Sees

The user sees a clear progression through stages.

Example: Shopping Agent → Payment Agent → Delivery Agent

What user experiences:

  • Clear status at each stage
  • Visible transitions between agents
  • Progress indication
  • Final confirmation with all details

Backstage: What the Agents Do

Behind the scenes, three specialized agents coordinate sequentially.

Agent A: Shopping Agent

  • Receives user request "buy me that book"
  • Searches 10 online retailers
  • Filters by stock availability and shipping options
  • Selects best price (ÂŁ15.99 from Amazon)
  • Prepares handoff package including: Product details (title, ISBN, price), Merchant information (Amazon), User context (ID, shipping address, accessibility needs)
  • Hands off to Agent B
  • Status: COMPLETE

Agent B: Payment Agent

  • Receives handoff from Agent A
  • Validates user has saved payment method
  • Checks sufficient funds/credit available
  • Processes payment transaction
  • Receives confirmation code from payment processor
  • Prepares handoff package including: Transaction ID, Amount charged, Payment method used, Order ID
  • Hands off to Agent C
  • Status: COMPLETE

Agent C: Delivery Agent

  • Receives handoff from Agent B
  • Calculates delivery date based on user address
  • Coordinates with merchant's shipping system
  • Confirms delivery for Friday
  • Generates tracking number
  • Returns complete confirmation to user
  • Status: COMPLETE

Critical handoff data:

  • Agent A → Agent B: Product details + user context + accessibility needs
  • Agent B → Agent C: Transaction confirmation + order details + delivery requirements
  • Agent C → User: Complete delivery information + tracking

Service Blueprint

The service blueprint shows the frontstage (what users see) above the line of visibility, and backstage (what agents do) below the line.

Key elements:

  • Frontstage: User sees status updates at each stage
  • Line of Visibility: Clear separation between what's visible and what's hidden
  • Backstage: Three agents coordinate sequentially with explicit handoffs
  • Handoff Points: Data packages passed between agents with full context

Accessibility Considerations

1. Status Announcements

The challenge: 

Screen reader users can't see visual progress indicators. Each handoff must be announced clearly.

Design solution:

  • Announce each stage change
  • Use clear, descriptive language
  • Don't just say "Loading..." - say what's happening
Good Example
  • "Finding best price... Product found. Now processing payment... Payment confirmed. Now arranging delivery..."
Bad Example
  • Silent transitions or just "Processing..."
Implementation note:

Use ARIA live regions (role="status" aria-live="polite") to announce status changes without interrupting screen reader flow.

2. Context Preservation Across Handoffs

The challenge: 

If a user tells Agent A they're blind, does Agent C know this? Accessibility needs must travel through the entire chain.

Design solution:

Every handoff package must include user accessibility context.

  • Screen reader user: All confirmations in text format (not images)
  • Wheelchair user: Delivery instructions include accessibility notes
  • Deaf user: No phone calls, text/email only
  • Cognitive accessibility: Simple language, no jargon, clear structure
Example handoff data:
  • User Context:
    - Name: John Smith
    - Shipping: 123 Main St
    - Accessibility needs:
    * Blind user (screen reader)
    * Confirmation format: Plain text email
    * Delivery notes: "User cannot see package, ring doorbell"
Test it:

Walk through the complete flow. At each stage, ask: "Does this agent know about the user's accessibility needs?"

3. Timing and Pacing

The challenge: 

Rapid-fire status updates can overwhelm users, especially those with cognitive disabilities or processing difficulties.

Design solution:

  • Minimum 2-3 seconds between status announcements
  • Allow users to pause the process if needed
  • Don't auto-advance without user confirmation for critical steps
  • Provide "Explain this" option at each stage
Good pacing:
  • "Finding price... [3 seconds] ...Found! ÂŁ15.99. [pause] Processing payment..."
Bad Pacing:
  • "Findingpriceprocessingpaymentarrangingdelivery" (too fast, overwhelming)
For neurodivergent users:
  • Predictable timing helps reduce anxiety
  • Clear stage markers help with processing
  • Option to "Step through manually" at their own pace

4. Error Recovery for All Users

The challenge: 

Errors must be clear and actionable for all users, including those using assistive technology.

Design solution:

  • Never just say "Error" or show error codes
  • Explain what went wrong in plain language
  • Provide clear next steps
  • Offer multiple alternatives
Good error:
  • "Payment was declined by your bank. You can: 1) Try a different card, 2) Update your payment method, or 3) Cancel this order. What would you like to do?"
Bad Error:
  • "Error 402: Payment declined"
Accessibility requirements:
  • Error announced immediately to screen readers
  • Error message has sufficient color contrast
  • Keyboard focus moves to error message
  • Clear path to fix the error

Common Failure Modes

Failure 1: Context Lost in Handoff

What happens:

  • User tells Agent A: "Gift wrap this"
  • Agent A finds product and hands off to Agent B
  • Agent B processes payment (doesn't know about gift wrap)
  • Agent C ships without gift wrap
  • User receives unwrapped item
Why it fails:
  • The "gift wrap" preference didn't travel through the handoff
  • Agent A forgot to pass it to Agent B
  • Agent B didn't know to pass it to Agent C
  • No validation that context was preserved
How to fix - Design the handoff package to include:

Core data (what the agent needs to do its job): Product ID, price, quantity, merchant

User context (preferences that MUST be preserved): Gift wrap request, Delivery instructions, Accessibility needs, Special requirements

Chain history (audit trail): Which agents processed this, When each handoff occurred, What was passed at each stage

Design user visibility: Show the user what's being carried through:

  • "Processing payment for Book (ÂŁ15.99) with gift wrap"
  • User can catch errors: "Wait, I didn't want gift wrap!"
Test checklist:
  • List every piece of information the user provides
  • Trace each piece through all agents
  • Verify nothing gets dropped
  • Test specifically with accessibility needs
  • Confirm final outcome includes all original requests

Failure 2: One Agent Fails, Entire Chain Stops

What happens:

  • Shopping Agent finds product
  • Payment Agent tries to process... times out
  • User sees "Processing payment..." forever
  • No update. No options. Just waiting.
  • User doesn't know if it's working or broken
Why it fails:
  • No plan for what happens when an agent fails
  • No timeout (how long to wait before giving up?)
  • Failure doesn't surface to the user
  • No alternative path designed
How to fix - Design the handoff package to include:

Design failure communication:

Instead of silent failure, provide clear feedback:

"Payment processing is taking longer than expected.

Would you like to:

  1. Keep trying (wait another 30 seconds)
  2. Try a different payment method
  3. Cancel and try later"

Design timeout rules:For each agent, decide:

  • How long should it try before timing out?
  • What message shows during the wait?
  • What happens after timeout?

Example timeouts:

  • Shopping Agent: 15 seconds max
  • Payment Agent: 30 seconds max
  • Delivery Agent: 20 seconds max

Design fallback options:When an agent fails, give users clear choices:

  1. Retry automatically (with limit - max 3 attempts)
  2. Try alternative method (different payment card, different shipping)
  3. Skip this step (if possible - rare)
  4. Cancel and start over (preserve some context if possible)
  5. Get human help (escalate to support)
Test checklist:
  • Simulate each agent failing
  • Verify user gets immediate feedback
  • Check recovery options are clear
  • Confirm user doesn't lose all progress
  • Test with screen reader (error announced clearly)

Failure 3: Silent Handoffs (User Doesn't Know What's Happening)

What happens:

  • User: "Buy me that book"
  • [30 seconds of silence]
  • AI Agent: "Done! Book ordered."

User thinks:

  • "Did it freeze?"
  • "Should I refresh?"
  • "What's taking so long?"
  • "Is it actually doing something?"
Why it fails:
  • Agents coordinate backstage (invisible to user)
  • No status updates between handoffs
  • User can't distinguish between "working" and "broken"
  • Anxiety increases with silence
How to fix - Design the handoff package to include:

Make handoffs visible:

Show clear progression:

  • "Finding best price..." [Agent A working]
  • "Found book for ÂŁ15.99. Processing payment..." [Handoff to B]
  • "Payment confirmed. Arranging delivery..." [Handoff to C]
  • "Done! Book arrives Friday." [Complete]

Design status update rules:

  • Show when each agent starts working
  • Show when handoff happens
  • Use present continuous tense ("Processing..." not "Processed")
  • Include time estimates when possible

Status update examples:

  • "Finding best price... (usually takes 5-10 seconds)"
  • "Processing payment... (connecting to your bank)"
  • "Arranging delivery... (checking courier availability)"

For screen reader users:

  • Each status change must be announced
  • Use ARIA live regions with appropriate politeness
  • Clear, distinct announcements
  • Not too frequent (avoid overwhelming)
Test checklist:
  • Close your eyes (or use actual screen reader)
  • Go through the complete flow
  • Can you follow what's happening?
  • Do you know which stage you're at?
  • Can you tell when handoffs occur?
  • Would you know if system froze?

Real-World Examples

Example 1: E-commerce Purchase

Pattern: Product Search → Payment → Shipping

Scenario: User says "Buy me running shoes, size 10"

Agent sequence:

  • Agent A (Product Search): Searches 10 retailers, compares prices, filters by size and availability, selects Nike Air Zoom for ÂŁ89.99
  • Agent B (Payment): Validates saved Visa card, processes payment, receives confirmation
  • Agent C (Shipping): Calculates delivery (Tuesday), coordinates with warehouse, generates tracking number
Why sequential works here:

Each step depends on the previous one.

You can't ship before knowing which product.

You can't ship before payment is confirmed.

Natural dependencies require sequential execution.

User sees:

"Finding running shoes size 10... "

"Found Nike Air Zoom (ÂŁ89.99)."

"Processing payment..."

"Payment confirmed. Arranging delivery..."

"Arrives Tuesday with tracking."

Example 2: Document Processing Pipeline

Pattern: Upload → Virus Scan → OCR → Storage

Scenario: User uploads a scanned contract for their records

Agent sequence:

  • Agent A (Upload Handler): Receives PDF file, validates format, checks file size
  • Agent B (Security Scanner): Scans for viruses and malware (MUST complete before processing)
  • Agent C (OCR Processor): Extracts text from scanned pages, creates searchable PDF
  • Agent D (Storage Manager): Saves to secure database, creates backup, generates access link
Why sequential works here:

Security requires virus scan before ANY processing.

OCR needs clean file.

Storage needs processed document.

Can't reorder without risk.

User sees:

"Uploading contract.pdf..."

"Scanning for security threats..."

"Extracting text..."

"Saving to your files..."

"Done! Document ready."

Example 3: Loan Application Processing

Pattern: Data Collection → Credit Check → Risk Assessment → Approval Decision

Scenario: User applies for ÂŁ10,000 personal loan

Agent sequence:

  • Agent A (Data Collector): Collects income, employment, existing debts, loan amount, purpose
  • Agent B (Credit Bureau): Runs credit check, retrieves credit score (needs complete data from A)
  • Agent C (Risk Assessor): Analyzes debt-to-income ratio, credit score, employment stability (needs score from B)
  • Agent D (Approval Agent): Makes lending decision based on risk assessment (needs analysis from C)
Why sequential works here:

Each decision requires information from the previous analysis.

Can't assess risk without credit score.

Can't approve without risk assessment.

Financial logic requires ordered execution.

User sees:

"Reviewing your application..."

"Checking credit history..."

"Assessing eligibility..."

"Calculating offer..."

"Decision ready! You're approved for ÂŁ10,000 at 8.5% APR."

Example 4: Medical Appointment Booking

Pattern: Availability Check → Calendar Block → Confirmation → Reminder Setup

Scenario: Wheelchair user needs to book accessible doctor appointment

Agent sequence:

  • Agent A (Availability): Checks doctor's schedule AND wheelchair-accessible exam rooms
  • Agent B (Booking): Blocks calendar slot, reserves accessible room, adds accessibility notes
  • Agent C (Confirmation): Sends accessible confirmation email (text, not image), includes accessibility details
  • Agent D (Reminder): Sets up reminder for day before, includes accessibility confirmation
Why sequential works here:

Can't block calendar before checking availability.

Can't send confirmation before booking is complete.

Can't set reminder before appointment exists.

Each step validates before proceeding.

User sees:

"Checking availability for wheelchair-accessible appointment..."

"Found slot Friday 2pm with Dr. Smith, accessible exam room..."

"Booking appointment..."

"Sending confirmation..."

"Done! Appointment confirmed with accessibility accommodations."

Accessibility consideration:

User's wheelchair access requirement travels through entire chain:

  • Agent A: Filters for accessible rooms only
  • Agent B: Books accessible room specifically
  • Agent C: Confirmation mentions "wheelchair-accessible exam room, ground floor"
  • Agent D: Reminder includes accessibility details

Example 5: Customer Support Ticket Resolution

Pattern: Initial Triage → Specialist Assignment → Resolution → Follow-up

Scenario: User reports "Can't log in to account"

Agent sequence:

  • Agent A (Triage Bot): Asks diagnostic questions, determines issue type (password reset needed)
  • Agent B (Password Agent): Sends secure reset link, verifies identity, processes reset
  • Agent C (Account Verification): Confirms successful login, checks account status
  • Agent D (Follow-up): Sends summary email, satisfaction survey
Why sequential works here:

Must diagnose before routing.

Must reset password before verification.

Must verify success before closing.

Support process has natural flow.

User sees:

"I'll help you log in..."

"Sending password reset link to your email..."

"Password reset successfully..."

"Account access verified..."

"All set! Check your email for details."

Accessibility consideration:

User's wheelchair access requirement travels through entire chain:

  • Agent A: Filters for accessible rooms only
  • Agent B: Books accessible room specifically
  • Agent C: Confirmation mentions "wheelchair-accessible exam room, ground floor"
  • Agent D: Reminder includes accessibility details
Design Checklist

When implementing Sequential Handoff, ensure:

Planning:

  • Each agent has clear, single responsibility
  • Dependencies between agents are documented
  • Handoff data structure is defined
  • Timeout limits set for each agent
  • Failure recovery paths designed

User Experience:

  • Status visible at each stage
  • Handoff transitions communicated
  • Time estimates provided when possible
  • Clear final confirmation with all details

Accessibility:

  • Status announcements for screen readers
  • Context includes accessibility needs
  • Appropriate pacing (not too fast)
  • Error messages clear and actionable
  • Keyboard navigation works throughout

Error Handling:

  • Timeout behavior defined
  • Failure messages are helpful
  • Recovery options provided
  • Users can retry or choose alternatives
  • Progress not completely lost on failure

Testing:

  • Manual walkthrough of happy path
  • Test each agent failure scenario
  • Test with screen reader
  • Test context preservation
  • Test with slow network (timeouts)
 Mark lesson complete

Comments are closed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
Scroll to Top