Cost-aware model routing.
Task taxonomy
Routing happens per action type, not per blind call. We enumerate the discrete jobs — classify an email, extract fields from a transcript, tag an account, summarize an account, draft outreach, judge whether an alert warrants a VP's attention, synthesize a deal narrative. Each becomes a routable unit with its own policy.
An eval set per task
For each task we assemble representative inputs with gold outputs or a scoring rubric, then score every candidate model against it: accuracy/F1 for structured extraction and classification, LLM-as-judge rubric scores for generative work. Quality becomes a number, not a vibe.
The quality floor — set by you
You set the minimum acceptable score per task. The router selects the cheapest model whose eval score clears that floor. Exposed as per-workflow controls — Cost-optimized / Balanced / Maximum quality — plus the ability to pin a specific model anywhere you want full control.
Runtime cascade with fallback
Dispatch to the selected model, then validate — schema/JSON validation, confidence checks, or a lightweight judge — and automatically escalate to a stronger model when output fails the bar. This is what lets the router route aggressively cheap without ever risking the trust-killing bad summary or false alert.
Observability
Every call logs model used, token cost, latency, and quality score, surfaced in a dashboard. This is what makes 'we manage your spend down' provable rather than asserted — and it feeds continuous re-tuning of routing policies as usage exposes new patterns.
How it fits your environment
The layer runs inside your environment and calls models via your own provider keys (BYOK) — Azure AI Foundry, OpenAI, Anthropic, or others. Tokens are billed to your account at your negotiated rates; prompts, logs, and spend stay inside your governance. Deploy into your Foundry, expose agents over MCP, emit telemetry into your existing observability.
On choosing your own harness
Models are yours to choose — a config change behind the routing layer at near-zero cost. The orchestration core is ours, built once and maintained. We meet the real requirement behind 'our framework' — that it run inside your governed environment — through interoperability, not by rewriting the orchestration onto a different harness. Interop is not rebuild.
Where the value is, honestly
The dispatch mechanism is commodity — a model gateway (e.g. LiteLLM or a custom router) handles it. The proprietary, licensed, maintained asset is steps 01–03: the domain eval suites and per-task routing policies tuned for sales intelligence. As cheaper, better models ship, the policies adopt them and your cost-per-outcome falls with no re-platforming on your side.
When an architect pushes back.
On the routing claim"Routing is policy-driven per task and backed by an eval set for each action — so 'quality' is a measured score against your own examples, not a guess. You set the floor; the router takes the cheapest model that clears it and automatically falls back to a stronger model if an output fails validation. And you can pin a specific model anywhere you want full control — nothing is hidden."
When they want their own harness"You choose the models and the provider account — that's a config change, and it's yours. The orchestration core is ours, built once and maintained. We make it live inside your governed environment — deploy into your Foundry, expose the agents over MCP, feed your telemetry — so it runs on your rails without us porting onto a different framework."
Your keys. Your account. Your rates.
Spend bends down as the model market gets cheaper — and you see every dollar. The opposite of metered credits that spike with usage.