The Agent Control Plane Problem
I had a Discord bot, an email processor, a scheduling agent, and a cost tracker — all running separately, none aware of each other. That's when I knew I needed ClawHQ.
At some point last year, I had six AI agents running across my projects. A Discord bot that answered questions and coordinated tasks. An email processor that parsed incoming messages and extracted events. A cost tracker for the Claude API. A web scraper for content research. A scheduling agent. A deployment notifier.
Each one worked fine in isolation. Together, they were a mess.
There was no single place to see what any of them were doing. No unified view of what they cost. No way to tell if one had crashed without checking its logs manually. If I wanted to stop them all before running a refactor, I had to SSH into containers one at a time. If one was misbehaving — sending too many messages, burning through tokens — I had no early warning. I'd find out after the fact.
I'd built a fleet of agents with no way to manage it.
What I mean by control plane
In networking, a control plane is the part of the system that makes decisions — it decides where packets go, who has access, what the rules are. The data plane does the actual work. They're separate concerns, and separating them is what makes large networks manageable.
AI agents have a data plane problem. They're increasingly good at the actual work — calling tools, generating responses, taking actions. What they don't have is a control plane. Nobody has built a good answer to "how do you manage a fleet of AI agents the same way you'd manage a fleet of servers?"
That's the problem ClawHQ is trying to solve.
What the system actually does
ClawHQ is a dashboard and coordination layer for AI agents. It runs on Cloudflare Workers — no always-on server, no infrastructure to babysit, globally distributed by default. Agents check in via a lightweight protocol and get registered in the dashboard. From there, you can see what's running, what's healthy, what each agent has done recently, and what it costs.
The health monitoring took the most iteration to get right. An agent's "health" is surprisingly hard to define. A web scraper that hasn't run in six hours could be healthy — maybe there was nothing to scrape. Or it could be broken. A Discord bot that hasn't sent a message in a day could be fine, or it could have lost its gateway connection. The signals you care about are different for every agent type.
What I landed on was a combination of active heartbeats — agents ping in on a schedule — and behavioral signals that are defined per-agent. If an agent hasn't heartbeated in the expected window, or if its recent behavior is outside normal parameters for that agent, the dashboard flags it. Not every deviation is a problem. But every problem is a deviation.
Token budgets were the other piece. Each agent gets a configured budget — a cap on what it can spend per hour or per day. If it's approaching the limit, the dashboard warns. If it hits the limit, the agent's calls start failing gracefully instead of running unchecked. I burned enough API budget during development to make this feel like a real feature, not a nice-to-have.
The design decisions I'd make differently
ClawHQ is built as a B2B product — it's meant for teams managing multiple agent deployments, not just me managing mine. That framing pushed me toward more flexibility than I needed at the start, and more complexity than was warranted.
If I were starting over, I'd build the personal version first. Get the core monitoring loop right — heartbeat, health status, cost tracking, basic alerting — before worrying about multi-tenant auth and team permissions. The fundamental problem is the same at any scale. The enterprise features are layered on top.
That's a lesson I've learned more than once: solve the core problem first for yourself, then generalize. Every time I've done it in the other order, I've shipped something that's generalized correctly but doesn't actually solve anything.
The broader pattern
The agent proliferation problem is going to get worse before it gets better. Agents are cheap to spin up and hard to audit. The tooling for building them is excellent. The tooling for managing them is nearly nonexistent.
What I think happens next is the same thing that happened with containers. Docker made it easy to spin up containers. Kubernetes made it possible to manage them at scale. There's going to be a Kubernetes moment for AI agents — a standard way to define, deploy, and monitor them that teams can actually operate.
ClawHQ is my early bet on what that looks like. I'm building it partly because I need it, and partly because I want to be far enough ahead of the problem that the solution is already working when everyone else realizes they have it too.
That's the only sustainable advantage I've found as a solo builder. Not speed, not cleverness — being in the right place early enough to learn from the problems before they become obvious.