Why this product
OpenClaw went from launch to roughly 250,000 GitHub stars in about sixty days, which made it the most interesting agent framework to study — not because it's the most capable, but because its adoption curve was driven by distribution rather than model quality. It connects to WhatsApp, Telegram, Slack and around fifty other channels, then executes real actions on your machine. I wanted to understand what that architecture costs.
The central finding
OpenClaw's value proposition and its primary vulnerability are the same design decision. Every channel it connects to is another path for an instruction to reach the agent — and the agent cannot distinguish an instruction you gave from text it merely read in an email or a webpage. Both arrive as words in the same context window.
What the teardown covers
Architecture and where the trust boundary should sit; an evaluation view on why multi-step tasks collapse (reliability multiplies rather than adds); two distinct failure modes — indirect prompt injection and unbounded execution loops; and a recommendation built around a tiered risk classifier that gates on where an instruction originated, not just what it does.
On the numbers
The evaluation figures are modeled from published benchmarks (BFCL, τ-bench, Terminal-Bench) rather than test runs I performed myself. They illustrate how errors compound across a chain of tool calls. Security figures are attributed to Zenity Labs, Snyk, and SecurityScorecard, with sources on the final slide.
What I'd do with more time
Stand up an actual OpenClaw instance and generate real eval data instead of modeled estimates — specifically, pass^k across repeated runs, so the variance is measured rather than inferred. I'd also want to pressure-test whether provenance tagging is tractable to implement, or whether it's clean on a slide and messy in code.