Skip to main content

Pattern Selection Guide

Who this is for

Builders who have reviewed the pattern catalog and need to map their specific scenario to a recommended pattern combination. If you're still exploring what patterns exist, start with the overview first.

Match your scenario to the recommended pattern combination.

Quick Reference​

ScenarioRecommended Pattern(s)Complexity
Simple FAQ / helpdeskSingle Agent + RAG + Tools🟢 Low
Multi-domain supportGraph (router) + Agents-as-Tools🟡 Medium
Complex case managementAgents-as-Tools + Workflow + HITL🔴 High
Collaborative troubleshootingSwarm🟠 Medium-High
Regulated / complianceSingle Agent + Reflection + HITL🟡 Medium
Multi-team platformBot Factory + Graph🔴 High
Cross-platform federationA2A + Gateway MCP targets🔴 High

Decision Tree​

Start Here: How Many Domains?​

Single domain (e.g., just customer billing):

  • Start with Single Agent + Tools
  • Add RAG if you need knowledge base grounding
  • Add HITL if actions are high-risk

Multiple domains (e.g., billing + support + account management):

  • Use Agents-as-Tools for clear domain separation
  • Or Graph if you need structured routing logic
  • Add Router/Dispatcher as entry point for intent classification

Execution Path Flexibility​

Deterministic flows (you know the steps in advance):

  • Use Workflow (DAG) for parallel execution
  • Suits batch processing, CI/CD, data pipelines

LLM-decided flows (agent figures out the path):

  • Use Graph for controlled branching with guardrails
  • Use Swarm for maximum agent autonomy

Hybrid (some fixed, some dynamic):

  • Use Agents-as-Tools - parent LLM picks which child, but children have predictable behavior

Cross-Organization Requirements​

Single team, single framework:

  • Any pattern works; start simple

Multi-team, shared platform:

  • Use Bot Factory for standardized agent templates
  • Ensures governance, approved tools, common guardrails

Cross-platform, cross-framework:

  • Use A2A Protocol for interoperability
  • Each team can use their preferred framework

Anti-Patterns to Avoid​

Anti-PatternWhy It's BadBetter Approach
Swarm for simple tasksUnpredictable, hard to debugSingle Agent + Tools
Graph without clear branchesOver-engineering, slow iterationStart with single agent, add routing later
HITL on every actionDefeats the purpose of automationHITL only on high-risk/high-confidence-gap actions
A2A for internal agentsProtocol overhead unnecessaryAgents-as-Tools within same runtime
Skipping observability"It worked in dev" → failure in prodAlways instrument from day one

Migrating Between Patterns​

As your agent matures, you may need to upgrade patterns:

  1. Single Agent → Agents-as-Tools — When tool count grows large (a common heuristic is ~15+ tools), or when domains need separate guardrails and isolation
  2. Graph → Swarm — When branching logic becomes too complex to predefine
  3. Agents-as-Tools → A2A — When agents cross team/framework boundaries
  4. Any pattern → + HITL — When deploying to regulated environments

AgentCore Runtime supports all patterns natively, so most migrations are primarily code-level changes. However, patterns that involve cross-agent communication (A2A) or platform-level standardization (Bot Factory) also require infrastructure configuration (endpoints, registries, account topology) beyond the agent code itself.

Further Reading​