How to use the best available model without letting one model, harness, quota, or pricing model become the workflow.

Learning stageFoundation patternProof statusPattern documented; more concrete routing evidence still needs public extraction.

Model-agnostic agentic workflows

What it is

A model-agnostic workflow keeps the durable work above the model. The product or operator describes the task, sources, constraints, privacy boundary, output format, and verification. A routing layer then chooses whether the work should run through a frontier model, a hosted alternative, a local open-weight model, a deterministic script, or a human approval step.

This is not an anti-frontier position. Use the best model when it creates the most leverage. The point is that the task contract, context, tools, logs, and checks should survive a model change.

Learning goal

Learn to design AI workflows where provider choice is reversible. The output of the learning should be a task contract, a route policy, and a verification method that still make sense if the model changes tomorrow.

Why it matters in production

The AI market changes faster than most production systems can be rewritten. Pricing changes. Quotas appear. Default models shift. Provider quality moves. Some tasks become too expensive to run through a premium model; others become too sensitive to leave a local boundary. A workflow that hard-codes one provider into every feature turns those market changes into product risk.

The safer pattern is optionality. The system can still prefer the strongest model for difficult judgment, but it has a route for cheap background work, private context preparation, deterministic source lookup, and fallback behavior.

How I actually build it

I start with a task contract:

What is the user trying to accomplish?
Which sources are trusted?
What privacy boundary applies?
How expensive or slow may the run be?
What output format is expected?
How will the result be checked?

Then I separate the layers:

Context preparation: collect, trim, summarize, or classify before the main model call.
Routing: choose frontier, hosted alternative, local model, script, or human based on policy.
Execution: run through a narrow adapter so feature code does not branch on provider names.
Verification: use tests, scripts, diffs, review, or source checks that do not depend on the model used.
Trace: record which route was chosen and why.

Practice loop

Pick one existing AI-assisted workflow.
Write the task contract without naming a provider.
Define three routes: premium model, local/private model, and deterministic script or manual fallback.
Run the same task through two routes and compare cost, quality, privacy, and latency.
Write down what would make the route decision automatic.

Proof artifact

A useful proof is a small route registry plus two real executions of the same task through different paths. The proof should include the route reason, the output, the verification result, and the fallback rule.

Current status

The public pattern is documented. FOS has several private examples of model/harness routing, but this page still needs a clean public artifact that links to a specific ticket or commit without exposing private runtime details.

What worked, what didn't

What worked is treating the model as one layer of the workflow, not the identity of the workflow. That makes it possible to use a premium coding assistant for ambiguous engineering work while moving classification, context preparation, or long-running background tasks to cheaper or local routes.

What did not work was making the router clever too early. A meta-agent that silently decides where work goes is hard to debug. A small explicit routing policy is easier to trust, explain, and improve.

Next build

Extract one public-safe route example from FOS: source context preparation, model choice, fallback, verification command, and what changed after the run.