A cheaper, more capable model does not make a workflow automatically worth automating. It makes one question more important: which parts of this process actually need model reasoning, and which need predictable rules, review or no AI at all?
That is the job of a model-routing policy. It is a short operating decision that assigns each step in a workflow to one of four paths: deterministic automation, an economical model, a higher-capability model, or a human. It is not procurement theatre. It is how a small business keeps a useful AI workflow from quietly becoming slow, expensive and difficult to explain.
OpenAI’s 21 October release of GPT-6.1 Sol is a useful prompt for this conversation: the company positions it as nearer to its higher-end GPT-6 Astra model for multi-step professional and business workflows, at lower listed token prices. That is an input to an operating decision, not a reason to put one model behind every task.1
Start with the work, not the model
The wrong opening question is usually: “Which is the best model?” Best at what, under what constraints, and with what consequence when it is wrong?
Take a familiar lead-follow-up workflow. A form submission arrives. The system checks whether it is complete, creates or updates a record, classifies the enquiry, drafts a reply, schedules the next action and alerts a person if something looks unusual. Calling a powerful model for every step feels simple because there is one tool to configure. In practice, it hides the actual design.
Some steps have a known answer. A duplicate email check, a required-field check, an opening-hours lookup and an assignment rule should normally be ordinary logic. They should run the same way each time, leave a clear record, and fail visibly if their input is malformed. That is what workflow automation is for.
Some steps need judgement but have low consequences. Sorting an enquiry into a small set of known categories, extracting a requested service, or producing a first draft can be useful model work. The response does not need a premium reasoning tier if the output can be checked cheaply or the system can fall back to a simple queue.
Other steps need more care because ambiguity is real. A high-value proposal, an exception in a contract, a messy multi-document comparison or a request that could change customer data may deserve a more capable model, more context, a confidence threshold, or all three. The model is still not the accountable party. The workflow owner is.
Use four routes, not one default
The policy can be simple enough to fit on one page:
| Route | Use it for | Do not use it for | Control to add |
|---|---|---|---|
| Deterministic | Known checks, routing, record creation, reminders | Ambiguous classification or bespoke writing | Validation, retries, clear error queue |
| Economical model | Drafts, summaries, bounded classification, extraction | Irreversible customer or financial actions | Strict prompt, structured output, fallback queue |
| Higher-capability model | Complex exceptions, multi-document reasoning, supervised analysis | Routine repeated steps with known rules | Spend limit, evaluation sample, human approval |
| Human | Sensitive judgement, commitments, payments, deletions, unclear cases | Work that a clear rule can safely handle | Named owner and decision record |
This is not a claim that one provider’s low-cost model is inherently “safe” or that a premium model is reliably right. Model-routing changes the question from what can this model do? to what can this process tolerate?
OpenAI’s own release makes the distinction visible. It presents GPT-6.1 Sol as a lower-cost option for complex professional work while still positioning GPT-6 Astra as the choice where the best result matters most. The useful lesson is not the product naming. It is that capability, latency and cost are trade-offs that belong in workflow design.1
Build the first policy in 20 minutes
Start with one recurring workflow—not every AI idea in the business. Lead qualification, invoice triage, meeting-note follow-up or support-message routing are good candidates because they repeat, have visible inputs and usually reveal their exceptions quickly.
-
Draw the process in six lines. Write the trigger, inputs, decision, action, owner and failure path. Do this before naming a model. If the owner or recovery path is missing, the process is not ready for unattended action.
-
Mark the irreversible steps. Sending a message, changing a CRM record, deleting a file, publishing a claim and releasing a payment are different from preparing a draft. Put a human approval or an explicit policy gate before actions that are hard to undo.
-
Find the known paths. Ask which decisions can be made from a fixed rule, a lookup or a validation. Move those out of the model. This improves speed and makes later errors easier to diagnose.
-
Set a routing threshold. For every model step, define what sends an item to a stronger route or a person. It might be a low confidence score, conflicting extracted facts, an unfamiliar request type, a high-value deal, or an output that fails schema validation.
-
Measure one outcome and one cost. For lead work, that could be time to first response and cost per qualified lead handled. For document triage, it could be percentage correctly routed and review time per document. A routing policy without a measurement is only a preference.
-
Review a small sample each week. Inspect the failures rather than only the successes. Did the model misunderstand the input, did the deterministic rule miss an edge case, or did the workflow send a judgement task to the wrong route? That answer tells you what to change.
A minimum viable version can be even smaller: retain the existing manual workflow, add deterministic intake checks, let an economical model create a draft, and require a person to approve the outward action. That can be assembled and tested in 20 minutes for a narrow process. The result is not full autonomy. It is evidence about where automation earns its place.
Cost is only one routing signal
Token price can matter, particularly when a workflow runs hundreds or thousands of times. OpenAI lists GPT-6.1 Sol at US$2 per million input tokens and US$10 per million output tokens, compared with US$10 and US$50 respectively for GPT-6 Astra; it also lists a substantially lower cached-input price for Sol. Those figures make routing worth considering, but they are not the business case on their own.1
A low per-task cost can still be wasteful if the workflow produces poor outputs, creates more review work, or causes staff to stop trusting it. Conversely, a higher-capability model can be cheap in context if it handles a rare exception that would otherwise take an experienced person an hour to untangle.
The broader operating cost includes prompt and context design, integration maintenance, error handling, monitoring and the time needed to review important outputs. Those are exactly the elements that turn a demonstration into automation delivery a team can keep running.
The same is true for model quality claims. Vendor benchmarks are useful signals, not a substitute for testing your own inputs. OpenAI reports that GPT-6.1 Sol improved over GPT-6 Sol on AutomationBench, a benchmark built around end-to-end business workflows using tools. That does not prove it will categorise your customer enquiries correctly or follow your commercial rules.1
Keep the right to change your mind
A routing policy should make future changes easier, not lock the business into a model family.
Keep the workflow’s core facts—the input schema, business rules, record of actions, audit trail and human-approval queue—outside the prompt wherever possible. Use structured outputs between steps. Record which route handled an item and why it escalated. Then a provider change, price change or new model release becomes a controlled test instead of a redesign.
This is the practical connection between AI adoption and operations. A business does not need to guess its way into an “agent strategy.” It needs one workflow where the route, owner, measure and stop condition are explicit.
The next action is simple: choose one workflow you already run every week and make a four-row routing table for it. If you cannot say why a step needs a model, start with a rule. If you cannot say how it recovers from an error, keep a human responsible. That is not moving slowly. It is building a system that can improve without becoming harder to trust.