Some Thoughts on Clawbot

Some Thoughts on Clawbot I've been playing with Clawbot these past few days and have quite a few thoughts. Last September at a hackathon, I built a project that also used Telegram/WhatsApp interactions to let agents proactively run async tasks, with tasks sometimes triggered by group chat content. The starting point was similar, but the final result couldn't compare at all. I think the main difference lies in the overall product/engineering approach, and this is actually a common problem with most hackathon toy projects. The first impression Clawbot gives is that it's not really building an agent per se (here we define an agent as a program with feedback mechanisms that can continuously read data and run functions until a goal is achieved). The documentation reads more like traditional operating system/distributed system runtime/platform design. I think this precisely shows that the main bottleneck for agents is no longer—or not entirely—model performance. When we can use Claude Code plus some skills to handle most computer operations, what's really missing for fully autonomous agents that can complete genuinely useful tasks is a complete system that can coordinate and connect all the components without interfering or conflicting with each other, allowing tasks to run as long as possible (this should be the main goal of system optimization for performance). And this is precisely the problem traditional operating system design faces. At the same time, because of the randomness in LLM calls and tool calls (some of which are even code written by the model on the fly), instability in coordinating interactions between processes and subprocesses is unavoidable—this is why you see so many distributed system design concepts (Clawbot itself is designed as a distributed architecture that can run on different nodes). 1. The most basic abstraction starts with a daemon that owns all processes, plus a gateway that exposes it externally, isolating risk by separating the entire system from costly/unstable LLM calls. 2. Webhook-based event-driven design lets agents efficiently react to environmental changes. 3. The fine-grained permission settings for various actions during onboarding (quickly reusing existing local auth) and the WhatsApp/Telegram Bluetooth-pairing-like handshake mechanism solve security issues. 4. The completely local-based nature lets the entire system more easily access multiple processes through the terminal, effectively reusing local software and tools like Claude Code, with permission management much easier than cloud-based solutions like Manus. So you can see that the reason for not being able to deliver such impressive results usually isn't the lack of one or two good ideas—good ideas are actually becoming cheaper now. More often it's whether you have a mature and complete system design that ensures a high enough performance ceiling while not wasting engineering effort on classic problems that have long been solved. Finally, we can also see that with AI coding tools all the rage now, even as the cost of writing code is decreasing, the barrier to building competitive systems hasn't been completely lowered. For agentic projects, engineering capability advantages might be more important than the first-mover advantage from coming up with new ideas. It's not enough to accidentally hit users with an idea or accidentally choose a better engineering route than competitors. What brings sustained competitive advantage is the continuous ability to build and iterate on engineering, or the ability to continuously capture changing user needs. Unless you're lucky enough to build something that generates its own advantages (through cost structure/network effects), believing in preemptive strikes and crazy iteration to gain competitive advantage is unrealistic. I think the systematic paradigm that Clawbot represents might become the mainstream direction, but this also means that outside of very specialized areas, this field will become very competitive (system design isn't a secret).