A few weeks ago, a founder at a YC dinner casually mentioned they’re not hiring sales anymore. Fourteen AI agents handle it. I looked around the table. Nobody flinched.
So I bought a beefy Mac Studio, cancelled my calls, didn’t sleep, and started building. An ops layer on top of OpenClaw agents — a control panel to orchestrate them, pull their data, and give me one dashboard. Electron app. Custom adapter. The works.
Painful doesn’t cover it.
OpenClaw Was a Beast to Wrangle
My feed was 80% OpenClaw for weeks. Wrappers, tools, dating apps — an entire ecosystem born in days. I jumped in headfirst.
First thing I built was an adapter to pull agent data and give me the functionality I needed. Sounds simple. It wasn’t.
OpenClaw moves fast. Config paths change. State directories get restructured. If you’ve built a wrapper that assumes any of that stays stable, you’re going to have a bad morning.
My adapter file became the most-touched file in the project. Not because I kept adding features — because things kept breaking underneath me. Every OpenClaw update meant surgery. Not a stable interface. An active war zone.
OpenClaw is a good concept, but automation isn’t free. You’re still spending 16+ hours building the thing out if you want it working well. Most people expect plug-and-play. It’s not.
Isolating My Wrapper from the Runtime
The first few versions shared everything with the host OpenClaw installation. State directory, config path, the whole thing. OpenClaw reorganizes its internals, and my control panel wakes up confused.
Spent a full day untangling this. The fix was boring but essential: give the wrapper its own state directory, its own config path, its own gateway port. Complete isolation. My setup doesn’t touch OpenClaw’s defaults, and OpenClaw doesn’t touch mine.
The boring truth: the exciting part — features, orchestration, the dashboard — takes maybe 30% of the time. The other 70% is making sure the ground underneath you isn’t shifting while you’re building on it.
I moved all my agent skills out of the repo and into a dedicated directory in my home folder. Decoupled entirely. If the repo blows up, the skills survive. If OpenClaw changes how it discovers skills, I have one place to fix.
Not glamorous. But it’s the difference between a setup that works on Tuesday and one that still works on Friday.
The Auth Rabbit Hole
I lost two days to auth. Two full days.
The gateway has its own opinions about authentication. I came in with assumptions about bearer headers that turned out wrong. Then device identity issues I didn’t expect. Then scope stripping — where the runtime silently drops permissions you thought you had.
The session model made it worse. I was spinning up a new connection per request, which sounded clean but created race conditions during session handoff. The runtime assumes a longer-lived relationship than I was giving it.
I kept staring at logs thinking the issue was my code. It wasn’t. It was the gap between what I assumed the runtime expected and what it actually expected. Those are the worst bugs — your mental model is wrong, not your implementation.
The fix: a singleton gateway with explicit daemon ownership. One long-lived connection. Let the runtime be the runtime. Stop fighting its assumptions about who you are and how long you’re sticking around.
Then OpenClaw Got Acquired
Right about the time I started feeling good about my setup, the news dropped: OpenAI acquired OpenClaw.
The runtime I’d spent weeks wrangling now has a new owner with new priorities.
Nobody tells you this about building on fast-moving infrastructure. It’s not just convention changes or auth quirks. The entire project can change hands. The roadmap you were implicitly betting on can vanish overnight.
My adapter — the one I’d painstakingly isolated — suddenly became the smartest decision I’d made. I wasn’t coupled to OpenClaw’s internals. I was coupled to my adapter’s interface. If OpenClaw changes drastically under new ownership, I have one file to rewrite. Not fifty.
I didn’t plan for that. The same discipline that protected me from weekly config changes also protected me from an acquisition. Sometimes defensive engineering pays off in ways you don’t expect.
Rules I Follow Now
After a few weeks of this, I’ve settled into a set of rules. Not universal laws — just what’s working for me.
-
Your adapter is your API. Don’t let the runtime’s internals leak into your application logic. One file. One interface. Everything else talks to that.
-
Isolate state completely. Separate directories, separate config, separate ports. Share state with the host installation and you’re one update away from a collision.
-
Own your daemon lifecycle. Don’t let the runtime decide when connections live and die. Singleton gateway, explicit ownership, long-lived sessions.
-
Keep skills portable. Agent skills, configs, anything you’ve customized — move them out of the project repo. Dedicated directory. Survives repo changes, runtime changes, acquisitions.
-
Assume the ground will move. Not “might move.” Will. Build every integration like the next release could break it.
-
Don’t fight the runtime’s assumptions. Figure out what it expects about identity, session lifetime, and auth flow. Conform to those instead of imposing your own.
My setup is still rough. But the core is stable in a way the first version never was. Not because I got smarter about OpenClaw — because I got smarter about not trusting it.
Everyone underestimates the integration work. They see the demo, they see the ecosystem, they think the hard part is the AI. It’s not. The hard part is the plumbing, the auth, the state management, the defensive wiring that lets you survive when the thing underneath you decides to become a different thing.
If you’re building something similar, DM me. Still figuring this out in real time.