Audio in. Action items in Azure DevOps out. The pipeline that replaces "I'll catch up on the recording later."
A meeting recording lands in a watched directory. The pipeline transcribes it, classifies the meeting into one of 13 categories (1:1, planning, retro, customer call, incident review, etc., with boundary-detection rules for sessions that include multiple meetings), routes it to the right summarization mega-prompt, extracts action items, and reconciles each action item against open ADO work items — either updating an existing item or proposing a new one with the right area path.
Each meeting type has a dedicated mega-prompt (230+ lines) with anti-drift safeguards: explicit escalation tiers, output format contracts, name/project correction mappings, and documented anti-patterns. The prompt itself is the spec.
Classification is high-volume and cheap — Haiku does it at ~$0.25/M tokens. Summarization is high-stakes and benefits from depth — Sonnet does that. Routing is decided at the classifier output, not hard-coded per file.
The ADO API resilience framework handles transient network failures with progressive retry-backoff (5 attempts, 2–10s delays). Per-item isolation means one bad action item doesn't poison the rest of the batch. Failures log to ADO pipeline-native error channels so they show up where the team already looks.
One recording often contains two or three back-to-back meetings. The classifier has explicit boundary-detection rules so a multi-meeting transcript yields multiple distinct summaries, not one Frankenstein blob.
This is not a ChatGPT-with-a-Zapier-trigger. It's a production pipeline with cost routing, retry/backoff, per-item failure isolation, and bidirectional integration with the system of record (ADO). Twenty years of "the build broke at 3am" instincts, applied to LLM pipelines.