I spent a few days poking at Clawbot and it clarified something I’d been hand-waving: the hardest part of “useful autonomous agents” is increasingly not model quality, but the runtime that keeps the whole thing coherent when tools/LLM calls are slow, flaky, or non-deterministic.

Clawbot reads less like “an agent” and more like a platform:

• A gateway/daemon that owns processes and isolates the system from expensive/unstable LLM calls

• Event-driven orchestration (webhooks) so agents react to real state changes rather than polling

• Fine-grained permissions during onboarding + handshake flows that make “local authority” safer to reuse

• Local-first execution so you can reuse existing tools (terminal, local apps, Claude Code, etc.) without turning everything into a cloud integration problem

This also explains why hackathon agent demos (including one I built last year) often feel brittle: they’re usually an “agent loop + tools,” but they lack the boring runtime pieces—resource management, concurrency control, failure handling, state persistence, and permission boundaries—that let tasks run for long periods without weird interference.

A few questions I’m left with:

1. What’s the right minimal “kernel” interface for agent runtimes (state, scheduling, authority, audit)?

2. How should these systems implement preemption / cancellation / checkpointing for long-running tool chains?

3. What’s the best pattern for “LLM as an unreliable subprocess” (retries, circuit breakers, sandboxing, determinism contracts)?

4. For multi-node setups, what’s the cleanest model: one daemon per node + one gateway, or fully federated gateways?

Full thoughts:

https://chenyu-li.info/blog/15/en/