AI SYSTEMS

Give each pass its weight.

Google's new Flash pair turns model choice into a routing decision: one lane for difficult planning and multimodal judgment, another for repeated extraction, classification, and subagent work.

TLDR

The useful unit is not the model. It is the pass, with a named job, a fixed return shape, and a rule for when the work moves up a lane.

•  Gemini 3.6 Flash and 3.5 Flash-Lite moved into general availability on July 21.

•  3.6 Flash takes text, images, video, audio, and PDF input, with a context window above one million tokens.

•  3.5 Flash-Lite is Google's lighter lane for repeated parsing, document extraction, classification, and subagent work.

•  Older sampling controls are ignored by these models, and a prefilled model reply is no longer accepted.

After a model lineup changes, the tidy instinct is to replace the old name everywhere. The new Flash pair suggests a more useful move: split the workflow by kind of judgment. The difficult pass gets room to reason across mixed material. The repeated pass gets a narrow contract it can execute many times.

That makes routing a craft decision. A system becomes calmer when every pass is asked to carry only the ambiguity it can actually resolve.

Google describes 3.6 Flash as the lane for code, complex agentic work, and multimodal tasks. Its inputs can include text, images, video, audio, and PDFs. It can return structured text, call tools, and work across as many as 1,048,576 input tokens.

Flash-Lite is positioned for the work that arrives in volume: parsing, extraction, classification, translation, and small delegated passes. The distinction is about the shape of the work, not a blanket verdict on one model over another. A mixed folder and a repeated field are different problems even when both can be described as analysis.

Imagine a campaign folder with a written brief, a rough cut, reference frames, a call transcript, and a PDF brand guide. The first pass has to decide what matters across formats, identify conflicts, and define what every later item should return. That is a 3.6 Flash pass because the judgment is cross-material and unsettled.

Its output is not the finished campaign. It is a compact schema: goal, audience, fixed constraints, fields to extract, and an escalation rule. The expensive part is deciding the frame once.

That first output should also name what it could not settle. When uncertainty is written into the schema, later passes have somewhere to return. A smooth answer with no unresolved fields simply pushes guessing farther down the line.

Once the schema exists, twenty-five assets can move through Flash-Lite one by one. Each pass receives one asset and the same expected fields: format, subject, claim, missing element, risk note, confidence. A small fixed contract turns speed into something observable.

Low-confidence items return to the heavy lane. Clear items continue. The lighter model is not being asked to invent the judgment that governs the batch, only to apply it consistently and expose uncertainty when it appears.

Review changes with that division. Instead of reopening all twenty-five assets, a human can inspect every escalation plus a small random sample of the clear set. The review plan belongs beside the routing rule, not at the end as an afterthought.

A handoff needs five things: the task, the allowed inputs, the return fields, the confidence scale, and the condition that sends an item back. Without that seam, the second model inherits a vague paragraph and the first model's reasoning disappears.

The seam deserves its own version history because a quiet change there alters every item that follows. Recording the schema, threshold, and model name together makes a later comparison possible.

A twenty-item set is enough to expose the seam. I would score field accuracy, unsupported claims, escalation precision, and reviewer edits. Then I would compare the two-lane route against the same work sent through 3.6 alone.

The migration detail belongs in that test. Google says temperature, top_p, and top_k are deprecated and ignored for the new models. Prefilling the model's reply is invalid, so older prompt wrappers may need system instructions or structured returns instead.

The failures are more useful than the average alone. Keep the items that escalated late, the fields reviewers changed, and the cases where both lanes agreed on an unsupported claim. Those examples become the next evaluation set and make the route less dependent on memory.

A clean route is measured at the handoff, where consistency, escalation, and reviewer effort can all be counted.

A two-model system is useful only when its boundary is legible. The heavy lane defines judgment, the repeat lane applies it, and the score tells us whether the split deserves to stay. That is more durable than replacing one model name with another and hoping the workflow improved.

THE NEXT WORKING NOTE

I am putting together a small routing ledger: a worksheet for naming each pass, its inputs, expected fields, escalation rule, and review sample, with a worked two-model content pipeline.

Want it when it ships? Reply with send me the routing ledger and I will get it to you.

A QUESTION FOR YOU

Which pass carries too much judgment?

Reply with the step that still asks one model to plan, extract, decide, and review at once. That seam is where the ledger should begin.

If this was useful, forward it to a creator who runs one model across every step.