Some of you have seen the videos — a control panel for my agents, task boards, session management. I’ve never mentioned it by name. Internally, I call it Superclaw. This is the first time I’m talking about it publicly.
I didn’t set out to build an agent management tool. I set out to automate my mornings. Calendar prep, X monitoring, SEO research, post suggestions, GitHub release summaries. Five or six agents running daily workflows so I could focus on the stuff that actually moves my company forward.
The problem was never getting agents to work. It was knowing what they were doing.
Living in Chats Sucks
I run my agents on OpenClaw. Solid runtime. But when you’re operating through chat sessions, everything is a wall of text. Agent finished a task? Scroll through the transcript. Agent failed? Good luck finding the error buried in paragraph nine. Need to check four agents at once? Open four terminals and squint.
I’m one person running a handful of agents. Not a scale problem — a visibility problem. I’d miss completed tasks, forget which agent was assigned to what, lose context switching between sessions. Death by a thousand scrolls.
What I Actually Needed
The requirements emerged from using my own agents every day for weeks. Nothing complicated:
A task board. Not a project management tool. Just queued, in progress, done, blocked, failed. Drag a task between columns. Assign it to an agent. Done.
Session management. Start, kill, see what’s running. Agents get full context upfront through prompt injection — not halfway through a conversation.
A persistent daemon. Before Superclaw, agents died when the terminal closed. I needed something dispatching tasks on a schedule in the background, keeping things alive without me babysitting.
Everything in one window. I used to have a terminal per agent. Now I open one Electron app and see agents, tasks, sessions, status at a glance.
None of this is revolutionary. Kanban board, process manager, dashboard. But when you’re running agents through pure chat, even basic tooling feels like a superpower.
Working With the Runtime, Not Against It
I built Superclaw on top of OpenClaw. I’m still not sure I like it.
Good concept, but you don’t get automation for free. I spent 16+ hours wrangling it into something I could work with — an adapter layer to pull data and expose the functionality I needed. It’s brittle. If OpenClaw changes internal conventions, my adapter breaks.
That’s the trade-off. OpenClaw gives me a capable agent runtime. Superclaw gives me the management plane it doesn’t have. The adapter sits between them and hopes for the best.
I’m not evangelizing this setup. I needed agents running today, not in six months when some perfect platform ships. OpenClaw was there. If something better shows up, the adapter pattern means I can swap the runtime without rewriting the control plane.
Why It Runs Locally
Superclaw started in the cloud. Supabase for the database, the whole setup.
Then I moved it to SQLite.
Not for philosophical reasons. Local was just faster to iterate on. No external dependencies. No deployment complexity. No cloud round-trips. Change the schema, test it in seconds.
Once I wrapped it in Electron, local-first became the natural architecture. The app lives on my Mac Studio. Agents run locally. Data stays on my machine. Boots in a couple seconds.
I didn’t plan for local-first. I just kept removing dependencies until the system was simpler. That’s how most of my architectural decisions happen — not top-down, but through simplification.
What Changed
The difference isn’t subtle.
Before Superclaw, task dispatch ran on 30-minute heartbeat cycles. Agents polled for work, found nothing, polled again. After refactoring to centralized cron-based dispatch, response time dropped to 5-10 minutes. Session creation went from ~800ms to ~250ms.
But the numbers aren’t the real story. The real change was cognitive. I stopped holding agent state in my head. Stopped context-switching between terminals. Stopped wondering “did that task actually run?” and just looked at the board.
The progression is funny in hindsight. I used to prep for calls manually. Then my EA did it. Then OpenClaw did it. Then I couldn’t manage OpenClaw doing it. So I built a management layer on top. Each step solved the previous problem and created a new one.
At some point you realize the meta-work of managing automation is its own job. Superclaw is my attempt to make that job small enough for one person.
Not a Product Launch
This isn’t a product announcement. Superclaw is an internal tool. It solves my problems in my specific setup.
I’m sharing it because the pattern matters. If you’re running more than a couple agents, you’ll hit the same wall. Chat interfaces work for single interactions. They’re terrible for ongoing operations. At some point you need a control plane — somewhere to see what’s happening, route tasks, and manage agent lifecycle.
Whether you build one, buy one, or keep squinting at terminal windows — that’s your call.
Living purely in chats sucks. I stopped doing it.
Built Superclaw over a few weeks in February 2026, mostly out of frustration. Electron app running Next.js, Express, and SQLite. If you’ve been following my tweets about “my agent control panel” — now you know what it’s called.