Agent-safe deployment is the wedge

Published 2026-05-05 by tavin

The first version of the agent-deployment pitch was simple: “Your AI agent can deploy over MCP.”

That was true, and it mattered. It is also no longer enough.

MCP is becoming normal platform surface area. Render, Railway, Vercel, Fly.io, and others are all moving toward agent-readable and agent-callable deployment APIs. That is good for the market. It means the question changes from “does the platform have MCP?” to “what kind of authority does the agent receive?”

For tavin.cloud, the answer is agent-safe deployment.

The wrong default is broad authority

The easiest way to let an agent deploy is to give it the same credential a human or CI system uses for everything:

• a long-lived platform API key
• a browser session
• a cloud account credential
• a kubeconfig
• a CLI already logged into production

That works until it does not. The agent may do the right thing, but the blast radius is hard to explain. If a human cannot quickly answer what the agent can access, how to revoke it, and what it changed, the permission model is too muddy for production operations.

The useful default is narrow authority

Agent-safe deployment starts with boring questions:

• Which repo is being deployed?
• Which branch and build plan are being used?
• Which user approved the action?
• Which credential did the agent use?
• Can the credential mutate anything else?
• Can it be revoked without touching the user’s browser session?
• Is every tool call auditable after the fact?

These are not flashy product features. They are the difference between an agent workflow people demo and an agent workflow people trust.

Deploy intents are the handoff

For public GitHub repos, tavin.cloud supports a deploy-intent handoff. An agent can infer repo details, create a deploy intent, and send the user an approval URL.

The user approves in the browser. The agent receives a tad_... token that can only poll status for that one intent. Approval creates the project, creates the service, clones the repo, builds with Railpack by default or Dockerfile when present, and starts the deployment.

That gives the agent enough agency to drive the workflow without giving it an account credential before the user has approved the infrastructure action.

MCP is still the right interface

MCP remains the right interface for authenticated workflows. Claude, Cursor, Codex, CI, or another client can use OAuth or a scoped PAT to call explicit tools:

• init_from_repo
• deploy_project_source
• wait_for_deployment
• set_env
• get_deployment_build_logs
• get_deployment_runtime_logs

The point is not that MCP is magic. The point is that the platform exposes product operations as structured tools instead of asking the agent to click through a dashboard or parse loose CLI output.

Repo-to-container keeps the runtime legible

The other half of the wedge is the repo. Agents are better at operating systems they can inspect. A repo gives the agent real artifacts to reason over:

• package manifests and lockfiles
• build commands
• exposed port
• startup command
• env var examples
• Dockerfile, when the app needs explicit runtime control

The deploy surface can stay narrow because the source and runtime clues are already in the repo, and the result is still a normal container.

The product bet

tavin.cloud should not try to be every PaaS at once. Render is mature. Railway is fast and broad. Fly is infrastructure-rich. Vercel owns the frontend path.

The sharper bet is smaller: make repo deployments safe for agents and legible for humans.

That means scoped credentials, browser approval, status-only handoffs, audit logs, build logs, env vars, custom domains, and live URLs. Kubernetes stays behind the curtain. Railpack handles the common path, Dockerfile handles explicit control, and the agent gets just enough authority to ship.