From OpenClaw User to Building Buda: A Founder’s Story

I didn’t set out to build an AI agent platform. I set out to stop babysitting one.

For most of last year, my agent setup lived on a little Linux mini-PC humming away in the corner of our office. I’d gone all-in on OpenClaw — the self-hosted, run-it-on-your-own-hardware approach a lot of us in this community know and love. And honestly? I still think it’s a genuinely great piece of work. If you want full control, your data physically sitting in a box you own, and the freedom to tinker with every layer, it’s hard to beat. The hacker ergonomics are real.

This post is the honest version of what happened next: what I loved, where I kept hitting walls, and why my co-founder and I eventually decided to build something different instead of just patching around the gaps.

What actually worked

Let me be fair, because the good parts are why I stuck with it as long as I did.

Running an agent locally felt like owning the thing rather than renting it. No surprise bills. Our files never left the box, which made the policy-heavy, vendor-contract, finance-adjacent work we do feel a lot less nerve-wracking. And when something broke, I could SSH in and fix it myself at 1am, which — let’s be real — is a feeling indie hackers are weirdly fond of.

For one person, one machine, and one set of tasks, that loop is tight. I’m not going to pretend otherwise.

Where it started to frustrate me

The cracks showed up the moment my situation got slightly less solo.

The hardware became a leash. The agent could only do work when that mini-PC was awake, online, and not chewing through a long-running task. The compute being “ours” also meant the downtime was ours — and an ops team that lives in SOPs and policy lookups can’t have the assistant go dark because a box in the corner decided to update itself.

Onboarding a second person was a nightmare. Picture a small, admin-heavy startup: a handful of people drowning in standard operating procedures, internal policies, and vendor docs. When someone new needed to lean on the agent, there was no clean way to say “here, use this too, but only these files.” It was my machine, my login, my everything. Sharing meant either handing over too much or rebuilding the whole setup somewhere else.

Memory lived in chat, and chat is not memory. This was the big one. I’d have a great working session where the agent finally got our refund and returns policy straight, and then… that context was just gone, buried in a scrollback I’d never find again. The reasoning evaporated. I kept re-pasting the same SOPs and re-explaining the same edge cases, week after week.

None of these are knocks on OpenClaw specifically — they’re the nature of a single-user, local-hardware model. But they were my daily reality, and they were adding up.

The decision to build instead of patch

The turning point was the realization that the same problem repeated everywhere I looked. A small operations team — the kind that runs on policies, procedures, and vendor paperwork — would set up a self-hosted agent, and within weeks be copy-pasting the same SOPs into a fresh chat because the agent had no durable place to keep them. So my co-founder and I wrote down what we actually wanted:

• Agents that run in the cloud so my laptop being closed doesn’t matter.
• A real file store the agent works from — not a chat log it forgets.
• A way to bring teammates in with scoped access.
• The same agent reachable from Slack, WhatsApp, wherever my customers actually are.

That wishlist became Buda. The name stands for Boundless Universal Drive-based Agent, and the “Drive-based” part is the whole thesis: the agent’s long-term knowledge lives in an actual Drive — SOPs, policies, contracts, research, generated outputs — not in a conversation that scrolls away. Chat is the meeting; Drive is the file cabinet. That one reframe fixed the biggest frustration.

The rest followed from being cloud-native instead of local. Each agent runs in its own cloud workspace with real tools — a Browser, a Terminal (an actual shell), Git with visual diffs and rollback, even VS Code over Remote SSH. No hardware to buy or keep awake. And because the org boundary is a thing we call a Space — with members, shared Drive, and shared billing — bringing a teammate onto the same agent with scoped access is now a permission setting, not a migration project. The new hire sees the files they should and nothing more.

And Channels closed the last gap. Instead of one person poking at a box in the corner, the agent answers where the team already works — Slack, WhatsApp, and a few others — so the same Drive-grounded assistant is reachable to everyone, in the tools they already have open.

I want to be precise about what it is, because the lazy description (“oh, another AI chatbot”) drives me up the wall: it’s an agent runtime plus a workspace, built for teams. One agent can serve people over the web, Slack, WhatsApp, Telegram, Discord, and a few other channels, while keeping its memory in Drive the whole time.

What I’d tell my past self

A few lessons, founder to founder:

Build the thing you’re already hacking around. I spent months writing glue scripts to fake persistent memory and remote access on a local setup. The glue scripts were the product spec. If you’re patching the same gap over and over, that gap is your roadmap.

“I control my own hardware” is a feature and a tax. Local-first is a real advantage for some people and I’d never argue against it universally. Just be honest about the maintenance, the uptime, the scaling, and the collaboration cost you’re personally absorbing. For me, that tax got too high once a second human was involved.

Don’t reduce your own product to the nearest cliché. It’s tempting to describe an agent tool as “a smarter chatbot” because people get it instantly. But it set the wrong expectations and attracted the wrong users. Naming the actual mental model — files, workspace, team — brought in people with real workflows.

I’m still early, and I’m not going to throw fake traction numbers at you to look impressive. But most of the early teams trying it came from exactly this frustration: the agent forgets, and only one person can use it. If that’s you, the self-hosted route might genuinely still be your best call — and if it’s not, well, that’s the gap I’m building in.

Either way, I’d love to hear how you’re running your agents and where it’s breaking. That’s the stuff I actually want to talk about.