Adversarial Verification Report · Jun 20, 2026 · 104 agents · 22 sources
97 claims extracted from primary docs, GitHub, and blog sources. Each tested against 3 independent adversarial verifiers. Most didn't make it.
OpenClaw is solving a different problem. It is a Node.js messaging gateway — WhatsApp, Telegram, Slack, Discord — that added browser capability as one tool among many. It was never designed for authenticated, session-sensitive bank workflows on local hardware. The hybrid Python/Playwright architecture you arrived at is the right answer for your specific problem, and Lobster — OpenClaw's own deterministic pipeline add-on — confirms that even its own ecosystem is converging on the same pattern you built.
$step.stdout and $step.json), approval gates that return a compact resumeToken on pause, and resumption via {"action":"resume","token":"...","approve":true} that skips already-completed steps. Authored by a developer who submitted PR #20 to the Lobster repo — a first-hand account, not marketing.| Dimension | OpenClaw | Hybrid Python / Playwright |
|---|---|---|
| Runtime | Node.js 24+ (not Python) | Python — your existing stack |
| Primary purpose | Messaging gateway with browser as one capability | Browser automation, LLM for planning only |
| LLM authority | Broad — plans AND executes system actions | Narrow — plans only; Playwright handles execution |
| Workflow durability | Lobster resume tokens (confirmed) | Custom state machine — you control the design |
| Bank session timeout | Still at risk — LLM latency between steps | Solved — Playwright keeps session warm between LLM calls |
| Security boundary | None enforced by default | Explicit — LLM cannot touch filesystem or shell |
| Local LLM requirements | Unknown — all specific claims refuted (see below) | Verified on your M1 Max with qwen3:32b |
| Browser integration | CDP WebSocket to cloud browser, or Browser Use skill | Direct Playwright — no intermediary, no cloud dependency |
| Deterministic pipelines | Available via Lobster add-on | Native — the entire architecture is deterministic by design |
Documented incidents & exposure (high confidence, multi-source):
These specific claims circulate in blog posts and comparison sites — and were refused by all three independent adversarial verifiers. Do not rely on them.
| Vote | Claim (killed) |
|---|---|
| 0-3 | OpenClaw requires at least 64K tokens of context; reliable threshold is 32B+ parameters with 24GB VRAM minimum |
| 0-3 | OpenClaw is built as a six-layer architecture (Interface, Orchestration, Reasoning, Context, Tooling, Coordination layers) |
| 0-3 | OpenClaw is explicitly unsuitable for deterministic pipelines or simple automation with fixed logic |
| 0-3 | OpenClaw uses a peer-agent model where agents communicate via agentToAgent tool rather than spawning child agents |
| 0-3 | Community sentiment shifted from excitement to frustration; developers moved toward Claude Code as an alternative |
| 0-3 | OpenClaw integrates with any OpenAI-compatible local LLM backend via a 'type: openai-compatible' config field |
| 0-3 | Requires GPU with at least 12GB VRAM; CPU-only inference produces "10-20× slower responses" |
| 0-3 | Only Qwen 3/2.5 Coder, Llama 4 Scout, Mistral Small 3.1, MiniMax M2.5 confirmed compatible with tool-calling interface |
| 0-3 | The recommended architecture positions OpenClaw as an orchestrator that delegates to browser agents as sub-skills |
| 0-3 | OpenClaw is a local-first personal assistant (as opposed to a gateway product) — this characterization is incomplete |
| 1-2 | OpenClaw is susceptible to "ClawJacked" indirect prompt injection attacks allowing credential exfiltration from malicious websites |
| 1-2 | The author of the dev.to Lobster piece explicitly argues against using LLMs for workflow routing |
| 1-2 | OpenClaw integrates browser automation, tools, skills, and workflows into a single unified orchestration layer |
Q1. What are the verified minimum local LLM requirements for OpenClaw — specifically context window size, parameter count, VRAM, and which Ollama/vLLM/LM Studio models are confirmed compatible with its tool-calling interface? Every specific claim on this topic was refuted.
Q2. Do Lobster resume tokens survive Gateway restarts? The specification confirms the token mechanism exists, but production failure modes for workflows spanning hours or days are undocumented in any verified source.
Q3. Has OpenClaw addressed the security exposure (245K+ servers, credential storage) with architectural changes to its permission model? A verified sandboxing or capability-scoping mechanism would meaningfully change the comparison.
Q4. How does OpenClaw's agent communication model actually work at the protocol level — hierarchical sub-agent spawning, peer-to-peer, or something else? The peer-agent claim was refuted but no verified replacement description was found.
OpenClaw was not designed for what you're building. Its Gateway architecture solves the problem of routing AI assistants across messaging channels — a genuinely useful problem, but not yours. Applying it to authenticated bank workflows on a local M1 Max would mean running a Node.js process you don't own, with an LLM that has broader system access than you want, against session-sensitive flows it was never designed for.
The hybrid Python/Playwright architecture you've arrived at is structurally correct: the LLM plans in Python, Playwright executes deterministically, the browser session stays warm between LLM calls. This is precisely the pattern Lobster was added to OpenClaw to approximate — which means the OpenClaw community validated your approach, not the other way around.
The one thing worth taking from OpenClaw: Lobster's resume token pattern is a clean design for pausing long-running workflows at approval gates. If your state machine grows complex, that specific interface is worth studying — not as a dependency, but as a reference implementation for how to handle human-in-the-loop interrupts in a deterministic pipeline.
Primary Sources