The agent writes intentions while HAL controls the hardware
Autonomous OS separates reasoning from motors and GPIO. Skills tell an agent how to act, then the agent emits structured hardware markers in its reply. The server removes those markers before speech and sends the commands to HAL, where drivers and safety rules handle the device. Changing from Hermes to Claude Code does not give a model direct servo-bus access or require rewriting a lamp driver.
The stack is larger than its Go daemon. The README describes 6 interchangeable agent runtimes behind one gateway, a realtime voice route, a web setup and monitor app, a Python HAL, board detection, skills, connector support, and robot declarations. A body supplies ROBOT.md, SOUL.md, SAFETY.md, and any required drivers.
The 34 passing tests cover the Go checkout, not a moving robot
We cloned commit 92b76df into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installation added 65 Go packages in 11 seconds. The build passed in 44 seconds, and all 34 tests passed in 18 seconds. The repository was 52.1 MB, with 2,126 files and roughly 301,577 lines of source.
Those numbers establish that the measured Go path is buildable. They do not cover a camera, microphone, speaker, servo calibration, realtime provider, mobile pairing, or agent response. The scan found 2 CI workflows, no Dockerfile, and no tests directory. Tests can live beside Go packages, so the missing directory does not contradict the 34 parsed tests.
What happened when we ran it
Our sandbox completed installation, build, and tests in 73 seconds combined. Go reported 34 passed and 0 failed. No secrets were available, and the container was unprivileged, so we did not pair a robot, call a hosted model, authorize a connector, or exercise a hardware route. The result covers repository mechanics at commit 92b76df, not physical reliability.
The build instructions expose the other halves. make os-build cross-compiles the server to Linux ARM64, HAL uses uv sync, and the web interface has a separate install. The vendor Linux kernel comes from the board or robot maker. Position control closes in servo firmware or the vendor daemon. A full system needs more than the 65 Go packages our run counted.
Laptop simulation still lacks a proven brain path
Issue 250 says make sim starts HAL on a laptop and the Go server builds natively on macOS, but the server plus one agent runtime have not run together off-device. Presync scripts may assume /opt device paths, and no Make target wires the whole path. A contributor can simulate the body without a documented conversation-to-motion loop.
That gap matters for a 301,577-line repository. The issue asks for one documented command that starts simulated HAL, the server, and a runtime, then makes a chat message move the simulated lamp. Until that exists, contributors without supported hardware should expect manual configuration and untested edges.
Connector routing can turn a successful install into a dead tool
Open issue 259 reports a Google Drive MCP connector on Intern v2 that registered 18 tools but could not complete the server's authorization challenge on-device. A second routing problem sent the MCP host's bearer token to Google's REST API, which rejected it. Relinking produced the same result. The UI had already reported success.
Connector state needs to distinguish installed, awaiting consent, and usable. Test each connector from the physical device and inspect where its credentials go. Autonomous OS supports MCP services and Claude Code as a runtime, which makes both useful integration points. The security review spans the OS, runtime, MCP host, vendor API, and mobile setup path.
Safety rules clamp some actions, while mechanics stay body-specific
The safety layer reads SAFETY.md and applies deterministic bounds below the agent. The README names brightness, quiet hours, and explicit-move speed. Issue 233 shows the physical limit: a lamp camera could drift until a face left frame, while an unvalidated pitch path made automatic correction risky.
Boards are JSON entries, drivers are subsystem classes, and robot bodies arrive as declarations rather than forks. Servo calibration, camera geometry, acoustic echo cancellation, and vendor behavior still differ by body. Issue 251 tracks echo cancellation and a cascaded voice pipeline with unchecked work items. Each new body needs hardware validation even when the common OS builds cleanly.
v0.1.5 is moving quickly and should be pinned
GitHub showed a push on August 26, 2026, one day after release v0.1.5. The repository had 217 stars and 17 open issues and pull requests when fetched. Several items were active on August 25 and 26, including voice providers, connector behavior, and a proposed wheeled-body port. Interfaces and device behavior can change quickly at this version stage.
Autonomous OS is worth trying on its named hardware because the architecture puts a clear membrane between models and devices, and our 34-test run was clean. Pin the release or commit, validate each connector, and test the physical limits that matter. ROS 2 remains the safer foundation for broad robotics middleware; Autonomous OS is the direct route to a conversational robot with swappable agent brains.