Automating Trading Card Copywriting with Multi-Agent Generative AI

fanatics_collectibles · Media & Entertainment · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Trading-card copywriting and compliance

Fanatics Collectibles needed to create card-back copy at scale while researching player stats, maintaining brand voice, and complying with changing licensing and style requirements across sports properties.

Constraints:

• editors previously spent weeks researching stats and writing narratives
• licensing requirements and compliance rulebooks change frequently
• roster changes create urgent last-minute requests
• every card requires multiple QA rounds with internal teams and licensing partners
• long-running multi-agent batches must not depend on a live browser session

Architecture

Fanatics built a Bedrock multi-agent copywriting system. A user supplies player lists, theme, and requirements through a Streamlit UI. A Claude Opus 4 supervisor/writer agent orchestrates structured MLB stats retrieval, historical copy examples, web-search research through Lambda and Tavily, and copy generation. A QA agent then validates sections against MLB guideline knowledge bases, formatting rules, and character limits. Jobs run asynchronously so large batches can complete in the background.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  streamlit-ui[Streamlit UI] --> background-worker[Background worker]
  background-worker --> writer-supervisor-agent[Writer supervisor agent]
  stats-pipeline[Stats pipeline] --> stats-knowledge-base[Stats knowledge base]
  stats-knowledge-base --> writer-supervisor-agent
  historical-copy-knowledge-base[Historical copy knowledge base] --> writer-supervisor-agent
  writer-supervisor-agent --> web-search-agent[Web search agent]
  web-search-agent --> web-search-lambda[Web search Lambda]
  web-search-lambda --> tavily-api[Tavily API]
  writer-supervisor-agent --> qa-agent[QA agent]
  mlb-guideline-knowledge-base[MLB guideline knowledge base] --> qa-agent
  qa-agent --> qa-lambda[QA Lambda]

Components

Data flow

The UI submits player, theme, and requirement specifications as a background job. The Claude Opus 4 writer supervisor analyzes missing information, pulls historical examples and validated stats from knowledge bases, invokes web search through Lambda and Tavily when current information is needed, drafts card copy, and hands it to a QA agent. The QA agent checks sections against MLB guidelines, formatting rules, and character limits before results are shown back through the UI.

Why this architecture

Fanatics split the system into specialized agents and knowledge sources because card copy needs both precise structured statistics and qualitative storytelling. Sectional QA exists because simply placing all compliance documents in a knowledge base was insufficient; targeted context improved rule checking. Asynchronous workers were necessary because multi-agent and batch jobs can run for minutes or hours.

Models used: Claude Opus 4 · Amazon Bedrock · LLM writer agent · LLM QA agent

Scale

• Editors previously spent weeks researching and writing each player batch.
  “For each player badge, our editors spent weeks researching their latest stats, reading game summaries, and crafting a unique narrative for each of them.”transcript, stated
• Large runs may take hours for batches of 100 subjects.
  “each run can take several minutes if you have a multi-agent solution, right? Or even hours if we run, let's say, 100 subjects at a batch.”transcript, stated
• The system reduced edits required by the QA team by 40%.
  “First, 40 few 40% of fewer edits now required by the QA team. AI generated car back copy produced fewer errors and more consistently”transcript, stated
• Card-back creation became 90% faster.
  “Second, 90% faster car back creation. What it used to take weeks now takes like hours, can be run with minimal”transcript, stated
• Fanatics reported 90% production-creation savings.

  "And third, 90% of product creation saving.

Um AI-generated car backs cost minimal and compared to the traditional manual process."

— transcript, stated

• The CDK template was designed to scale from baseball to NBA, UFC, WWE, and other properties.
  “we developed the solution for baseball first. But we also have many sports and entertainment properties like NBA, UFC, WWE, etc.”transcript, stated

Alternatives considered (roads not taken)

Manual editorial research and compliance checking

Rejected because: It took weeks, created pressure under roster changes, and required repeated QA/licensing iteration.

Rely only on raw statistics

Rejected because: Raw stats did not provide enough narrative quality, so the team added stat ranking and qualitative web research.

Process all compliance context at once

Rejected because: The model missed rules even with documentation available, so Fanatics broke copy and guidelines into topical sections.

Synchronous web application processing

Rejected because: Browser timeouts, network drops, and sleeping laptops made long-running jobs unreliable.

Build production infrastructure from day one

Rejected because: Starting in the Bedrock GUI let the team learn, test prompts, compare models, and understand behavior quickly before moving to CDK.

Patterns

multi-agent-orchestration (orchestration)

A Claude Opus supervisor coordinates writer, web-search, and QA agents with knowledge bases and Lambda tools.

rag-retrieval (retrieval)

Bedrock knowledge bases ground generation and QA in player stats, historical examples, style guides, and licensing requirements.

tool-use-orchestration (orchestration)

The writer agent invokes Lambda-backed Tavily web search and the QA agent uses a Lambda function for formatting and character-limit checks.

guardrails-io-filtering (safety)

A QA agent checks generated copy against licensing requirements, style guidelines, formatting rules, and character limits.

async-message-orchestration (operations)

Long-running card-copy jobs are submitted from the UI to background workers and later surfaced through status/progress polling.

prompt-versioning (prompting)

The system injects historical card-copy examples as few-shot style anchors for the generation prompt.

Tradeoffs

Combine structured stats with qualitative web research

Chose parallel stats knowledge base plus web-search agent over using raw official statistics alone.

Rationale: Raw stats were accurate but insufficient for compelling narrative copy, so the architecture adds qualitative current-player context when needed.

Use sectional QA instead of one broad compliance pass

Chose topic-sorted guidelines and section-by-section QA review over processing all generated copy and compliance documents at once.

Rationale: Targeted context improved the QA agent's catch rate after the model missed rules in a large knowledge base.

Start in the Bedrock GUI before CDK

Chose fast console experimentation for the first proof of concept over immediate infrastructure-as-code deployment.

Rationale: The GUI allowed prompt testing, model comparison, and system learning in hours before the team invested in repeatable CDK deployment.

Use asynchronous background processing

Chose job submission, independent worker processing, and UI status checks over having the web UI wait for whole jobs to finish.

Rationale: Batches and multi-agent runs can take long enough that synchronous browser sessions are unstable.

Generalize the deployment as a reusable CDK template

Chose build once and deploy across sports properties over rebuilding separate systems from scratch for each sport.

Rationale: Each sport has different rules, but the core architecture can be reused with license-specific configuration.

Gotchas (what bit them)

The LLM missed compliance rules even with documentation available.

Root cause: A large knowledge base alone did not surface the most relevant rules at the right time.

Resolution: Fanatics broke copy and guidelines into sections so the QA agent reviewed targeted content against targeted rules.

Generated copy tended toward dramatic and repetitive language.

Root cause: The model's style preferences did not automatically match card-brand voice and set-level variety needs.

Resolution: The team added progressive word tracking and injected historical card-back copy as examples.

Synchronous UI processing was unreliable for long-running batches.

Root cause: Multi-agent jobs can take minutes or hours, while browsers and networks can time out or disconnect.

Resolution: The UI submits jobs to background workers and later checks status and results.

The first AI copy experiment exposed temporal sequencing weaknesses.

Root cause: The model struggled with concepts like next-night ordering and time sequence.

Resolution: Those findings informed the Bedrock production design and the need for guardrails.

Evaluation

Fanatics ran a collector proof of concept comparing human and AI card-back copy, then measured operational outcomes in production such as QA edit reduction, speed, and cost savings.

Metrics: high collector acceptance rate for AI-generated copy · no significant preference between AI-generated and human-written copy in the small test set · 40% fewer QA edits · 90% faster card-back creation · 90% production creation savings

Outcomes

• Collectors accepted AI-generated card-back copy at rates comparable to human copy in the POC.
• Production time moved from weeks to hours or under a day.
• The QA team needed 40% fewer edits.
• Fanatics reported 90% creation-cost savings.
• Editors could spend more time on high-value creative work.

The system supports large batches such as 100 subjects and was designed to scale from baseball to multiple sports and entertainment properties.