Ask HN: Does OpenClaw need a re-architecture to be usable?
5 comments
This is a great observation. I'm the creator of OpenClaw, and you've hit on exactly why we recently introduced the "Gateway" architecture.
The early versions were indeed "single programs trying to do everything," which is fine for a demo but fails for long-horizon tasks. The new Gateway architecture (v1.0+) moves us toward the OS model you're describing:
1. Process Supervision: The Gateway acts as a supervisor for multiple agent sessions. If an agent crashes or hangs, the Gateway can detect the heartbeat failure and attempt recovery. 2. State Persistence: We're moving memory and session state into a decoupled database (Clawdb) so you can restart the process without losing context. 3. Event-Driven: Sub-agents can now spawn to handle background work and notify the main session via system events, rather than blocking the main loop.
We're still early in the transition, but the goal is to make OpenClaw the "agentic kernel" that handles the messy reality of failure, rather than just a wrapper around a prompt. Reliability is the main focus for the next few months.
The early versions were indeed "single programs trying to do everything," which is fine for a demo but fails for long-horizon tasks. The new Gateway architecture (v1.0+) moves us toward the OS model you're describing:
1. Process Supervision: The Gateway acts as a supervisor for multiple agent sessions. If an agent crashes or hangs, the Gateway can detect the heartbeat failure and attempt recovery. 2. State Persistence: We're moving memory and session state into a decoupled database (Clawdb) so you can restart the process without losing context. 3. Event-Driven: Sub-agents can now spawn to handle background work and notify the main session via system events, rather than blocking the main loop.
We're still early in the transition, but the goal is to make OpenClaw the "agentic kernel" that handles the messy reality of failure, rather than just a wrapper around a prompt. Reliability is the main focus for the next few months.
It’s impressive to see OpenClaw improving itself—especially with so many people contributing while the project is still brand new. Have you tried optimizing your workflow on it yet? You can add and tweak skills to much improve accuracy and token efficiency. Which model are you using, and where are you running it? Performance seems to vary a lot right now, and there are already tons of X posts and videos with different optimization approaches.
The first few days were exciting. It felt like we’re finally getting closer to autonomous agents that can actually operate a computer end-to-end. But after the initial excitement faded, I started noticing some consistent issues:
- It frequently stops responding mid-task
- Execution fails without clear recovery
- Task success rate feels inconsistent and unpredictable
- Long-running tasks degrade over time
It made me wonder whether the current architecture is fundamentally limiting reliability.
Right now, it feels closer to a “single program trying to do everything” model. But if we look at the history of computing, systems only became truly robust when we moved toward operating system–like abstractions:
- event-driven execution
- proper failure recovery
- watchdog / heartbeat monitoring
- task supervision trees
- state persistence and resumability
In other words, less like a script, more like an OS.
My current hypothesis is that tools like OpenClaw might need a deeper re-architecture — not just better prompting or incremental patches — but a system-level rethink focused on reliability and scalability from day one.
Curious what others think:
Is this mainly an engineering maturity issue that will be fixed incrementally?
Or is there a more fundamental architectural gap in current agent frameworks?
Has anyone tried building agents with more OS-like supervision models?
Would love to hear perspectives from people building in this space.