Fanatics AI support system uses AWS multi-agent design model

Editorial visualization of Fanatics' AWS multi-agent support workflow for sports betting customer service.

Fanatics details its multi-agent customer support stack​

Fanatics Betting and Gaming has described an AWS-based multi-agent customer support system built for the operational demands of U.S. sports betting. The system uses specialized AI agents, retrieval tools, responsible gaming classification and human escalation rather than a single decision-tree chatbot. AWS reports measurable early improvements from Fanatics' internal metrics, but those figures should be read as company-reported results from a vendor case study, not an independent audit.

Why sports betting support needed a different design​

Fanatics Betting and Gaming built the system to handle support questions that change by jurisdiction, event timing and customer context. According to AWS, customers ask about account issues, deposit limits, withdrawal timelines, betting rules and responsible gaming resources, while rules differ across the U.S. states where an operator is licensed.

That variability makes simple chatbot flows brittle. A customer in Indiana can require a different answer than a customer in New Jersey, and a message about a withdrawal can also carry responsible gaming implications. The source says support requests can rise to more than 40 inquiries every two minutes during major sporting events, creating a need for systems that scale quickly without pushing every edge case into a human queue.

Fanatics CTO Ian Botts said the company wanted faster and more accurate answers while not compromising on responsible gaming or compliance. The implication is that Fanatics treated customer support as a regulated workflow problem, not only as a conversational interface problem.


How the request moves through the stack​

The architecture follows an orchestrator pattern in which one supervisor agent coordinates specialized tools and sub-agents. AWS says a customer message enters through the Fanatics Betting and Gaming mobile app, passes through Salesforce Einstein, and then reaches a Spring AI service running on Amazon Elastic Kubernetes Service.

From there, the request moves through Amazon Bedrock Guardrails and a Responsible Gaming classifier before reaching the Supervisor Agent. The supervisor can call a Retrieval Augmented Generation tool, account and transaction tools exposed through Model Context Protocol servers, and a transfer-to-agent tool for escalation.

This design matters because the customer receives one response while the system can split the work behind the scenes. A question about a recent deposit, for example, may require transaction data, account context and state-specific policy retrieval before the final answer is assembled.


RAG handles changing rules and support documents​

The most used tool in the Fanatics system is its custom Retrieval Augmented Generation pipeline. Instead of relying on a managed knowledge base, the team built its own ingestion, chunking and retrieval process to control what information the model receives.

AWS says the pipeline collects support documentation from sources such as state-specific payment method guides, FAQ articles, responsible gaming resources and account management guides. Documents are split with a token-based chunking strategy, embedded with Amazon Titan V2, and stored as vectors in MongoDB Atlas. For jurisdiction-specific questions, the system performs both state-specific and general searches, then combines results for the supervisor agent.

That approach reflects a practical constraint in betting support: the correct answer is often a blend of broad company guidance and local rule detail. Fanatics software engineer Sharoze Amir said the custom RAG pipeline gave the team control over what the model sees and how it retrieves information.


Responsible gaming checks sit before the supervisor​

Fanatics placed responsible gaming classification early in the flow rather than treating it as a post-processing step. AWS says the classifier uses Amazon Nova 2 Lite and evaluates both the current message and the full conversation history against a compliance-approved framework.

High-severity classifications trigger immediate transfer to a human agent with full conversation context. Lower-severity flags are recorded for compliance review while the conversation can continue. This structure is designed to detect escalating patterns instead of relying only on keyword matches in a single customer message.

Trevor Gurgick, Fanatics' head of applied AI, said off-the-shelf support agents treat conversations too uniformly for this use case. The reported design shows why regulated consumer AI deployments often need industry-specific classifiers in addition to general-purpose language models.


EKS, Bedrock and multiple models split the workload​

Fanatics runs its AI stack on Amazon EKS, including MCP servers and the Spring AI service. AWS says this lets the MCP server and Spring AI service scale independently, while additional MCP servers can be added as Kubernetes deployments when new domains or features are needed.

The model layer is divided by task. Amazon Nova 2 Lite is used for the responsible gaming classifier, Anthropic Claude Sonnet on Amazon Bedrock is used for supervisor and orchestration work, and Amazon Titan V2 is used for embeddings in the RAG pipeline. Fanatics also uses Amazon Bedrock Guardrails to help detect prompt injection and keep interactions within intended boundaries.

The architecture shows a cost and latency tradeoff common in production AI systems. Smaller models can handle narrow classification tasks, while larger reasoning models are reserved for orchestration and conversation management.


Early results are company-reported, not independently verified​

AWS says Fanatics recorded measurable gains within the first two months of deployment, based on Fanatics' internal metrics. The source reports an approximate 56 percent improvement in containment rate and an approximate 53 percent improvement in resolution rates compared with the previous support experience.

The source also says the system has resolved thousands of cases autonomously and that customer satisfaction is trending upward. Those claims are material but should be read with attribution because the packet does not include an independent measurement methodology, sample size, external audit or full baseline data.

Fanatics also built an evaluation loop around the system. AWS says an LLM-as-a-Judge process reviews completed conversations, while an operations team checks results daily, identifies failure patterns and files improvement tickets. Engineering teams monitor hallucination detection, latency and cost tracking, and replay production conversations against updated versions before changes reach customers.


Conclusion​

Fanatics' case study is a useful example of how multi-agent systems are moving from AI demos into regulated customer operations. The notable point is not merely that a sportsbook used a chatbot, but that the support flow separates orchestration, document retrieval, account tools, transaction tools, safety checks and human escalation.

The evidence comes from AWS's own Machine Learning Blog, so the performance figures remain company-reported. Still, the architecture details are specific enough to show the direction of enterprise AI support: fewer monolithic bots, more task-specific agents, and more compliance logic embedded directly into the conversation path.


Sources​


Editorial Team - CoinBotLab
  • Reading time 5 min read
  • Views4
  • Reading time 5 min read
  • Views4
  • Reading time 6 min read
  • Views9
  • Reading time 5 min read
  • Views12
  • Reading time 6 min read
  • Views13
  • Reading time 5 min read
  • Views12

Comments

There are no comments to display

Information

Author
CoinBotLab AI Editor
Published
Reading time
5 min read
Views
3

More by CoinBotLab AI Editor

Top