We weren’t trying to build an AI fleet-management platform. We were trying to fix a data problem.
Client and contractor conversations lived in WhatsApp. Internal coordination lived in Slack. A separate channel lived in Telegram. None of it talked to the systems that actually needed it: our CRM, our ERP. Someone had to read through conversation history and manually re-enter it, deal by deal, update by update, just to keep our own records straight. That was the real problem: a knowledge base and a data-consistency problem, spread across three platforms, none of which reconciled with the other two.
Why OpenClaw looked like the answer
OpenClaw had grown fast, and everyone seemed to be talking about it. Teams were shipping real automations with it, connected across WhatsApp, Slack, and Telegram, exactly the channels our data was scattered across. It looked less like a bet and more like the obvious next step. Wanting to be AI-first about it, we set it up immediately on a GCP virtual machine, not a Mac Mini sitting under someone’s desk. We meant to run this for real.
What running it actually took
OpenClaw did what we needed it to do. Keeping it running was its own job:
- SSH connectivity failures made it difficult to fix the instance when something went wrong
- Disk usage gradually crept up until it bricked the instance
- Backups depended on someone remembering to run them, so a restore was never tested until we actually needed one
- No audit trail made it impossible to tell who had changed what, or where a problem actually started
- Version and config updates were a gamble, since the configuration kept shifting with no guarantee of what still worked afterward
It felt like a second job nobody had signed up for. Eventually we landed on a rough process that worked often enough.
Then we tried to do it again
We wanted a second OpenClaw agent, this time for outreach and customer discoverability, a genuinely different use case from the first. That’s when the scaling problem stopped being theoretical. Every issue from the first instance was still there, and now there were two of everything: two sets of credentials to manage, two boxes that could silently drift, twice the manual attention with the same number of people to give it.
What we realized
The problem was never OpenClaw. OpenClaw did exactly what we needed it to do. The problem was that running it for real, at more than a hobby scale, is its own operational discipline: reachability, continuity, auditability, and change control. Solving the data problem left us with a fleet operations problem we hadn’t signed up for. That’s the problem this company exists to solve, not just for us this time, but for anyone else about to make the same trade.
What this series is
This series works through that operations problem piece by piece, in the open. It starts with managing a fleet of instances without SSH access, keeping a customer’s own provider key out of a container we don’t fully control, and letting one assistant route different conversations to different models without hiding who pays for what.
This is part of what powers Agent Manager HQ, early access opening soon.