Everybody Demos the Robot. Nobody Demos the Update.

This week, two engineers who spent years building commercial robots for a living started a company. They had their pick of problems. Manipulation, navigation, perception, foundation models, all of it wide open and all of it fundable.

They picked: how does the software get onto the machine.

Jack Morrison and Davis Foster came out of Scythe Robotics, which builds autonomous commercial mowers. Their new company is Agency Tool Company, and the first product, ATC Deploy, does one thing. It pushes updates to fleets of machines in the field. That's it. That's the company.

Morrison described the problem this way:

"You've got to manage a whole host of scripts to copy the software onto the machine... scale that out to tens, hundreds, or thousands of machines, and it becomes a problem."

I read that and felt personally addressed.

The number is ten, not a thousand

I put edge AI monitoring into small commercial buildings. There's a sump pump in a Watertown basement that's been running 24/7 for two years. There are about forty devices in a building in Northampton. Air handlers, compressors, walk-in coolers.

The Watertown pump has an update process, and the update process is me. I get in the truck. If something goes sideways, I'm standing in front of the box with a laptop and a USB cable. It's not elegant, but it works, and for one device in one basement forty minutes away, it is genuinely the right answer.

Forty devices is a different universe.

Forty devices means the fifteen-minute job is now a ten-hour job, except it isn't ten hours, because they don't fail identically. Thirty-six take the update. Two are offline because the tenant unplugged something. One takes it and comes back wrong. One takes it, comes back fine, and then behaves differently in a way nobody notices for six days.

Now do that four times a year while running a business.

The thing people get wrong about fleet operations is the scale where it breaks. You read "thousands of machines" and think this is a problem for someone with a warehouse full of robots. Morrison put the pain threshold at tens, and from where I sit that's exactly right. The wall isn't at 500 devices. It's at about 10, and it arrives quietly, because the tenth device doesn't feel different from the ninth. It just means the day you spend updating is now the whole day.

The three failure modes, in a basement

What makes the Agency pitch credible is that the failure modes Morrison names are the ones you only know if you've been in the field.

1. The connection is bad, and that's the normal condition

Field robots run on LTE, 3G, satellite. Morrison lists them like weather.

My equipment lives in basements and mechanical rooms. Concrete, steel, and a mechanical room is where the WiFi access point isn't. Two bars is a good day. An update process that assumes a healthy link will fail at 80 percent, retry from zero, fail at 80 percent again, and eat the month's cellular data doing it.

The fix is unglamorous and well understood: resumable transfers, delta updates so you ship the change instead of the whole image, content-addressed artifacts so an interrupted download can pick up instead of restart. Field robotics figured this out because it had to. It applies identically to a $200 box on a shelf next to a pump.

2. The machine powers down in the middle

Morrison notes robots power down unexpectedly. In a commercial building this isn't an edge case, it's Tuesday. A monitor is on the same circuit as equipment that trips breakers. That's not a design flaw; that's the point of putting it there.

So the real question about any update system is: what happens if power is lost exactly halfway through the write?

There's a correct answer, and it's forty years old. Two partitions. The device runs from A while B is written and verified. It only switches after the new image checks out, and if the new version doesn't come up healthy, it falls back to A on its own. The device that loses power mid-update boots the old version and calls home. Nobody drives anywhere.

This is old, boring, embedded-industry practice. It exists precisely because the field is hostile. What's striking is how much modern edge AI gear ships without it, because it was designed by people who deploy to servers, where a bad update is a rollback command and not a two-hour drive.

3. The scripts

Every shop doing this has a folder of scripts. Copy the binary, restart the service, check it came up, log something. They work. They were written for six devices and they are load-bearing for forty.

The Agency approach I find persuasive is that ATC Deploy is built to work with the operating system, Docker images, and file layout you already have, rather than demanding you rebuild around a platform. Morrison: "We do 98% of the work, and just that last little step that fits into their workflow is on them." That's the correct shape for infrastructure. Most tooling in this space fails by requiring a religious conversion first.

Their launch partners tell you the market plainly: Burro (agricultural robots), Gather AI (warehouse inventory drones), and Tempo (grinding machines). Farm equipment, flying inventory scanners, and industrial grinders have nothing in common except one thing.

The layer that's on nobody's map

Here's the part I find telling about the timing.

The same week Agency launched, The Robot Report published a map of the physical AI infrastructure stack. Five control points: NVIDIA for accelerated compute and simulation, Applied Intuition for validation, Scale AI for training data at industrial volume, Hugging Face LeRobot for open models and standard data formats, Lightwheel for closing the loop from real deployment back into simulation.

It's a good piece and I don't think it's wrong. But read it as an operator and something is missing. Every layer on that map is about producing intelligence. Not one of them is about delivering it to a machine sitting in a basement in Massachusetts on a bad cell connection.

The map ends where my week starts.

That gap is the most reliable pattern in this industry. The demo is the robot folding the shirt. The business is version 1.4 reaching 40 devices without bricking one, on a Thursday, while it's raining.

Why this is also a security question

There was a second story this week, and it looks unrelated until you hold it next to the first one.

On July 16, Hugging Face detected and disclosed a breach. Their own account: someone got in through the data-processing pipeline, using a remote-code dataset loader plus a template injection in a dataset configuration, escalated to node-level access, and moved laterally across internal clusters. Internal datasets and service credentials were accessed.

The detail that got the attention: Hugging Face describes the campaign as run by an autonomous agent framework, performing many thousands of individual actions. They are explicit that the model behind it is not known. A number of outlets have named a specific lab's models as the culprit. That attribution is not in Hugging Face's disclosure, so I'm not going to repeat it, and I'd be skeptical of anyone who does.

The confirmed version is enough. An agentic system, running unattended at machine speed, chained a dataset-loader bug into cluster credentials at a company with a real security team.

Now, the good news, and it's genuinely good: Hugging Face found no evidence of tampering with public models, user-facing datasets, or Spaces, and verified their software supply chain, container images and published packages, as clean. Nothing downstream was poisoned. Their guidance to users was to rotate access tokens.

So why does a monitoring guy care?

Because if your device pulls a model or a container from a public registry, that registry is part of your building. The update path is not just an operations problem, it's the pipe through which outside code reaches equipment inside someone's basement. Agency Tool Company and the Hugging Face incident are the same story told from two ends: one about getting software onto machines reliably, one about what happens when the place software comes from has a bad week.

The practical version, and I did this myself this week:

• Pin artifacts by digest, not by tag. A tag can be moved. A digest can't. If your device asks for latest, you have handed a stranger a decision about what runs in a customer's building.
• Keep a local copy of anything you depend on. If upstream vanishes or gets pulled, you should not be the one finding out at 2am.
• Rotate your tokens. Hugging Face's own advice. Fifteen minutes. Do it even if you only ever pulled public models.
• Know the list. If you can't say in one minute what external code your fleet pulls and from where, that's the actual finding.

The fair counter-argument

I want to state the other side honestly, because there's a version of this where I'm overcomplicating a simple product.

A pump monitor watches five numbers for drift. Run time per cycle, cycles per hour, current draw, vibration, temperature. That job does not change. You could reasonably decide the right update cadence is almost never, ship a sealed box, and note that a device which never changes cannot be broken by a change. That's cheaper, it's simpler, and it's a defensible engineering position. Plenty of good industrial equipment works exactly this way.

It holds until the first time you need it not to.

A security patch. A sensor recalibration after you learn something about how that model of transducer drifts in year two. And the big one: the alarm-tuning fix. A monitor that cries wolf twice gets muted forever, and the tuning that stops it is something you only learn from months of watching that specific machine. If you can't ship that improvement to the devices already in the field, you're stuck selling the version of your product you understood the least, which was the version you shipped first.

"We don't update" is a real strategy right up to the day you have to.

The question to ask your vendor

If you're getting quotes for building monitoring or predictive maintenance, here's a question that isn't on anybody's checklist, and that's exactly why it works.

"How does a device get new software, and what happens if it loses power halfway through?"

You'll learn more from thirty seconds of the answer than from an hour of spec sheets. What you're listening for:

Then a follow-up: where does the software come from? If part of the answer is a public model registry, ask whether it's pinned to an exact version and whether they keep their own copy. After this month that's a fair question, and a vendor who's thought about it will be glad you asked.

None of this is on a spec sheet. It doesn't demo well. Nobody has ever closed a deal on rollback behavior.

But two people who build commercial robots for a living just bet a company on it being the hard part. They spent years watching software reach machines in fields and warehouses, and they concluded that the delivery is the problem worth solving.

They're right, and it's just as true forty minutes from here, in a basement, on two bars of signal, next to a pump that doesn't stop running because you'd like to push an update.

Sources: Agency Tool Company launch, founders Jack Morrison and Davis Foster formerly of Scythe Robotics, ATC Deploy's design to work with existing operating systems, Docker OCI images and file structures, the planned ATC Build product for cloud access to embedded compute, launch partners Burro, Gather AI and Tempo, and both Morrison quotes, via The Robot Report, “Agency Tool Company wants to make OTA software updates easier” (July 28, 2026). The five physical AI infrastructure platforms — NVIDIA, Applied Intuition, Scale AI, Hugging Face LeRobot and Lightwheel — via The Robot Report, “5 Physical AI Infrastructure Platforms Shaping Robotics in 2026” (July 30, 2026). Hugging Face security incident detected and disclosed July 16, 2026, including the remote-code dataset loader and dataset-configuration template injection, node-level escalation and lateral movement across internal clusters, access to a limited set of internal datasets and service credentials, the description of the campaign as run by an autonomous agent framework with the model still unknown, the finding of no evidence of tampering with public models, user-facing datasets or Spaces, verification of container images and published packages as clean, and the guidance to rotate access tokens, via the official Hugging Face security disclosure and corroborating coverage in The Hacker News (July 20, 2026). Third-party attribution of the agent framework to any specific lab's models does not appear in the Hugging Face disclosure and is not asserted here. Small commercial HVAC predictive maintenance pricing of $125 to $208 per month via Oxmaint 2026 benchmarks. Field deployments at The Intersecto Watertown sump-pump site and Northampton 40-device building.