mech.app
Automation

Swarm vs. Graph: AWS Benchmarks Two Multi-Agent Orchestration Patterns for Production Prospecting Pipelines

Head-to-head comparison of sequential delegation and parallel DAG orchestration in a real multi-agent system that scores prospects and generates emails.

Source: aws.amazon.com
Swarm vs. Graph: AWS Benchmarks Two Multi-Agent Orchestration Patterns for Production Prospecting Pipelines

Most multi-agent discussions stay theoretical. AWS just published production benchmarks from Thrad.ai comparing two orchestration patterns (Swarm and Graph) on the same workload: a prospecting pipeline that scores leads across six sources, classifies intent, and generates personalized emails. The post includes latency, cost, and quality metrics, plus governance controls for enterprise deployment.

The Problem Shape

Thrad.ai’s sales team spent 30 to 45 minutes per lead researching across Reddit, Hacker News, Stack Overflow, GitHub, LinkedIn, and company websites. A single agent can’t handle this: the signal diversity is too broad, the source APIs too varied, and the analysis too nuanced for one model to handle well.

The solution is specialist agents per source, then a fusion agent that spots cross-source patterns. A founder asking “What should I use for X?” in r/SaaS while their product launches on Hacker News is a stronger signal than either event alone.

Orchestration Pattern Comparison

AWS benchmarked two patterns using Strands Agents and Amazon Bedrock AgentCore:

Swarm orchestration: Sequential delegation where one agent hands off to the next. The coordinator agent calls source agents one by one, waits for each response, then passes accumulated context to the analysis agent.

Graph orchestration: Parallel DAG where source agents run concurrently. The coordinator fans out to all source agents simultaneously, collects results, then triggers the analysis agent.

PatternLatencyCostQualityFailure ModeUse Case Fit
SwarmHigher (sequential)Lower (fewer parallel calls)Better context flowSingle agent failure blocks pipelineContext-critical workflows
GraphLower (parallel)Higher (concurrent API calls)Requires explicit context passingPartial completion harder to detectThrad.ai choice: latency-critical sales (40% faster)

The Graph pattern cut latency by 40% but increased cost by 25% due to concurrent Bedrock API calls. Email quality was comparable, but Graph required more explicit state management to prevent context loss between parallel branches.

Weighted Criteria Scoring with Temporal Decay

The system scores prospects using weighted criteria across multiple dimensions:

  • Engagement signals: GitHub stars, Stack Overflow questions, Reddit upvotes
  • Intent classification: Problem-seeking vs. solution-seeking language
  • Temporal decay: Recent activity weighted higher than old signals

The scoring function looks like this:

def calculate_prospect_score(signals, weights, decay_days=30):
    score = 0
    for signal in signals:
        age_days = (datetime.now() - signal.timestamp).days
        decay_factor = math.exp(-age_days / decay_days)
        score += signal.value * weights[signal.type] * decay_factor
    return score

The decay parameter prevents stale signals from inflating scores. A GitHub repo that crossed 2,400 stars six months ago is less relevant than one that crossed 500 stars yesterday.

To prevent agents from gaming their own scoring functions, the analysis agent applies cross-source correlation checks. A high Reddit score without corresponding GitHub or Stack Overflow activity triggers a penalty. This forces the system to look for correlated signals rather than optimizing individual sources.

State Management and Observability

Strands Agents handles multi-agent state through Amazon Bedrock AgentCore, which provides:

  • Shared memory: All agents can read from a common context store
  • Event log: Every agent action, tool call, and handoff is recorded
  • Checkpoint recovery: If an agent fails mid-pipeline, the system can resume from the last successful checkpoint

For production observability, the system tracks:

  • Inter-agent handoff failures: When one agent passes malformed context to the next (for example, if the Reddit agent returns an empty array instead of a list of posts, the analysis agent logs a handoff failure and proceeds with five sources instead of six)
  • Partial completion rates: How often the pipeline completes all source agents vs. timing out
  • Token consumption per agent: Which agents are burning the most budget
  • Email generation success rate: How many drafts pass governance checks

The Graph pattern exposes more observability challenges because partial completion is harder to detect. If three out of six source agents succeed, should the analysis agent proceed or wait? The system uses a configurable threshold: if at least four source agents return results within 10 seconds, the analysis agent proceeds. Otherwise, it retries failed agents once before giving up. If the Reddit agent times out, the system retries once; if it fails again, the analysis agent proceeds with five sources instead of six.

Governance Controls for Outbound Email

When agents generate emails at scale, you need approval gates without blocking the pipeline. The system implements three layers:

  1. Content filters: Block emails containing banned phrases, competitor names, or overly aggressive language
  2. Human-in-the-loop review: Emails above a certain prospect score (top 10%) go to a review queue
  3. Rate limiting: No more than 50 emails per day to prevent spam flags

The approval gate sits between the email generation agent and the send agent. High-value prospects get human review; everything else gets automated filtering. The system logs all filtered emails for periodic review to catch false positives. The 10% threshold was calibrated via A/B testing on email open rates, starting at 5% and increasing until diminishing returns appeared.

Architecture Flow

The production pipeline looks like this:

  1. Coordinator agent receives a prospect name and company
  2. Source agents (Reddit, HN, Stack Overflow, GitHub, LinkedIn, web scraper) run in parallel (Graph) or sequence (Swarm)
  3. Analysis agent receives all source results, applies weighted scoring with temporal decay, and classifies intent
  4. Email generation agent drafts personalized outreach based on analysis
  5. Governance agent applies content filters and routes high-value prospects to human review
  6. Send agent delivers approved emails via SendGrid

Each agent is a Bedrock AgentCore instance with its own tool set. The Reddit agent uses the Reddit API, the GitHub agent uses the GitHub API, and so on. The analysis agent has no external tools; it only processes the aggregated context from source agents.

When to Use Each Pattern

Use Swarm orchestration when:

  • Context flow between agents is critical
  • You need deterministic execution order
  • Cost matters more than latency
  • Your agents have dependencies (agent B needs agent A’s output)

Use Graph orchestration when:

  • Latency is the primary constraint
  • Source agents are independent
  • You can afford higher API costs
  • Partial completion is acceptable

For Thrad.ai’s use case, Graph won because sales teams care more about response time than cost. Cutting research time from 30 minutes to 5 minutes (including agent latency) justified the 25% cost increase.

Technical Verdict

Use Graph orchestration if you process more than 500 prospects per day and need sub-10 second response times. At Thrad.ai’s volume (1,200 leads/day), Graph reduced total researcher time by 300 hours per month. If your cost per lead must stay below $0.50, use Swarm; Graph is acceptable if you can tolerate $0.65 per lead. If more than 5% partial completion is unacceptable (for example, compliance requires all six sources), use Swarm with retry logic.

Use Swarm orchestration if your latency SLA allows 20 to 30 seconds per prospect and cost per lead is the primary constraint. Swarm works well for batch processing overnight or when agents have strict dependencies (for example, the LinkedIn agent needs the company website agent’s output first).

Avoid multi-agent orchestration entirely if your data sources are homogeneous or your analysis is simple enough for a single agent with multiple tools. The orchestration overhead (state management, inter-agent handoffs, observability) only pays off when the problem truly requires specialization. If a single Claude 3.5 Sonnet call with six API tools can handle your workload, skip the multi-agent complexity.

The governance controls are table stakes for any system that generates outbound communication at scale. If you skip the approval gates, you will spam prospects and damage your brand.