Operating Systems for Physical Work

Why coordinating human workers, AI agents, and robots requires a new category of software

Field workers coordinating on a construction site

The Problem

Eighty percent of the global workforce does not sit at a desk. Yet the software that coordinates field work has barely evolved in twenty years. Construction crews, field service technicians, delivery networks, and maintenance teams still rely on dispatch boards, SMS coordination, and paper checklists.

More importantly, the nature of field work is changing. Three distinct types of workers now coexist on a single job:

Human workers who execute complex tasks, make judgment calls, and oversee outcomes
AI agents that can quote complex work, schedule teams, route jobs, and negotiate with customers
Robots deployed to handle repetitive, dangerous, or precision work (inspection, demolition, heavy lifting)

Today's software was designed for a world of just humans. It can dispatch a crew or route a delivery. But it cannot coordinate a human, an AI, and a robot on the same job. That gap is the opportunity.

Why This Matters

The core insight: Coordinating three types of workers on one task is fundamentally different from dispatching humans or managing equipment. Safety, liability, timing, and decision-making all change when a robot and human are working side-by-side, and an AI agent needs to know in real-time whether to trust the robot's output or escalate to the human.

This is not an incremental problem. The questions are architectural:

How do you route a job between a human, an AI agent, and a robot? What are the decision trees?
What does safety look like when humans and robots work literally side-by-side?
How do you measure reliability when three independent agents are coordinating?
Where does liability land when a robot makes a mistake? The human? The AI? The platform?
How do you bill for work when the same task spans human labor, AI time, and robot hours?

The existing category (workforce management software) treats robots as inventory, not as active decision-makers. The existing category treats AI as a back-office tool (scheduling, routing), not as a worker on the job. Neither assumption holds anymore.

Why a Landing Page MVP Is Not Enough

You could build a landing page, get customers, and deploy a basic dispatcher. Many such MVPs exist. But the complexity hides inside the product, not on the marketing surface.

The core decisions are not about whether customers want this. They clearly do. The core decisions are about:

Technical Architecture

How do you model a job that can be split between human, AI, and robot workers?
How do you handle real-time coordination when workers are asynchronous (a robot finishes a task at 2:15pm, the human isn't ready for handoff until 2:45pm)?
How do you validate that work was done correctly? Who signs off? The human? An AI inspector? Both?

Safety and Liability

Building this without deep construction/field service domain expertise is risky. Early customers could get hurt. The liability is real.
Robots are heavy machinery. Coordinating their deployment with human workers is not a software problem; it's a safety engineering problem.

Go-to-Market Complexity

Your customers are not tech-forward. They are construction foremen, field service managers, and logistics coordinators.
Each vertical (construction, maintenance, delivery) has different equipment, different job types, and different regulatory constraints.
You cannot sell a generic "operating system for workers." You have to pick a vertical and go deep.

What the Realistic Product Would Look Like

Month 0-3: Single Vertical, Two Worker Types

Pick construction, HVAC, or field service. Build a job dispatcher that handles human workers and AI agents. No robots yet. The AI agent quotes jobs, suggests scheduling, and flags high-risk work for human review. Humans can override or delegate. Get 5-10 early customers and learn what breaks.

Month 3-6: Add Observation and Validation

Robots are mostly cameras and sensors today. Integrate with job-site cameras (or deploy cheap camera drones) so the AI agent can verify work was done. The robot's job is to observe and report; humans decide next steps. This is less ambitious than autonomous robots, but it's more valuable than dispatch software.

Month 6-12: Add Autonomous Task Routing

Once you understand what work can be automated, introduce robots for specific sub-tasks (inspections, measurements, asset tracking). The dispatcher now routes not just humans, but human+robot pairs on the same job. Expand to one adjacent vertical.

Month 12+: Horizontalization

You now have a playbook for human+robot coordination. Expand to adjacent fields (logistics, manufacturing, utilities). The operating system becomes defensible because each vertical's playbook is deeply learned and hard to replicate.

Who Would Build This

This is not a software-only story. Successful bidders would likely have:

Deep construction or field service experience. You need someone who has managed a crew and knows why today's tools fail. A first-time founder in construction tech will miss critical safety and workflow nuances.
Robotics hardware partnerships. You cannot build this without access to robots (or the ability to integrate with robot APIs). That requires relationships with Agile Robotics, Boston Dynamics, or equivalent.
Regulatory navigation. Deploying robots on construction sites involves liability waivers, insurance, and worker safety boards. A team that has navigated this before has a 2-year head start.
Patient capital. This is not a 18-month venture-scale problem. It is a 3-5 year build to meaningful revenue. You need a founder or backing that is willing to be slow.

Alternatively, this could be built by an existing field service software company (ServiceTitan, Housecall Pro) or a robotics company (Boston Dynamics, Agile Robotics) that decides to own the dispatch layer. The risk for a startup is that by the time this product is ready, a larger incumbent has already moved in.

Honest 12-Month Outlook

Revenue

If you pick one vertical and acquire 10 customers by month 6 at $2k-$5k MRR each, you are at $20k-$50k ARR after 6 months. By month 12, if retention is 80% and you add 5 more customers, you are at $40k-$100k ARR. This is pre-product-market fit. You are learning, not scaling.

Growth

Your bottleneck is sales, not product. Field service companies do not buy software via product hunt or Slack communities. You need to go to trade shows, sit down with operations managers, and solve their specific problems. This is 12-18 months of slow, customer-by-customer growth.

Challenges

Churn risk: Each customer is a beta tester. If the product breaks on a live job, that customer churns and talks badly about you.
Liability exposure: If something goes wrong (a robot does unexpected damage, an AI agent makes a bad decision), you are liable. Lawyers will be expensive.
Hardware dependencies: You depend on robot APIs and integrations that you don't control. If a robot platform pivots or shuts down, your product breaks.
Vertical depth: Each vertical is different enough that your playbook does not transfer. You will rewrite the product 3-4 times as you move verticals.

Five Questions to Answer First

Who owns the robot on a job site? If the customer owns it, they need support and maintenance, which is not your problem. If you provide it, you are liable for robot downtime. Which model scales? Which model is the customer willing to pay for?
What does liability look like? Talk to a construction attorney and roboticist. What insurance does a customer need? What waivers do you need? At what scale does the liability become uninsurable?
Can robots really do 20% of field work, or is it 5%? If it's 5%, you are selling an AI dispatcher with a camera, not an operating system for three types of workers. The market size is 1/4th as large. Validate this before committing.
Do existing customers want this, or do they want cheaper labor? Many field service operators are trying to reduce headcount. They do not want a system that helps them deploy humans, AI, and robots in concert. They want automation to eliminate humans. Is that actually your market, or are you chasing a phantom?
Who is your unfair advantage? If the answer is "I understand construction," that is not enough. Servicetitan founders understand construction. What do YOU know that they don't? If it is robotics, do you have partnerships or IP that prevent them from building this? If not, this is a features race you will lose.

Thesis

This is a real, valuable problem. The opportunity is not in the software layer (dispatching robots is easy). The opportunity is in understanding how humans, AI agents, and robots should coordinate, and building that knowledge into a vertical-specific operating system. The winner will be someone with deep domain expertise in one vertical and the patience to spend 3-5 years building before growth accelerates. It is a team play, not a solo founder's story. And it requires partners (robot makers, construction companies, lawyers) before you write the first line of code.