My Monitor Has Exactly One Person Who Can Correct It

A robotics company called Reimagine Robotics came out of stealth on Monday. It was founded by Jonathan Scholz, who started Google DeepMind's Applied Robotics team in London and ran it for seven years, along with three of his former colleagues from that group. London and Sydney, pre-seed money, no robot of their own.

What they're selling isn't a model or a machine. It's a way for the person doing the work to correct the robot while standing next to it.

"A useful robot should be able to learn from the person doing the work. They should be able to show it a task, put it right when it makes a mistake and move on to the next problem. That is what it means for a robot to learn on the job."

I read that on Monday morning, thought it sounded reasonable, and moved on. Then I got to the part of the announcement that describes an actual deployment, and it stopped me.

The Customer Did the Next Three Jobs

Reimagine put robots into a made-to-order plastics business to tend 3D printers overnight. Pulling print beds out, working latches, pressing controls. Unglamorous, real, exactly the kind of work that never gets automated because paying a robotics integrator to program it costs more than the labor it replaces.

Then this: the customer's own team used the platform to automate three more stages themselves. Washing, curing, drying. Nobody from the vendor came back out.

I have been reading physical AI announcements every week for a long stretch now, and I cannot remember the last time I saw that. The standard story is a pilot, a case study, a quote from a VP, and then silence, because expanding the deployment requires the vendor again, and the vendor is expensive and busy. Here the expansion happened without them, because the interface for teaching the robot was pointed at the floor instead of at the front office.

That sent me to look at my own systems, and what I found isn't flattering.

One Person

I monitor a sump pump and a forty-device building. Both systems fire alerts. Both systems occasionally fire alerts that turn out to be nothing.

There is exactly one person on earth who can correct either of them, and it's me.

When the building throws an alert at six in the morning, the path by which "that alert was wrong" becomes an actual change in the system runs entirely through my inbox and my evening. There is no other path. There is no form, no button, no reply-to that does anything.

And here's the part that makes it worse rather than just inconvenient: I am not the person who knows.

The building has a maintenance guy. He walks past that equipment every day. When my system says a unit is short-cycling, he is the one who goes and looks at it, and he is the only human being in the loop who can say whether the thing I flagged was real. He tells me sometimes. In a text. Which I read on my phone, think "good, that one was right," and then do nothing structural with, because there is nowhere for it to go.

I want to be clear that this isn't a scaling worry I'm flagging for later. It's wrong right now, at two sites. It's the kind of thing you don't see because the workaround — a guy texting you — works well enough to keep you from noticing that nothing is accumulating.

The Correction Budget Is Smaller Than I Assumed

The reason I'd been letting this slide is that I had a number in my head about what it costs to make a system learn from feedback, and the number was large. Thousands of labeled examples. A training pipeline. Time I don't have.

Google DeepMind published something last week that resets that estimate.

Gemini Robotics 2 got most of the coverage for its flashy half — whole-body control of a humanoid, legs and torso and arms and fingers under one policy, running Apptronik's Apollo 2 with its 22-degree-of-freedom hand doing knot-tying and ziplock bags. Genuinely impressive, and irrelevant to me, because nothing in my buildings walks.

The variant I care about is Gemini Robotics On-Device 2. It runs entirely locally, with no internet connection. And it fits a completely new robot body — different shape, different sensors — from fewer than 200 examples and a few hours of training.

Fewer than two hundred.

My two sites will produce two hundred alerts and dispositions in a couple of months just by existing. Not as a data collection project. As a side effect of the system doing its job and a guy walking over to look. That's not a corpus I have to go buy or build. It's a corpus I am currently throwing away, one text message at a time.

Nobody Added a Sensor This Week

There's a third story from the same week, and it's the one that convinced me the bottleneck was never where I thought it was.

Renesas published a belt monitoring result: detecting tears and structural damage in motor-driven belts before they fail, continuously, instead of on an inspection schedule. Ninety-eight percent cross-validation accuracy, holding up across both cold starts and thermal steady state, which is where a lot of vibration work quietly falls apart.

They did it with no sensor on the belt at all. No accelerometer, no microphone, nothing added. It reads inverter voltage and current feedback — signals the motor controller already produces — and infers the belt's condition from them.

The model is 9 KB of RAM and 4.8 KB of ROM. It runs on a motor control microcontroller.

I have a personal stake in that result, because it's the architecture my sump pump monitor already uses. There is no sensor on my pump. There's a smart plug between the pump and the wall, and the system watches how much current the motor pulls and for how long. Running, not running, running too long, cycling too often — all of it inferred from the draw. I built it that way because it was cheap and I didn't want to touch the pump. Renesas just published the accuracy number that says it's the right way to build it on much harder problems than mine.

Now line the three up:

• Reimagine removed the programmer.
• Gemini On-Device 2 removed the cloud, and dropped the data cost to under 200 examples.
• Renesas removed the sensor.

Three announcements in one week, and not one of them made a machine smarter by adding hardware to it. Every one made the loop shorter and moved it closer to the person standing next to the equipment.

What I'm Building This Week

1. Two buttons on every alert

Every alert my system sends gets replies the recipient can use without logging into anything. Real. Not real. And a third, because it's the most common honest answer in a mechanical room: real, already fixed.

SMS reply or a one-tap link. No app, no account, no password. A maintenance tech is not going to create a login to help me improve my software, and asking him to is how you find out that nobody ever uses the feature you built.

2. One table behind it

Timestamp, site, device, alert type, the sensor values at the moment it fired, the disposition, who dispositioned it, and a free-text note. That's the entire schema. There is no version two of this design.

I am deliberately not building any tuning on top of it yet. The mistake would be to wait until I know exactly how I'll use the data before I start collecting it, because every week I spend designing that is a week of ground truth that continues to exist only in somebody's text history.

3. The tech goes on the account, and I say why

Today I sell to whoever signs the invoice and email alerts to whoever they list. Going forward the on-site maintenance person is a named user of the system, not a recipient of its email. That's the Reimagine lesson translated to a business with no robots in it: point the interface at the floor.

And it makes the pitch concrete in a way that "AI-powered monitoring" never will. Your tech dispositions each alert with one tap. After ninety days you own a labeled record of what actually failed in your building and what didn't — and it's yours, not mine, the same way the parts list for your install is yours.

The Number I Can't Currently Give You

Here's the second-order benefit, and I've come around to thinking it's the bigger one.

The most reasonable question a skeptical facilities manager can ask me is: how often is it wrong?

Right now I cannot answer that. Not because the answer is bad — I don't think it is — but because I have never had a mechanism that would let me know. I have impressions. I have a text message history. I do not have a false positive rate, and anything I said about it would be a guess dressed up as a number.

Ninety days of one-tap dispositions and I have the real figure. I would bet almost nobody selling monitoring at a hundred and fifty a month can produce theirs either, for exactly the same reason: the correction loop terminates in a founder's inbox, and inboxes don't compute rates.

An alert nobody can correct is a notification. An alert somebody can correct is the beginning of a system that gets better every time it's wrong. The gap between those two is one reply-to address and a table, and I've been sitting on the wrong side of it for a year and a half.