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

A reader asked a question on my meeting-notes workflow post that I couldn't stop thinking about: for a 10-person team running 3–4 meetings a day, routing every transcript through a flagship model gets expensive fast. Have I tried a mini model, or local inference? Fair question — and the answer is a pattern, not a model swap: I never let the expensive model see the easy work. Here's the cascade.

The shape of the problem

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. A small fraction are genuinely hard: ambiguous owners, implied deadlines, items scattered across three speakers. If you route everything through the flagship model, you are paying flagship prices for parsing work a mini model does just as well.

The naive fix — "just use the mini model for everything" — fails the way the reader suspected: minis hallucinate more, drop items from terse notes, and misattribute owners. The interesting question isn't which model, it's who decides when the cheap answer isn't good enough. That decision has to be mechanical, not vibes.

The cascade

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. No matching quote, the item is dropped. This gate is model-agnostic — it doesn't care which model produced the item, only whether the item is grounded.

Items that fail the gate get one mini retry. Items that fail twice in a row escalate: that single item — not the whole meeting — is re-extracted by the flagship model, then re-gated. The escalation is per-item because the workload is lopsided: in practice the vast majority of items pass on the first mini attempt, so the flagship only ever sees the hard few percent.

transcript
  → mini extract → evidence-quote gate
      ├─ pass → done
      └─ fail → mini retry → gate
                    ├─ pass → done
                    └─ fail → flagship extract → gate
                                  ├─ pass → done
                                  └─ fail → human review queue

Two things to note. First, the flagship's output is gated too — a bigger model hallucinates less often, but "less often" isn't "never," and the gate is cheap. Second, the terminal state is a human review queue, never silent acceptance. An item that fails the flagship's gate twice is genuinely ambiguous; auto-accepting it is how you get phantom tasks assigned to real people.

The two budgets

A cascade without budgets is just deferred spending. Mine has two:

1. The escalation budget. If more than roughly a third of items in a meeting escalate, the problem is the input, not the model — a bad prompt, a transcript with no speaker labels, notes too terse to ground anything. Escalating harder doesn't fix that; it just buys expensive hallucinations. Past the threshold, the whole meeting goes to review and I fix the prompt. The mini model is also a canary: when the canary keeps dying, you don't buy a bigger canary.

2. The rerun budget. Meetings get reprocessed — notes updated, transcripts corrected. Every rerun must upsert by a stable key (meeting ID + item content hash), never append. Without this, one edited transcript re-spends the entire extraction cost and creates duplicate items. This is the idempotency rule from part 2 of my series, applied to money instead of correctness.

Three ways to screw up a cascade

1. Escalating the whole meeting. The moment you escalate per-meeting instead of per-item, you've rebuilt the original problem with extra steps. The lopsidedness is the entire point — protect it.

2. Letting the mini retry forever. One retry distinguishes transient sloppiness (the mini fumbled the quote formatting) from systematic failure (the note genuinely doesn't support an item). Unbounded retries just launder the cost back in through the mini's token meter while the gate keeps saying no.

3. Grading the mini on the flagship's rubric. Don't compare mini output to flagship output and call the difference "quality loss." Compare both against the gate: grounded or not, attributable or not. The gate is the spec. A mini item that passes the gate is not a worse item — it's a cheaper item that met the same bar.

What it doesn't give you

It doesn't give you a quality guarantee, and it doesn't give you a fixed cost. What it gives you is a cost ceiling with a quality floor: the most you'll spend on a meeting is bounded by the escalation budget, and nothing lands in the task manager without a verbatim quote tying it to the transcript. The mini model doesn't need to be as good as the flagship. It needs to be good enough for the easy 90%, with a mechanical tripwire for the rest.

As for local inference (Ollama and friends): same cascade, different bottom tier. The gate doesn't care where the tokens came from. I'd still keep the escalation path to a hosted flagship for the hard items — local models are great at parsing, worse at the genuinely ambiguous cases, and the per-item escalation keeps the hosted bill tiny either way.

I'm building AI Automation Lab — n8n workflow templates for AI automation — and keeping a free lab on GitHub. I also send occasional notes on n8n reliability patterns: get them here.