Most teams answer a runaway AI bill by consolidating on one vendor, and that makes AI vendor lock-in permanent. Remy Guercio of Tailscale argued the opposite at the AI Engineer World's Fair 2026: keep every layer swappable behind an AI gateway, set unlimited budgets on cheap models and narrow budgets on frontier ones, and read the logs afterwards.
What an AI gateway actually does about AI vendor lock-in
An AI gateway is a proxy that sits between agents and every model, connector and API they call. It is the practical answer to AI vendor lock-in because it makes each layer replaceable without re-authenticating users. Remy Guercio, who works on the AI gateway Aperture at Tailscale, the identity-based mesh network company, made that case at the AI Engineer World's Fair 2026.
The design goal is choice at each of four layers: the models, the data connectors, the interface and the sandbox. A team does not need a bespoke option at every layer. It needs the ability to swap one when a cheaper or better option appears, and to do that per team rather than for the whole company at once.
Gateways are not a new category. LiteLLM, OpenRouter and Portkey all route model calls, and Guercio says any of them beats no gateway at all. What changes between them is how identity reaches the request, whether MCP traffic passes through the same control point, and how much of the four-layer picture the gateway can see.
The commercial logic is straightforward. If your only approved path is two frontier models inside their own stacked ecosystems, every new AI use case inherits frontier pricing, and expanding AI usage into marketing or support becomes untenable. A gateway lets a cheap model carry most of the traffic while frontier models stay reserved.
Guercio also recommends a gateway to people who have no lock-in problem at all. A single developer running a background agent on a tailnet can point that agent at a gateway and get a record of what it actually did. That answer, not cost routing, is why many of the individuals he talks to adopt one.
Why consolidating on one vendor makes AI vendor lock-in worse
Consolidating everyone onto a single vendor reduces visible spend and deepens lock-in, because the panic response to a large bill is the same move that removes future optionality. Guercio described talking to hundreds of teams about their AI spend over the six months before the talk, and said the standard plan they arrive with is to standardize on one tool, maybe two.
The pressure is real. Finance asks what the money bought, the daily Anthropic Codex invoices keep arriving, and standardizing looks like control. The problem is that the fix addresses the invoice while leaving the causes untouched:
- Long sessions that never reset context
- Expensive models used for work a cheap model handles
- Authentication spread across every tool the team tries
On the first cause, Guercio has unusually direct evidence. He runs the same gateway his customers use, so he sees the raw usage. Sessions of hundreds or thousands of messages are normal, nobody clears the context, and a single session can accumulate tens of millions of tokens with the cache maxed out for its entire run.
Guercio's framing is that the industry moves from token maxing to ROI maxing. Token maxing describes the last 12 months: million-token context windows, context pulled in from anywhere, coding tools reading a repository through the CLI. That work is what made genuinely agentic coding possible. ROI maxing is not only cost cutting. It means proving value, and it means opening the stack so AI usage can spread beyond the small group of people willing to pay frontier prices for every experiment.
A gateway keeps the option to standardize on one vendor for a given team while preserving the ability to route a different team elsewhere. Standardization becomes a routing rule, not an architectural commitment.
The four layers of an internal AI deployment
An internal AI deployment has four separable layers, and ROI maxing means keeping the ability to make a choice at any of them. Lock-in hides in whichever layer you stop treating as replaceable, and Guercio's argument is that a gateway is what keeps the layer boundaries real.
| Layer | What it covers | Where lock-in appears |
|---|---|---|
| Models | The LLM endpoints the agent calls | Provider-specific endpoints and pricing baked into the agent |
| Data connectors | MCP servers, CLIs, REST APIs, file reads | Server version drift and per-tool OAuth |
| Interface | Chat, editor chat, phone, Slack threads | Identity lost when a UI sits in front of the gateway |
| Sandbox | The environment the agent runs in | No standard definition, so replacement is manual |
Model access is the layer everyone recognizes. Providers differ in price, context limits, tool-calling behaviour and rate limits, and the gateway holds the keys so an agent does not embed a provider-specific endpoint. Guercio's demo gateway carries Anthropic, OpenAI, Vercel, Bedrock, Codex and Anthropic OAuth at once, with no per-user key creation screen behind any of them.
Data connectors are where MCP lives, but Guercio deliberately does not restrict the category to MCP. A connector can be an MCP server, a CLI, a REST API, or a file read. In practice MCP servers diverge: the specification exists, implementations adopt different versions of it, and Guercio jokes that you can date a server by how it chose to do OAuth.
The interface layer is the one teams forget. It moved from chat, to chat inside an editor, back to phones, and now toward Slack threads. Marketing may genuinely ask data questions inside a Slack thread while engineering stays in a terminal, and Guercio's point is that an entire engineering team is unlikely to code through Slack, while an entire marketing team plausibly could. The gateway should not care which interface is used.
Sandboxes are the fourth layer, and they are the least standardized. Guercio expects a different definition from every person in the room, and he reads that fragmentation as a healthy phase rather than a problem to solve now. Each sandbox provider targets a different need, and teams are already integrating them. Tailscale's stated plan is to add sandbox orchestration to the gateway so the four layers appear in one view.
Identity instead of shared API keys
Aperture authenticates requests with Tailscale identity rather than synthetic API keys, so the gateway knows which user, machine or tag made a call. Tailscale builds a mesh network on WireGuard in which every connection carries the identity of the machine or user on the other side, including tags for machine identities and node IDs for individual instantiations.
That identity can be a person, such as an engineer running Claude Code on a laptop, or a tag representing a service like a pull-request review bot, narrowed further by the node ID of each running copy. Guercio says group information synced from providers such as Microsoft Entra or Okta can be attached as well, which is what lets an admin write rules like marketing gets Google Calendar and Gmail while engineering also gets GitHub, or read-only access to GitHub for one side of the engineering team.
The library behind this is tsnet, an open-source Go package from Tailscale that lets an application join a tailnet directly and read the identity of peers. Aperture is built on it. The Tailscale client itself installs on anything that runs the workload, including containers, laptops and GPU servers, and it is the identity of those machines that the gateway reads. The practical effect is that a developer points Cursor, Claude Code or Codex at the gateway endpoint, and if the device is on the tailnet the request arrives already authenticated.
The claim worth stating carefully: this removes the shared-key pattern, not authentication work in general. Users still authenticate to the tailnet through the organization's identity provider, and the gateway still holds upstream provider credentials. What disappears is re-issuing a key for every tool a developer wants to try.
How gateways become both an LLM gateway and an MCP gateway
A gateway that handles only model calls leaves the data layer uncontrolled, which is why Guercio uses the broader term AI gateway. Aperture routes LLM requests, brokers MCP servers, and turns ordinary APIs into MCP endpoints. Admins configure which MCP servers are permitted, and authorization rules attach to the same identity that already governs model access.
The difference between an LLM gateway and an AI gateway is the connector layer. In Aperture, connectors live in the gateway rather than in the client, so a chat UI or a Slack bot inherits them without its own setup. Guercio describes the gateway as a translation layer that sits in front of every endpoint the agent might reach, and the chat UI's own API surface is open to teams that would rather build their own Slack bot, voice interface or mobile client.
OAuth handling is the clearest example of why this matters. If authentication runs in the gateway, a developer testing a new agent framework does not re-authorize against GitHub, Google and a model provider for each tool. Guercio calls these small frictions the reason people stop experimenting with cheaper or faster workflows.
One limitation to note: Guercio says Aperture's built-in chat UI currently causes the gateway to see requests as originating from the UI rather than the end user, the same identity loss that other self-hosted chat UIs such as Open WebUI exhibit. Full OAuth pass-through is being added so user and machine identities survive that hop. Until it ships, treat the chat UI as a separate identity context.
Budgets, logs and diagnosing what an agent did
Budgets and logs are the two features that turn a gateway from a router into a management tool. Guercio describes budgets that are not uniform: an unlimited budget on a cheap model such as GLM 5.2, and an extremely narrow budget on a frontier model. The same identity rules decide who gets which.
Logs answer a question that invoices cannot. When an agent spirals without reaching an answer, the gateway keeps the trace, and Guercio notes that cheaper models are usually worse at stopping themselves but fine at analysing where they went wrong when pointed back at the record. Individual developers run their own usage through a gateway for that reason, including people running background agents on a tailnet who need to check what the agent did while they were away, and whether it did something it was not supposed to.
This is traceability, not a guarantee of cost control either. The gateway records what passed through it, so an agent that reaches a provider endpoint directly sits outside the budget and the log. Closing that hole means making the gateway the only path, which is an organizational decision rather than a product feature.
For spend accountability, the gateway is the point where usage can be attributed to a person, a team or a bot. That attribution is what lets an organization answer finance's question with per-team numbers instead of one aggregate invoice.
Where the ecosystem stands in 2026
Gateways, MCP servers and sandboxes are all shipping now, but at different levels of maturity, and the talk describes a market still forming rather than a settled standard. Aperture was presented in October 2026 by the engineer building it, so treat the specific feature set as a product report from its vendor rather than an independent evaluation.
On the connector side, MCP adoption is broad enough that version drift is the practical problem, which Guercio describes as an archaeology exercise when configuring servers. On the sandbox side, the market is fragmented by design. The gateways themselves range from routing-only to identity-aware, and the useful question for a buyer is which layer the product actually controls.
The honest reading is that no gateway removes lock-in by itself. It relocates the decision. Your agents and workflows still depend on specific tools, but the dependency sits behind a control point you can change on a Tuesday, in one place, without touching every laptop in the company.
That reframing is the part that survives the vendor framing. Whether or not Aperture fits your organization, the four-layer model is a usable audit checklist: name your model providers, your connectors, your interfaces and your sandboxes, then ask which of those four you could change this quarter, and which you could not.
FAQ
How does an AI gateway prevent AI vendor lock-in?
It centralizes model keys, MCP connectors and API credentials behind one endpoint, so teams can switch tools without re-authenticating against every provider. The gateway also applies budgets and keeps logs per identity, so a change is a routing decision rather than a migration project.
What is the difference between an LLM gateway and an AI gateway?
An LLM gateway routes model calls only. An AI gateway also brokers data connectors such as MCP servers and APIs, so authorization and logging cover the data layer as well as the model layer. Tailscale's Aperture is positioned as the broader kind.
Does Aperture require API keys for each user?
No. Aperture reads identity from the Tailscale network, so a request arriving from a device on the tailnet is already attributed to a user, machine or tag. Administrators still manage upstream provider credentials on the gateway itself.
What is tsnet?
tsnet is an open-source Go library from Tailscale that lets an application join a tailnet and read peer identity directly. Aperture is built on it, and it is the mechanism that lets a self-hosted service participate in tailnet identity without a separate VPN client.
Can a gateway reduce AI token costs on its own?
It can, but not automatically. Budgets per model and per identity cap the damage, and logs show which sessions burn tokens. Guercio describes sessions of hundreds or thousands of messages that never reset context, with caching maxed for the whole run, as a common source of waste.
Is an AI gateway only useful for large companies?
No. Guercio says individuals run their own usage through a gateway to see what background agents are doing. Visibility into an agent's actions is useful at any team size, and it is the stated reason many solo users adopt one.
What are the four layers of an internal AI deployment?
The models, the data connectors, the interface and the sandbox. Lock-in hides in whichever layer is treated as fixed, and the argument for a gateway is that it keeps all four swappable for different teams.
Does a gateway make AI usage compliant or secure by default?
No. Routing traffic through one control point gives you attribution, allowlists and logs, which are useful controls. Compliance, tenant isolation and regulated-industry requirements depend on the surrounding platform and organizational process, not on the gateway alone.
What happens to identity when a chat UI sits in front of the gateway?
Guercio says Aperture's built-in chat UI currently makes requests appear to come from the UI rather than the end user, the same problem that shows up with self-hosted chat UIs such as Open WebUI. Full OAuth pass-through is planned so user and machine identities survive that hop; until it ships, that path has weaker attribution.
Should you pick one gateway vendor for the whole company?
You pick one control point, but you do not have to pick one route. Standardization at the gateway can be a per-team rule, so one team is pinned to a vendor while another is free to route elsewhere. The gateway is the only component that has to be universal.
Turning this into an article people can find
The argument in this talk is that choice belongs behind a control point you own, and the same applies to how you publish the ideas you already have on video. If you record talks, interviews or walkthroughs where you explain a mechanism step by step, Skalablog turns that recording into a written article: paste the YouTube URL, let it transcribe the video, and generate a draft you can edit and publish on your own site. You can read more and try it from Skala Blog.
Sources and further reading
- An AI Future Without the Lock-In — Remy Guercio, Tailscale
- Tailscale builds the identity-based mesh network and the Aperture AI gateway discussed in this article.
- Model Context Protocol is the specification behind the MCP servers described in the connector layer.
If you are learning to build agentic systems and want the tooling to go with it, Gustavo Dev Doido runs the Crazystack Typescript track at Crazystack, and the Bootcamp do Dev Doido covers the same ground in a cohort format.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits