The Robot Tax: Why Serve Robotics' 'AWS Moment' is a Connectivity Trap

I have spent my career watching the big telecom carriers carve the world into proprietary fiefdoms. I've seen the playbook: build the essential infrastructure, convince the customer they can't survive without it, and then slowly tighten the screws through pricing models that penalize growth. Now, I am seeing that exact same blueprint being drawn up for the future of robotics.

Serve Robotics—the company that emerged from Uber’s 2021 acquisition of Postmates and went public in 2024—recently announced a pivot that should make every autonomous developer shudder. As TechCrunch first reported, Serve is launching a new business line called "Physical AI Services." The goal, according to CEO and co-founder Ali Kashani, is to become the "AWS for robots."

On the surface, it sounds like a benevolent offering of tools and connectivity. In reality, it is a bid to own the very air that robots breathe.

Let's look at the components of this "Physical AI Services" ecosystem. Serve is offering three primary products: a data curator tool for finding edge cases, a foundation-model data catalog based on their own sidewalk robot experience, and the crown jewel of the lock-in strategy: Serve Link.

Serve Link functions as a bridge, linking robots operating in the field with AI systems hosted in data centers. As Kashani told TechCrunch, the goal is to allow companies to utilize powerful AI models without needing to house all that computing power onboard the robot itself. He argues that the "connectivity piece" must be high performance to manage unreliable networks.

This is where the alarm bells should go off. By positioning itself as the indispensable bridge between the physical robot and the "offline intelligence" required to operate it, Serve Robotics isn't just selling a service; it is building a proprietary connectivity moat.

When a company like Bedrock Robotics—a startup developing self-driving systems for construction equipment—integrates its fleet into Serve Link, it isn't just adopting a tool. It is tethering its operational viability to Serve's proprietary architecture. Once your fleet is dependent on a specific connectivity pipeline to handle "exception handling" and data collection, switching costs become astronomical. You aren't just changing a software vendor; you are performing open-heart surgery on your entire fleet's nervous system.

Kashani explicitly told TechCrunch that he learned this playbook from Amazon. He noted that while you start by building the end-to-end application, the ultimate goal is to "open your technology so others build with you and on your platform."

Let's be clear about what "building on a platform" means in the corporate world. It means the platform owner decides the price of admission. It means the platform owner decides the terms of service. It means that once the ecosystem is established, the provider can implement what I call the "robot tax"—a recurring, escalating fee for the privilege of staying connected.

We have seen this in the telecom industry for decades. Carriers build the network, lock users into restrictive contracts, and then charge exorbitant fees for the very connectivity that the user's business depends upon. Serve Robotics is simply applying this predatory model to the sidewalk and the construction site.

Adding to this concern is Serve's partnership with T-Mobile. According to TechCrunch, the two are working to bring AI computing power closer to the robots. While this might improve latency, it further cements the alliance between a connectivity provider and a robotics platform, creating a vertical integration that could squeeze out independent competitors and leave customers with no alternative but to pay the toll.

Serve is already diversifying its robot fleet, moving beyond its googly-eyed sidewalk delivery machines to include robots for hospitals (via its acquisition of Diligent Robotics) and targeting robots for farms and warehouses. As they expand their physical footprint and their partner list—shifting away from Uber toward partners like Wonder and DoorDash—the temptation to monetize the connectivity layer becomes irresistible.

If you are a robotics developer, the "AWS moment" Kashani describes isn't an invitation to innovate; it's an invitation to be captured. The promise of not having to put computing power onboard your robot is a siren song. It trades hardware costs today for a permanent, proprietary subscription fee tomorrow.

Serve Robotics claims to be solving the problem of "robots in human spaces." But the real problem they are creating is a future where the autonomy of the robot is owned not by the company that built the machine, but by the company that owns the link. We don't need another connectivity monopoly. We certainly don't need one that can shut down a construction site or a hospital delivery fleet with a single billing update.