The atmosphere during an NFL playoff game or the Super Bowl is one of extreme volatility, where a single play can shift millions of dollars in bets within seconds. For the users of Fanatics Betting and Gaming (FBG), this intensity translates into a desperate need for immediate, accurate information. When a bet is on the line, a delay of a few minutes or a vague answer from a chatbot is not just a nuisance; it is a catalyst for customer churn. During these peak windows, FBG faces a staggering surge in volume, processing upwards of 40 requests every two minutes. The pressure is compounded by a fragmented legal landscape, as sports betting in the United States is governed by a patchwork of state-level regulations. A user in Indiana faces different deposit limits and withdrawal schedules than a user in New Jersey, and the rules regarding responsible gaming vary wildly across borders. For years, the industry standard was the decision tree chatbot, but these rigid structures collapsed under the weight of such complexity. Every new state regulation required a new branch in the tree, creating a maintenance nightmare that inevitably pushed frustrated users toward human agents, driving up operational costs and wait times.
The Orchestration of Bedrock and Specialized Agents
To break this cycle, FBG moved away from monolithic bot logic toward a model-agnostic orchestration layer powered by Amazon Bedrock. By standardizing their API approach, the team ensured they were not locked into a single LLM provider, allowing them to swap models as the state of the art evolves without rewriting their entire codebase. At the heart of this system is a Supervisor Agent based on Anthropic Claude. This agent does not attempt to answer every question itself; instead, it acts as a high-level dispatcher. When a customer query arrives, the Supervisor Agent extracts the intent and determines which specialized tool is best equipped to handle the request. Whether the user is asking to change account settings or verify a complex transaction history, the Supervisor Agent manages the workflow, calling the necessary tools and synthesizing the raw data into a natural language response. If the first tool provides an insufficient answer, the agent can dynamically reconfigure the query or call additional tools before finalizing the output.
Safety and compliance are integrated directly into the request pipeline rather than being treated as an afterthought. Before a prompt even reaches the AI logic, Amazon Bedrock Guardrails scan for prompt injection attacks and malicious inputs. Once cleared, the message is routed to a specialized classification agent powered by Amazon Nova 2 Lite. This agent serves as a dedicated compliance officer, scanning every interaction in real-time for signs of gambling addiction or violations of responsible gaming regulations. Because the legal stakes are so high, this agent is programmed with a strict trigger: if a high-risk scenario is detected, the AI immediately terminates the automated flow and initiates a transfer-to-human. To ensure a seamless transition, the system passes the full conversation context and the AI-analyzed intent to the human agent, eliminating the need for the customer to repeat their grievance.
Decoupling Logic via MCP and Spring AI
The true architectural shift occurs in how the AI interacts with external data. Traditionally, connecting an LLM to a REST API requires custom glue code for every single endpoint, creating a brittle system where a minor API change can break the entire agent. FBG solved this by implementing the Model Context Protocol (MCP). By standardizing the way agents communicate with external data sources, FBG created a universal interface for account services and transaction histories. This means that when a new data source is added or an existing API is updated, the team only needs to modify the tool definition within the MCP server. The Supervisor Agent automatically recognizes the updated specification without requiring a change to its core prompts.
Because FBG operates within a heavy Java enterprise environment, they integrated the Spring AI framework to provide native MCP support. This allows their engineers to manage MCP servers using Java, bridging the gap between modern AI orchestration and legacy enterprise stability. The system distinguishes between local tools and MCP server tools based on the nature of the task. RAG-based tools that search internal knowledge bases or simple state-change tools are handled locally. In contrast, functions requiring real-time external data, such as checking a user's current balance or betting history, are delegated to the MCP server. For teams preferring Python, the AWS open-source SDK Strands Agents provides a parallel path for implementation.
This modularity extends to the deployment layer. FBG hosts its Spring AI services on Amazon EKS (Elastic Kubernetes Service), with Salesforce Einstein serving as the front-end chat interface. By running the MCP servers and Spring AI services as independent Kubernetes services, FBG can scale specific components of the AI pipeline without redeploying the entire system. If a specific agent—such as the one handling transaction queries—experiences a surge in demand during a game, the team can scale only those specific pods. This prevents resource waste and ensures that a spike in one area of the service does not degrade the performance of the entire support ecosystem. This decoupled approach means that adding a new business unit or a new state's regulatory logic is as simple as deploying a new MCP tool, reducing deployment risk to nearly zero.
The transition from a rigid decision tree to a modular, multi-agent architecture transforms customer support from a cost center into a scalable asset. By separating intent extraction, regulatory filtering, and data retrieval into independent modules, FBG has created a system that evolves as fast as the sports betting market itself.
