Microsoft Foundry's model router now analyzes requests and selects an appropriate underlying model. Its September 2026 updates add per-request routing metadata, allowing developers to see which model served a request, the routing mode, attempted models, fallback behaviour, and routing latency.
This is important because very soon, more applications may work this way.
The interesting question about AI applications is no longer simply: “Which model should we use?” There are now more models, more specialized capabilities, and more ways to build with them. The harder problem is what happens when an application has to choose between them.
A request comes in. Should the application execute it directly? Send it to code? Ask a decision model? Use a smaller language model? Escalate to a frontier model? Give it to an agent? Or ask a human?
That is a different problem from model selection. It is an orchestration problem. And the next generation of AI applications may be defined less by the model sitting behind them and more by the intelligence layer deciding where each piece of work should go.

The Application Becomes the Decision-Maker

Imagine you are building an AI-powered customer support application.
A customer sends a message saying their payment failed.
The application could send the entire request to its most powerful model and ask it to figure everything out. But that is only one possible architecture.
The system might first check whether the payment failure matches a known error code. If it does, ordinary application logic can handle it.
If the request needs classification, a specialized model can make that decision.
If the customer needs a simple explanation, a smaller language model may be sufficient.
If the case involves several systems and requires investigation, an agent can take over.
If the case involves a sensitive financial decision, the workflow may stop and ask a human to approve the next step.
The important part is not that all these technologies exist. It is that the application has to know when to use each one. This is where AI model routing becomes more than a convenience feature. It becomes part of the application's architecture.

Routing Is More Than Just “Pick a Model”

Routing cannot simply mean a request comes in and goes to any random model. Routing itself requires intelligence. It needs to understand what the request is, what the application is trying to accomplish, what constraints apply, and what happened previously.
The router is therefore not simply choosing Model A or Model B. It is choosing how the application should think about the task at all.
Eventually, the routing decision may not even be between two language models. It could look more like this:
- Exact UI change → Is the requested state already known? → Direct control
- Known business rule → Is the logic deterministic? → Code / workflow
- Bounded classification → Is this a defined decision? → Decision model
- Simple language task → Does it need deep reasoning? → Efficient model
- Complex reasoning → Is ambiguity or synthesis involved? → Frontier model
- Multiple connected actions → Is execution worth delegating? → Agent
- High-risk exception → Does accountability matter? → Human
That is why the real shift is from model selection to intelligence orchestration.

More AI Creates More Routing Decisions

This becomes even more important as applications become more agentic.
Anthropic reported that more than 90% of its measured R&D work in August involved human-AI collaboration, with around 30,000 agents operating on its internal platform. Claude led 26% of measured AI R&D tasks, under human supervision.
The interesting implication is that an environment with thousands of AI workers creates thousands of decisions about what should happen next.
Which agent gets the task? Which model should that agent use? What information should it receive? Should it continue? Should another system validate its work? Should it retry? Should the task be escalated? Should a person intervene?
At a small scale, developers can hard-code many of these decisions. At a larger scale, routing becomes infrastructure. The application needs a layer that can continuously make those choices.

There's Also the Cost Concern

There is another reason this matters. AI applications are increasingly paying for intelligence by the request, the token, or the amount of work performed.
Gartner has forecast that AI coding costs could surpass the average developer salary by 2028 as token consumption rises and AI coding moves further toward consumption-based pricing. Gartner's recommendation is essentially to bring more discipline to how AI is used rather than assuming that more model usage automatically means more productivity.
That changes the economics of architecture. Suppose an application receives a million requests. The question isn't simply whether the frontier model can handle them. It is: How many of those requests actually need it?

This Is Bigger Than Model Routing

The phrase AI model routing is useful, but the category may ultimately become much broader. Because the best destination for a task is not always another model.
A router might decide: Don't use AI. Or use code. Or use this specialized model. Or use the expensive model because the task is genuinely difficult. Or let an agent execute these steps. Or stop and ask a human.
That is why the real shift is from model selection to intelligence orchestration.
And this is already becoming a market in its own right. Recent reporting from India describes startups building routing layers that choose models based on cost, speed, accuracy, reliability, and data governance, with some systems directing simpler tasks toward smaller models and more complex work toward stronger ones.

Where This Leaves FloNeo

This is also where FloNeo's Low Token No Code philosophy becomes more interesting. LTNC isn't simply about using fewer tokens. It is about refusing to make AI the default mechanism for every operation. This happens through an intelligent combination of direct control, application logic, workflows, appropriate AI usage, agentic execution, and human control.
The smarter application is the one that knows what kind of thinking each task requires. Eventually, users may not even notice which model handled their request. They will simply experience an application that knows when to act, when to think, when to delegate, and when to ask.
The future AI app won't have one brain. It'll have an intelligence router.

Get First Access to FloNeo

FloNeo is being built for that mixed future: AI where intelligence adds value, direct control where the intent is already clear, and visible workflows and application structure underneath it all.
Get First Access to FloNeo: https://floneo.co/waitlist
Free registration. Be among the first to experience FloNeo when early access opens.

Next in the Series

Part 3: The Smartest AI App Uses Less AI - But in a Good Way
Part 3 takes the routing idea all the way into FloNeo's LTNC product philosophy: why “less AI” can actually mean a smarter application.

References

Microsoft Foundry — What's new in model router — https://learn.microsoft.com/en-us/azure/foundry/foundry-models/whats-new-model-router
Reuters — Anthropic says Claude now leads a quarter of work building its next AI models — https://www.reuters.com/business/anthropic-says-claude-now-leads-quarter-work-building-its-next-ai-models-2026-09-17/
Gartner — AI coding costs will surpass average developer salary by 2028 — https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges
The Financial Express — Beyond the model race, India targets the switchboard — https://www.financialexpress.com/business/news/beyond-the-model-race-india-targets-the-switchboard/4343576/
TypeSafe AI — Introducing System One Models & Jev — https://typesafe.ai/blog/introducing-system-one-models-and-jev
FloNeo — How FloNeo's 4-Layer Architecture Makes AI Prototyping Ultra-Affordable — https://floneo.co/blog/how-floneos-4-layer-architecture-makes-ai-prototyping-ultra-affordable