2. Parallel Coordination

Parallel Coordination is a coordination pattern where multiple agents work simultaneously on independent tasks, then return their results to a coordinator who synthesizes them into a unified response.

It's a concurrent flow where agents execute in parallel because their tasks don't depend on each other.

Each agent works independently, but all are dispatched at the same time.

This pattern is fast and efficient. Multiple things happen at once.

Coordinator → Agent A + Agent B + Agent C (simultaneously) → Coordinator synthesizes → User

When to use: Tasks don't depend on each other, results can be presented independently, no synthesis logic needed.

When to Use It

Use Parallel Coordination when:

  • Tasks don't depend on each other
  • Speed is critical (parallel is faster than sequential)
  • You want to query multiple sources simultaneously
  • Each agent has independent data sources
  • Results can be combined after all complete
  • One agent's work doesn't affect another's

Examples:

  • Travel planning (flights + hotels + car rentals searched simultaneously)
  • Price comparison (checking multiple retailers at once)
  • Multi-source research (querying multiple databases in parallel)
  • Parallel document processing (translation + summarization + sentiment analysis)

When NOT to Use It

Don't use Parallel Coordination when:

  • Steps must happen in order (use Sequential Handoff instead)
  • Later agents need results from earlier ones (dependencies exist)
  • You need to route to different specialists based on request type (use Conditional Handoff)
  • Results from one agent determine what other agents do
  • One task must complete before others start

Wrong use cases:

  • Shopping → Payment → Delivery (sequential dependencies)
  • Routing customer questions to specialists (conditional routing)
  • Step-by-step approval workflow (ordered process)

Frontstage: What the User Sees

The user sees a single "searching..." status while multiple agents work behind the scenes, then receives all results together.

Example: Trip Planning (Flights + Hotels + Car Rentals)

What user experiences:

  • Single loading state ("Searching flights, hotels, and car rentals...")
  • Progress indicators showing multiple parallel searches
  • All results presented together (easy to compare)
  • Combined total with all options
  • Single confirmation for all bookings

Backstage: What the Agents Do

Behind the scenes, a coordinator dispatches three specialist agents simultaneously, waits for all to complete, then synthesizes results.

Coordinator Agent

Role: Orchestrates parallel execution

  • Receives user request: "Plan trip to Paris next weekend"
  • Parses requirements: destination, dates, preferences
  • Dispatches 3 specialist agents simultaneously (at same timestamp)
  • Status: WAITING FOR ALL
  • Monitors which agents have completed
  • Once ALL complete, synthesizes results
  • Calculates total price
  • Presents unified options to user

Agent A: Flight Agent (works in parallel)

START TIME: 10:23:00 (same time as Hotel and Car agents)

  • Queries British Airways API
  • Queries EasyJet API
  • Queries Air France API
  • Filters by: Paris, Friday-Sunday, best price
  • Selects: £250, 8am Friday departure

END TIME: 10:23:03 (Duration: 3 seconds)

Returns to coordinator:

{
"flight": "BA123",
"price": 250,
"departure": "08:00 Fri",
"return": "20:00 Sun"
}

Status: COMPLETE

Agent B: Hotel Agent (works in parallel)

START TIME: 10:23:00

  • Queries Booking.com API
  • Queries Hotels.com API
  • Filters by: Paris, 2 nights, wheelchair accessible
  • Selects: 3-star hotel, £180/night, accessible room

END TIME: 10:23:04 (Duration: 4 seconds)

Returns to coordinator:

{
"hotel": "Hotel Central Paris",
"price_per_night": 180,
"nights": 2,
"total": 360,
"accessibility": "wheelchair_accessible"
}

Status: COMPLETE

Agent C: Car Rental Agent (works in parallel)

START TIME: 10:23:00

  • Queries Hertz API
  • Queries Enterprise API
  • Filters by: Paris, automatic transmission, 2 days
  • Selects: VW Golf automatic, £45/day

END TIME: 10:23:02 (Duration: 2 seconds)

Returns to coordinator:

{
"car": "VW Golf Automatic",
"price_per_day": 45,
"days": 2,
"total": 90
}

Status: COMPLETE (first to finish!)

Critical Coordination Data

Coordinator dispatches to all agents:

  • Destination: Paris
  • Dates: Friday-Sunday
  • User preferences: wheelchair accessibility, automatic transmission

All agents return to coordinator:

  • Flight results (3 seconds)
  • Hotel results (4 seconds) ← SLOWEST
  • Car results (2 seconds) ← FASTEST

Coordinator waits for slowest (4 seconds total), then synthesizes:

  • Flight: £250
  • Hotel: £360 (2 nights)
  • Car: £90 (2 days)
  • Total: £610

Service Blueprint

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

Key elements:

  • Frontstage: User sees single "searching..." with progress indicators
  • Line of Visibility: Clear separation between visible and hidden
  • Backstage: Three agents work simultaneously (parallel execution window)
  • Coordinator: Dispatches all at once, waits for all, synthesizes results
  • Timing: Total time equals slowest agent (not sum of all agents)

Accessibility Considerations

1. Parallel Progress Announcements

The challenge: 

Screen reader users can't see visual progress bars. How do they know what's happening when 3 things happen at once?

Design solution:

  • Announce each agent as it completes (don't wait for all).
Good Example
  • "Searching flights, hotels, and car rentals..."
    [2 seconds]
    "Car rental search complete."
    [1 second]
    "Flight search complete."
    [1 second]
    "Hotel search complete. Here are your options."
Bad Example
  • [4 seconds of silence]
    "Done!"
Implementation note:

Use ARIA live regions to announce completions as they happen without interrupting screen reader flow.

2. Context Preservation Across All Agents

The challenge: 

If user needs wheelchair-accessible hotel, does the hotel agent know this? Accessibility requirements must be sent to ALL agents in the parallel dispatch.

Design solution:

  • Every agent in the parallel set receives full user context.
  • Flight Agent: Receives accessibility needs (might affect seating)
  • Hotel Agent: Filters ONLY wheelchair-accessible hotels
  • Car Agent: Might affect vehicle selection
Test it:

For each agent in parallel set, verify: "Does this agent have the user's accessibility context?"

3. Result Presentation

The challenge: 

When presenting multiple results simultaneously, screen reader users need clear structure to navigate options.

Design solution:

  • Present results in navigable structure.
  • Each option has clear heading.
  • User can tab through each option independently.
  • Total cost announced at end.
Screen reader hears:

"Travel options. Flight: British Airways BA123, £250. Hotel: Hotel Central Paris, wheelchair accessible, £180 per night. Car: VW Golf Automatic, £45 per day. Total weekend cost: £610."

4. Timeout Communication

The challenge: 

If one agent takes much longer than others, how do you communicate progress without overwhelming the user?

Design solution:

  • Progressive disclosure approach.
Example:

[2 seconds] "Car rental search complete."

[1 second] "Flight search complete."

[2 seconds - hotel still working] "Hotel search taking longer than expected... still searching..."

[3 seconds more] "Hotel search complete. Here are your options."

For timeout situations:

[10 seconds - hotel agent timeout]

"Found flights and cars. Hotel search unavailable right now. Would you like to see flight and car options, or try again later?"

Common Failure Modes

Failure 1: One Agent Fails, Others Succeed

What happens:

  • Flight Agent: Completes successfully
  • Hotel Agent: Completes successfully
  • Car Agent: Fails (no automatic cars available)
  • User doesn't see results because system waits for ALL agents.
Why it fails:
  • Coordinator set to "wait for all or fail"
  • One failure blocks entire response
  • User doesn't know 2 of 3 succeeded
  • No graceful degradation designed
How to fix - Design partial result presentation:

Instead of blocking, present what succeeded.

"Found flights and hotels for your Paris trip. Car rentals unavailable (no automatic transmission available for your dates).

Flight: £250 Hotel: £180/night

Would you like to:

  • Book flight and hotel without car
  • Try manual transmission car
  • Try different dates
  • Cancel"
Design decision rules:
  • If 2+ of 3 agents succeed: Present partial results
  • If only 1 of 3 succeeds: Too incomplete, ask to retry
  • If 0 of 3 succeed: Clear failure message with alternatives
Test checklist:
  • Simulate each agent failing individually
  • Verify partial results shown
  • Check user has clear options
  • Confirm accessibility needs still respected in partial results
  • Test with screen reader (partial results announced clearly)

Failure 2: Coordinator Waits Forever (No Timeout)

What happens:

  • Flight Agent: Completes in 3 seconds
  • Hotel Agent: Completes in 4 seconds
  • Car Agent: Hangs... 15 seconds... 30 seconds... never completes
  • User sees "Searching..." forever with no update.
Why it fails:
  • No timeout set for individual agents
  • Coordinator blocks indefinitely
  • No fallback behavior designed
  • User can't tell if system froze or is working
How to fix - Design timeout rules:

Set maximum wait time for each agent:

  • Flight Agent: 10 seconds max
  • Hotel Agent: 10 seconds max
  • Car Agent: 10 seconds max

After timeout, treat as failure.

Design progressive disclosure:

  • Don't wait for slowest agent to show ANY results.
  • [2 seconds] "Car search complete"
  • [3 seconds] "Flight search complete"
  • [4 seconds] "Hotel search complete"
  • "Here are your options..."
  • User sees progress, not silence.
Test checklist:

  • Simulate each agent timing out
  • Verify timeout triggers after set duration
  • Check partial results presented
  • Confirm user informed about timeout
  • Test timeout message with screen reader

Failure 3: Results Presented Too Fast (Overwhelming)

What happens:

  • Three agents complete almost simultaneously.
  • Screen reader announces: "Car search complete flight search complete hotel search complete here are your options flight british airways hotel central paris car vw golf..."
  • User can't process information stream.
Why it fails:
  • No pacing between announcements
  • Screen reader floods user with speech
  • Cognitive overload
  • Can't distinguish between separate results
How to fix:

Design announcement pacing:

Even if agents complete simultaneously, space announcements.

  • [Car completes at 2.0s] "Car rental search complete."
  • [Pause 1 second]
  • "Flight search complete."
  • [Pause 1 second]
  • "Hotel search complete."
  • [Pause 2 seconds]
  • "Here are your options..."

Minimum 1-2 seconds between announcements.

Design completion summary:

  • Instead of announcing each individually, summarize.
  • "All searches complete. Found 3 options: flights, hotels, and car rentals. Total cost: £610. Ready to review?"

For neurodivergent users:

  • Predictable pacing reduces anxiety
  • Clear separation between results helps processing
  • Option to review results "one at a time" at their own pace
Test checklist:

  • Simulate all agents completing simultaneously
  • Verify announcements paced appropriately
  • Test with actual screen reader
  • Check cognitive load (ask someone to listen)
  • Confirm users can process each announcement

Real-World Examples

Example 1: Travel Planning

Pattern: Flights + Hotels + Car Rentals (Parallel)

Scenario: User says "Plan a weekend trip to Paris"

Agent execution:

Coordinator dispatches simultaneously:

  • Flight Agent: Searches BA, EasyJet, Air France (3 seconds)
  • Hotel Agent: Searches Booking.com, Hotels.com, filters accessible (4 seconds)
  • Car Agent: Searches Hertz, Enterprise, filters automatic (2 seconds)

All return results to coordinator.

Coordinator synthesizes: Combines all options, calculates total (£610), presents unified options.

Why parallel works here:

Tasks are completely independent

Flight search doesn't need hotel results

Hotel search doesn't need car results

All can run simultaneously

Speed benefit: 

4 seconds total (vs 9 seconds sequential = 56% faster)

User sees:

"Searching flights, hotels, and car rentals..."

"Found options: Flight £250, Hotel £180/night, Car £45/day. Total: £610. Confirm?"

Example 2: Price Comparison Shopping

Pattern: Multiple Retailers (Parallel)

Scenario: User says "Find me the best price for AirPods Pro"

Agent sequence:

Coordinator dispatches simultaneously:

  • Amazon Agent: Queries Amazon API (2 seconds)
  • Best Buy Agent: Queries Best Buy API (3 seconds)
  • Apple Store Agent: Queries Apple API (2.5 seconds)
  • eBay Agent: Queries eBay API (4 seconds)

All return results to coordinator.

Coordinator synthesizes: Compares prices, selects best deal, presents top 3 options.

Why parallel works here:

Each retailer query is independent

No dependencies between searches

Speed critical (user wants fast comparison)

Speed benefit:

4 seconds total (vs 11.5 seconds sequential = 65% faster)

User sees:

"Checking prices at Amazon, Best Buy, Apple Store, and eBay..."

"Best prices found:

  1. Amazon: £199 (in stock, Prime delivery)
  2. Best Buy: £209 (in stock, pickup available)
  3. eBay: £185 (refurbished)

Cheapest new: Amazon £199. Buy now?"

Example 3: Document Processing

Pattern: Translation + Summarization + Sentiment Analysis (Parallel)

Scenario: User uploads customer feedback document in French

Agent sequence:

Coordinator dispatches simultaneously:

  • Translation Agent: Translates French → English (8 seconds)
  • Summarization Agent: Extracts key points from French original (6 seconds)
  • Sentiment Agent: Analyzes sentiment of French original (4 seconds)
  • Entity Extraction Agent: Identifies products, names, locations (5 seconds)

All return results to coordinator.

Coordinator synthesizes: Combines translation, summary, sentiment, entities into unified report.

Why parallel works here:

All agents can read same source document simultaneously

No dependencies (all process original)

Comprehensive analysis needed

Speed benefit:

8 seconds total (vs 23 seconds sequential = 65% faster)

User sees:

"Processing your document: translating, extracting summary, analyzing sentiment, identifying entities..."

"Analysis complete:Translation: [English version]Summary: Customer expresses frustration with delivery delays...Sentiment: 65% negativeKey mentions: Product X (5 times)

Download full report"

Design Checklist

When implementing Parallel Coordination, ensure:

Planning:

  • Tasks are truly independent (no dependencies)
  • Coordinator logic handles partial results
  • Timeout limits set for each agent
  • Failure recovery paths designed
  • Speed benefit justifies complexity

User Experience:

  • Loading state shows parallel work
  • Progress indicators for multiple agents
  • Results presented clearly together
  • Combined totals/summaries provided
  • Clear comparison between options

Accessibility:

  • Announcements for each agent completion
  • Pacing between announcements (not overwhelming)
  • Context sent to ALL agents in parallel dispatch
  • Results navigable by screen reader
  • Timeout communicated clearly

Error Handling:

  • Partial results presented if some agents fail
  • Timeout behavior defined for each agent
  • Failure messages explain what succeeded/failed
  • Recovery options provided (retry failed agents)
  • User doesn't wait indefinitely

Testing:

  • Test happy path (all agents succeed)
  • Test each agent failing individually
  • Test multiple agents failing
  • Test timeout scenarios
  • Test with screen reader (announcement pacing)
  • Measure actual speed improvement vs sequential
 Mark lesson complete

Comments are closed.

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