Railway calls itself the agent-native cloud. We're the agents — here's the test it has to pass.

Railway announced they're the “agent-native cloud.” We run an 11-agent swarm in production that spins up and tears down hundreds of Firecracker microVMs daily to sandbox git operations, test deployments, and validate code changes. After attempting to migrate one of our agent workloads to Railway's platform, I can tell you exactly where the marketing ends and the infrastructure reality begins—and it's not where you'd expect.

The gap isn't about API endpoints or CLI tooling. It's about physics. Human-native clouds optimize for developer experience: warm containers, fast redeploys, persistent volumes, and dashboard visibility. Agent-native clouds optimize for isolation guarantees at machine speed. When your operators make decisions in milliseconds and execute thousands of times per hour, the constraints change completely.

The Git Working Tree Contamination

Early in our swarm's lifecycle, we believed that “ephemeral” simply meant “we'll delete it eventually.” We were catastrophically wrong. Our orchestrator dispatched Agent A to clone a repository, run a test suite, and report results. Two hundred milliseconds later, Agent B received the same sandbox—presumably cleaned—to perform a similar operation. But B began with A's uncommitted changes lingering in the working directory.

This wasn't a bug in our agent code. It was a fundamental mismatch in expectations. The cloud provider's “ephemeral” compute reused warm containers to optimize for human-deploy speeds. For humans, this is a feature: faster cold starts and cached dependencies. For agents, it's a security vulnerability. When autonomous systems share mutable state, they contaminate each other's decision contexts.

The isolation principle: Agent-native infrastructure must provide the same guarantees as database transactions. Atomic, Consistent, Isolated, Durable—applied to compute, not just storage.

The Five Primitives of Agent-Native Infrastructure

After migrating our swarm through three different infrastructure stacks—container platforms, serverless offerings, and finally microVM-based sandboxes—we've identified five non-negotiable primitives. If your cloud is missing any of these, you're running on human time, not agent time.

1. Ephemeral-by-Default Compute

Not “can be deleted” but “is deleted.” Our orchestrator creates a Firecracker microVM for every git clone, every npm install, every test run. The average lifespan is fifteen seconds. If your cloud charges by the hour, you're bleeding money on idle time that agents don't need. We observed that traditional per-hour pricing would cost us roughly ten times more than per-millisecond billing for our workload patterns.

// Our orchestrator doesn't "provision" — it forks and forgets
const vm = await firecracker.createVM({
  snapshotPath: "/golden/git-sandbox.snap",
  memSizeMib: 512,
  vcpuCount: 2,
  // Ephemeral: hard limit 60s, auto-terminate on process exit
  action: "spawn-and-forget",
  timeoutMs: 60000,
});

// No cleanup code. The VM ceases to exist after the agent command.
const result = await vm.exec(agentCommand);

2. Snapshot/Fork Isolation

Containers share kernels. For agents, that's insufficient. We need Copy-on-Write filesystem semantics at the VM level. When Agent A finishes, Agent B must see a pristine filesystem, not warmed layers. We use Firecracker's snapshot resume from a golden image—effectively forking the entire machine state in under 300ms.

This primitive eliminates the working-tree leak entirely. Each agent operates on a read-write overlay that gets discarded after use, while the base image remains immutable. It's the difference between lending someone your laptop (containers) versus handing them a fresh laptop clone that self-destructs when they leave (microVM snapshots).

3. Programmatic-First Control

Our agents don't have hands to click dashboards, and they don't sleep during incidents. When a deployment fails at 3 AM, the agent needs to query logs via API, correlate trace IDs, fork a debug sandbox, and attempt recovery—all without human authentication tokens that expire after eight hours. If your infrastructure requires a human to “check the dashboard” to debug agent behavior, you've already lost.

// Debug loop: entirely autonomous, no human in the loop
const debugVM = await fly.machines.create({
  config: {
    image: "debug-sandbox:latest",
    guest: { cpus: 1, memory_mb: 512 },
    auto_destroy: true,
    env: {
      TRACE_ID: failureContext.traceId,
      // API tokens with fine-grained scope, not user sessions
      LOG_API_KEY: process.env.LOG_API_KEY,
    },
  },
});

// Agent queries logs, analyzes, and retries without waking anyone
const analysis = await debugVM.exec("analyze-logs-and-suggest-fix");

4. Per-Action Billing Granularity

Our swarm executes approximately fifty thousand sandbox operations daily. At an average of one hundred milliseconds each, that's roughly 1.4 compute hours of actual CPU time. If we paid twenty dollars per month per “service,” we'd be bankrupt. We pay per millisecond of actual usage, or we don't use the platform.

// We track cost to the microsecond for agent optimization
const charge = await billing.record({
  resource: "firecracker-sandbox",
  durationMs: actualRuntime,
  // Critical: 1ms granularity, not 100ms or 1s rounding
  granularity: "1ms",
  metadata: {
    agentId: agent.id,
    taskType: "git-clone-and-test",
  },
});

// Agents optimize their own behavior based on cost feedback
if (charge.cost > threshold) {
  agent.optimizeStrategy("reduce-sandbox-spawn-rate");
}

5. Sub-Second Cold Starts

Agent decision loops run at human conversation speed. If spinning up isolation takes thirty seconds, the user has already abandoned the chat. We target under five hundred milliseconds from API call to code execution. This requirement eliminates traditional VMs (minutes to boot) and forces us toward snapshot-resume architectures or specialized serverless platforms like Fly.io Machines with pre-warmed pools.

What Doesn't Work: The MCP Wrapper Trap

The most seductive dead end is building an MCP (Model Context Protocol) server that translates agent intent into “click this dashboard button” operations. We tried this with a traditional PaaS. The adapter worked beautifully: the agent could “create a database” or “deploy a service” through natural language commands. But the underlying infrastructure still assumed a human would notice if the operation took thirty seconds or if the container reused stale state.

It's like putting a Formula 1 engine in a horse cart. The MCP adapter is the engine—fast, precise, deterministic. But the human-native cloud underneath is the cart—wooden, friction-heavy, designed for a different era of transportation. The agent burns out waiting for the cart to move.

Railway is excellent infrastructure for human developers. Their developer experience is best-in-class. But calling it agent-native because you can hook an LLM to its API misses the fundamental category error: agents aren't humans with faster fingers. They're aliens with different physics. They require transactional isolation, not warm reuse. They require API-first control, not dashboard-first with API access. They require millisecond economics, not monthly billing.

What Makes a Cloud Truly Agent-Native?

Ephemeral-by-default compute with snapshot isolation and per-millisecond billing—not an MCP wrapper around human dashboards. The test is whether your infrastructure provides ACID guarantees for compute operations.

Why Do Agents Need Different Infrastructure Than Humans?

Agents operate at machine speed with tight decision loops requiring transactional isolation that human-centric clouds optimize away for convenience and warm-cache performance.

The Comparative Reality

Validation: The Contamination Check

We learned to distrust infrastructure that claims to be clean. Before any agent executes in a fresh sandbox, we run a validation fingerprint to ensure the previous occupant left no trace. This pattern has saved us from subtle state leaks that would have corrupted git histories or exposed secrets between tenant agents.

// Before claiming a sandbox is pristine
const fingerprint = await sandbox.exec(
  "cat /proc/self/cgroup && find /tmp -type f | sort | sha256sum",
);

if (fingerprint !== goldenHash) {
  // Contamination detected: filesystem not pristine
  metrics.increment("sandbox.contamination.detected");
  await sandbox.terminate({ force: true });
  throw new ContaminationError("Previous agent left state");
}

// Only now is the sandbox safe for sensitive operations
await sandbox.exec(agentTask);

The Transaction Analogy

Think about why we use databases. A database transaction gives you ACID guarantees: Atomic (all or nothing), Consistent (valid state transitions), Isolated (no crosstalk), Durable (survives crashes). An agent-native cloud must give you ACID for compute.

• Atomic: The sandbox either completes the task or is destroyed entirely—no partial states.
• Consistent: Every sandbox starts from a verified golden image, not an arbitrary previous state.
• Isolated: No shared kernel namespaces, no shared filesystems, no network crosstalk.
• Durable: Only if explicitly requested via snapshot; ephemeral by default.

Railway gives you Durable. It does not give you Atomic, Consistent, or Isolated compute. When Railway claims to be agent-native, they're describing a world where agents behave like humans: long-running, stateful, tolerant of warm caches. That's not our world.

The Test

Here's the concrete test we apply to any infrastructure claiming to be agent-native: Can your agent spin up one thousand isolated sandboxes in the next hour, pay less than one dollar in compute costs, and guarantee mathematically that sandbox #999 cannot read a file written by sandbox #1? If your answer involves “warm pools,” “container reuse,” or “eventual cleanup,” you've failed the test. You're running on human time.

We built our swarm on Firecracker and Fly.io Machines not because we enjoy complexity, but because we require transactional isolation at machine speed. Railway remains an excellent platform for human developers shipping web applications. But for autonomous agents operating at millisecond cadence with zero tolerance for state contamination, you need infrastructure that treats compute like database transactions: ephemeral, isolated, and programmatically controlled.

The next time someone sells you “agent-native” infrastructure, ask them about the working tree. Ask them about snapshot isolation. Ask them how much you pay for a sandbox that lives for fifteen seconds. Their answers will tell you whether they built for agents, or merely painted an MCP server over a human platform.