Skip to content

CONCEPT Cited by 2 sources

Robot Experience (RX)

Definition

Robot Experience (RX) is the product-design axis that sits alongside UX (end-user experience) and DX (developer experience) and asks: when an LLM-driven coding agent ("robot") uses this platform, does the platform's shape fit the robot's workload? Introduced by name in Fly.io's 2025-04-08 post "Our Best Customers Are Now Robots" as a product-shaping concern the author argues "nobody has nailed yet."

Canonical wiki statement

Fly.io, 2025-04-08:

One of our north stars has always been nailing the DX of a public cloud. But the robots aren't going anywhere. It's time to start thinking about what it means to have a good RX. That's not as simple as just exposing every feature in an MCP server! We think the fundamentals of how the platform works are going to matter just as much. We have not yet nailed the RX; nobody has. But it's an interesting question.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

What distinguishes RX from DX

Fly's post gives four specific data points where the RX-shape diverges from the DX-shape:

  • Compute lifecycle. Humans "reasonably" mash the create button to boot apps; robots consume the start/stop split — create once, start/stop many times, pay only when running.
  • Storage. Humans want Postgres; robots want a filesystem + object storage so they can iterate in place on a Machine that boots from a minimal base image.
  • Networking. Humans want simple load balancing; robots need session affinity for long-lived MCP SSE connections to multitenant MCP servers.
  • Secrets. Humans are fine pasting an OAuth token into an env var; robots need tokenized-secret brokers so the LLM never holds the real credential.

RX ≠ "expose every feature in an MCP server"

Fly's post is explicit that the naïve read of RX ("just publish an MCP server for the Fly API") is insufficient:

That's not as simple as just exposing every feature in an MCP server! We think the fundamentals of how the platform works are going to matter just as much.

(Source: sources/2025-04-08-flyio-our-best-customers-are-now-robots)

The claim is that how the platform works — lifecycle primitives, storage primitives, routing control, secret handling — shapes whether robots can use it effectively, independently of whether there's an MCP front door. An RX-shaped platform has to get those fundamentals right first; an MCP surface on top is the second step, not the first.

Adjacent framings on the wiki

  • concepts/agent-readiness-score — Cloudflare's 2026-Q2 Agent Readiness Score covers the same design concern on the documentation + site-crawlability axis, giving concrete scoring criteria for whether a site can be consumed by an AI-agent crawler. Fly.io's RX concern is on the compute-platform-primitives axis. Same spirit, different layer.
  • concepts/agent-ergonomic-cli — Cloudflare's framing that a CLI must be "agent-ergonomic" generalises to APIs. Agent ergonomics at the tool / CLI / API surface layer is RX at the tool-surface level; Fly.io's RX is RX at the platform- primitive level.
  • concepts/agentic-development-loop — the workload shape that motivates the RX axis.
  • concepts/vibe-coding — Fly.io's gloss for the coding- session shape RX platforms need to serve.

Why RX matters now

The post's load-bearing empirical claim is that the growth- driving users on Fly.io over the past ~6 months (late 2024 → early 2025) are LLM-driven agents, not humans:

A funny thing has happened over the last 6 months or so. If you look at the numbers, DX might not matter that much. That's because the users driving the most growth on the platform aren't people at all. They're… robots.

That shift — if generalisable beyond Fly.io — makes RX a first-order product-design concern for any compute, storage, or API platform, the way mobile was in 2008 or cloud-native was in 2015.

What's still unknown

  • RX metrics. The post names RX as a design axis but does not propose metrics for it. There's no "RX score" analogue of Cloudflare's Agent Readiness Score at the platform- primitive level.
  • RX regressions. No published framework for when an RX improvement regresses DX or UX (or vice versa). Fly's four data points are all cases where RX + DX are compatible (start is fast for both; Flycast scopes for both); the harder case — where they genuinely conflict — isn't engaged with.
  • RX liability model. When a robot does something destructive using a platform primitive, who is liable? The post doesn't engage with this at all — it's a forward- looking product framing, not a policy framing.

Seen in

  • sources/2025-04-08-flyio-our-best-customers-are-now-robots — Fly.io's 2025-04-08 post introducing RX by name as a product-design axis alongside UX and DX.
  • sources/2025-06-20-flyio-phoenixnew-remote-ai-runtime-for-phoenix — coding-agent specialisation of RX. Four months after introducing the RX framing, Fly.io ships Phoenix.new — a full product (ephemeral cloud-IDE for agents) where the primary tenant of a per-session Fly Machine is a coding agent with root shell, the iteration model is async-agent-workflow rather than interactive IDE, and shipping artifacts are pull requests via gh. McCord's framing — "the future of development … probably looks less like cracking open a shell and finding a file to edit, and more like popping into a CI environment with agents working away around the clock" — is the coding-agent-flavoured restatement of the 2025-04-08 RX thesis.
Last updated · 200 distilled / 1,178 read