ctopus

The problem

Hardware doesn't ship agent-callable APIs.

?

→

an agent surface that doesn't exist yet

Every appliance, lab instrument, robot arm, sensor rig, smart-home device — anything with a microcontroller — should be agent-controllable. Drivers and SDKs are written one device at a time, by humans, for one OS. The MCP explosion in software hasn't reached hardware.

The approach

The coding agent is the software.

Prompts are infrastructure.

You don't ship code. You ship an agent that reads markdown specs and writes the code at install time — on whatever hardware happens to be plugged in.

One shell command. ~20 minutes. Every connected peripheral becomes a typed, agent-callable MCP tool.

Team & traction

Open. Live. Available right now.

Live demo

octopusprotocol.ai

drive our Pi from your phone, right now

Technical blog

qsimeon.github.io/octopus-hw/blog/

how it works, what we learned, what's next

Honest open work

Where we are. Where this goes.

Today — limitations

Robust over fast. Same install, same hardware, two slightly different generated servers. Stochastic by default — deterministic when it matters.

Speed. ~25-min installs are too slow for casual demos. Caching + warm starts.

Vibe-code bloat → local-first. Built fast, accumulated cruft; simplification + on-device agents next. Pi-class hardware should run a Pi-class agent.

Next — where this goes

Distributed device catalog. Every install learns. Meta-learning across deployments → a shared, sharper spec library.

Self-perception, both faces. Daemon watches its logs; camera watches the arm. Extend both with what we learn.

Robotics + agentic control. Like a virus learning to infect more hardware — closing the gap from VLM to action.

Customer capture. Become for embodied devices what Uber became for rideshare — the easy way in, with the network effect.