FBG Multi-Agent Support System Cuts Containment Gap 56%

Fanatics Betting and Gaming (FBG) has shipped a production multi-agent customer support system on AWS that improved its containment rate by approximately 56 percent and resolution rates by approximately 53 percent within the first two months of deployment. For engineers designing agent pipelines, this case study addresses genuinely hard coordination problems — U.S. state-by-state regulatory variance, real-time responsible gaming enforcement, and traffic spikes exceeding 40 support inquiries every two minutes during peak sporting events — using a concrete stack with specific model and service choices at each layer.

Orchestrator-Plus-Specialist Topology

Rather than a monolithic chatbot, FBG built an orchestrator pattern: a Supervisor Agent running Anthropic Claude Sonnet on Amazon Bedrock receives each inbound message, decides which tools to invoke, and synthesizes a unified reply. The supervisor sits downstream of two pre-processing layers — Amazon Bedrock Guardrails for prompt-injection detection, and a Responsible Gaming classification agent — before it ever touches business logic. This layering means safety enforcement is structural, not dependent on the orchestrator's own reasoning.

The full request path: FBG mobile app → Salesforce Einstein (chat interface) → Spring AI service on Amazon EKS (token validation) → Bedrock Guardrails → Responsible Gaming classifier → Supervisor Agent → tool invocation → response. Tool calls leave the supervisor via two channels: Model Context Protocol (MCP) servers hosted as Kubernetes services for account and transaction queries against external REST APIs, and local tools embedded directly in the Spring AI service for RAG retrieval and human escalation. FBG chose Spring AI because their engineers had deep Java expertise; AWS's open-source Python alternative, Strands Agents, provides equivalent MCP support for Python-first teams.

State-Specific RAG and the Dual-Search Pattern

The RAG pipeline is the system's highest-frequency tool. FBG built it custom rather than using a managed knowledge base to retain precise control over chunking and retrieval. The ingestion pipeline collects state-specific payment method guides, FAQ articles, responsible gaming resources, and account management guides, then splits them using a token-based chunking strategy before embedding with Amazon Titan V2. Vectors are stored in MongoDB Atlas.

At query time, the system rewrites the customer's question into a vector search-optimized form using an LLM, then runs two parallel similarity searches for jurisdiction-specific queries: one scoped to the customer's state and one against general documents. Both result sets are merged before being passed to the supervisor. This dual-search pattern lets a single response correctly blend, say, New Jersey withdrawal timelines with platform-wide account rules. The knowledge base grows by hundreds of documents monthly, driven by gap analysis from conversation logs.

Responsible Gaming Classification and Model Sizing

The Responsible Gaming classifier runs Amazon Nova 2 Lite — a deliberate choice of a smaller, faster model for a well-scoped classification task with a limited outcome set. The model receives the full conversation history alongside the current message, enabling pattern detection across a session rather than single-turn keyword matching. High-severity classifications trigger an immediate escalation to a human agent with complete conversation context transferred. Lower-severity signals are logged for compliance review while the conversation continues.

The core engineering principle: reserve larger, more expensive models for open-ended reasoning tasks (the supervisor), and use the smallest model that meets accuracy requirements for well-defined classification. Every model in the stack is accessed through the same Amazon Bedrock API, so routing different workloads to different models requires no infrastructure changes.

Model and Service Decisions at Each Layer

For peak-event throughput, the supervisor agent uses a round-robin strategy across model Regions on Bedrock, preventing throughput limits from degrading response quality during NFL playoffs or the Super Bowl — the same events that push inbound volume past 40 inquiries per two minutes. Amazon EKS autoscaling handles MCP server and Spring AI service capacity automatically without manual intervention.

Evaluation and Iteration

FBG launched with just 4 of their more than 20 support case types, building evaluation infrastructure before expanding scope. An LLM-as-a-Judge pipeline automatically classifies every completed conversation as resolved or unresolved; an operations team reviews those judgments daily and files improvement tickets, creating a compounding feedback loop.

The team's standing policy is to exhaust prompt optimization before migrating to a larger model, keeping marginal costs low. Teams looking to systematize that discipline can apply automated LLM prompt optimization techniques before committing to a model upgrade. The system has resolved thousands of cases autonomously, with customer satisfaction trending upward and users frequently unaware they are interacting with AI.

The FBG architecture is a concrete proof point that agent specialization, model right-sizing, and structural safety layering can each be solved independently — and that agentic system design earns its complexity budget when jurisdictional rules, compliance enforcement, and unpredictable traffic loads make a monolithic model genuinely insufficient.