Operating Systems for the Physical World: Software Priced Like Labor — Why YC Wants a Boss for Agents, Robots, and People

This is the ninth article in this series reading Y Combinator's Fall 2026 Requests for Startups one request at a time. The request in question is "New Operating Systems for the Physical World," written by YC's Charlie Warren, and it starts from a statistic that should embarrass the software industry: "80% of the global workforce doesn't sit at a desk." The software that manages all that non-desk work — construction management platforms, CMMS tools for maintenance teams, fleet operations systems — hasn't really changed in over 20 years. Warren's characterization of the incumbent category is blunt: the existing software basically does some combination of dispatching people, tracking them, managing assets, and billing. It was built to digitize paper workflows, and it succeeded, and then it stopped.

What the request actually says

The core claim is that the workforce being managed is about to stop being homogeneous. Warren describes three kinds of workers arriving on the same job: AI agents that can quote a service and schedule a team, robots physically deployed in the field, and humans who increasingly wear devices that document their work as they do it. None of the incumbent systems were designed for that mix, because when they were built, the mix didn't exist.

The request then asks the questions that define the product. How do you route a job between an agent, a robot, and a person? What does safety look like when humans and robots work literally side by side? Those are the actual hard problems, and we'll come back to them.

The economic argument is the sharpest part. Warren notes that these industries spend 10 to 100 times more on labor than on software. The incumbent platforms charge for coordination and visibility — a seat license, a per-project fee — which caps them at the software line of the budget. A system that manages combined robot and human labor gets priced against the labor line, which is one to two orders of magnitude larger. In Warren's words, "the opportunity here is heck of a lot bigger than the existing software." There's a second prize buried in the request: whoever runs this layer will record all the work as it actually happens — end-to-end data about physical work execution that neither the frontier AI labs nor the robotics companies will possess on their own. That data is the training corpus for whatever comes next.

Why now, and why not before

Each ingredient in Warren's three-worker picture crossed a usefulness threshold recently, and roughly simultaneously. Language models became reliable enough to handle the clerical spine of field service — intake, quoting, scheduling, dispatch narration — which is precisely the work the old software made humans do through forms. Field robots stopped being demos: machines for drywall finishing, site layout, material hauling, and industrial inspection are on real job sites with real contracts, mostly as single-task specialists sold or rented by their makers. And wearables — helmet cameras, smart glasses, sensor-laden vests — turned the field worker from an unobserved actor into a data source, whether or not anyone is yet doing much with the footage.

What has not arrived is the layer above. Today, a contractor who employs a robot rents it from one vendor with its own portal, runs human crews on a project management platform from another era, and gets AI in the form of a chatbot bolted onto the office side. Three worker types, zero shared schedulers. The RFS is a request for the scheduler.

What is actually hard

The messy environment problem comes first. Software people habitually underestimate physical work because they imagine it as a warehouse: fixed layout, known inventory, repeatable tasks. A construction site is the opposite — the environment is itself the work in progress, changing daily, weather-dependent, shared by subcontractors who don't share systems or incentives. Any operating system for that world must tolerate stale data, partial observability, and plans that die on contact with Tuesday morning.

Second, legacy workflow gravity. Field industries run on habits with decades of legal and insurance scaffolding: work orders, lien waivers, safety briefings, union rules, prevailing-wage documentation. A new OS can't rip this out; it must ingest it, which means unglamorous integration work against systems whose vendors have no interest in being integrated with. The graveyard of construction-tech startups is full of superior products that lost to whatever the general contractor's insurer already accepted.

Third, safety — the question Warren poses directly. When a human and a robot share a physical space, the routing decision becomes a liability decision. Who certified the handoff? What happens when the robot's task overlaps a human's path? Industrial robotics solved this with cages and light curtains; field robotics has no cages. The honest answer is that the coordination layer inherits responsibility for outcomes it doesn't fully control, and the company that figures out the insurance and certification story may matter more than the one with the best scheduler.

Fourth, the human-robot handoff itself. Routing a job between an agent, a robot, and a person implies the system knows each worker's real capability envelope. It won't, at first. Robots fail in ways their spec sheets don't predict; humans absorb ambiguity that robots can't. Early versions of this OS will effectively be exception-management systems, where the exceptions are most of the volume. That is survivable only if the product is honest about it: sell fast visibility and reassignment, not the fantasy of autonomous orchestration.

Who's attempting it? The incumbents — construction platforms like Procore, trades software like ServiceTitan, fleet telematics like Samsara — own the workflows and the data exhaust but are architecturally and commercially wedded to per-seat human coordination. The robotics companies (Canvas in drywall finishing is among the examples circulating in industry coverage) own the machines but not the job. A newer cohort is reportedly building the connective tissue — robot-agnostic deployment and orchestration layers — though it is early and most of what's public is positioning. The white space Warren describes, one system that treats agents, robots, and people as a single schedulable workforce, appears genuinely unoccupied.

Building it likely means starting the way the best vertical software always starts: one trade, one workflow, one worker type mix, in a segment where a robot or an agent already does real work — inspection-heavy maintenance and repetitive-task construction niches look most tractable. Charge against outcomes delivered rather than seats, accept that the first product is mostly software for humans with a robot column in the schedule, and let the labor-line pricing grow as the non-human share of the work does. The moat, if it comes, is the execution data.

Where Gwen stands

Robots and field operations are not Gwen's lane, and it would be silly to pretend otherwise. Gwen is not a robotics, hardware, or field-operations product, and nothing in this request is something Gwen builds toward.

The honest overlap is conceptual. Gwen's daily work is coordinating digital agents on long-lived missions — routing each task across many AI models by measured quality and cost, keeping durable transcripts, and gating outward actions behind human approvals before anything gets sent, published, or spent. That pattern rhymes with the one Warren describes: heterogeneous workers with different capability envelopes, a scheduler that has to know what each can actually do, and humans holding the approval points where consequences live. But the rhyme runs in one direction only — the physical version is harder in every way that matters, because Gwen's failures cost a retry and a field failure can cost a person.

Where Gwen can genuinely serve this category is picks-and-shovels. A startup building a physical-world OS still needs a web presence that explains a complicated product, a CRM and email pipeline for a long enterprise sales motion, research on regulations and competitors, and the everyday marketing and operations work that a small technical team shouldn't spend its hours on. Gwen builds and hosts websites and small web apps from a plain-language description on live, shareable links — the customer owns the code and can export it to GitHub — and does the surrounding content, CRM, research, and operations work against a Work Budget with enforced spend ceilings. Modest, digital, and adjacent. The robots belong to someone else.