🔭 The enterprise moat may be shifting from the model to the rails

The argument. Last week the labs were paying to shape the regulatory gate. This week a different contest opened — over who controls how agents discover and coordinate tools — and the two frontier labs weren't among the founding backers. ARD is the discovery layer: the catalog an agent reads to learn what tools exist. Stack it with Google's A2A (agent-to-agent coordination, live in 150 organisations) and Anthropic's own MCP (the tool connection) and you get the plumbing of the agentic enterprise.

Why founding backers might matter — the honest version. It's not that rivals are locked out. ARD is federated and Apache-2.0; anyone can publish a catalog or implement the spec. The edge, if there is one, is softer: the backers also own the runtimes and software best positioned to read these catalogs by default — Workspace, Microsoft 365, Salesforce. If those defaults land their way, whoever sets them shapes which tools an agent reaches first. That default behaviour isn't set yet — it's the specific thing to watch, and it's why the thesis is a hypothesis, not a result.

The bet. By the end of Q4 2026, at least one frontier lab formally backs ARD — a public commitment or a shipped reference implementation, not a passing compatibility note — or announces a competing discovery standard of its own. The labs move fast when they sense a structural threat; the deployment billions are the signal.

You are my vendor lock-in auditor. Below is one

AI workflow I run in production, plus the tools

and models it touches.

1. List every hard dependency: which model,

which vendor's API, which proprietary format

or protocol it relies on.

2. For each, rate switching cost 1-5, where

1 = a config change and 5 = weeks of re-

engineering, data conversion or downtime.

Name what locks me in: the model, the data

or format, the integration, or the contract.

Separate technical lock-in (code, formats)

from commercial and data lock-in (contracts,

data gravity, evaluation history).

Justify each rating with the migration effort

behind it: hours, systems touched, data to

convert. Mark every dependency as verified

(from what I gave you) or assumption (needs

my confirmation).

3. Flag the one dependency that would hurt most

to lose, and the one cheapest to make

portable this week.

4. Give me a portable-by-default version of the

workflow: same job, swappable parts.

Rule: “it works fine right now” is not the same

as “I could switch on a Friday.”

LiteLLM

A single interface in front of 100+ models — so switching providers is a config change at the API layer, not a code rewrite.

★★★★ / 5

This issue's about rails, so the tool is the one that keeps you off everyone's. LiteLLM is an open-source (MIT) proxy that puts a single OpenAI-style endpoint in front of 100+ providers — OpenAI, Anthropic, Google, DeepSeek, self-hosted, whatever. Your code calls one interface; you change the model behind it with a line of config. That's the DeepSeek migration above turned into a non-event, and last week's Fable-5-reroutes-to-Opus problem turned into something you actually control.

• Unified API across 100+ LLMs — same call, any provider

• Per-key budgets and spend caps built in

• Automatic fallback when a provider errors or rate-limits

• Drop-in with existing OpenAI SDK code

Use if: you touch more than one model and never want a vendor's deadline to become your emergency. Skip if: you're all-in on one provider's agent platform by choice — then the abstraction just adds a hop. Link →

What it fixes: interface-level portability — the code you call. It won't equalise tool-use behaviour, context handling, structured outputs or eval scores across providers; those still differ. But it turns a provider swap from a rebuild into a config edit. Why four, not five: it adds a hop — one more failure layer, some latency, and observability to maintain — and it lags provider-specific features by weeks.

An alias is a promise the vendor can quietly rewrite.

When DeepSeek retires deepseek-reasoner on 24 July, the alias doesn't just vanish — it re-points to V4-Flash, a lighter model, at flash pricing. Swap the name, keep your code running, and your heavy reasoning silently drops a tier. Nothing errors. The output still looks fine.

The move. Pin exact model versions in production. Not every alias is a landmine — a stable, versioned one is fine. The risk is aliases that auto-move (a “-latest” tag) or ones scheduled for remapping, like DeepSeek's: both let the vendor change what you're running without telling you.

Why it works: aliases optimise for the vendor's convenience, not yours — they're how a provider ships a migration without a support ticket. Pinning means changes happen when you decide, not when a deprecation calendar does.

Where it doesn't apply: rapid prototyping, where “always newest” is the point.
Pro move: log the resolved model ID from every response and diff it weekly. If the name you sent isn't the model you got back, that's your finding. The principle is controlled change, not permanent immobility — pinning has its own upkeep, and not every provider pins the same way.

Forward iPrompt → For the colleague who's still only comparing benchmark scores.