The operating system for physical work: routing one job across agent, robot and person

21:40, a fault report from a residential block. The entrance area is dirty and there is a viewing first thing tomorrow. Today what happens is this: someone calls, someone writes it down, someone dispatches in the morning, and eventually a van sets off.

With three kinds of worker on one job list, something else happens. An agent takes the report, asks the follow-up questions, qualifies it and opens the job. A cleaning robot already in the building runs the floor overnight. Whatever is left, because a threshold is in the way or a surface needs wet work, goes to a person on the early shift with a photo, a location and a remaining scope.

None of that is a forecast. Each of the three pieces exists on its own and can be bought today. IFR World Robotics 2025 counted almost 200,000 professional service robots sold in 2024, up 9 percent, and a robot-as-a-service fleet growing 31 percent. What is missing is not the machine. It is the job list that runs all three together.

Field service software models a person, a vehicle and a time slot. It dispatches, tracks, manages assets and bills. Y Combinator describes exactly that as the state of the art in its Request for Startups on operating systems for the physical world, and points out that these industries spend ten to a hundred times more on labour than on software.

A machine does not fit that data model, and the mismatches are not cosmetic.

• It has no travel time, it has a charge curve.
• It does not call in sick, it enters a fault state, and the two require completely different responses.
• It works for nothing overnight and gets in the way during the day.
• And it can finish a job 70 percent of the way, which in a staffing plan is an undefined state.

An AI agent breaks the model from the other end. It produces work faster than a human dispatcher can review it, which turns the review step itself into the bottleneck unless the system is built to let some decisions through unreviewed and to record which ones.

The interesting engineering is not in assigning the job. It is in what happens when the assignment turns out to be wrong halfway through.

A job a robot half finishes has to arrive in the world as a usable partial result: what is done, what is not, why not, and what the person finishing it needs to bring. Without that, every machine failure becomes a phone call, and the coordination overhead quietly exceeds the labour saved. We have seen more automation projects die of coordination cost than of technical failure.

So the fallback path gets specified first and the autonomy second. In practice that means writing down, before anything is procured, which exception goes to which person, with what evidence attached, and inside what time window.

The moment people and machines use the same floor, this stops being an operational question and becomes an evidence question.

Driverless industrial trucks and autonomous mobile robots fall under ISO 3691-4, which has been listed in the EU Official Journal as a harmonised standard since May 2024. It is a type C standard, and personnel detection is to be designed to performance level d under ISO 13849. Above it sits Regulation (EU) 2023/1230 on machinery, published on 29 June 2023 and applying from 20 January 2027 in place of Directive 2006/42/EC; machines placed on the market before that date keep grandfathering.

Two standards not to confuse with those: ISO 10218 was revised in 2025 and covers industrial robots, and ISO 13482 covers robots in physical contact with a person. Both are quoted regularly for machines they do not apply to, and a supplier that gets this wrong in a pitch will not get it right in a conformity file.

For an operator the practical consequence is narrower than it sounds. The question of who uses which area when, and how that is documented, gets answered now, at the point of procurement, rather than in 2027.

Fleet interoperability has one credible standard in this space. VDA 5050 defines the interface between a master control system and driverless transport vehicles, and it is the reason a mixed AGV and AMR fleet can be driven from one controller at all.

What it does not do is normalise everything an operator actually needs. Localisation confidence, payload state, subsystem degradation and vendor-specific error codes still live inside proprietary software, and mapping them into one usable alarm model is integration work, per fleet, every time. Anyone who tells you fleet interoperability is a solved problem has not connected two brands.

Robot uptime is the wrong metric. A machine can be 99 percent available and complete nothing, because the door was shut, the lift was busy or the area was blocked. Uptime measures the supplier. It does not measure the operation.

The number that matters is completed jobs per shift, regardless of which kind of worker completed them. There is no industry standard for that, and we do not claim to own one. What can be done is to write down, per site and before the first machine moves, what counts as a completed job, so that afterwards the argument is about the result rather than about the measurement.

Whoever runs physical work produces the record of how that work actually happens. No model vendor and no robot manufacturer has that record. It is the reason operators are structurally better placed in this shift than it first looks.

That is not unconditional. As soon as wearables, cameras or location tracking touch employees, German law makes it a codetermination matter: section 87(1)(6) of the Works Constitution Act covers technical systems that are capable of monitoring behaviour or performance, and capability is enough, intent is not required. The GDPR applies regardless. Bringing the works council in after the pilot means running the pilot twice, and that is the most common avoidable failure in this category.

Nothing above requires a platform decision. It requires one clean task.

• Pick a single recurring job with a defined route and a defined time window.
• Write the fallback path before the procurement, not after it.
• Define the completed job in writing, per site.
• Settle the standards question at specification time, not at delivery.
• Talk to the works council before the pilot, not after.

That is the sequence werob runs as an integrator: a specification from a plain-language description, hardware selected across more than 44 manufacturers, connection to the systems already in use, and a cockpit that makes the deployment visible. It is worth being precise about what that is not. werob does not sell an autonomous dispatcher, and there is no product in this market that routes work across agents, robots and people without an operator in the loop. The mixed workforce page sets out the argument in full, and the werob console shows the cockpit as a public demo.