Coder announced Agent Relay on September 2, with SpaceXAI as the launch partner — a way to run Cursor’s cloud coding agents entirely inside a customer’s own infrastructure. It’s currently in private preview, one partnership deep, but the architecture pattern it’s built on is worth understanding now, because it’s the same shape a handful of other vendors are converging on for the same reason: regulated enterprises want agentic coding tools, but they’ve been structurally unable to adopt the vendor-hosted versions.

The problem this actually solves

Most “cloud coding agent” products today work the same way: your code, prompts, and often your secrets travel to the vendor’s infrastructure, the agent loop runs there, and results come back. That’s fine for a huge swath of companies. It’s a non-starter for banks, defense contractors, and government agencies with data residency and network isolation requirements that predate agentic coding entirely — the same requirements that already blocked plenty of SaaS tooling for these organizations for the last decade.

Agent Relay’s split is specific: tool execution — file reads, shell commands, test runs, anything that touches actual source code or internal services — happens inside a Coder workspace on infrastructure the customer controls. Inference and planning — the actual model calls that decide what to do — still run on Cursor’s side. Source code, secrets, and internal service access never leave the customer’s network; only the agent’s reasoning traffic (prompts, plans, diffs to review) crosses the boundary.

┌─────────────────────────────┐        ┌──────────────────────┐
│   Customer network           │        │   Cursor cloud        │
│                               │        │                        │
│  ┌─────────────────────┐    │        │  ┌──────────────────┐ │
│  │ Coder workspace       │    │◄──────►│  │ Agent loop         │ │
│  │  - source code         │    │ plans/ │  │  - inference        │ │
│  │  - secrets              │    │ diffs  │  │  - planning          │ │
│  │  - shell/test execution │    │        │  └──────────────────┘ │
│  └─────────────────────┘    │        │                        │
└─────────────────────────────┘        └──────────────────────┘

This is a fundamentally different trust boundary than either extreme most teams default to — “everything runs on the vendor’s cloud” or “we can’t use hosted agent tools at all, build something in-house.” It’s closer to how a lot of enterprise SaaS matured a decade ago: a control plane that stays vendor-operated (billing, UI, model access, feature updates) paired with a data plane the customer owns and never has to trust a third party with.

Where I’d actually reach for this pattern

I don’t work with regulated-enterprise clients directly, but I’ve built enough internal agent tooling to recognize the shape of the tradeoff. Three situations where I’d deliberately split tool execution from inference like this, rather than just picking “fully hosted” or “fully self-hosted”:

Working against a client’s production database or internal APIs. If an agent needs to run queries or hit internal services during a task, I don’t want those credentials anywhere near a third-party’s execution environment — even a reputable one, even with contractual guarantees. Splitting execution onto infrastructure I control means the blast radius of a leaked prompt-log or a compromised vendor account stops at “they saw a diff,” not “they had a live database credential.”

Compliance-gated codebases. A few of the client engagements I’ve worked have contractual clauses about where source code can physically reside, independent of whether the vendor is trustworthy — the constraint isn’t about trust, it’s about audit and liability. No amount of vendor security posture satisfies a contractual data-residency clause; only architecture does.

Cost-sensitive high-volume agent runs. This is the underrated benefit: if tool execution runs on your own compute, you’re not paying a vendor’s markup on every shell command, file read, and test run an agent fires off during a long task — only on the inference calls that actually need their model. For a long-running refactor task that touches hundreds of files, the execution-step count can dwarf the inference-step count.

The part that doesn’t get solved by this pattern

Splitting execution from inference doesn’t remove the vendor from your trust boundary — it narrows it. Cursor’s model still sees your prompts, your code diffs, and enough of your codebase’s shape to plan intelligently. If “no code ever leaves our network in any form” is the actual requirement, self-hosted execution alone doesn’t satisfy it; you’d need a fully self-hosted or open-weight model too, which is a different (and currently much larger) tradeoff against capability. Agent Relay’s pitch is specifically for organizations whose real requirement is “raw source, secrets, and internal service access stay put” — not “the vendor never sees anything.” Worth reading the actual compliance requirement carefully before assuming this pattern clears it; I’ve seen teams conflate “data residency” with “zero vendor visibility” and they are not the same bar.

There’s also an operational cost that’s easy to underweight in the pitch: you’re now running and maintaining the execution infrastructure yourself — patching the workspace images, managing the network boundary, monitoring the relay connection for the inevitable day it flakes mid-task. That’s real platform-engineering work that a fully-hosted agent tool doesn’t ask of you. For an enterprise with an existing platform team, that’s a Tuesday. For a smaller org evaluating this because it sounds more secure, it’s a new maintenance burden they should size honestly before committing.

Why this pattern is likely to spread

Coder isn’t alone in this shape — it’s the same instinct behind self-hosted runners for CI, behind BYOC (bring-your-own-cloud) deployment models that became common for data platforms a few years back, and behind every “control plane hosted, data plane yours” architecture that’s shown up whenever a vendor tool needs deep access to something a regulated customer can’t hand over wholesale. Agentic coding tools are just the latest category to hit that wall, and the fact that Cursor — not exactly a laggard on hosted-agent UX — is willing to split its architecture this way for enterprise access is a signal that the regulated-enterprise segment is now large enough to be worth the engineering cost of supporting two deployment topologies instead of one.

If you’re evaluating agentic coding tools for a compliance-constrained environment, the question to ask a vendor isn’t “is it secure” — everyone says yes. It’s “what specifically crosses the network boundary, and can I audit that traffic independently of your dashboard.” Agent Relay’s answer — plans and diffs, not source or secrets — is a concrete, checkable claim. That’s the bar other vendors chasing this segment will need to clear too.