Everyone’s talking about Openclaw this week. If you haven’t seen it: it takes a Claude model, strips off the guardrails, wraps it in some extra tooling, and lets it run autonomously. People are impressed. I ran it. And I have thoughts.
What Openclaw actually does
There are really three things going on:
First, it runs in what they call dangerous mode. No safety rails, full access to your machine. The agent will scour your computer for API keys hidden in config files, environment variables, wherever. It may use them. It may publish them. You don’t know. This is why the security-conscious crowd runs it on dedicated cloud hardware with nothing on it they didn’t explicitly provision. That’s the right instinct.
Second, it has a built-in cron that lets the agent schedule its own work. This is the part that matters most. Tell it to manage your X account and it will keep posting all day without stopping. It doesn’t run to completion and then wait for you to kick it again. It stays alive.
Third, it shifts the interface to be chat-centric through existing messaging channels. The win here is portability. You can talk to it while commuting, ask questions from your phone, and it has the full context of your projects, your files, your authentication. That’s something you don’t get when you open a fresh conversation in ChatGPT.
My take: too big a leap
I’ve been running agents hard for weeks. I’ve built multi-agent teams with Claude Code and pushed the current tooling about as far as it goes. And my honest reaction to Openclaw is that it jumped too far.
The user interface introduces a huge number of configuration options. There are a lot of moving parts to set up. It’s not an incremental lift from the interfaces people are already comfortable with. It’s a full departure. And I think that matters more than the community is acknowledging right now.
There may also be some architectural choices that are going to be hard to walk back from. When you build a foundation that’s too complex from day one, you end up having to simplify later, and simplifying is always harder than starting simple.
The real insight: agents need a heartbeat
Strip away the configuration and the dangerous mode and the chat interface. What’s the core idea that makes Openclaw feel alive?
It’s a loop.
Current AI models just turn off. They don’t compute any signals between conversations. There’s no input, no processing, nothing running. They’re not awake unless someone talks to them or they’re working through a task. They have no self-start feature. When they reach the end of a prompt, they effectively pass out and don’t wake up until someone asks them another question.
That’s wildly different from a human brain, which keeps running between conversations. You finish talking to someone and you keep thinking about what they said. You notice things. You have ideas at 2am.
The insight, whether it came from the RALPH loop concept or from Openclaw’s cron, is the same: give the agent a heartbeat. A daemon process that periodically checks in and says “is there anything new to do?” That’s what keeps a little bit of life alive in these things.
What a heartbeat enables
With just a simple startup hook, every time your agent wakes up it checks:
- Are there new blog posts or news to process?
- Did anybody post something on a website I’m monitoring?
- What time is it, and should I adjust the smart home lights?
- Are there new GitHub issues or error logs on the server?
- Is there anything left in the PRD that needs building?
- Can I rerun the unit tests to make sure everything still passes?
Each check is an opportunity for the agent to take a bigger action. That action might be posting to Twitter, writing a marketing report, continuing development on a project, or flagging something that needs human attention.
This is a different thing entirely from scheduled tasks in ChatGPT. Those run a prompt on a timer, sure. But they don’t spin off and create new things. They don’t continuously work through a multi-step project. A local agent with a heartbeat can pick up where it left off, assess the state of a project, and keep going. I’ve been using this kind of persistent agent approach for growth engineering with Claude Code and the difference is night and day.
A simpler path
I’ve been building this into the Culture framework. There’s a daemon that auto-updates itself when the core code changes and pings each agent on a schedule. Anything the agent wants to do gets triggered on that heartbeat. Check a website, generate some content, participate in a larger process.
Right now it’s basic. But the direction is clear. Delayed jobs: “check this in 30 minutes” and the agent schedules itself to wake up in 30 minutes. Recurring tasks on a cron: run this report every two days, check inventory every morning, post a thread every afternoon. These patterns are well established in SaaS operations. Work queues, background jobs, scheduled tasks. Every serious web application runs on them. The difference is that now the worker picking up the job is an AI agent instead of a function.
And the whole thing sits on top of Claude Code. No new interface to learn. No massive configuration surface. Just a daemon and a skill file, extending the tools people are already using.
Incremental beats revolutionary
Openclaw might get there. They might simplify the interface and solidify the architecture. But right now it feels like it skipped a few steps.
I think the safer bet is incremental. Add one thing at a time to the tools people already know. The daemon is the single most valuable addition: it turns a stateless prompt-response tool into something that behaves like a persistent agent. Combine that with skill files for context and you have most of what makes Openclaw exciting without the complexity tax. It’s the same philosophy behind mini AI automations: small additions, compounding returns.
If you want to try this approach, join the Culture at join-the-culture.com. It’s early, but the idea is simple: give your agents a heartbeat and see what they do with it.