Fanatics Betting and Gaming 如何构建多智能体客户支持系统

Fanatics Betting and Gaming（FBG）在 AWS 上构建了一个多智能体客户支持系统，以解决体育博彩行业特有的挑战。客户期待立即获得准确答案，尤其是在分秒必争的直播赛事期间。客户会询问账户问题、充值限额、各州特定法规以及负责任博彩资源。规则会因运营商获牌开展业务的不同司法辖区而有所不同。基于决策树构建的传统聊天机器人解决方案难以应对这种复杂性，往往会令客户感到挫败，并随着人工坐席队列增长而推高成本。

Fanatics Betting and Gaming（FBG）是一个将先进技术与深厚体育专业知识相结合的体育博彩平台。作为 Fanatics 品牌家族的一部分，FBG 在美国多个州开展业务，服务于快速增长的用户群体；这些用户需要全天候支持，尤其是在 NFL 季后赛和超级碗等高流量赛事期间。

面对支持请求量的指数级增长，FBG 的工程团队在 AWS 上构建了一套多智能体 AI 系统，能够以比纯人工支持更快、更准确且成本低得多的方式解决客户问题。本文将介绍其架构、所涉及的 AWS 服务，以及你在设计自己的多智能体客户支持解决方案时可以考虑的模式。

挑战

随着 FBG 业务规模扩大，其现有支持模式要求每次交互增加更多人工介入，导致运营成本随客户群规模成比例增长。团队意识到，有机会在为下一阶段增长做好支持基础设施准备的同时，改善客户体验。有几个因素使这一问题尤为困难。

美国每个州对于支付方式、充值限额、提款时限及负责任博彩要求都有各自的规定。印第安纳州客户获得的答案与新泽西州客户不同。在重大体育赛事期间，支持请求可能激增至每两分钟超过 40 条咨询，系统必须立即扩展，同时不能降低响应质量。

查询类型的多样性进一步加剧了问题。客户询问的内容涵盖交易历史、账户设置、投注规则和自我排除选项等方方面面。没有任何单一模型或知识库能够覆盖全部内容。此外，运营商还必须实时识别并响应问题赌博迹象。这需要对对话上下文具备细致的理解，而不仅仅是关键词匹配。

FBG 需要一个能够自主处理这种复杂性，同时准确知道何时应升级给人工坐席的系统。

“随着我们的规模扩大，我们知道支持体验也需要与我们一同演进。我们希望为客户提供更快、更准确的答案，同时确保绝不在负责任博彩或合规方面妥协。目标是构建一个能够随时间不断变得更好的系统，而不只是变得更大。”

— Ian Botts，Fanatics Betting and Gaming 首席技术官

解决方案概览

FBG 没有依赖单一、庞大的聊天机器人，而是设计了一套多智能体系统，由专门的智能体处理客户交互中的不同环节。由于团队已在 Amazon Elastic Kubernetes Service（Amazon EKS）上积累了深厚的运营经验，因此可以基于既有容器平台来独立部署、扩展和迭代每个智能体。

FBG 选择 Amazon Bedrock，是因为它可通过单一 API 以模型无关的方式访问多个基础模型，使团队能够为每项任务匹配最合适的模型，并在出现更优选项时切换模型。由于 Bedrock 运行在其现有 AWS 环境中，系统也继承了 FBG 已建立的安全和治理控制；Amazon Bedrock Guardrails 则提供了其合规要求所需的负责任 AI 防护机制。

该架构遵循编排器模式。一个主编排智能体接收每条客户消息，与专用工具和子智能体协调，并返回统一响应。这种设计让团队可以添加新能力，例如新工具、新知识领域和新业务单元，而无需重写核心系统。

“我们设计该系统时，确保每个智能体都有明确职责，并且可以独立改进。这种模块化正是我们能够快速行动的原因。当需要支持新的案例类型或新的业务单元时，我们只需添加一个新工具或智能体，而无需触及系统的其他部分。”

— Luis Fernandez Rocha，Fanatics Betting and Gaming 高级软件工程经理

图 1 展示了高级架构。

图 1：AWS 上多智能体客户支持系统的端到端架构

客户消息通过 FBG 移动应用进入，经 Salesforce Einstein 传递至 Amazon EKS 上的 Spring AI 服务，随后流经 Amazon Bedrock Guardrails 和负责任博彩分类器，再到达 Supervisor Agent。Supervisor Agent 调用专用工具，包括检索增强生成（RAG）管道、账户和交易 Model Context Protocol（MCP）服务器，以及人工坐席转接工具，以生成响应。

请求如何在系统中流转

客户通过 FBG 移动应用发送消息，该应用连接 Salesforce Einstein 作为聊天界面层。请求通过标准 REST 调用被路由至运行在 Amazon EKS 上的 Spring AI 服务。该服务验证客户令牌并调用 AI 智能体。

请求随后会经过 Amazon Bedrock Guardrails，以帮助在到达 AI 层之前检测提示词注入。由 Amazon Nova 2 Lite 驱动的负责任博彩分类智能体，会根据经合规部门批准的分类框架评估每条消息。高严重性分类会触发立即转接至人工坐席，并附带完整的对话上下文。

运行在 Amazon Bedrock 上、使用 Anthropic Claude 的 Supervisor Agent，会根据客户意图决定调用哪些工具。视查询内容而定，监督智能体会调用一个或多个专用工具，其中部分通过 MCP 调用，另一些则在服务本地运行：

• 检索增强生成（RAG）工具会从向量存储中检索相关知识，用于回答 FAQ 类型的问题。
• 账户工具（MCP）会查询内部账户服务，以获取客户专属信息。
• 交易工具（MCP）会检索近期交易历史，包括充值、提款和投注活动。
• 人工坐席转接工具会在客户明确提出要求，或情况需要人工判断时升级至人工坐席。

监督智能体会综合工具响应，并向客户返回自然语言回答。

深入解析：关键架构组件

本节将分析使系统运行的四个组件：Amazon EKS 托管平台、定制 RAG 管道、负责任博彩分类器，以及帮助保持对话安全的 Guardrails。

用于智能体托管和 MCP 服务器的 Amazon EKS

FBG 将整个 AI 技术栈运行在 Amazon EKS 上，并将其 MCP 服务器和 Spring AI 服务托管为 Kubernetes 服务。MCP 服务器提供工具，通过 REST 调用访问账户服务和交易历史服务等外部服务。本地工具则直接位于 Spring AI 服务中，与 Claude 大语言模型（LLM）一起运行，包括 RAG 工具和人工转接工具。

这种方法为多智能体系统提供了多项优势。MCP 服务器和 Spring AI 服务可根据需求独立扩展。当 FBG 需要支持额外的业务领域或功能时，添加一个新的 MCP 服务器只需新增一次 Kubernetes 部署。团队还可以更新单个工具，而无需重新部署整个系统。新的 MCP 工具可被添加至现有 MCP 服务器，无需部署新的 Pod。

FBG 使用 Spring AI 作为应用框架，它提供原生 MCP 支持。MCP 服务器定义了监督智能体可以动态发现和调用的工具。团队选择 Spring AI，是因为其开发人员拥有深厚的 Java 专业能力，这使他们能够快速推进。对于使用 Python 的团队，Strands Agents 是 AWS 推出的开源 SDK，提供类似的智能体编排和 MCP 支持。

对于考虑采用类似方法的团队，Amazon EKS 提供了在大规模环境中管理多个智能体服务所需的容器编排能力。MCP 则提供了智能体之间工具通信的标准化协议。偏好托管式体验的团队还可以了解 Amazon Bedrock AgentCore；这是一个可使用任何框架或模型来大规模构建、连接和优化智能体的平台。AgentCore 同样支持通过 MCP 集成工具。

使用 Amazon Titan 嵌入模型的定制 RAG

系统中使用最频繁的工具是 RAG 管道。FBG 构建了定制实现，而不是使用托管式知识库，从而能够精确控制摄取、分块和检索流程。

该管道的工作方式如下：支持文档从上游来源收集而来，包括各州特定的支付方式指南、FAQ 文章、负责任博彩资源和账户管理指南。文档采用基于 Token 的分块策略进行拆分，即每份文档按固定数量的 Token（模型处理的文本单元）划分为多个片段，而不是按句子或段落拆分。这让团队能够精细控制分块边界。随后，文本块使用 Amazon Titan V2 生成嵌入向量，并将生成的向量表示存储在 MongoDB Atlas 中。

当客户提出问题时，系统会使用 LLM 将查询转换为适合向量搜索的形式，然后针对文档存储执行相似度搜索。对于司法辖区特定的问题，系统会同时执行州特定搜索和通用搜索，合并结果后再将其传递给监督智能体以生成回答。

当你的知识库具有复杂检索需求时，例如需要在单个响应中结合州特定文档与通用文档，这种定制方法尤具价值。知识库正在持续扩展，团队会通过对话分析识别缺口，并每月新增数百份文档。

“构建自己的 RAG 管道，让我们能够完全控制模型看到什么内容以及如何检索信息。每个州都有不同规则，因此我们需要能够在单个响应中结合州特定文档和通用文档。这种控制程度对准确性带来了决定性影响。”

— Sharoze Amir，Fanatics Betting and Gaming 软件工程师

使用 Amazon Nova 进行负责任博彩分类

负责任博彩既是监管要求，也是 FBG 的核心价值观。团队与合规部门合作构建了一套分类系统。该系统评估客户交互，以确认是否符合负责任博彩标准，并在需要时将客户连接至正确的资源。

该系统使用 Amazon Nova 2 Lite，这是一款轻量、快速的分类模型。团队有意选择较小的模型：该任务定义清晰，具有明确示例和有限的结果集合，因此更大、成本更高的模型会增加延迟，却无法提升准确性。

该模型同时接收当前消息和完整对话历史，使其能够检测不断升级的模式，而不是依赖单条消息的关键词匹配。当系统识别出高严重性风险时，会立即将客户转接给人工坐席，并附带完整对话上下文。较低严重性标记会被记录以供合规审查，同时允许对话继续进行。

这是一种适用范围广泛的模式：对于边界明确的分类任务，应使用能够满足准确性要求的最小模型；将更大的模型留给开放式推理任务。

“现成的支持智能体会以同样方式对待每一段对话，而我们的系统不能如此——一个关于提款的问题，实际上可能是一个负责任博彩时刻，识别这一点需要与我们的合规框架深度集成。这就是为什么我们选择在 AWS 上内部构建：没有任何供应商能够以我们行业所要求的方式处理这些敏感领域。”

— Trevor Gurgick，Fanatics Betting and Gaming 应用 AI 负责人

用于安全防护的 Amazon Bedrock Guardrails

FBG 使用 Amazon Bedrock Guardrails 来帮助防范提示词注入，并帮助确保对话处于适当边界之内。团队对 Guardrails 配置进行了调优，以在安全性与客户服务交互的实际情况之间取得平衡；在客户服务中，过度严格的过滤器可能会给客户体验带来阻碍。

关键洞察是：应根据实际用例调优 Guardrails，而不是默认采用最高限制。对于客户支持而言，提示词注入防护至关重要，但过于激进的内容过滤会产生令客户沮丧的误报。

多模型架构

FBG 在 Amazon Bedrock 上运行多模型架构，并采用有意识的自下而上方法进行模型选择。对于负责任博彩等分类任务，他们使用 Amazon Nova 2 Lite。它速度快、成本效益高，并且足以处理具有明确示例、定义清晰的分类任务。对于对话管理等监督和编排任务，他们使用 Amazon Bedrock 上的 Anthropic Claude Sonnet。Claude ha

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 can’t — a question about a withdrawal might really be a responsible gaming moment, and recognizing that requires deep integration with our compliance framework. That’s why we built on AWS in-house: no vendor was going to handle those sensitive areas the way our industry demands.”

— Trevor Gurgick, Head of Applied AI, Fanatics Betting and Gaming

Amazon Bedrock Guardrails for security

FBG uses Amazon Bedrock Guardrails to help protect against prompt injection and help keep conversations within appropriate boundaries. The team tuned their guardrail configuration to help balance security with the realities of customer service interactions, where overly restrictive filters can create friction in the customer experience.

The key insight: tune your guardrails to your actual use case rather than applying maximum restrictions by default. For customer support, prompt injection protection is critical, but overly aggressive content filtering creates false positives that frustrate customers.

A multi-model architecture

FBG runs a multi-model architecture on Amazon Bedrock, taking a deliberate, bottom-up approach to model selection. For classification tasks like responsible gaming, they use Amazon Nova 2 Lite. It is fast, cost-effective, and sufficient for well-defined classification where clear examples exist. For supervisor and orchestration tasks such as conversation management, they use Anthropic Claude Sonnet on Amazon Bedrock. Claude handles complex reasoning, tool orchestration, and natural conversation. For embeddings in the RAG pipeline, they use Amazon Titan V2, which generates high-quality vector representations. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock.

The team uses a round-robin strategy across model Regions for the supervisor agent, ensuring they never hit throughput limits during peak events. Because every model is accessed through the same Amazon Bedrock API, routing different workloads to different models requires no changes to the underlying infrastructure.

Results

Within the first two months of deployment, the multi-agent system delivered measurable improvements over FBG’s previous support experience, based on FBG’s internal metrics. The containment rate improved by approximately 56 percent, meaning more customer issues are now resolved without human agent involvement. Resolution rates improved by approximately 53 percent, with customers getting their problems actually solved rather than deflected. The system has resolved thousands of cases autonomously, representing significant cost savings because AI-powered interactions cost a fraction of human agent interactions. Customer satisfaction is also trending upward. Conversation quality has improved so significantly that customers frequently don’t realize they’re interacting with AI.

During peak sporting events, the system handles high request volumes while maintaining consistent performance and response quality. Amazon EKS autoscaling ensures that the MCP servers and Spring AI service add capacity automatically as traffic spikes, without requiring manual intervention. This means that whether it’s a quiet Tuesday or the Super Bowl, customers receive the same fast, accurate responses regardless of how many others are asking questions at the same time.

Continuous improvement: Evaluation and iteration

Building the agent is just the beginning. What makes FBG’s approach stand out is the investment they’ve made in continuously improving the system after deployment. The team treats their multi-agent system as a living product, not a one-time implementation. They review conversation logs, track resolution accuracy, and use real customer interactions to refine prompts, adjust tool behavior, and identify gaps in their knowledge base. This ongoing investment ensures that the system gets smarter over time rather than degrading as customer needs evolve.

At the core of their evaluation strategy is an LLM-as-a-Judge system that automatically reviews every completed conversation, classifying whether the AI successfully resolved the case or whether it fell short. An operations team reviews these evaluations daily, identifying patterns in where the agent struggles and filing improvement tickets to close those gaps. This creates a feedback loop where the agent gets measurably better over time.

On the engineering side, the team monitors system health through real-time observability metrics, including hallucination detection, latency, and cost tracking. When developing new features or testing changes, they pull actual customer conversations from production and replay them against the updated architecture to surface edge cases before anything reaches customers.

One discipline that has been particularly effective is the team’s approach to prompt engineering. Rather than jumping to a more powerful (and more expensive) model when performance dips, they first look at whether the system prompt can be improved or whether there are contradictions in the instructions. This keeps costs low while driving continuous quality improvements, and they only upgrade models when the prompt has been fully optimized for the task. Teams looking to systematize this discipline can use advanced prompt optimization in Amazon Bedrock, which refines prompts against evaluation criteria and compares results across multiple models before committing to a migration.

Getting started: Building your own multi-agent support system

If you’re looking to build a similar multi-agent customer support system, here’s a practical starting path.

Define your scope narrowly

FBG launched with just 4 of their over 20 case types. Starting narrow lets you prove value quickly, build evaluation infrastructure, and learn what works before expanding. Pick the case types with the highest volume and clearest resolution criteria.

Set up your infrastructure

Deploy your agent services on Amazon EKS for full control or use Amazon Bedrock AgentCore for a managed experience. Use MCP for communication between your orchestrator and tool services.

Build your RAG pipeline

Start with Amazon Bedrock Knowledge Bases, the fully managed RAG capability, or build a custom pipeline with Amazon Titan embeddings if you need fine-grained control over retrieval logic. Either way, invest time in your chunking strategy. It has more impact on response quality than model selection.

Implement guardrails and compliance from day one

Use Amazon Bedrock Guardrails to help protect against prompt injection. If your industry has compliance requirements (gaming, healthcare, finance), build classification agents early. They’re easier to integrate from the start than to retrofit later.

Start small with model selection

Use the smallest model that meets your accuracy requirements for each task. Reserve larger models for your orchestration agent where complex reasoning is needed. Amazon Bedrock makes it straightforward to swap models as you iterate.

Invest in evaluation early

Build your evaluation pipeline alongside your agent, not after. Track containment rates, resolution rates, and customer satisfaction from day one. Use LLM-as-a-Judge patterns to automate conversation review at scale.

Conclusion

Fanatics Betting and Gaming’s multi-agent architecture demonstrates how combining Amazon EKS, Amazon Bedrock, MCP, and purpose-built AWS AI services can deliver customer support that scales with your business while maintaining quality and compliance. By using specialized agents for different tasks, including orchestration, knowledge retrieval, classification, and tool execution, the system handles the complexity of state-specific regulations, real-time responsible gaming detection, and high-traffic sporting events.

The patterns in this post apply broadly. Define your scope narrowly, use specialized agents with clear responsibilities, choose the smallest model that meets your accuracy requirements, and invest in evaluation infrastructure from the start.

If you’re ready to build a similar multi-agent customer support system, start by defining your agent boundaries and identifying the tools each agent needs. You can deploy your agents on Amazon EKS for full control over scaling and orchestration or use Amazon Bedrock AgentCore for a managed runtime that handles infrastructure for you. For the AI layer, Amazon Bedrock gives you access to models like Anthropic Claude and Amazon Nova through a single API, and Amazon Bedrock Guardrails can help you add safety checks without custom code. To get started, see the Amazon Bedrock Getting Started guide and the Strands Agents documentation for an open-source Python framework that supports MCP-based tool orchestration.

---

About the authors

Parker Bradshaw

Parker is a Senior Solutions Architect at AWS, where he helps retail, ecommerce, and sports & entertainment companies put AI and data to work. From generative AI applications to large-scale storage architectures, he focuses on turning emerging technology into real business value rolling up his sleeves alongside engineering teams to build systems like the multi-agent architecture featured in this post. Parker holds an MBA from Utah Valley University and multiple AWS certifications. When he’s not building, he’s spending time with family or on the pickleball court.

Luis Fernandez-Rocha

Luis is a Senior Engineering Manager of Growth Engineering at Fanatics Betting and Gaming, where he works across search, machine learning, and generative AI. He focuses on customer experience, exploring how the intersection of these science-driven domains can streamline and elevate the overall user experience. When he’s not building, he’s out on the golf course or the padel court.

Sharoze Amir

Sharoze is a Senior Software Engineer at Fanatics Betting and Gaming (FBG) specializing in generative AI and agentic systems, where he serves as technical lead on one of the teams building AI products for the company. He led the development of FBG’s Customer Service AI Agentic platform, the first generative AI solution FBG delivered to its customers, taking it from prototype to production. With six years of experience spanning high-throughput backend systems, real-time data platforms, and agentic AI architecture and applications, Sharoze brings a blend of distributed systems and applied AI expertise that enables him to build robust agentic solutions that hold up in production. He previously worked at Mastercard and holds a B.S. in Computer Science from the University of Missouri – Columbia.

Trevor Gurgick

Trevor leads Applied AI at Fanatics, where he created the company’s enterprise AI strategy, ships AI agents, and drives internal transformation. He brings more than a decade of experience turning frontier research into real-world products, including autonomous hospital robots, next-generation fulfillment robotics at Amazon, and conversational AI for Alexa. When he’s not building, he teaches MIT research teams how to turn breakthroughs into businesses, spends his time cooking and chasing after his toddler.