The Robot App Store Just Hit 200 Apps. What's the Boiler-Room Version?

This week Hugging Face confirmed what The Robot Report covered on May 7: the Reachy Mini app store now hosts more than 200 apps, built by 150-plus creators, the majority of whom had never written robotics code before. Hardware list price is $299. The authoring loop is plain English in, working code out — the user describes the behavior they want, an agent writes it, tests it, ships it to the robot, and iterates with the user until it runs the way they expected.

This is the most important story in physical AI this week, and it has almost nothing to do with the Reachy Mini specifically. The interesting thing is that the agent-authoring pattern shipped, in production, on physical hardware, at hobby-grade price. Two hundred apps in a few months. The loop works.

The boiler room is next. Nobody has shipped that product yet.

What the Reachy Mini loop actually does

An owner of a Reachy Mini opens an interface, types a sentence like "say hello when someone sits down across from you and follow them with your head if they move," and walks away. The agent generates the behavior tree, wires it to the sensors, runs it in a browser-based simulator first, then ships it to the robot. If the behavior is wrong, the owner says what is wrong and the agent fixes it. The finished app is an open-source repo on the Hugging Face Hub, forkable, one-click installable on any other Reachy Mini in the world.

That last sentence is what matters. The unit of distribution is a working app, not a pull request. The unit of authorship is a description, not a codebase. The unit of governance is a public repo with a license, not a vendor-locked SDK.

For two months we have been writing on this site about the supplier-side shift in physical AI: sensors converging on integrated modules, born-aligned data formats, edge-AI hardware as a commodity wave. The authoring shift is the second half of the same story. The components got cheap; this week the loop that wires them together got cheap too.

Why the boiler room is the right second target

A small commercial building is not a robot, but its operational shape is closer to one than most owners realize. There is a small number of physical assets — a boiler, two air handlers, a sump pump, a water heater, a service entrance — each generating a continuous data stream. There are a small number of behaviors that matter, all of them about catching a deviation early enough to avoid a service call. There is a single owner, usually with no IT department, whose patience for learning Modbus is zero.

Every one of those constraints fits the Reachy Mini authoring pattern almost line for line. The owner does not want to write code. They want to describe a behavior — "tell me if the sump pump runs more than ten times in an hour" — and have it run. The behaviors are short. The hardware to host them is a Mac mini or a Raspberry Pi. The data layer is MQTT. None of that is speculative; the sump pump deployment already runs that exact stack.

What does not exist yet is the authoring loop on top of it. The sump pump runs because we wrote the rule. Nobody has shipped the version where the owner describes the rule and an agent writes it.

The first six apps the boiler-room app store should ship with

If a boiler-room app store launched tomorrow, here are the apps that should be in it on day one. Each one is a behavior that has come up on real Intersecto deployments. Each one is short enough that an agent could plausibly author it from a one-sentence description. Each one is the kind of thing an owner would type into a "describe what you want monitored" box without flinching.

1. Sump pump cycle watchdog. One sentence: "alert me if the sump pump runs more than N times in an hour, or if it runs continuously for more than N minutes." Two thresholds. Two alerts. The sump pump deployment ran 97 recovery cycles in a single rainy night using exactly this rule. An agent should be able to author it from the sentence above, including the input topic, the action library, and a default alert channel.
2. Air-handler short-cycle detector. One sentence: "alert me if any AHU starts and stops more than five times in fifteen minutes." This is the canonical mechanical-failure precursor. It is also the canonical "the data is technically present and operationally useless" example — most BAS systems have this telemetry on a dashboard nobody watches.
3. Boiler temperature drift baseline. One sentence: "watch supply water temperature against the schedule, tell me when the day's average drifts more than 5 degrees from the previous week's average for the same outdoor temperature." This is an app that requires the agent to wire in outdoor temperature as a co-feature and maintain a rolling baseline. It is the "buildings get baselines" idea reduced to a single configurable behavior.
4. Water-leak watchdog. One sentence: "if any of these flood sensors goes wet, call this number and shut off the main." This is the highest-stakes version of the pattern because the action library has to include a relay output, not just a notification. Building it once turns it into a one-click install for every other building.
5. Occupancy-versus-energy reconciler. One sentence: "tell me when the building draws more than 30% of its peak energy outside of the hours people are here." This is the small-building version of Microsoft's daily-retrained HVAC scheduling loop. It does not need four parallel ML models and a Redmond campus. It needs an occupancy signal, an energy signal, and a comparator.
6. "Has anyone been in the basement this week?" One sentence, exactly as written. The answer comes from a $4 PIR sensor and a timestamp. The reason this is the sixth app is not because it is the most technically interesting; it is because it is the kind of question owners actually ask out loud, and the existence of an authoring loop where they can ask it that way is the entire point.

Six apps. Each one short. Each one already runnable on the same Mac-mini-class hardware that hosts the sump pump deployment today. The thing that does not exist yet is the layer where the owner authors them in plain English.

What it would take to actually ship this

The component pieces are all already on the bench:

• A local LLM and an agent loop. Both run on the same Mac mini that already runs the inference for the sump pump.
• An action library. The set of things the agent is allowed to do — read an MQTT topic, write a relay output, send a notification, query a baseline — is small enough to enumerate by hand. That is the whole reason this is buildable for boiler rooms and not yet for general-purpose home automation.
• A simulator. Reachy Mini ships one in a browser. The boiler-room version is a five-line MQTT replay of the previous week's data. It does not need to be fancy. It needs to let the owner say "no, that is wrong" before the rule ships to the relay.
• A repo format. Each app is a single file with a description, an input list, an action list, and a body. That is the unit of distribution. The owner forks the sump pump app, changes "ten times" to "five times," ships it. Done.

None of that is research. All of it is engineering, and not very much of it. The barrier to shipping a boiler-room app store has not been technical for at least a year. It has been the absence of a practitioner who runs both a real building deployment and a real agent stack at the same time, and who is willing to publish.

Why this product ships from a small-building practitioner, not a portfolio MSI

The portfolio Master Systems Integrators have the relationships and the budgets, but they will not ship this. The reason is structural. The MSI's customer is a portfolio owner with thousands of OT devices, who buys six-figure annual contracts, who values customization over fork-ability. The MSI's product is the inverse of an app store: bespoke per-customer, not standardized, not public.

The small-building practitioner has the opposite shape. The customer is one owner, the contract is in the low four figures a month, the value is in the standardization. A $199-a-month service that ships with six pre-installed apps and the option to author more is a different product than a $250,000 MSI contract. It can only come from somebody whose customer accepts a standard product because customization is unaffordable.

That is why the Reachy Mini app store opened with hobbyists and not with industrial robotics vendors. The shape of the customer determines the shape of the product. The same logic predicts that the boiler-room version, when it ships, will ship from a small-building practitioner, not from Honeywell or Johnson Controls.

The architectural shift that connects this to last week's posts

This is the third post in a sequence, and the three posts make one argument together. The cloud-latency post on May 4 established that physical AI must be edge-first. The construction-loophole post on May 7 established that the operator-side language for connected buildings just got named. This post says that the authoring loop on top of the edge-first stack just shipped on physical hardware, in public, at $299.

Stacked: the building-monitoring practitioner now has an edge-first architecture that is industry-standard, an operator-side vocabulary that is portfolio-grade, and a working precedent for the agent-authoring loop that owns the customer's experience. All three landed in one week. None of them was true the week before.

What I'm watching

Three signals that will tell whether the boiler-room app store is a real product or a thought experiment:

1. Whether anybody publishes a boiler-room "app" in the Reachy Mini format inside the next month. A single repo, with a one-sentence description, a default input topic, an action list, and a runnable file, would be the first concrete artifact. As of this week, no such artifact exists. By next Friday, the first one will exist on this site.
2. Whether the Reachy Mini ecosystem produces an industrial fork. The agent loop and the action library generalize. Somebody — possibly Hugging Face, more likely a third party — will ship a "Reachy Mini for buildings" SDK by the end of the year. The shape that lands first will determine whose vocabulary the small-building market adopts.
3. Whether commercial-property insurance carriers start rewarding "monitored to a published standard." The construction-loophole post argued that insurance is the trailing-edge forcing function. An app-store standard makes "monitored to a published behavior" auditable in a way that bespoke MSI contracts are not. That is the kind of detail that turns a practitioner-built standard into a market-wide one.

The bottom line

The Reachy Mini app store crossing 200 apps from 150+ creators is not interesting because of the robot. It is interesting because the agent-authoring loop shipped on physical hardware, in public, at hobby price, with a forkable repo as the unit of distribution.

The same loop is buildable today for the small commercial building. The components are all already on the bench, in the same lab, often on the same Mac mini that hosts the existing sump pump deployment. The first six apps are short enough to enumerate, concrete enough to ship, and already implicit in the kinds of behaviors real owners ask for out loud.

The window to be the practitioner who publishes the first boiler-room "app" in this format is open right now. Next Friday's post on this site will introduce the first one. The proposal language for the service that hosts the rest of them should change this quarter.

Read the case studies and related posts: How edge AI prevented a basement flood | 42% off energy costs on a community center | Closing the construction loophole on a small building | Why physical AI requires edge-first architectures