Designing the interface between two workforces

Stateful Robotics builds decision intelligence for autonomous robot fleets: software that turns operational requirements into resilient robot behaviour over missions lasting anywhere from minutes to weeks. The robots inspect, sample, and act on the world around them, often in environments people cannot easily enter. They plan and move on their own.

That capability is one half of a partnership. The machines and the people who run them are different kinds of worker, and they have to work together without sharing a language, a vantage point, or a sense of time. The fleet brings reach, endurance, and real autonomy in the field. The people bring accountability, and the wider judgement that decides what the fleet should be doing and when a situation has moved beyond what it should handle alone. Seen this way, the product is the interface between two workforces: the place where work, information, and authority pass between them.

Stateful’s own framing centres the machine side, making the fleet capable and dependable. My work took up the human side: how a person directs a fleet they do not drive, reads behaviour they did not witness, and decides, moment to moment, whether to leave it running or step in.

What discovery found

The work began before any design, with a discovery engagement: a workshop with the full team, then the synthesis and architecture that turned what surfaced into something the company could build on.

The diagnosis was clear, and the team recognised it once it was named. Stateful had built genuinely sophisticated technology, and an interface designed to prove that it worked. It proved the fleet to its makers. What it could not yet do was help an operator direct the fleet, read it, or know when to trust it.

Several things surfaced together. The map of the environment was necessary and insufficient: operators needed spatial context they recognised before they could make sense of what a robot was doing. The system’s real differentiator, its ability to explain why a robot behaved as it did, existed only as verbose text almost no one could parse. Uncertainty was missing from the interface, although the system itself reasoned in probabilities. And one observation reframed the problem. When a robot could not be reached, knowing where it was became almost indistinguishable from predicting where it would go. Observation and prediction collapsed into the same uncertain act.

The architecture also had to fit how operators actually work, which is in a loop. They plan a mission, preview it, watch it run, review what happened, and carry what they learn into the next plan. Discovery turned all of this into a shared structure: which views should exist, how they connect around that loop, the user archetypes they serve, and the permissions that govern who can do what. Underneath it ran one demand. For the two sides to work together, each has to be able to understand the other.

What each side had to understand of the other

A person directing the fleet depends on one distinction above all: what the system has observed, and what it only predicts or infers.

A robot that has lost signal is somewhere the map can only estimate. An approved plan is an intention until it has run. A confidence reading is a probability. When the interface blurs these, the operator either trusts too much and misses a problem, or trusts too little and steps into work that was going fine. Both failures are costly, and in some environments dangerous.

So the design gave the operator one consistent way to read time and certainty at a glance. Observed, predicted, and inferred behaviour took different visual forms that held everywhere they appeared: on the map, in the fleet panel, on the timeline, and in the moment a robot dropped offline and inference quietly took over from observation. Certainty was carried by form, identity by colour and label together, and nothing critical rested on colour alone. The operator learns the language once and reads it the same way everywhere. It is how the fleet makes itself understood.

How the fleet reports up

A relationship that stretches across long missions cannot depend on a person watching continuously. The fleet has to report up, and the reporting has to be calibrated.

Most of the design lived between full confidence and intervention. The system had to separate three states at a glance. Nominal means nothing is needed, and the absence of alarm can itself be trusted. Worth attention is a pattern or an event the operator might want to look at. Act now is the rare moment a person is genuinely required. It had to draw these distinctions at two levels: the single event, this robot at this moment, and the pattern accumulating across the fleet or the mission. A view that only flags events misses the slow drift, and one that only shows overall health misses the sharp single failure.

The hard part is calibration. A signal that fires too easily trains the operator to ignore it. One that fires too rarely is never trusted to fire at all. The interface earns its standing by being right about what deserves notice. That is the difference between a fleet a person babysits and one they can leave to work.

How authority passes

When attention turns to action, authority has to pass cleanly between the two sides.

Intervention was reserved for the few moments a person was genuinely needed, and shaped so that stepping in meant directing the fleet without taking the wheel. The permissions model drawn in discovery governed who could act on what, so authority was a property of role. Handing control back was treated as carefully as taking it. Throughout, the people held authority over the fleet without having to drive it: present at the decisions that mattered, absent from the ones that did not.

What had to hold

The language had to survive scale and edge cases. The patterns had to hold at a small validated deployment and at a larger one with several times the assets, areas, and robots. They had to hold when a robot disconnected and the relationship continued on inference. They had to hold across planning, live supervision, and retrospective review, so that an operator moving between predicted, live, and historical views was reading one tool in three modes. And they had to hold across the full span of the work, from a task of a few minutes to a mission that unfolds over weeks.

The rules underneath mattered more than any single view: identity in colour and label, certainty in form, authority in role, and intervention kept for the few moments it was genuinely needed.

What changed

This was a design and discovery engagement, and the build is still ahead. What changed came earlier than anything measurable in the field, and at this stage it matters more: the team gained a shared, explicit account of a system that had lived implicitly.

What had been carried in the heads of the people who understood it, and in logs only the engineers could read, became an inspectable reference the whole team could work from and argue with: the interface, the flows, the permissions model, the user archetypes, and the questions left open for future scale. Decisions that had been carried unframed were named, and naming them settled them. The design and its documentation became one artefact.

The deeper shift was in how the product understood itself. It had been a console for verifying that robots work. It became the interface between two workforces: the place where a capable fleet and the people accountable for it meet, divide the labour, and keep each other informed. That is the foundation the build will stand on.

What it taught

The interface between two workforces holds when each side can understand the other, when the fleet reports up honestly enough to be left alone, and when authority passes cleanly at the few moments it must. Trust is what remains when those three are true.