How and why I built openclawpm

February 20, 2026

projects ai product-management

I kept seeing agent demos that looked magical. Then I tried to build one I could actually use—highly specialized, real context, real tools—and it fell apart the second I switched machines.

That's the real problem: the agent isn't the prompt. The agent is the runtime.

So I built openclawpm: a CLI that provisions isolated, persistent environments and runs OpenClaw-powered agents inside them. Ship specialized agents on remote hardware like normal software, not a fragile demo.

What "specialized" actually means

Not a generic chatbot. A specialized agent has a job ("PM doc generator", "content ops from Notion"), context that persists across sessions, an environment where tools actually work—files, git, API tokens, schedulers—and a runtime that isn't your laptop.

That last point matters more than it sounds. If your agent only lives on your laptop, it's not a product. It's a hobby.

What breaks when you try to run agents for real

Four things kept killing me:

State is either missing or messy. Agents are better when they remember things. But if "memory" is a text file on your laptop, you're one machine away from losing it.

Isolation is non-negotiable. Specialized agents per project or customer means hard boundaries: filesystem, env vars, secrets, dependencies. "Just run it in a folder" doesn't scale.

Remote execution isn't optional. Scheduled jobs, long-running tasks, integrations—all of it needs a stable runtime. Not your laptop lid staying open.

Reliability beats cleverness. Once you've used a tool that fails 30% of the time, you stop trusting it. The goal isn't the smartest agent. It's the one that keeps working.

The fix: give each agent its own sprite

openclawpm leans on Sprites (from Fly.io): persistent, hardware-isolated Linux microVMs you can spin up on demand. They sleep when idle, wake when needed, and keep their filesystem between runs.

Docs: docs.sprites.dev

The architecture is dead simple:

openclawpm (CLI) → provision sprite → install/configure agent → run tasks → persist state

The sprite becomes the agent's home—a tiny dedicated computer for that one specialized agent. At a high level, openclawpm is a control plane: create an isolated environment, bootstrap it with what the agent needs, run jobs in it, keep the results for next time.

What the workflow feels like

  1. Provision a sprite for a particular agent/persona
  2. Seed it with context + tools
  3. Run tasks against it repeatedly
  4. Keep everything isolated from other work

Even if you're not a CLI person, the point is: a repeatable way to run specialized agents without turning your laptop into a server.

Where this is going

Once you can provision isolated runtimes, a lot opens up.

Specialized agents per role—PM, marketing, support, research—each with its own context, tools, files, and guardrails. Specialized agents per customer, which is the real productization unlock: per-customer environments without the usual ops nightmare.

And when the agent lives on remote hardware, it can run schedules, process files, connect to integrations, and actually be reliable. That's what makes an agent feel like a system, not a conversation.

This is the foundation I'm building PMPrompt on. The long-term vision isn't a prompt library—it's specialized agents that know your context and execute repeatable workflows. openclawpm makes that operationally sane.

What's next

Still early, but the roadmap is clear:

If you're building agents…

If you've hit the wall of "cool demo, but how do I run this reliably?"—that's exactly the problem openclawpm solves.

Show Comments