From a Meeting Recording to a Structured Action-Item List on One Key: Chaining Transcription, Extraction and Dedup

Why split the pipeline into stages

A meeting recording is a single input, but the work inside it is several different jobs. Audio becomes text. Text becomes structure. Structure becomes a reliable, deduplicated list. If you try to do all of that in one prompt, you usually get a mediocre transcript, a loosely formatted list, and duplicates you have to fix by hand.

Splitting the pipeline into stages gives you three benefits:

• Backend choice per stage. Transcription needs an audio-capable model; extraction and reconciliation are pure text tasks that can run on whichever text model fits your budget and quality bar.
• Inspectable intermediate artifacts. You keep the transcript and the raw extraction as separate records, which makes failures easy to debug and results easy to audit.
• Cheaper iteration. When you want to change the extraction schema or the dedup rule, you re-run only that stage against the saved transcript instead of re-uploading and re-transcribing audio.

On an API aggregator that exposes many models behind one key, you can move between backends per stage without touching your credentials or billing setup.

Stage 1: Transcribe the recording

Send the audio file to a model that accepts audio input and returns text. Practical points:

• Preprocess lightly. Convert to a common format, keep a mono channel, and check that the file is within the provider's supported size and duration limits. Long meetings may need to be chunked.
• Keep timestamps if the model returns them. Segment-level timestamps make it much easier later to resolve conflicting attribution ("who said they would do this?").
• Store the transcript as an artifact. Write it to disk or object storage with the source file hash. Every later stage reads from this saved transcript, not from the audio.
• Watch speaker information. Speaker diarization is not guaranteed on every backend. If you need speaker labels, confirm the chosen model produces them, or plan a separate diarization step.

Stage 2: Extract action items into a schema

Treat extraction as a structured-output problem, not a free-form summarization problem. Define a schema first, then ask the model to fill it.

A workable item schema:

• task: a short imperative description of what needs to happen.
• owner: the person responsible, or null if unassigned.
• due: a date or relative deadline as stated, or null.
• source_quote: the transcript span that justifies the item.
• confidence: the model's own assessment, if your backend exposes logprobs or you ask for a coarse label.

Guidelines that materially improve results:

• Give the model the schema explicitly. Include field names, types, and allowed nulls. JSON-schema-style constraints help when the model supports structured output.
• Require a source quote per item. This is the single best guard against invented tasks and makes the dedup stage much easier.
• Define what counts as an action item. "Someone committed to doing something with a verb and an object" is clearer than "anything actionable."
• The task: state this definition in the prompt and repeat it in your evaluation notes.
• Chunk long transcripts. Provide a small overlap between chunks so a sentence split across a boundary is still visible to the model, then merge items and discard exact repeats.

Stage 3: Run extraction on more than one model (optional but useful)

Different models catch different things. One may surface an implicit commitment that another skips; another may be stricter about what counts as an action.

A pragmatic pattern:

1. Run the same extraction prompt against two text backends.
2. Keep both raw outputs, tagged by model.
3. Merge the candidate lists into one pool before dedup.

This raises recall but also raises the duplicate rate, which is exactly why reconciliation is the next stage. Do not run a large ensemble by default; two backends is usually enough to see the benefit, and you can add a third when recall matters more than cost.

Stage 4: Reconcile and deduplicate

Duplicate action items rarely look identical. Two models may phrase the same commitment as "Prepare Q3 budget draft" and "Draft budget for next quarter," possibly with different owners or deadlines. Exact string matching will miss most of these.

Use a two-pass approach.

Pass A: deterministic normalization

• Trim whitespace and normalize case and punctuation.
• Normalize dates to a single format where possible; keep unparseable deadlines as raw strings.
• Drop items with empty task fields and items whose source_quote cannot be located in the transcript.
• Collapse items that are byte-identical after normalization.

Pass B: model-assisted clustering

Send the normalized candidate list to a text model and ask it to group items that refer to the same real-world action. Ask for a grouping keyed by item id, not rewritten text, so you can trace every merged group back to its inputs.

Rules to give the model:

• Merge only when the underlying action, owner, and timeframe are compatible. If owners conflict, keep both and flag the conflict.
• Prefer the phrasing with the clearest verb and object, but do not invent details.
• Preserve every source_quote from the merged members.

When groups come back, apply deterministic merge rules in your own code: choose one representative task, reconcile owner and due by majority or by earliest explicit date, and keep all quotes as evidence.

Stage 5: Validate before you ship

Before the list leaves your pipeline, run a few cheap checks:

• Quote grounding. Every final item's source_quote should appear (fuzzily) in the transcript. Drop or flag items that fail.
• Field sanity. Owners should look like names or roles mentioned in the transcript; deadlines should parse or be explicitly flagged as unparsed.
• No silent invention. An item with no quote should be removed, not repaired.
• Deterministic output. Sort the final list (for example by owner, then by task) so reruns produce stable diffs.

Log the discarded and merged items alongside the final list. That log is what lets you tune the prompt and the merge rules over time.

Where a single key helps

The pipeline touches several model families: an audio-capable backend for transcription, at least one text backend for extraction, and optionally another for reconciliation. With one API key across providers, stage configuration becomes a code change, not a procurement project. You can swap the extraction model, compare two backends, or move reconciliation to a cheaper model without renegotiating access.

Cost and credit notes

On this aggregator, usage is billed at the official model price multiplied by 1.3, and you top up with USDC on Base without KYC. Contributors who help maintain the platform are credited at the official price times 1.1 (times 1.2 for premium contributions) in USDC.

Because each stage is metered separately, the big cost levers are straightforward:

• Transcribe once, reuse the transcript across extraction experiments instead of re-running audio.
• Reserve the stronger text model for reconciliation, where merge quality matters most, and use a lighter model for first-pass extraction if it meets your quality bar.
• Keep ensembles small. Two backends plus a reconciliation pass is usually a better trade than a wide ensemble that produces more duplicates.

A minimal end-to-end shape

1. Hash and store the audio; transcribe it; save the transcript with timestamps.
2. Chunk the transcript with overlap; extract items per chunk against a fixed schema; merge chunk outputs and drop exact repeats.
3. Optionally repeat step 2 on a second text backend and pool the results.
4. Normalize deterministically; cluster with a model; merge by rule; keep evidence quotes.
5. Validate quote grounding and field sanity; sort; publish the list and the audit log.