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 the same sense of time. The fleet brings reach, endurance, and its own real autonomy in the field. The people bring accountability and the wider judgement that decides what the fleet should be doing in the first place, and when a situation has moved beyond what it should handle alone. Seen one way, the product is the interface between these 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. The design work picks up on 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 there 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. The interface, though, had been built to verify that the technology worked, not to let the machines and the people actually work together. It proved the fleet to its makers. It did not yet help an operator direct it, read it, or know when to trust it.
A few things surfaced together. The map of the environment was necessary but not enough on its own: 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 absent from the interface, even though the system itself reasoned in probabilities. And one observation reframed the whole 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 not in a line. They loop: plan a mission, preview it, watch it run, review what happened, and feed what they learn back into the next plan. Discovery turned all of this into a shared structure: what views should exist, how they connected around that loop, the user archetypes they served, and the permissions that governed who could 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 versus what it only predicts.
Observed, predicted, and inferred
A robot that has lost signal is not where the map last drew it. A plan that has been approved is not the same as a plan that has run. A confidence reading is not a fact. If the interface blurs these together, the operator either trusts too much and misses a problem, or trusts too little and intervenes in work that was fine. Both failures are costly, and in some environments dangerous.
So the design gave the operator a consistent way to read time and certainty at a glance. Observed behaviour and predicted behaviour took different visual forms that held everywhere they appeared: on the map, in the fleet panel, on the timeline, in the moment a robot dropped offline and prediction 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 learned the language once and read it the same way everywhere. It is how the fleet makes itself understood to the people running it.
How the fleet reports up
Understanding is not enough. A relationship that can stretch 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 in the space between full confidence and intervention. The system had to distinguish, at a glance, between three states: nominal, where nothing is needed and the absence of alarm can itself be trusted; worth attention, a pattern or event the operator might want to look at; and act now, the rare moment a person is genuinely required. It had to make these distinctions at two levels, the single event, this robot at this moment, and the pattern, something accumulating across the fleet or the window, because a view that only flags discrete events misses the slow drift, and one that only shows aggregate health misses the sharp single failure.
Nominal, worth attention, and act now
The fleet handles most alone; human involvement rises only as the situation demands it.
The hard part is calibration. A signal that fires too easily trains the operator to ignore it. One that fires too rarely is not trusted to fire at all. The interface earns its standing not by showing everything, but 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 does turn 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 did not mean taking the wheel. The permissions model, drawn in discovery, governed who could act on what, so authority was a property of role rather than a free for all. Handing control back was treated as carefully as taking it. The aim throughout was that 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
A single legible screen is not the achievement. The language has to survive scale and edge.
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 had to continue on inference rather than fact. 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 with three modes, not three different tools. 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 connective tissue mattered more than any single view. The strongest decisions were the rules that stayed consistent underneath everything: identity in colour and label, certainty in form, authority in role, 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 is not yet something you can measure in the world. It is something earlier and, for work at this stage, more important: 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 stopped being a console for verifying that robots work, and 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 not the thing you design. It is what is left when those three are true.