I'm working on an agentic OS, which is much more than just a harness manager.
Meclaw is the foundation, the substrate, not a harness. Meclaw isn't based on a rigid harness structure arranged in a loop around an LLM. Meclaw breaks down a harness into its individual parts, into actors. Each actor is a directory, a config.json file, an SQLite database and a sandbox, and it doesn't access anything else. It's message-based. The edges between actors form a large graph. There are no direct agent loops. An LLM cell (cell=actor) makes a call and sends its response as a message. The conditional graph can then route the message wherever it needs to go, for example, to tools, and the route may, conditionally, lead back through the graph to the LLM, though it doesn't have to. It can also take its own paths, to another small, fast LLM, for instance, which first summarizes things before sending the message back to the original LLM. Everything is configurable. A change to the graph structure is made via a diff, which is posted to a system api, validated, and applied. All of this is written to a ledger in an audit-friendly manner during runtime. Everything is posted via the same interface.
Two things I find really exciting are the voice and web cells. I haven't seen either of them implemented this way directly in the harness yet. The voice cell is used to communicate with voice providers via WebSockets. In Meclaw-OS, I have an example that also connects to a FreeSwitch for telephony. Simply through a code cell. And the web cell is super exciting. It is SSR and pushes only small diffs to the client over a websocket. On the client side, I'm using the LiveView client from the Phoenix Project, thanks and best regards to Chris McCord. This gives agents the ability to dynamically display information to the user in realtime.
All of this is bundled with audit support, secrets are stored in a vault cell, and each cell runs in its own sandbox. It's all wrapped up nicely.
This is a follow-up post to https://news.ycombinator.com/item?id=49590351 because valid criticism was raised regarding the GH README, stating that it appears to be automatically generated. I have now completely rewritten it by hand.
Limitations, so no one wastes their time: Linux only, since isolation takes place at the kernel level (Landlock, network namespace, cgroup v2, seccomp), and while a macOS version would fulfill the promise, it would lose this feature. Code cells run Python 3, nothing else. No authentication in the binary, that belongs in the upstream proxy.
Hey HN, Marcus here.
I'm working on an agentic OS, which is much more than just a harness manager.
Meclaw is the foundation, the substrate, not a harness. Meclaw isn't based on a rigid harness structure arranged in a loop around an LLM. Meclaw breaks down a harness into its individual parts, into actors. Each actor is a directory, a config.json file, an SQLite database and a sandbox, and it doesn't access anything else. It's message-based. The edges between actors form a large graph. There are no direct agent loops. An LLM cell (cell=actor) makes a call and sends its response as a message. The conditional graph can then route the message wherever it needs to go, for example, to tools, and the route may, conditionally, lead back through the graph to the LLM, though it doesn't have to. It can also take its own paths, to another small, fast LLM, for instance, which first summarizes things before sending the message back to the original LLM. Everything is configurable. A change to the graph structure is made via a diff, which is posted to a system api, validated, and applied. All of this is written to a ledger in an audit-friendly manner during runtime. Everything is posted via the same interface.
Two things I find really exciting are the voice and web cells. I haven't seen either of them implemented this way directly in the harness yet. The voice cell is used to communicate with voice providers via WebSockets. In Meclaw-OS, I have an example that also connects to a FreeSwitch for telephony. Simply through a code cell. And the web cell is super exciting. It is SSR and pushes only small diffs to the client over a websocket. On the client side, I'm using the LiveView client from the Phoenix Project, thanks and best regards to Chris McCord. This gives agents the ability to dynamically display information to the user in realtime.
All of this is bundled with audit support, secrets are stored in a vault cell, and each cell runs in its own sandbox. It's all wrapped up nicely.
This is a follow-up post to https://news.ycombinator.com/item?id=49590351 because valid criticism was raised regarding the GH README, stating that it appears to be automatically generated. I have now completely rewritten it by hand.
Limitations, so no one wastes their time: Linux only, since isolation takes place at the kernel level (Landlock, network namespace, cgroup v2, seccomp), and while a macOS version would fulfill the promise, it would lose this feature. Code cells run Python 3, nothing else. No authentication in the binary, that belongs in the upstream proxy.