Fanatics Betting's multi-agent support build: the axis that matters is the state line

Amazon Web Services has published the architecture behind Fanatics Betting and Gaming's multi-agent customer support system: specialized agents deployed on Amazon EKS, with foundation models called through Amazon Bedrock under an orchestrator pattern ^{[1][10][11][12][14]}. The reason to read it is not the agent count but the failure mode it is aimed at, which is that the correct answer to a support question changes when the customer crosses a state line ^[4].

FBG operates across multiple US states ^[6]. Every state sets its own rules for payment methods, deposit limits, withdrawal timelines and responsible gaming requirements, so a customer in Indiana gets a different answer than one in New Jersey, according to the AWS post ^[4]. That is four rule categories multiplied by jurisdiction before anyone has asked an actual question ^[17]. The post is blunt about the consequence: chatbots built on decision trees struggle with this, frustrating customers and pushing cost into human agent queues ^[3]. FBG's prior model required more human touches per interaction, so operating cost grew proportionally with the customer base ^[7].

The instinct when decomposing a support system is to cut by intent: a deposits agent, an account agent, a betting-rules agent. That design puts the jurisdiction table inside every agent. A single rule change in one state then becomes an edit to several agents plus a regression pass over every intent they serve, which is the same coupling that made the decision tree unmaintainable, just wearing a model. Cutting along the jurisdiction axis puts the volatile, audited material in one place and lets intent handling stay generic. Volume is elastic; regulation is not.

To be precise about what the post claims: it does not say FBG sharded agents by state. It describes agents with clear responsibilities that can be improved independently, and says new case types or business units are handled by adding a tool or an agent rather than rewriting the core ^[14][16]. Bedrock was chosen for model-agnostic access through one API so each task can be matched to a model and models swapped later ^[12], and because it runs inside FBG's existing AWS environment the system inherits established security and governance controls, with Bedrock Guardrails supplying the compliance safeguards ^[13].

Two constraints resist any clean decomposition. During major events such as NFL playoffs and the Super Bowl, inquiries can surge past 40 every two minutes, which works out to 20 a minute or about 1,200 an hour, and the post says quality must not degrade under that load ^[5][6][18]. And operators have to spot and respond to signs of problem gambling in real time, which the post says needs conversational context rather than keyword matching ^[8]. Detection is cross-cutting; the thresholds and required resources are local ^[4].

CTO Ian Botts says the goal was faster, more accurate answers without compromising responsible gaming or compliance, and something that got better over time rather than just bigger ^[15]. AWS says the system resolves issues faster, more accurately and at a fraction of the cost of human-only support, with no figure attached in the post ^[19].

Watch whether launching in a new state is a configuration entry or a new agent, since that is the real test of the modularity claim ^[14]. Watch how model swaps are revalidated per jurisdiction once Bedrock makes swapping cheap ^[12]. And watch the escalation threshold: the stated requirement was autonomy plus knowing exactly when to hand off to a human ^[20].