Here is a question every company deploying AI agents will face within twelve months: when you have five agents running — a shopping assistant, a catalog manager, an analyst, a copywriter, a support bot — which model does each one use?
The default answer is whichever model the team that built it happened to like. Five apps, five hardcoded model choices, five copies of the same API key in five .env files, five invisible bills. When a provider has an outage, five apps fail independently. When finance asks what AI costs per product line, nobody can answer.
We refused to accept that architecture, so we built the layer that fixes it. This is the story of Mercury Flux — our model-routing engine — and the commerce agents that run on it. It's also a preview of how we deploy agentic AI for enterprise clients.
TL;DR: Hardcoding a model into every AI app is the new hardcoding passwords into source code. Mercury Flux is an AI routing layer that sits between every agent and every model provider — Gemini, GLM, Grok, Kimi, any of them: each app authenticates with its own key, gets its own route table (task type → model → fallback chain), and reports its own token usage. Our commerce agents — a customer-facing shopping assistant and a back-office merchant agent where every write waits for human approval — run on this stack at roughly $0.07 per million tokens blended, about 2% of retail API cost. The same stack powers the SEO and GEO pipelines behind our AI visibility work. The router decides the model. The apps never know. That's the point.
I am James, CEO of Mercury Technology Solutions. We build AI-to-human bridges for enterprises, and we run our own agent fleet at a scale that makes architecture decisions non-optional — around 18 billion tokens a month. Flux is the routing engine that keeps that affordable, observable, and under control. Today I'll show you what it does, and why the commerce agents are its first real customer.
The Problem: Model Sprawl
The AI application stack of 2026 has a missing layer, and most teams feel it without being able to name it.
You have model providers — excellent ones, multiplying: Google, OpenAI, Anthropic, and a wave of strong challengers. You have agent frameworks. What's missing is the piece that decides which model, for which workload, at what cost, with what fallback, billed to whom.
Without that layer, every app becomes its own routing decision, made once, by a developer, in code. The consequences compound quietly:
- Cost blindness. Five apps, five provider accounts, no unified view. Nobody can say what the shopping assistant costs versus the support bot.
- Key sprawl. Every app holds raw provider keys. Rotating one means a hunt across every repo. One leak is a full-account leak.
- No failover. Provider has a bad afternoon, and every app that hardcoded it goes down with it.
- Model lock-in. Switching a workload to a better or cheaper model means touching app code — so it doesn't happen, and you overpay forever.
It's not that the models aren't good enough; it's that the architecture has no ability to choose.
Mercury Flux: The Layer That Chooses
Flux is a thin, ruthless layer between your agents and the model providers. The design fits in one paragraph:
Every app authenticates to Flux with its own key — never a provider key. Each request carries a route name instead of a model name: tool-loop for tool-calling work, long-text for drafting, analysis for deep reasoning. Flux resolves the route against that app's table — an ordered chain like Grok for tool discipline, GLM as fallback — adds the real provider credentials, and forwards the call. Every request is logged with per-app, per-route token accounting. Providers go down, Flux fails over. Models change price, you edit a table. Apps never notice.
Think of it as the electrical panel for AI: one feed from the utilities (the providers), a breaker for every circuit (the apps), and a meter on each line. You don't rewire the house to turn off a lamp.
The economics come from the routing itself. Tool loops run on AI models chosen for function-calling discipline. Long-form generation runs where cost per token is lowest. Hard reasoning gets the frontier model only when the task actually needs it. Across our fleet — commerce agents, SEO content pipelines, the GEO audits we ship to enterprise clients — this compounds to that $0.07-per-million blended rate: two orders of magnitude below what the same LLM volume costs at premium retail pricing. A routing decision made once, in a table, instead of never, in code.
The First Tenants: Commerce Agents
Flux's first production workload is a pair of commerce agents we built for retail deployments, on an open reference blueprint we hardened and extended with our own runtime.
The shopping agent is the customer-facing one. It searches the catalog, compares options, plans purchases, fills the cart, and answers order and policy questions — with memory of what the customer tells it. It is the store's answer to the shift happening right now: buyers who once asked Google for "best two-person tent" increasingly ask ChatGPT, Perplexity, or Gemini directly and expect the store's assistant to be sharper than a search result. It is fast, patient, and never gets tired of "which of these two is better for a small balcony?"
The merchant agent is the back-office one. It explains performance, maintains listings, acts on inventory alerts, adjusts pricing, drafts campaigns. And here is the part that matters for enterprises: every write it makes is staged, not executed. A price change, a restock, a listing edit — each lands as a proposed change that waits for a human to approve through an approval surface. The agent proposes; the operator disposes.
The safety architecture underneath is the part we're proudest of, because it's the part demos never show you:
- Provenance gates. The cart only accepts products a catalog tool actually returned this session. The model can't hallucinate a purchase.
- Guardrails at apply time. Price move too deep, restock too large, protected field touched — the change is refused regardless of who approved it.
- Fenced context. Third-party text the agent reads is sanitized and delimited so a malicious product description can't inject instructions. The agent reads the web; the web does not get to read the agent.
This is the AI-to-human bridge we build for a living: the AI does the work, humans approve the writes. Not a chatbot bolted onto a storefront — a system where autonomy and accountability are separated by design.
What Routing Bought Us: A Live Comparison
Because Flux separates routing from app code, we ran the same shopping-agent workload through two different models by editing one line of configuration. The difference was decisive.
One model — strong at prose — fumbled the tool contracts: malformed skill calls, repeated searches, no completed purchase. The other handled the same enum schemas cleanly, loaded its operating instructions on the first try, and completed the full search-to-cart flow — while correctly obeying a rule in its skill manual that says research turns present findings before writing to the cart. Same agent, same gates, same prompt. Only the model differed, and the model is exactly the thing a routing layer lets you change.
Multiply that one comparison by every workload, every client, every quarter. Models improve and reprice constantly; the teams that can re-route in seconds will always outperform the teams that scheduled a refactor for next sprint. Flux turns model choice from an architecture commitment into a configuration line.
Why This Matters for Enterprises
If you're deploying agentic AI — commerce or otherwise — three implications:
- Per-app model routing is table stakes. The workload decides the AI model: tool discipline for agents, cheap long-context for content, frontier only for judgment. A routing layer makes this a policy, not a per-app accident.
- Keys and cost belong in one place. Apps authenticate to the router; the router alone holds provider credentials. Token metabolism is measured per app, per route — so "what does AI cost per product line?" becomes a query, not a forensic audit. Treat it as core digital transformation infrastructure, not a marketing tool.
- Autonomy needs approval gates. Agents that write to production systems — carts, catalogs, prices — need staged changes and human approval as architectural features, not prompt suggestions. The commerce blueprint we run proves it works under real tool-calling load.
The 43% of leads that fall through the AI-to-human gap? They fall because companies deploy either all-human (slow) or all-AI (unaccountable) systems. The bridge is staged autonomy: machines that work, humans who approve, and a routing layer that keeps the whole thing affordable enough to actually deploy — whether the workload is commerce, SEO, or the GEO programs that make a brand citable when AI answers.
That's Mercury Flux. One router. Every agent. Its own model, its own bill, its own breaker.
Mercury Technology Solutions: Accelerate Digitality.
