I think there is a strange problem coming for AI desktop robots.
The hardware is getting more interesting.
The AI is getting better.
People are building new behaviors, new applications, new voices, new integrations and completely new ways to use these little machines.
But there is a much simpler question:
How do I find any of that stuff?
That sounds like a small product problem.
I don't think it is.
A robot can become dramatically more capable after you buy it, but those improvements are almost useless to an ordinary owner if discovering them requires searching GitHub, reading Discord messages, following developers on social media, or figuring out which random project still works with the latest firmware.
This is where I think AI desktop robots may eventually need something that looks a lot like an app store.
Not necessarily Apple's App Store.
Not necessarily a closed marketplace.
But some kind of place where a person can look at their robot and ask:
"Okay. What else can this thing do?"
The smartphone solved this problem a long time ago
Think about what happens after you buy a phone.
The hardware doesn't suddenly become ten times more interesting because the manufacturer shipped ten times more hardware.
The ecosystem does the work.
You open the app store.
You discover something.
You install it.
Now your phone can do something it couldn't do yesterday.
That sounds obvious because smartphones have trained us to think this way.
The hardware is the base.
The software is what keeps expanding the reasons to use it.
Desktop robots are in a much earlier stage.
Most of them still feel like products rather than platforms.
You buy the robot.
You use the features the manufacturer gives you.
Maybe an update arrives.
Maybe there is a new game.
Maybe the company adds a new AI feature.
And then you wait.
That is a very different relationship from:
"There are 60 things I can install on this robot, and people are adding more every week."
The second experience has much more room to grow.
Reachy Mini is already showing what this could look like
The interesting thing is that this isn't just theoretical anymore.
Reachy Mini now has a community application ecosystem built around Hugging Face Spaces. Pollen's current application page lists dozens of official and community apps, including telepresence, meal planning, music games, face tracking, voice applications, office assistants, photo booths and other experiments.
Hugging Face has also described a larger Reachy Mini app store with more than 200 community apps and more than 150 creators in its May 2026 update.
That's a meaningful shift.
The robot itself hasn't changed into a completely different machine.
But the number of things people can do with it keeps expanding.
And importantly, the manufacturer doesn't have to personally build every experience.
Someone else can.
That's the part I find interesting.
The app store isn't really about apps
This is where I think the terminology can become misleading.
A robot doesn't necessarily need dozens of little smartphone-style apps.
It needs a way to discover:
new things the robot can do.
That could be an app.
It could be a skill.
It could be a new behavior.
It could be an AI agent.
It could be a game.
It could be a voice experience.
It could be an integration with another service.
The important part is not the package format.
It's discoverability.
Imagine buying a robot and six months later seeing:
New this week:
A robot that plays Simon Says.
A robot that helps you cook.
A robot that becomes a telepresence camera.
A robot that plays music games.
A robot that reacts when someone enters the room.
Now the robot feels like something that is changing.
Without that layer, all those projects can exist and the ordinary owner may never know they exist.
That's the difference between:
software exists
and:
software reaches users.
MicroDuck is taking a different route
This is where MicroDuck gets interesting.
MicroDuck isn't currently built around an app-store model.
Its open-source approach is much closer to:
Here is the robot.
Here is the SDK.
Here is the simulator.
Here is the training stack.
Here are the policies.
Go build something.
Pollen explicitly positions the software stack around training and sharing behaviors, and its current site points users toward community policies and Discord.
I like this approach for experimentation.
It's much closer to how an open robotics platform should work.
But there is still a gap.
A developer sees:
SDK → simulation → policy → repository → deployment
A normal owner sees:
"I bought a duck. What can I install?"
Those are completely different experiences.
And I think the industry will eventually have to solve that gap.
Open source does not automatically mean discoverable
This is one of the things I've become more convinced about while looking at these robots.
Open source is useful because people can build things.
But that doesn't mean ordinary users can find those things.
Imagine that someone builds an incredible new MicroDuck behavior.
It works.
It's published.
Another person forks it.
A few people try it.
Someone posts a video.
And then the project disappears into a GitHub repository.
Technically, the software exists.
Practically, most owners will never see it.
That's not an open-source problem.
It's a distribution problem.
The same thing happens with Android apps, browser extensions, plugins, games and almost every other software ecosystem.
Once there are enough projects, discovery becomes its own product.
This may actually be more important for robots than phones
There is another reason I think this matters.
A robot's capabilities are much less predictable than a phone app's.
An app can usually operate inside a well-defined screen.
A robot can:
see
hear
move
speak
touch things
react to its environment
use tools
interact with other devices
That means software can change the robot's behavior in much more visible ways.
A small software update could change what the robot does in your room.
That's exciting.
It also makes discovery much more important.
You don't want to hear:
"There is a new behavior on GitHub."
You want to see:
"Your robot can now do this."
And then ideally:
"Try it."
There is a second problem: quality
An open ecosystem creates another challenge.
What happens when there are 500 robot apps?
Finding something is one problem.
Finding something good is another.
This is where a robot ecosystem needs more than a list.
You probably want:
ratings
screenshots
short demos
compatibility information
last updated date
required hardware
supported robot versions
who made it
whether it costs money
whether your data leaves the device
That sounds very familiar because we've already solved this problem with app stores.
The interesting part is that robots may eventually need the same infrastructure.
Not because robots are phones.
Because users have the same problem:
There is too much software. Help me find the thing I actually want.
The manufacturer should not have to build everything
This might be the biggest change.
A good robot company shouldn't necessarily try to create every experience itself.
That's expensive.
It's also limiting.
A small team at a robot company might build ten excellent experiences.
A community of 1,000 people could build hundreds.
Reachy Mini is already demonstrating this direction. Its application ecosystem contains community projects that go far beyond what you'd normally expect from a single manufacturer: games, telepresence, office tools, vision experiments, voice systems and other small ideas that don't necessarily justify becoming official product features.
That's exactly what communities are good at.
Someone has a strange idea.
They try it.
If it works, someone else uses it.
Then someone improves it.
Eventually, something that started as a weekend experiment can become a reason to buy the robot.
That's a much healthier product loop than waiting for the manufacturer to think of everything.
But I don't think every robot needs a closed app store
This is where I'd be careful.
I don't think the conclusion should be:
Every robot company needs to build an Apple-style store.
That would miss the point.
An open model may actually work better for some robots.
MicroDuck is a good example.
A repository-based model makes sense when the audience wants to experiment and share behaviors.
A Hugging Face-style ecosystem makes sense when developers are comfortable publishing models, apps and agents.
A simple consumer marketplace might make more sense for someone who doesn't know what GitHub is.
The important thing is the layer between:
people build things
and
ordinary owners use things.
The exact implementation can vary.
The real winner may be the robot with the easiest discovery
This is something I would watch closely over the next few years.
Imagine two robots.
Robot A technically supports 50 capabilities.
Robot B supports 20.
But Robot B has a place where you can see:
New this week
Most popular
Made by the community
For work
For games
For kids
For your living room
For your robot
And you can install something in one click.
Which robot feels like it is improving faster?
Probably Robot B.
Not because the hardware is better.
Because the software is easier to discover.
That's an important distinction.
A capability you can't find is almost like a capability you don't have.
This changes what I look at when evaluating a robot
I've spent a lot of time looking at robot specifications.
Motors.
Cameras.
Sensors.
Battery.
AI models.
They all matter.
But I think another question is going to become increasingly important:
What happens after I buy it?
Not just:
What can this robot do today?
But:
What could I discover next month?
That's a completely different way of looking at a robot.
And it also changes how I'd evaluate the company behind it.
Does it have a developer community?
Does it make third-party software easy to share?
Can users discover new projects?
Can someone publish something without getting permission?
Are updates visible?
Can owners see what other people are building?
Is there a clear way to know what works with your version?
Those questions may eventually tell you more about the long-term life of a robot than another line on its specification sheet.
I think robots are going to need a "what's new?" screen
Maybe it will be called an app store.
Maybe it will be a community hub.
Maybe it will be an AI assistant that says:
"Three new things were published for your robot this week."
I don't really care what the interface is called.
I care that the robot doesn't become a dead-end product after the excitement of the first week.
Because that's the bigger problem.
The hardware gets you interested.
Software gives you something new to try.
The community creates more possibilities.
And discovery connects all three.
That's how a robot starts to feel less like a gadget you bought and more like a platform that keeps changing.
And I think that's a much more interesting future for AI desktop robots.
