One work, many titles: tagging and grouping a streaming catalog

A streaming catalog is full of duplicates. The same series shows up on Netflix, Prime, and a regional service — each with its own listing and its own noisy title. It shows up again across countries: a Japanese title on a JP platform, a Korean listing, a US listing, each in a different script and a different local name. And sitting right next to those genuine duplicates are look-alikes that must stay apart: a 1997 film and its 2025 reboot, a series and its movie spin-off, a generic bucket that should never be grouped by name at all.

The business needs one simple thing from all of this: one work, one identity, so engagement rolls up correctly and every title carries consistent metadata. Getting there is two jobs, and they’re not the same job.

Job	What it is	Nature
Grouping	Collapse every listing of the same work into one collection so metrics aggregate correctly.	Entity resolution — mostly deterministic.
Tagging	Give each title consistent attributes: genre, type, country, language, studio, official English title.	Enrichment — deterministic where a source exists, judgment where it doesn’t.

1 · Deterministic where you can, agents where you can’t

The most important design decision: an AI agent is the wrong tool for the part that must be exact and auditable, and the right tool for the fuzzy minority.

Grouping has a strong key. If two listings carry the same authoritative id (an IMDb id), they are the same work — merge them. If there’s no id, a deterministic fallback key does the job: (platform, cleaned English title, type, year). Rules handle the overwhelming majority cleanly:

• Same authoritative id → one collection across every platform.
• One id per group, one group per id — never merge two different works, never fragment one.
• Different year → a remake → a separate work (Anaconda 1997 ≠ 2025).
• Type must match — a series and its movie are two works (Dr. Stone the series ≠ the film).
• Generic labels are never grouped by title.

⚠ The failure mode to design against. Hand the whole job to one big LLM and you recreate the classic bug: enrichment guesses the wrong id for the 2025 reboot, so it gets merged into the 1997 collection, and now a stakeholder sees the wrong show’s numbers. The model didn’t “hallucinate a sentence” — it silently corrupted a join key, with no clean trail to unwind it. The agent never writes the group id and never invents an authoritative id. It proposes; deterministic rules and a human decide.

That leaves the agent the hard ~6%: the same work across countries with different local titles and no shared id, ambiguous remakes and spin-offs, and non-Latin official titles that need resolving. That’s where judgment beats a lookup — and exactly where you want a capable model, tightly fenced.

2 · The workflow, phase by phase

Six phases. Deterministic steps stay as code you can test; the agent is invoked inside just two of them, and only for the cases the rules can’t close.

flowchart LR
  A[Crawl platforms] --> B[Clean titles]
  B --> C[Enrich and tag]
  C --> D{Group}
  D -->|id or fallback key| E[Deterministic merge]
  D -->|hard case| F[Agent adjudication]
  F --> G[Human approve]
  E --> H[QC rules]
  G --> H
  H --> I[Apply - reversible]

1. Crawl. Pull each platform’s catalog. A title with no catalog entry is crawled properly, never band-aided in with a title-only insert — that’s how phantom records and mis-merges start.
2. Clean titles. Strip noise with a fixed rule engine: season/part/episode markers, bracketed meta-tags, dub/sub labels, trailer keywords, dangling brackets. Cleaning normalizes; it does not translate. If the cleaned result is still non-Latin, fall back to the crawled pipeline English title.
3. Enrich & tag. Fill the attributes: genre (a fixed, priority-ordered master list), type, country, language, studio, and the official English title — the most critical field for grouping later. Source priority is explicit (authoritative id > drama/anime databases > platform), and trusted sources differ by market. The agent resolves only what the sources can’t.
4. Group. Join on the authoritative id; fall back to the deterministic key. The agent adjudicates only the leftover hard candidates, and only proposes.
5. QC & confidence. Run the rule catalogue: two ids in one group, one id split across groups, type mismatch, a remake merged with its original. Run conflict checks on the raw per-platform data, not the resolved view — the view masks per-member id conflicts. Keep two separate confidence signals, never one blended number.
6. Apply. Every write is reversible: dry-run first, back up, record history under a tag, support rollback. Single-record corrections are a split + edit that reassigns a fresh group id — not a full pipeline re-run.

3 · Where the agent earns its keep

Most candidate pairs are decided by rules before the model is ever asked. The agent sees only what’s left, and its answer is a recommendation with evidence — not a database write.

flowchart TD
  P[Record + candidate collection] --> Q{Same authoritative id?}
  Q -->|yes| S[SAME - merge]
  Q -->|no| R{Same type AND year?}
  R -->|no| X[DIFFERENT - keep separate]
  R -->|yes| Y{Generic label?}
  Y -->|yes| X
  Y -->|no| Z[Agent judges cross-title / cross-country]
  Z -->|high confidence + evidence| S
  Z -->|unsure| U[Route to operator]

The adjudicator’s job is narrow and its output is structured: a decision (SAME / DIFFERENT / UNSURE), the target group, the reasons, the evidence it checked (id, titles across platforms, year, type), and its own confidence. It reads ground truth to verify — it does not trust its own memory of what a title “should” be.

⬡ The same discipline for English titles. Resolving an official English title for a non-Latin listing follows the same shape: try the authoritative display title, then a drama/anime database, then an AI ensemble — but auto-apply only when the engines agree and the agreed title shares a real word with a literal translation of the native title (an anchor). Everything unanchored goes to review. That one gate is what stops a model from confidently turning a title into the wrong name.

4 · Building it on Hive

Hive doesn’t replace your pipeline — it hosts the judgment layer and the operator tools. Your deterministic code stays; Hive gives the agents a home, a memory, tools, guardrails, and evals. The key move is four narrow agents, not one do-everything bot:

Agent	Engine	Does	Must not
Match Adjudicator	smart	Decide SAME/DIFFERENT on hard candidate pairs; verify against the id ground-truth data.	write a group id · invent an id
Tagger / Enricher	fast → smart	Genre, type, country, language, studio; returns its own confidence + citations.	overwrite the English title · compute the trust score
Title Resolver	reuse existing tool	Wrap your English-title resolver; triage the review queue and explain low-confidence cases.	drop the anchor / agreement gate
QC Reviewer	smart	Explain flagged violations on raw per-platform data; recommend split + edit.	suggest a full re-run for a single fix

Register what you already have. A read-only database tool gives the agents the id ground-truth table, the raw per-platform table (to catch masked conflicts), and the resolved view — the single most important integration, because it lets the agent verify instead of guess. Existing tools — your English-title resolver, your apply/preview tooling — are reused, not rebuilt, and only the dry-run side of “apply” is exposed to agents. A knowledge base grounds every agent in your rules — the collection rules, the master-genre list, the per-market source tiers, the QC catalogue — rather than generic priors.

Production stays in control of the pipeline and calls each agent as a service for its one fuzzy step; operators work the review queue from a workflow or chat. The orchestrator never owns the deterministic decisions.

5 · Guardrails that keep it honest

Each of these maps to a scar from doing this the hard way:

• Propose, never write. Agents emit suggestions plus confidence; a deterministic gate and a human approval step apply them.
• Two confidence signals, never blended. Keep the model’s own confidence separate from an objective, market-aware trust score derived in code. Don’t let the agent overwrite the trust number.
• Auto-apply only when it’s verifiable — a ground-truth id match, or engine agreement with an anchor. Everything else routes to an operator.
• Everything reversible — dry-run, backup, tagged history, rollback; single-record fixes are split + edit. The agent never does an irreversible write.
• Audit every decision. A run log records each agent call — tokens, cost, latency, status, error — so a bad batch is traceable and killable.
• Cost discipline. A capable model for adjudication and QC; a fast, cheap model for high-volume tagging. Caching and per-model caps keep a big backfill from becoming a big bill.

6 · Lock the behaviour with evals

The catalog’s hardest cases are known. Turn each into a graded test so no prompt tweak or model swap can quietly regress it. An agent’s golden set runs the moment you edit it, and pings you if anything fails.

Agent	Golden case	Expected
Adjudicator	Anaconda 1997 vs 2025	DIFFERENT
Adjudicator	Dr. Stone series vs movie	DIFFERENT (type)
Adjudicator	Same work JP + KR + US, shared id	SAME
Adjudicator	A generic content bucket	Never group by title
Title Resolver	A dual-script (native + Latin) title	Keep the Latin name
Title Resolver	A romaji title with no anchor	Route to review, don’t guess
Tagger	Known genre / type / country mappings	Match the master rules

These are cheap to build and they compound: every production mis-tag you fix becomes a new eval, and the set grows toward the exact edges your catalog actually hits. It’s the same loop that separates a demo from something you can depend on.

The model isn’t the moat here — your rules, your ground-truth data, and your evals are. Keep the deterministic core exact and auditable, fence the agent to the judgment it’s actually good at, gate every write behind verification and a human, and lock it all down with a golden set. That’s how you tag and de-duplicate a global catalog with AI in the loop and keep it trustworthy.

Examples (Anaconda, Dr. Stone) are public titles used for illustration. The workflow generalizes to any multi-platform, multi-market catalog where one work must have one identity — and it’s exactly the kind of system we build on Hive.