Two Models, One Pipeline: The Mini-First Cascade Behind My n8n Meeting-Notes Workflow

Description and use

The workflow uses a mini model for most items and escalates only hard cases to a flagship model, bounding cost and ensuring every accepted task is grounded in the transcript.

Problem

For a 10‑person team running 3–4 meetings a day, routing every transcript through a flagship model is expensive; the mini model is cheaper but less accurate.

Outcome

The cascade limits flagship usage to the hard few percent of items, keeping costs bounded while guaranteeing every accepted task is grounded in the transcript.

Workflow

• 1. Send transcript to mini model for extraction
• 2. Pass mini output through evidence‑quote gate (exact string match against transcript)
• 3. If gate passes, item is accepted
• 4. If gate fails, retry mini extraction once
• 5. If retry fails, re‑extract with flagship model
• 6. Pass flagship output through gate
• 7. If gate passes, accept; if fails, send to human review queue

Evidence

Meeting‑note extraction is a lopsided workload. Most action items are trivially extractable — "John will send the API spec by Friday" needs no reasoning, just parsing.

Source

Every extraction call goes to the mini model first. The mini's output then passes through the same evidence‑quote gate from my exactly‑once series: each action item must carry a verbatim quote from the transcript, and an n8n Code node checks the quote against the transcript with an exact string match.

Source

If more than roughly a third of items in a meeting escape the mini model, the problem is the input, not the model — a bad prompt, a transcript with no speaker labels, notes too terse to ground anything.

Source