Look at the direction of the connection. The provider sends a resource request into Coder, Agent Relay launches a workspace, using a prebuild for a warm start, applies the correct template, and the provider's daemon inside that workspace opens a secure link back out to its external service [4]. Each Coder workspace can start a Cursor worker that dials outbound [7]. Nothing requires an inbound hole, which the network team will like, and the flow carrying agent traffic to the vendor is the one that ends up on the egress allowlist rather than under inspection. Coder says Agent Firewall, RBAC and audit logging apply automatically because the work happens inside a workspace, so there is no separate security model to build for agent traffic [5].
The split is planner remote, effectors local. Cursor continues to run the agent loop, including inference and planning, while tool calls execute in Coder environments on the customer's network, which is how Coder gets to say source code, secrets and internal services stay on machines the customer controls [6]. A planner still needs context to plan with. Both posts describe the perimeter in terms of where tool calls execute, not in terms of what the loop is sent to reason over. For the perimeter claim to hold up in a bank's review, one of two things has to be true: the remote loop plans without file contents, or the context it receives is scoped and recorded on the way out. Neither post says which.
The attribution work is the part I would pay for. Agent Relay resolves each incoming request against the organization's existing identity provider, so an agent's commits, tool calls and file access carry the same attribution as a human developer's [8]. Coder's own AI Maturity Model assessment of 100 engineering organizations found 70 percent running agents on infrastructure never designed to support them and only 31 percent at organization-wide governance, usually because nobody can say which human an agent's actions trace back to [9]. That leaves 69 of the 100 without it, and a 39-point gap between the two figures [10]. Coder assessed those organizations itself, so treat the numbers as the shape of the problem rather than its size.
The most persuasive paragraph in the launch post is the one about what failed. Coder's earlier self-hosted work used AgentAPI, an approach similar to today's Agent Client protocol, to run agent CLIs inside workspaces behind a common interface; it worked, but AgentAPI never gained traction as a standard, and wrapping CLI agents added friction when recreating their experience in a web app [13]. Registering as a compute pool in someone else's scheduler avoids re-implementing someone else's product surface, and it divides the work honestly: Coder supplies the machine, the vendor supplies the loop. Coder Agents remains the other path, running its reasoning loop in the Coder control plane while code, credentials and execution stay in customer infrastructure [14].
Both posts reach for Gartner. Forty percent of enterprise applications carrying task-specific agents by the end of 2026, up from less than 5 percent in 2025 [11], is more than eightfold in about a year [12], and that transfers to your capacity plan only if your applications get counted the way Gartner counts a task-specific agent feature. If your constraint is where commands run and which human owns them, this is the right tradeoff, and the plumbing looks well made. If your constraint is what the model sees, the relay moves execution and leaves that question where it was.
