AWS Sales ran into the agent sprawl problem at scale. They deployed more than 20 domain-specific agents across their global sales organization: CRM operations, meeting scheduling, customer insights, product recommendations, compliance checks. Each agent worked. The problem was that sales reps had to know which agent to invoke, manage context across fragmented conversations, and manually combine outputs from different systems.
The cognitive load shifted from the software to the user. Instead of focusing on customer conversations, reps were context-switching between specialized tools. AWS built Field Advisor on Bedrock AgentCore to solve this with a routing layer that decides which agent handles each request without forcing the user to pre-select.
The Orchestration Problem
Agent proliferation creates a worse UX than having no agents at all when:
- Users must choose between 20+ specialized agents before asking a question
- Context does not flow between agents (pricing data does not reach the compliance agent)
- Each agent maintains separate session state
- Outputs require manual assembly across systems
The AWS Sales deployment exposed this pattern. Specialized agents deliver value in isolation, but without orchestration, the user carries the routing burden. A question like “What’s the pricing for this customer and does it meet compliance requirements?” touches multiple domains. Without a router, the user must invoke the pricing agent, extract the answer, then invoke the compliance agent with manually copied context.
Architecture: Router + Specialized Agents
Field Advisor uses a router agent that sits in front of the domain-specific agents. The router:
- Receives the user’s natural language request
- Analyzes intent and required domain knowledge
- Routes to one or more specialized agents
- Manages context handoff between agents
- Assembles the final response
The specialized agents remain focused on their domains. The router handles orchestration logic.
Component Responsibilities
| Component | Responsibility | Failure Mode |
|---|---|---|
| Router Agent | Intent classification, agent selection, context assembly | Misroutes to wrong specialist, loses context in handoff |
| Domain Agents | Execute specialized tasks (CRM, scheduling, insights) | Return incomplete data, timeout on external API calls |
| State Manager | Persist session and long-term memory across agents | Context loss on agent transition, stale data |
| Identity Layer | Propagate OAuth tokens across agent boundaries | Permission errors when specialist needs different scope |
| Observability | Trace request flow through multi-agent execution | Blind spots when agents call other agents recursively |
Context Handoff Mechanics
When a request requires multiple agents, the router must preserve context across boundaries. A pricing question that triggers a compliance check needs:
- Customer identifier
- Product SKU
- Pricing tier from the first agent
- Compliance region from CRM data
The state manager maintains this context in a shared session. Each agent receives:
- The original user request
- Relevant context from prior agents
- Its specific task scope
Without this, the compliance agent would re-fetch customer data already retrieved by the pricing agent, or worse, operate on stale assumptions.
Routing Decision Logic
The router uses the LLM to classify intent and map to agent capabilities. This is not keyword matching. The router analyzes:
- Domain entities mentioned (customer names, product codes, dates)
- Action verbs (schedule, check, recommend, forecast)
- Implicit context (a follow-up question assumes prior conversation state)
For ambiguous requests, the router can invoke multiple agents in parallel or sequence. A question like “Prepare for my meeting with Acme Corp tomorrow” might trigger:
- CRM agent (fetch account history)
- Scheduling agent (confirm meeting details)
- Insights agent (recent activity, open opportunities)
- Product recommendation agent (based on account profile)
The router assembles these outputs into a unified briefing.
AgentCore Primitives Used
AWS Sales chose Bedrock AgentCore because it provides managed infrastructure for multi-agent orchestration:
- Isolated execution environments: Each agent runs in a separate security boundary with its own IAM permissions
- Unified gateway: Single entry point for tool and agent access across AWS accounts
- Persistent memory: Session state and long-term context stored outside agent execution
- Identity propagation: OAuth tokens flow through the router to specialists without re-authentication
- Observability: Distributed tracing across agent invocations
These primitives remove the need to build custom state management, identity plumbing, and observability infrastructure.
Deployment Shape
Field Advisor runs as a managed service within the AWS Sales organization. The deployment includes:
- Router agent (single instance, scales horizontally)
- 20+ domain-specific agents (each deployed independently)
- Shared state store (DynamoDB for session persistence)
- Identity service (OAuth integration with corporate SSO)
- Observability stack (CloudWatch + X-Ray for distributed tracing)
Each domain agent team owns their agent’s logic and tools. The router team owns orchestration and context management. This separation allows domain teams to iterate without coordinating releases.
Likely Failure Modes
Router misclassification: The router sends a compliance question to the pricing agent. Mitigation: Log routing decisions, measure accuracy, retrain on misclassified examples.
Context loss on handoff: The second agent in a chain does not receive data from the first. Mitigation: Validate context payload before invoking next agent, fail fast with clear error.
Circular routing: Router invokes Agent A, which asks a question that routes back to Agent A. Mitigation: Track agent call depth, enforce maximum chain length.
Permission boundary errors: Specialist agent needs access to a resource not covered by the router’s OAuth token. Mitigation: Pre-flight permission checks, clear error messages with required scopes.
Observability blind spots: Nested agent calls do not propagate trace context. Mitigation: Enforce trace ID propagation in agent SDK, validate in integration tests.
Measurable Results
AWS Sales reports:
- Reduced context-switching between systems
- Unified interface for 20+ specialized capabilities
- Preserved domain agent autonomy (teams iterate independently)
- Improved time spent on customer conversations vs. tool navigation
The key metric is not agent accuracy. It is whether sales reps can ask natural questions and get assembled answers without knowing which agents to invoke.
Technical Verdict
Use this pattern when:
- You have more than 5 specialized agents and users must choose between them
- Requests frequently require data from multiple domains
- Context handoff is manual and error-prone
- Agent teams need to iterate independently without coordinating releases
Avoid this pattern when:
- You have 1-3 agents with clear, non-overlapping use cases
- Users prefer explicit control over which specialist handles their request
- Context rarely flows between agents
- The routing decision is simple enough for a deterministic rule (no LLM needed)
The router adds latency and complexity. Only introduce it when agent sprawl creates worse UX than the orchestration overhead.