翻訳待ち：How Fanatics Betting and Gaming built a multi-agent customer support system

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Fanatics Betting and Gaming (FBG) built a multi-agent customer support system on AWS to solve a challenge unique to sports betting. Customers expect instant, accurate answers, especially during live events when every minute counts. Customers ask about account issues, deposit limits, state-specific regulations, and responsible gaming resources. The rules vary across every jurisdiction where an operator is licensed. Traditional chatbot solutions built on decision trees struggle with this complexity, often frustrating customers and driving up costs as human agent queues grow. Fanatics Betting and Gaming (FBG) is a sports betting platform that combines advanced technology with deep sports expertise. As part of the Fanatics family of brands, FBG operates across multiple U.S. states, serving a rapidly growing user base that demands around the clock support, particularly during high-traffic events like NFL playoffs and the Super Bowl. Facing exponential growth in support volume, FBG’s engineering team built a multi-agent AI system on AWS that resolves customer issues faster, more accurately, and at a fraction of the cost of human-only support. In this post, we walk through the architecture, the AWS services involved, and the patterns you can consider when designing your own multi-agent customer support solution. The challenge As FBG scaled, their existing support model required more human touches per interaction, creating higher operational costs that grew proportionally with their customer base. The team recognized an opportunity to improve their customers’ experience while preparing the support infrastructure for the next phase of growth. Several factors made the problem especially difficult. Every U.S. state has its own rules for payment methods, deposit limits, withdrawal timelines, and responsible gaming requirements. A customer in Indiana gets different answers than one in New Jersey. During major sporting events, support requests can surge to over 40 inquiries every two minutes, and the system needs to scale instantly without degrading response quality. The diversity of queries compounds the problem. Customers ask about everything from transaction history and account settings to betting rules and self-exclusion options. No single model or knowledge base covers it all. On top of that, operators must identify and respond to signs of problem gambling in real time. This requires a nuanced understanding of conversational context, not just keyword matching. FBG needed a system that could handle this complexity autonomously while knowing exactly when to escalate to a human agent. “As we scaled, we knew our support experience needed to evolve with us. We wanted to give our customers faster, more accurate answers while making sure we never compromised on responsible gaming or compliance. The goal was to build something that got better over time, not just bigger.” — Ian Botts, CTO, Fanatics Betting and Gaming Solution overview Rather than relying on a single monolithic chatbot, FBG designed a multi-agent system where specialized agents handle different aspects of the customer interaction. Because the team had already built deep operational expertise on Amazon Elastic Kubernetes Service (Amazon EKS), they could build on their existing container platform to deploy, scale, and iterate on each agent independently. FBG chose Amazon Bedrock for its model-agnostic access to multiple foundation models through a single API, which lets the team match each task to the best model and swap models as better options emerge. Because Bedrock runs within their existing AWS environment, the system also inherits FBG’s established security and governance controls, and Amazon Bedrock Guardrails provides the responsible AI safeguards their compliance requirements demand. The architecture follows an orchestrator pattern. A primary orchestration agent receives each customer message, coordinates with specialized tools and sub-agents, and returns a unified response. This design allows the team to add new capabilities, such as new tools, new knowledge domains, and new business units, without rewriting the core system. “We designed the system so that each agent has a clear responsibility and can be improved independently. That modularity is what allows us to move fast. When we need to support a new case type or a new business unit, we add a new tool or agent without touching the rest of the system.” — Luis Fernandez Rocha, Sr. Manager of Software Engineering, Fanatics Betting and Gaming Figure 1 illustrates the high-level architecture. Figure 1: End-to-end architecture of the multi-agent customer support system on AWS A customer message enters through the FBG mobile app, passes through Salesforce Einstein to the Spring AI service on Amazon EKS, then flows through Amazon Bedrock Guardrails and a Responsible Gaming classifier before reaching the Supervisor Agent. The Supervisor Agent invokes specialized tools, including a Retrieval Augmented Generation (RAG) pipeline, account and transaction Model Context Protocol (MCP) servers, and a transfer-to-agent tool to generate a response. How a request flows through the system A customer sends a message through the FBG mobile app, which connects to Salesforce Einstein as the chat interface layer. The request is routed through standard REST calls to the Spring AI service running on Amazon EKS. This service validates the customer token and invokes the AI agent. The request then passes through Amazon Bedrock Guardrails to help detect prompt injection before reaching the AI layer. A Responsible Gaming classification agent, powered by Amazon Nova 2 Lite, evaluates every message against a compliance-approved classification framework. High-severity classifications trigger an immediate transfer to a human agent with full conversation context. The Supervisor Agent, running Anthropic Claude on Amazon Bedrock, determines which tools to invoke based on the customer’s intent. Depending on the query, the supervisor calls one or more specialized tools, some through MCP and others local to the service: Retrieval Augmented Generation (RAG) Tool retrieves relevant knowledge from a vector store for FAQ-style questions. Account Tools (MCP) queries internal account services for customer-specific information. Transaction Tools (MCP) retrieves recent transaction history including deposits, withdrawals, and betting activity. Transfer-to-Agent Tool escalates to a human agent when the customer explicitly requests it or when the situation requires human judgment. The supervisor synthesizes the tool responses and returns a natural language response to the customer. Deep dive: Key architectural components In this section, we examine the four components that make the system work: the Amazon EKS hosting platform, the custom RAG pipeline, the responsible gaming classifier, and the guardrails that help keep conversations safe. Amazon EKS for agent hosting and MCP servers FBG runs their entire AI stack on Amazon EKS hosting their MCP server and Spring AI service as Kubernetes services. The MCP server exposes tools that make REST calls to external services like the account service and transaction-history service. Local tools live directly in the Spring AI service alongside the Claude large language model (LLM). These include the RAG tool and Transfer-to-Human tool. This approach provides several advantages for multi-agent systems. The MCP server and Spring AI service scale independently based on demand. When FBG needs to support additional business domains or features, adding a new MCP server is just another Kubernetes deployment. The team can also update individual tools without redeploying the entire system. New MCP tools are added to an existing MCP server without requiring new pod deployments. FBG uses Spring AI as its application framework, which provides native MCP support. The MCP server defines tools that the supervisor agent can discover and invoke dynamically. The team chose Spring AI because their developers had deep Java expertise, which let them move quickly. For teams working in Python, Strands Agents is an open source SDK from AWS that provides similar agent orchestration and MCP support. For teams considering a similar approach, Amazon EKS provides the container orchestration needed to manage multiple agent services at scale. MCP provides the standardized protocol for tool communication between agents. Teams that prefer a managed experience can also explore Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. AgentCore also supports MCP for tool integration. Custom RAG with Amazon Titan embeddings The most frequently used tool in the system is the RAG pipeline. FBG built a custom implementation rather than using a managed knowledge base, giving them precise control over the ingestion, chunking, and retrieval process. The pipeline works in this way. Support documentation is collected from upstream sources, including state-specific payment method guides, FAQ articles, responsible gaming resources, and account management guides. Documents are split using a token-based chunking strategy, meaning each document is divided into segments of a fixed number of tokens (the units of text a model processes) rather than by sentences or paragraphs. This gives the team fine-grained control over chunk boundaries. Chunks are then embedded using Amazon Titan V2, generating vector representations stored in MongoDB Atlas. When a customer asks a question, the system converts the query into a vector search-optimized form using an LLM, then performs a similarity search against the document store. For jurisdiction-specific questions, the system performs both a state-specific search and a general search, combining the results before passing them to the supervisor agent for response generation. This custom approach is particularly valuable when your knowledge base has complex retrieval requirements, like needing to combine state-specific and general documents in a single response. The knowledge base is continuously expanding, with hundreds of new documents added monthly as the team identifies gaps through conversation analysis. “Building our own RAG pipeline gave us full control over what the model sees and how it retrieves information. Every state has different rules, so we needed the ability to combine state-specific and general documents in a single response. That level of control made all the difference in accuracy.” — Sharoze Amir, Software Engineer, Fanatics Betting and Gaming Responsible gaming classification with Amazon Nova Responsible gaming is a regulatory requirement and a core value for FBG. The team worked with their compliance department to build a classification system. The system evaluates customer interactions to confirm responsible gaming standards are met and connects customers with the right resources when needed. The system uses Amazon Nova 2 Lite, a lightweight, fast classification model. The team chose a smaller model deliberately. The task is well-defined with clear examples and a limited set of outcomes, so a larger, more expensive model would add latency without improving accuracy. The model receives both the current message and the full conversation history, enabling it to detect escalating patterns rather than relying on single-message keyword matching. When the system identifies a high-severity concern, it immediately transfers the customer to a human agent with full conversation context. Lower-severity flags are recorded for compliance review while allowing the conversation to continue. This is a pattern that applies broadly: use the smallest model that meets your accuracy requirements for well-scoped classification tasks, and reserve larger models for open-ended reasoning. “Off-the-shelf support agents treat every conversation the same. Ours [truncated for AI cost control]