{"slug": "the-durable-asset-is-the-control-plane-not-the-frontier-model", "title": "The Durable Asset is the Control Plane, not the Frontier Model", "summary": "Databricks released Omnigent, an open-source meta-harness that provides a common interface across Claude Code, Codex, Cursor, Pi, and custom agents so harnesses and models can be swapped or composed while tools and policies stay stable, with a managed beta version offering built-in contextual policies. The argument, illustrated by Cursor's July 2026 launch of Cursor Router alongside its Composer models and agent runtime, is that companies should not make a single model provider or harness their architecture. Databricks' layer moves control above the individual harness — policies, spend limits, sandboxing, shared sessions, and runtime portability — rather than treating a frontier model as the platform.", "body_md": "They are building a stack: models, routers, harnesses, and a meta-harness that keeps policy, spend, and evals above any single vendor.\n\nMany companies still treat “use the frontier model for everything” as an AI strategy. It isn’t. It’s a default.\n\nAt scale, that default becomes unnecessary inference cost, provider concentration, and data-governance exposure. The model is impressive. The architecture is not.\n\nCursor is a useful case study because it lived both sides of the problem.\n\nIt became one of Anthropic’s biggest customers while Anthropic’s Claude Code increasingly became a competitor at the application layer. At the same time, Cursor invested deeper in its own stack: Composer models, its own agent runtime, and — in July 2026 — Cursor Router.\n\nThe lesson is not “don’t use frontier models.” Frontier models remain the right tool for hard, ambiguous, high-stakes work. The lesson is narrower:\n\nDon’t make a single model provider — or a single harness — your architecture.\n\nCompany IP should not live only inside someone else’s model weights, context window, or agent loop. When the vendor ships the same job as a product, the partnership inverts.\n\nMature AI platforms are starting to look like a stack rather than a subscription.\n\nA model is the specialist. Some are expensive and general. Some are cheap and good enough. Some are tuned for a domain. None of them should be hardcoded as “the platform.”\n\nA router decides which specialist sees each request. That is not prompt caching and not simple failover. Caching saves tokens on the same request. Failover keeps you online when a provider blinks. Routing is workload triage: complexity, expected quality, latency, cost, tool compatibility, and policy.\n\nAn agent harness is the execution runtime around the model — tools, files, context, memory, permissions, sandboxing, and the loop that turns tokens into actions. Claude Code, Codex, Cursor, and Pi (the open-source coding agent from Earendil Works) are harnesses. They are powerful. They also have different runtime, tool, and session semantics. Each one is a silo unless something sits above it.\n\nA meta-harness is that layer above. It treats harnesses as interchangeable parts of a larger system.\n\nNot every prompt deserves a frontier model. Not every frontier answer should ship without a check.\n\nKnown, bounded work can go to the most efficient validated model. That might be an open-weight model, a smaller proprietary model, or a specialized one. Ambiguous or difficult work can escalate to the frontier. High-stakes work should add another layer: verification, policy controls and, where appropriate, human approval.\n\nThis is how token capital actually compounds. You do not get the return by starving the frontier model. You get it by refusing to spend frontier dollars on work a cheaper, validated model already handles.\n\nOnce agents can write files, run commands, and call tools, the model is no longer the whole risk surface. The harness is.\n\nA harness decides what the model can touch. It holds session state. It encodes a vendor’s opinion about memory, compaction, permissions, and the loop. That is why swapping Claude Code for Codex is not a model-name change. It is a runtime change.\n\nTeams that “standardize on one coding agent” recreate the same lock-in they were trying to escape at the model layer — only now the lock-in includes tools, transcripts, and operating habits.\n\nDatabricks’ open-source Omnigent is a clear example of this layer. It provides a common interface across Claude Code, Codex, Cursor, Pi, and custom agents, so harnesses and models can be swapped or composed while tools and policies stay stable.\n\nIts significance is not another agent framework. It is moving control above the individual harness: policies, spend limits, sandboxing, shared sessions, and runtime portability. In Databricks’ managed implementation — currently in beta, with built-in contextual policies rather than arbitrary custom policy code — identity and model governance can also flow through the Databricks control plane.\n\nThe stack is easier to see if you stop thinking in model brand names and start thinking in care pathways.\n\nYou don’t send every patient to the most expensive specialist. Primary care handles predictable cases. Specialists handle cases where their expertise creates incremental value. Triage determines who goes where. The exam room is the operating environment. The hospital system provides identity, policy, budgets, security, records, and oversight across all of them.\n\nThat last layer is what most companies are still missing. They bought a specialist. They did not build a hospital.\n\nNo single vendor owns the whole stack yet. That is the point. Different firms are hardening different layers:\n\n- **Cursor Router** classifies each request and sends it to a model, in a Cost, Balance, or Intelligence mode.\n\n- **Snowflake** has announced dynamic model routing in Cortex AI Gateway.\n\n- **Microsoft Foundry** ships Model Router as a single deployed endpoint over a pool of models.\n\n- **NVIDIA NeMo Switchyard** can route different stages of an agent run across efficient and frontier models — model-per-step, not model-per-app.\n\n- **LiteLLM, Portkey, and Vercel AI Gateway** provide provider abstraction, traffic management, fallback, cost controls, and gateway policy.\n\n- **Databricks Omnigent** is the public example of the layer above harnesses.\n\nThese are not interchangeable products. Cortex and Foundry are doing routing. Switchyard is doing in-agent model selection. Omnigent is doing harness composition and control. Gateways are the traffic plane. If you flatten all of that into “we use a router,” you will buy the wrong layer.\n\nRouting layers also carry dependencies of their own, and that matters more in regulated environments than the marketing suggests. Cursor Router requires Cursor Grok 4.5 to be enabled — the router needs a powerful but cost-efficient model for the turns it is not sending to the frontier — and blocking too many models reduces routing quality or disables the router outright. Foundry has an analogous constraint: when you curate a model subset, your effective context window becomes that of the smallest model in the subset.\n\nSo “policies that follow the workload” has a limit. If your organization cannot approve a specific provider or region, the router may degrade or stop working entirely. Ask every routing vendor which models are mandatory before you assume the layer is provider-neutral.\n\nA router is only useful if you can continuously measure whether each routing decision preserved quality while improving cost, latency, or risk. Without that loop, you have a load balancer with extra vocabulary.\n\nThe implementations worth copying already treat evals as part of the router.\n\nSnowflake has described a second model evaluating output quality after a task completes, then feeding that signal back into future routing decisions. Cursor has been explicit that routing should be learned from real developer work rather than inferred from benchmark scores. It optimizes for user satisfaction and evaluates keep rate — how much generated code survives in the codebase over time.\n\nThose are production outcomes. They are imperfect. They are still closer to enterprise value than a public leaderboard.\n\nThe durable enterprise asset is not the frontier model. Models will keep changing. Prices will keep moving. Vendors will keep shipping products that compete with their own best customers.\n\n**The asset is the control plane:**\n\n- models that can change without a rewrite\n\n- routing that can learn\n\n- harnesses that can be substituted\n\n- policies that follow the workload\n\n- identity and budgets that stay centralized\n\n- evals and telemetry that prove the system is improving\n\nThat is also why only operationally mature teams pull this off. You need evals that say which work is safe to send to a cheaper model. You need policy that is not a prompt. You need procurement that can run more than one provider. You need the discipline to measure cost per successful outcome, not cost per token.\n\nFrontier when it matters. Efficient models for the rest. A router in between. A harness around the model. A meta-harness above the silos.\n\nThe advantage is not which model you picked. It is how you operate the portfolio.\n\n*Notes: Cursor Router launched 22 July 2026 for Teams and Enterprise plans, with Cost, Balance, and Intelligence optimization modes; Enterprise teams must enable it manually. Databricks Omnigent is open source under Apache 2.0; the managed Databricks path is in beta as of September 2026 documentation. Snowflake’s dynamic model routing in Cortex AI Gateway was announced on a private-preview track. Microsoft Foundry Model Router is deployed as a single Foundry model over a pool of underlying models. Pi refers to the open-source coding agent at pi.dev (Earendil Works), not Inflection’s consumer assistant. Product capabilities summarized from vendor documentation and announcements; treat vendor-reported savings figures as directional.*\n\n[The Durable Asset is the Control Plane, not the Frontier Model](https://pub.towardsai.net/the-durable-asset-is-the-control-plane-not-the-frontier-model-a399446bb1f1) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/the-durable-asset-is-the-control-plane-not-the-frontier-model", "canonical_source": "https://pub.towardsai.net/the-durable-asset-is-the-control-plane-not-the-frontier-model-a399446bb1f1?source=rss----98111c9905da---4", "published_at": "2026-09-14 05:50:00+00:00", "updated_at": "2026-09-14 06:33:18.907736+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-products", "ai-tools", "developer-tools"], "entities": ["Databricks", "Omnigent", "Cursor", "Cursor Router", "Anthropic", "Claude Code", "Codex", "Earendil Works"], "alternates": {"html": "https://wpnews.pro/news/the-durable-asset-is-the-control-plane-not-the-frontier-model", "markdown": "https://wpnews.pro/news/the-durable-asset-is-the-control-plane-not-the-frontier-model.md", "text": "https://wpnews.pro/news/the-durable-asset-is-the-control-plane-not-the-frontier-model.txt", "jsonld": "https://wpnews.pro/news/the-durable-asset-is-the-control-plane-not-the-frontier-model.jsonld"}}