1. Something like OpenClaw will change the world.
2. OpenClaw is not yet ready.
The heart of OpenClaw (and the promise) is the autonomy. We can already do a lot with the paid harnesses offered by OpenAI and Anthropic, so the secret sauce here is agents doing stuff for us without us having to babysit them or even ask them.
The problem is that OpenClaw does this is an extreme rudimentary way: with "heartbeats." These are basically cron jobs which execute every five minutes. The cron job executes a list of tasks, which in turn execute other tasks. The architecture is extremely inefficient, heavy in LLM compute, and prone to failure. I could enumerate the thousand ways it can and will fail but it's not important. So the autonomy part of the autonomous assistant works very badly. Many people end up with a series of prescriptive cron jobs and mistakenly call that OpenClaw.
Compounding this is memory. It is extremely primitive. Unfortunately even the most advanced RAG solutions out there are poor. LLMs are powerful due to the calculated weights between parametric knowledge. Referring to non-parametric knowledge is incredibly inefficient. The difference between a wheelchair and a rocket ship. This compounds over time. Each time OpenClaw needs to "think" about anything, it preloads a huge amount of "memories" into the query. Everything from your personal details to architecture to the specific task. Something as simple as "what time is it" can chew through tens of thousands of tokens. Now consider what happens over time as the agent learns more and more about you. Does that all get included in every single query? It eventually fails under its own weight.
There is no elegant solution to this. You can "compress" previous knowledge but this is very lossy and the LLMs do a terrible job of intelligently retaining the right stuff. RAG solutions are testing intelligent routing. One method is an agentic memory feedback loop to seek out knowledge which might exist. The problem is this is circular and mathematically impossible. Does the LLM always attempt to search every memory file in the hope that one of the .md files contains something useful? This is hopelessly slow. Does it try to infer based on weekly/monthly summaries? This has proven extremely error-prone.
At this point I think this will be first solved by OpenAI and/or Anthropic. They'll create a clean vectorised memory solution (likely a light LLM which can train itself in the background on a schedule) and a sustainable heartbeat cadence packaged into their existing apps. Anthropic is clearly taking cues from OpenClaw right now. In a couple of years we might have a competent open source agent solution. By then we might also have decent local LLMs to give us some privacy, because sending all my most intimate info to OpenAI doesn't feel great.
Heartbeat cron and naive memory are the right thread to pull. Agree.
The problem is the data/trust boundary. One agent process, one credential store, all channels sharing both. Whenever we scale the memory up, which we all want to do, we scale the disaster radius of every prompt injection with it.
Wirken accounted for this in the first design step. Per-channel process isolation. Handshakes between adapters and the core. Compile-time type constraints so a Discord adapter cannot construct a Telegram session handle. Encrypted credential vault. Hash-chained audit log of every action. All, remaining model-agnostic, so local models and confidential-compute providers are drop-in.
Your memory point is still unsolved at this layer. When memory does get solved, you want the solver running where it cannot leak the wrong credentials to the wrong channel. Otherwise the smarter it gets, the worse the breach.
Agentic coding has all of the same issues and it gets solved much the same way: give LLMs tool calls to file persistent memories by topic, list what topics are available (possibly with multiple levels of subtopics in turn) and retrieve them into the context when relevant. Not too different from what humans do with zettelkasten and the like.