Dora NodaIn the last two weeks of July 2026, two developer platforms answered the same question — "how should an AI agent operate your infrastructure?" — with opposite shapes. Railway put its agent inside team chat: mention @Railway in Slack or Discord and it inspects deployments, reads logs, and makes changes without leaving the conversation. Render put its platform inside the agent: one MCP server at a single URL that Claude Code, Codex, Cursor, or a cron job can all speak to, with OAuth sign-in and a tool for every platform action including triggering a deploy.
Both are real, both shipped, and both work today. But only one of these shapes survives contact with the fifth chat app and the fifteenth agent. Here is the comparison up front:
| Railway: agent-in-chat | Render: platform-in-agent | |
|---|---|---|
| Integration surface | One app per chat platform (Slack, Discord) | One MCP server (mcp.render.com/mcp) |
| How it authenticates | Per-user account link + per-workspace link command (/railway-link vs /link workspace) | OAuth for Claude Code/Codex/Cursor; API key for CI |
| What the agent can do | Chat-mediated: inspect, read logs, make changes via conversation | Tool-mediated: a tool per platform action (list services, trigger deploy, edit env vars) |
| Cost of supporting surface N+1 | Build, submit, and maintain another chat app | Zero — any MCP client connects to the same server |
| Cost of supporting agent M+1 | Rebuild the agent for each new chat home | Zero — the protocol is the integration |
The verdict: per-chatbot plugins fragment; a protocol server compounds. The rest of this post shows why — and what a self-hosted platform that owns its machines should expose instead.
What Railway shipped: the agent moves into team chat
Railway's July 2026 was an agent blitz. Cloud Agents entered beta on July 31, Agent Connectors (Notion, Linear, Sentry, plus your own MCP servers) followed on August 7, and the changelog entry for August 14 reads "Cloud Agents Everywhere." The Slack and Discord agent integrations are the team-chat leg of that push: install the app, link it, and the same Railway Agent that runs in the dashboard starts answering @Railway mentions where your team already works.
The linking model is genuinely well thought out. Two connections gate every message: each person links their chat identity to their Railway account, and a workspace admin links the chat workspace to exactly one Railway workspace, which decides which projects the agent can see and which workspace pays for usage. Both are re-checked on every message — leave the workspace and the agent goes silent immediately. Per-user access, per-workspace billing, instant revocation: this is the correct security shape for a shared-surface agent.
But notice what multiplies. Slack gets an install flow and a /railway-link command; Discord gets a different install flow and a /link workspace command. Each chat platform has its own app review process, its own permission model, its own rate limits, and its own UI vocabulary (threads vs replies, embeds vs blocks).
Every capability Railway adds to the agent — a new inspection, a new action — must be expressed, tested, and documented twice, once per chat home. The integrations are in beta, and the docs warn that breaking changes may occur. That warning is honest, and it is also the tell: a surface that lives inside someone else's client inherits someone else's churn.
What Render shipped: the platform moves into the agent
Render's answer, shipped as a July 22 changelog entry, is a single hosted MCP server with OAuth support for Claude Code, Codex, and Cursor. Configure your tool with one URL, complete one browser sign-in, and the agent gains a tool for every platform action Render exposes: list services, inspect deploys, trigger a new deploy (optionally clearing the build cache), manage environment variables. API-key auth stays available for non-interactive environments like CI/CD.
Three properties make this shape different from a plugin. First, it is protocol-standard: anything that speaks MCP — today Claude Code, Codex, Cursor, Zed, GitHub Copilot, tomorrow whatever your team adopts — connects to the same endpoint with no per-client engineering from Render. Second, it is open source: the server lives at render-oss/render-mcp-server, so capability gaps are filed as issues against one repo, not whispered into five different app-store review queues. Third, official plugins with pre-registered OAuth client IDs mean the happy path is "install plugin, click approve" — no API key to paste, rotate, or leak into a dotfile.
The honest footnote is that Render's tool coverage is not yet complete: image-backed services and IP allowlists, for example, are documented gaps with an invitation to file issues. That incompleteness is a point in the protocol's favor, not against it. One server means one gap list, visible in one place, closable once for every client simultaneously.
The sprawl math: N chat apps × M capabilities
Here is the core argument, stated as arithmetic. Every agent integration has two dimensions: the surfaces it lives in, and the capabilities it exposes. A per-chatbot strategy multiplies them. Two chat apps and ten capabilities is twenty integrations to build, review, secure, and keep in parity — and the twenty-first arrives the day your team adopts Teams, or Telegram, or whatever replaces Slack. A protocol-server strategy adds them: ten tools on one server, reachable from any client that speaks the protocol. Supporting client N+1 costs the platform vendor nothing, because the client vendor already paid the cost of speaking MCP.
The industry is voting with its endpoints. Fly.io's Sprites — persistent MicroVM computers for agents — ship a hosted MCP server at a single URL with browser OAuth, plus thin plugins for Claude Code, Cursor, OpenCode, and Cortex that all point at the same server. The pattern is one server, many clients, zero per-client platform work. Even the chat side is consolidating rather than fragmenting: Slack's August 2026 Slack Code launch embeds Claude Code, Devin, Copilot, and Vercel's agent into shared channels, conceding that teams will not install one bot per agent per platform forever.
And the protocol itself is hardening into infrastructure. The MCP spec's July 28, 2026 update made OAuth 2.1 mandatory for remote servers; whole-internet censuses now count ten thousand-plus live remote MCP hosts. A platform betting on MCP is betting on a surface with a standards body, a conformance story, and every agent vendor implementing the client side. A platform betting on chat apps is betting on keeping N parallel implementations in parity forever. One of these bets gets cheaper over time. The other gets more expensive with every launch.
Steelmanned counters
"Chat is where the team already works — approvals happen there." True, and it is Railway's strongest point. A deploy approval that arrives as a thread reply beats one that requires opening a dashboard. But notice this concedes the argument's shape: chat is a notification and approval surface, not an operations surface. The approval can be a message; the thing being approved — the deploy, the rollback, the env-var change — should still execute through one protocol-standard tool call that works identically from chat, from a terminal agent, and from a 3 AM cron job. Approvals in chat, actions on the protocol: these compose.
"MCP itself is the wrong default — Fly.io says CLI-first." Fly.io's "Unfortunately, Sprites Now Speak MCP" post argues, bluntly, that for agents that can run shell commands, showing the agent a good CLI beats loading MCP tool schemas up front. They have a point about context efficiency, and any honest protocol-server advocate should sit with it. But the critique is about which machine interface the agent prefers, not about per-surface plugins versus one surface. A CLI and an MCP server are both "one surface, every client" shapes — Fly ships both, pointed at the same backend. The enemy of both is the N×M matrix.
"Railway also ships an MCP server, so this is a false dichotomy." Correct — Railway's docs offer an MCP server, Agent Skills, and plugins alongside the chat integrations, and that breadth deserves credit. But flagship placement matters. Railway's headline agent bet is "the agent joins your chat," with all the per-platform install/link/maintain cost that entails; Render's is "your agent speaks our protocol." A platform can do both, and the chat leg will still be the leg that costs N times more per capability. The dichotomy is not "Railway bad, Render good" — it is "the chat-plugin leg of any strategy is the leg that does not scale."
What a self-hosted PaaS should expose instead
For a platform that runs on machines you own, the lesson compresses to a checklist:
- Ship machine-readable state first. If an agent cannot
GETthe fleet's declared and actual state, no integration shape saves you. - Keep the API and CLI as the stable contract. They are what cron jobs, scripts, and shell-capable agents already speak.
- Expose exactly one agent-native surface. A single MCP server over OAuth, with one tool per platform action, so every present and future agent client connects without per-client work from you.
- Resist the chat-app treadmill. The moment you ship one bespoke bot, you have volunteered to ship — and forever maintain — one per chat platform your users inhabit.
That is the shape a self-hosted, open-source PaaS should converge on: own the machines, own the API, and let the protocol do the multiplying.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with machine-readable state and agent-native operations as first-class design goals. Star the repo on GitHub or deploy your first app today.
