Adopting a popular agent runtime is not the same as making an architecture decision.
In January, an open-source agent framework called OpenClaw, first released as Clawdbot in November, crossed 250,000 GitHub stars in roughly sixty days. That is one of the fastest climbs an open-source project has ever had, and it is genuinely good software. It self-hosts on your own hardware, talks to you over WhatsApp, Telegram, Discord, and iMessage, runs around the clock, and is model-agnostic. A community registry called ClawHub already lists more than thirteen thousand installable skills.
We get asked about it a lot, usually some version of "everyone is running on this, why aren't you?" It is a fair question, and the honest answer is not "it's bad." The honest answer is that adopting a popular runtime is not the same thing as making an architecture decision, and for the surfaces we work on, this class of runtime is disqualified by the very design that makes it convenient.
This is how we read it, and what we build instead.
It is worth holding two recent facts side by side.
First: on April 4, Anthropic cut off Claude Pro and Max subscription access for third-party agent frameworks, OpenClaw among them, and moved autonomous agent usage onto metered billing. Starting June 15 it formalizes that into a separate monthly credit pool. The stated reason is plain arithmetic: a single autonomous agent left running for a day can burn the equivalent of one to five thousand dollars in model calls, which a flat consumer subscription was never built to absorb.
Second: that same always-on, unsupervised autonomy is the security story, not just the billing story. An agent that runs unattended, reads your messaging channels, and can pull from thirteen thousand community skills is not a convenience. It is a standing decision about attack surface, blast radius, and trust, made mostly by default.
Four structural surfaces, none of which is a configuration mistake you can patch. They come from the architecture.
Thirteen thousand installable skills is a real ecosystem and a real attack surface. Every skill is third-party code running inside your agent with access to the agent's tools and credentials. The convenience of "compose connectors instead of writing them" is exactly the convenience of running code you did not read.
An agent reachable over WhatsApp, Telegram, Discord, and iMessage takes untrusted text from the outside world and feeds it straight into a model that can act. Prompt injection through an inbound channel is the most reliably exploited weakness in agent systems today, and a multi-channel gateway is, by design, more doors into the same privileged brain.
A long-lived process holding credentials and the right to act is a target that sits still. You now own its patching, its secret storage, its isolation, and its monitoring. Self-hosted means you control it. It also means the hardening is yours, and most deployments never do it.
Swapping providers per task sounds like an advantage. For anything with sensitive data it means several egress paths and several vendor trust decisions instead of one you vetted carefully. "Run a cheaper model for bulk work" can mean your data crossed to a provider nobody reviewed.
None of this makes OpenClaw wrong. For a personal assistant or an internal tool over data you do not mind exposing, these tradeoffs are reasonable and the speed is worth it. They stop being reasonable the moment there is regulated data, client trust, a compliance obligation, or, in our case, a security product whose entire value is being trustworthy.
We build agents too. The difference is that every property above, we treat as a decision to make on purpose, not a default to inherit. The agents we ship, the Solon family, are built on the opposite commitments.
Solon does one thing: it audits cloud access posture, who and what can reach what across network and identity. It is deliberately not a general-purpose autonomous runtime. A narrow capability surface is a narrow attack surface, and we have chosen, repeatedly, to defer the platform in favor of the focused agent.
Solon runs inside your own account and reasons through your own AI entitlement. The configuration it reads does not leave your infrastructure, and for customers who require it, there is no outbound internet call at all. There is no vendor portal holding a copy of your environment.
Solon is read-only. The one agent in the family that can change anything requires a separate credential that is off by default, a token bound to the exact reviewed change, a dry run, a live re-check, lockout protection, and automatic rollback, with every action recorded. That is the opposite of an unattended daemon with broad standing rights.
We pick the provider deliberately and keep the reasoning step open to your security review. Provider-agility is a feature for a hobby agent and a liability for a security product.
Every finding Solon makes cites the real resource it inspected, and a citation that cannot trace to something it actually read is reported as a violation, not shipped. An agent that runs unaudited community skills cannot make that promise.
And one more, from how we run our own fleet rather than from the product: we separate the planner from the actor, with a human approval gate in between. The session that decides what to do never executes it. An operator approves. A gated executor that cannot push or merge does the work. An auditor reviews the result. The convenience-runtime pattern collapses plan, act, and persist into one long-lived process with no gate. We pulled them apart on purpose, because an agent that approves its own actions is not an agent you can hand a production cloud.
A self-hosted, always-on, model-agnostic agent that reads your channels and runs community code is a genuine advance for personal use and a disqualified default for regulated data and client trust, because unbounded unsupervised autonomy is the same property whether it shows up as a surprise model bill or a quiet compromise, and the answer is a scoped agent, hosted in your cloud, gated on every write, grounded in what it actually read, with a human between deciding and doing.
If someone on your team is weighing one of these runtimes for production, that is exactly the conversation we are good at: what is the data, what is the blast radius, what has to be gated, and where is the convenience worth it versus where it is a liability you cannot see yet. We build cloud agents on the disciplined version of this, and we will tell you on the call where you do not need us.
We do not take every engagement, and we will tell you on the call whether we are the right partner.