An AI Future Without the Lock-In — Remy Guercio, Tailscale

Remy Guercio of Tailscale argues that the era of unlimited AI budgets is over and that teams need to escape lock-in while proving real ROI. He breaks an internal AI deployment into four layers (models, data connectors, interfaces, and sandboxes) and presents an AI gateway as the way to keep each layer swappable. He demonstrates how Tailscale's Aperture uses tailnet identity instead of shared API keys, sets per-model budgets, serves as both an LLM and MCP gateway, centralizes authentication for coding agents, and provides logs for diagnosing agent behavior.

7 min read
An AI Future Without the Lock-In — Remy Guercio, Tailscale
source: https://www.youtube.com/watch?v=s-glGHAa1a4

Remy Guercio, who works on Tailscale’s AI gateway Aperture, looks back at the last year as a period of ’token maxing’. He doesn’t mean that pejoratively. Teams have been exploring million-token context windows, pulling context from anywhere through MCP, and using coding tools that find context through the CLI. This made truly agentic coding possible, and he expects agentic use cases beyond coding to keep growing. The approach has real costs, though. It is expensive, and the era of effectively unlimited AI budgets has ended in the last few months. It also encourages wasted tokens by default. From Aperture’s usage data he sees sessions with hundreds or thousands of messages where nobody clears the context, and sessions with tens of millions of tokens where the cache stays saturated the whole time. Finally, it has produced vertically integrated toolchains, with Claude Code, Codex and others building everything from the model up to the agent layer, which deepens lock-in.

The wrong response: consolidating on one vendor

Over the last six months Remy has talked with hundreds of teams about their AI spend. When finance starts asking questions, the usual reflex is to consolidate on a single vendor, or maybe two, in order to regain control. He argues this is a poor answer. It trades flexibility for control, and it locks the organization into whatever it picked first. It also makes it hard to expand AI usage across the company, because if one frontier stack is the only option, certain uses are simply too expensive to justify.

From token maxing to ROI maxing

Remy proposes the next phase as ‘ROI maxing’. This is not just about cutting costs. It means demonstrating real value from what you do with AI, and opening up the choices available so that AI can be used for more than frontier-level tasks where tokens are being wasted. Doing that starts with understanding the components of an internal AI deployment, which are not customer-facing AI features but the tools a company’s own employees use.

The four layers and where lock-in hides

He breaks an internal deployment into four layers:

  • The models (LLMs), which are the reasoning engines.
  • The data connectors. For many people this means MCP, but in practice it can be CLIs, APIs, or simply reading a file into the agent’s context.
  • The interface. This has moved from chat, to mobile, to agents invoked from Slack, and it is worth separating from everything else.
  • The sandbox, meaning the environment in which the agent actually runs.

ROI maxing means keeping the ability to make a choice at any of these layers when it is needed. Teams need not make a bespoke choice at every layer, but the choice must remain available. The right mix differs across an organization. Remy doesn’t imagine an entire engineering team coding through a Slack thread, but he can easily imagine a marketing team doing data questions and other work entirely from Slack.

Why an AI gateway keeps you swappable

An AI gateway sits between agents and their interfaces and all the endpoints behind them, including LLM endpoints, MCP endpoints and API endpoints. It lets you control and monitor what is happening, whether for security, cost, or understanding what an agent is doing. Remy stresses that the term ‘AI gateway’ is intentionally broad. Aperture acts as both an LLM gateway and an MCP gateway, and it can also wrap standard APIs and re-expose them as MCP servers.

He also highlights the diagnostic value of logs. Agents, especially cheaper models, often spiral out of control and are poor at stopping themselves, but they are good at analyzing what went wrong afterward. With a gateway’s logs, you can point the agent back at its own run and ask what happened. He notes that this is useful even for individuals who run agents like OpenClaw on their tailnet in the background and later discover it did something unexpected.

Identity from the tailnet instead of shared keys

The usual gateway workflow is to hand over your provider keys and then mint synthetic keys for every user and tool. Aperture avoids this by building on Tailscale, which is an identity-based mesh network built on WireGuard. Every connection made over the tailnet carries the identity of the machine or user on the other end. That can be a tagged machine identity, such as a PR review bot, with a node identity underneath for each instance, or a human user, such as himself using Claude Code on a laptop. Integrating Entra or Okta can also sync group membership, so the gateway knows which groups a person belongs to.

Aperture is built using tsnet, an open-source Tailscale library for building this kind of identity-aware app. For LLMs, the admin configures providers once. Anthropic, OpenAI, Vertex, Bedrock and Codex keys are all placed on the gateway. A connecting user or agent then needs no extra steps, because the gateway already knows who they are and which models they can access. Budgets are set per model. Cheap models such as GLM can be effectively unlimited, while frontier models get a narrow budget.

MCP access and authentication in one place

On the data side, admins configure MCP servers in Aperture and can use the built-in ones, which have been vetted. Remy notes that MCP implementations differ in how closely they follow the standard, so setting them up can feel like archaeology. Access is controlled through the same identity system. For example, marketing might get Google Calendar and Gmail while engineering also gets GitHub, possibly read-only for some subgroups.

Authentication happens centrally. Whether someone uses Cursor, Claude Code, Codex, or a new agent framework, they simply hit the endpoint, and if they are on the tailnet they are authenticated as themselves or as their device. There is no need to re-authenticate into every tool. Remy argues that this lowers the switching cost, which makes it easier to try new tools and workflows. Many teams never experiment because of these small points of friction.

Interfaces and sandboxes

Aperture includes a built-in chat UI, but it is built on APIs that users can also leverage to create Slack bots, mobile apps, voice interfaces, or other new experiences. Connectors are configured in Aperture itself, not in the chat UI. A forthcoming pass-through OAuth feature is meant to fix a common problem with third-party UIs, where identity is lost and everything appears to come from the system. With pass-through, the gateway would still see user and machine identities even when a different interface is used.

Sandboxes are an area where Remy sees many options already, perhaps too many, since everyone defines a sandbox differently. He describes this as a ’let a thousand flowers bloom’ phase. Aperture plans to add an orchestration layer for sandboxes, so that the gateway acts as a kind of universal translation layer across LLMs, data connectors, interfaces, and environments.

Closing thoughts

Remy’s central point is that ROI maxing is about maximizing choice to prevent lock-in. Even without Aperture, he recommends considering an AI gateway, both to avoid juggling multiple providers and to understand what agents are actually doing. As he puts it, the value of an AI gateway goes beyond lock-in to experimentation and understanding.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

AI Agents Don't Read Your Policy Docs. They Hit Your APIs — Gravitee

AI Agents Don't Read Your Policy Docs. They Hit Your APIs — Gravitee

Sam, CTO at Gravity, argues that AI agent governance must be enforced in infrastructure rather than in prompts or policy documents. Through five live demos against a hotel-booking agent, he shows a gateway blocking destructive tool calls, preventing data exfiltration, rate-limiting runaway agents, serving cached semantic responses, and rejecting oversized prompts before any LLM call. He also covers observability, vendor decoupling via LLM routing, trimming bloated MCP tool lists, and managing shadow AI.

Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i

Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i

Gabriel Martinez of G2i argues that slop is not AI-written code but work that looks finished before the thinking behind it is done. He connects it to missing judgment, code as a liability, misaligned incentives that reward merging speed over review, oversized PRs and documents that push understanding onto reviewers, and the case for conventions, diagrams as review surfaces, and small changes. He closes by explaining why G2i built ORC to keep humans in control of agent-generated work.