Part 09 of 13 · Choosing a Model

Why we choose the default model before a workflow runs

For a known, repeated task, model choice belongs in the versioned design with runtime escalation reserved for the difficult tail.

Read the article on Substack ↗ (opens in a new tab)

Summary

The extraction node does one thing thousands of times a month against an unchanging task definition, schema and accuracy bar, so deciding on every invocation which model should run it is both wasted work and unpredictable — and the finance team would rather know what is running. Opus can make the decision early because the task is known before any inference happens: the workflow supplies the node’s task class, schemas, constraints and position among other nodes, stored as durable metadata in the Work Knowledge Graph.

Routing therefore begins by parsing the graph, finding inference-bearing nodes and classifying each as easy, bounded or complex by risk, reasoning depth, context size and quality requirements. Candidate models spanning small, open-weight and frontier tiers are then benchmarked on representative task data built from the node’s own definition and schemas, supplemented by human-reviewed traces where they exist, with an output judge grading accuracy, latency, cost and failure modes against the task’s configured thresholds and the full cost of error.

The approved route is written back into the graph as a dispatch policy attached to the node — a design-time artifact versioned with the workflow — which is the article’s central claim: model selection becomes part of the workflow’s definition rather than a property of each request. At run time the executor simply retrieves and applies the route, with an optional lightweight quality gate that can trigger an approved fallback to a permitted model or to human review, noting that escalation never expands the allowed inference boundary.

Five mechanisms keep the route from ossifying: per-case escalation, aggregate monitoring, invalidation on workflow change, invalidation on model change, and scheduled re-benchmarking. The costs are up-front evaluation for every inference-bearing node and ongoing route maintenance, and whether the production saving outweighs them is framed as a measurement — per-node win rate, fallback rate and cost saved net of benchmarking — rather than a given.

All thirteen parts →