Announcing Gorai! A Modern Robotics Framework

gorai / robotics / go / golang / nats / ai / open-source / emerging-robotics

I’ve been teasing this for a while. Time to stop teasing. Meet Gorai — a modern, open-source robotics framework written in Go.

If you read my Why Go for Robotics? post, or my rant on Agentic Python, you already know where my head’s been at. I kept asking the same question: why not do foundational robotics work in Go? Well, I’ve been building. Gorai is the answer.

This Is Emerging Robotics

Gorai is the foundation of Emerging Robotics: Open-Source Robotics for the Real World. We’re building software - and actual robots and robotics kits - specifically for the AI era. We are designing from the ground up for agentic development, onboard AI agents, and how AI will fundamentally change robotic fleet operations. And it’s all enabled by gorai.

What Is Gorai?

Even a single robot is really a pile of microcontrollers, single-board computers, sensors, and motors all talking to each other. Most frameworks consider that to be one monolithic blob. Gorai doesn’t. It treats every sensor as a resource you read and every actuator as a tool you call — discoverable services on a message mesh, addressed by name, not by hardwired cables.

If “resources and tools” sounds like how AI agents already think about the world — yes. That’s the whole point, and I’ll come back to it in a second. Gorai speaks capability-model semantics natively over NATS.

  • Sensors as resources, actuators as tools — an AI-agent-ready capability mesh
  • Single static binary, embedded NATS, zero external services
  • Composite robots — one logical robot can span a rover, a drone, a sensor mast, all joined at runtime
  • Action logs and replay as first-class primitives, because autonomy without replay is folklore
  • Safety enforced at the capability node, not trusted to the agent

Now, before you start yelling: yes, you can extend beyond the one binary (using NATS, of course!). And yes, you can move real-time/latency critical components onto a microcontroller and join that to the mesh using gorai-gsp to do the serialization. There’s even an example firmware for the RP2040. But that’s a subject for another post!

To be clear about scope: I’m not trying to replace ROS 2. Different tool, different crowd. Gorai is for software-first folks who want to build robots the way we build modern distributed systems — and who want AI to be a first-class citizen, not a bolt-on.

Designed for the AI Era

I want to be dead clear about this, because it’s the entire reason Gorai exists: this is not a robotics framework that happens to tolerate AI. It’s a robotics framework designed because of AI. The bet is simple — the robots worth building from here on out are going to be driven, at least in part, by agents. So we designed for that on day one, not as a bolt-on you duct-tape onto the side later.

The whole thing rests on two principles.

1. A robot is a distributed system — so build it like one.

Most frameworks treat a robot as one monolithic blob of code. It isn’t. It’s a pile of microcontrollers, single-board computers, sensors, and motors all talking to each other, and pretending otherwise is where the pain starts. Gorai treats every piece as an independent service on a message mesh, addressed by name over NATS — not by hardwired cables. Add a node, drop a node, span three chassis at runtime; the mesh doesn’t care. And here’s why that matters for AI: it’s the architecture that lets a planning agent or a fleet coordinator reach in and address any capability, on any robot, without knowing a thing about how it’s wired.

2. Sensors are resources, actuators are tools.

Read that again. If you’ve spent any time around LLMs, it should sound awfully familiar — resources and tools are exactly how AI agents already model the world. That’s not a happy accident. It’s the point. Gorai speaks that capability-model language natively, so the same interface a human uses to drive the robot today is the interface an agent uses to drive it tomorrow. No translation layer. No rewrite. No firmware surgery. Same mesh. And yes, sometimes that mesh will be in a very tight real-time loop.

Put those two together and you’ve got the thesis in one line: robotics for the AI era. Not “AI-compatible.” Not “AI-ready.” Built, from the mesh up, for a world where the thing holding the controls -or even part of the controls - might not be a human.

See It Drive: the PiCar-X Example

Talk is cheap. So there’s a working reference robot you can build today: gorai-gopicar-example.

The PiCar-X is a little four-wheeled robot car kit from SunFounder — steering servo, drive motor, an ultrasonic distance sensor, a line/cliff sensor, and a camera on a pan/tilt mount. It’s a genuinely great little “better than a plastic toy” robot, and the best part is you can just buy one: it’s about $90 on Amazon — minus the Raspberry Pi, which you supply yourself. No custom PCBs, no soldering iron, no waiting on a fab. Order it, assemble it with a Pi, and you’ve got real hardware to run Gorai on.

Take a SunFounder PiCar-X, cross-compile the binary, scp it over, and run:

./picarx run robot.json

One command spins up the robot. It serves a web control UI at http://<pi>:8080/. Drive it with the arrow keys. Pan and tilt the camera. Watch live telemetry and video stream back. Hit spacebar to stop the motors, and ’s’ for an emergency stop.

Here’s the beautiful part: the browser is just another agent on the mesh. The exact same interface a planning agent or a fleet coordinator would use. The car is teleoperable today and agent-drivable tomorrow — with zero changes to the capability layer. That’s not “it’s on the roadmap” - that’s running code. Today.

And it’s safe by construction: a watchdog stops the car within about half a second if control input drops, the e-stop latches until you clear it, cliff detection keeps it off the edge of your desk, and every command gets clamped to the servo and throttle limits. All of that lives in the component, not the UI — because you never trust the thing sending commands.

But wait - what about using Claude Code?

Of course. Why not develop directly on the Pi? That’s how I built this robot. Claude runs fine on a Pi. You should try it!

Let an Agent Poke at It: gorai-mcp

Now here’s where it gets fun. Because Gorai already models the world as resources and tools, exposing it to an LLM is almost embarrassingly natural. That’s what gorai-mcp is: an MCP server that bridges your robot’s mesh to any MCP client. Point Claude at it and the model can see the robot — read the sensors as resources, call the actuators as tools — no glue code, no custom shim. It just shows up as capabilities the agent can reason about.

It’s genuinely magic the first time you watch a model discover your robot and start asking it questions.

But — and I want to be crystal clear here — you don’t want to control the robot for real with this. It is way too slow. Think about the round trip: your command goes through the MCP transport, up to a model, waits on inference, comes back down. That’s hundreds of milliseconds to seconds per decision. That is fine for “what do you see?” or “plan me a route.” It is absolutely, categorically not fine for the tight control loop that keeps a moving car out of the wall. Real-time control stays where it belongs: down on the node, in typed Go, running at mesh speed with the safety watchdogs I mentioned above.

So think of gorai-mcp as the robot’s conversation layer, not its reflexes. High-level reasoning and experimentation up top; fast, deterministic control down low. Don’t mix those up, or you’ll drive a very smart robot straight off your desk.

Which brings me to the thing I probably shouldn’t tell you about yet…

One More Thing… 🌊

Multi-rotor drones democratized the sky — fleet management, autonomous waypoints, modular payloads, all at hobbyist prices. So why is the water still locked behind $50,000 price tags, proprietary hardware, and industrial gatekeeping?

Meet SURF — an open-source, open-hardware, 3D-printable autonomous surface drone. Radically open: every CAD file, every line of code, every line of the BOM. Modular by design. Fleet-ready out of the box. It self-rights if it capsizes. It fits in your car trunk. And it runs on Gorai.

The robot design is all done by Luca Herlein - yes, my son, and yes this is the father-son project I mentioned before. Luca is the modern meta-Engineer. He codes, he’s as good as anyone I know using coding agents to boost his speed, and he has a BS in Aerospace Engineering from CU Boulder. He’s building an amazing sea-surface robot - based on gorai of course!

Surface Unmanned Reconnaissance Frame - SURF. Or maybe we just like the ocean. You decide. And yes, we will use this for recording whale song this winter!

It’s about to go in the water for its first operational testing. Here are some photos as it’s coming together:

Click to see an enlarged photo

I’m not going to say more yet — but keep an eye on this space, because when SURF gets wet, you’ll hear about it. We’ll be profiling on the Emerging Robotics website.

Try It

Gorai and the PiCar-X example are open source, right now:

Build the car. Drive it from your browser. Then imagine an agent holding the same controls. That’s the future we’re building toward — reliable, predictable, single-binary robotics that’s ready for AI. It brings the ease of Arduino, but kicked up a level in capability, and lets you do real robotics without having to learn the complexity of ROS 2.

If you build something with it, or you just want to argue about it, drop me a note on LinkedIn. And pay it forward.

 Share!