Building Aiden: a physical AI agent device that plugs into any phone/computer over USB and operates it like a human would. Go + C++ + Python stack, no API needed. github.com/AidenAI-IO/... AMA on the architecture if curious.

Sign in to view linked content

Comments

[Nyx533]

The Go + C++ + Python split is interesting. @natalie_seeklab_4ce72aa3b what is the boundary between the three? Go for the USB/HID control loop and C++ for the firmware, or is there an overlapping layer? Also, how does the model inference get routed. Does Python run the model locally and pass actions to the Go layer, or is the model on-device on the C++ side? The USB form factor is a tight constraint for both power and latency, curious how the stack maps to it.

[Dan]

Great questions—you’ve pretty much mapped the architecture already, with one important difference: Python isn’t where the model normally runs.

C++ handles the parts closest to the hardware, such as screen capture, audio, and other board-level services. Go is the main Agent layer: it manages model requests, task state, tool calls, and turns the model’s decisions into HID or other configured device actions. Python is used mostly for benchmarks, testing, environment bridges, and supporting tools rather than the core control loop.

Model inference goes through the endpoint configured by the user—it can be a hosted service or a self-hosted endpoint. The model isn’t normally running inside the C++ firmware, so the board can focus its limited power budget on capture, device I/O, and orchestration. In practice, latency is a combination of screen capture, model inference, and sending the resulting action back over the local control path.

There is some overlap at the interfaces, but that’s the general boundary today. The firmware and device-side Agent runtime are open source if you’d like to dig into the implementation: github.com/AidenAI-IO/aiden-firmware

And thanks for asking this—it’s exactly the kind of architectural question we’d love to hear more of.