A personal CRM and operations layer running on an autonomous AI agent runtime
A personal operations platform, on an autonomous-AI-employee runtime
A bespoke personal CRM and operations layer — contacts, integrations, an integration-toggle sheet, a strict secrets model — running not as an app but as a set of tasks an autonomous AI 'employee' carries out for me. The runtime, not the UI, is the product.
Running a one-person practice with twenty clients and a hundred decisions a week means a stack of SaaS apps that don't talk to each other, secrets scattered across them, and integrations that quietly break. The 'one tool to rule them all' pitch never holds up — and the tools weren't designed for an AI to operate them on your behalf.
A personal operations platform built on top of an autonomous-AI-agent runtime — a small CRM, explicit integration toggles each with their own budget, a strict secrets model — where the agent does most of the operating, and I delegate in plain language instead of clicking through apps.
| Before | After | |
|---|---|---|
| Where the work happens | across a stack of consumer-SaaS apps | one runtime, with an agent doing the operating |
| How you reach your data | open the right app, search, scroll | ask the agent in plain language |
| Integrations | a fragile chain of webhooks and Zapier | explicit toggles, each priced and budgeted |
| Where secrets live | in whichever apps you set up first | one model, one place, one set of rotation rules |
| What the platform 'looks like' | a UI you click through | an agent you delegate to |
A pile of subscriptions and a swivel-chair operating system becomes one personal CRM where the AI is the operator. The stack the rest of the world buys ten apps for runs as five flat tables and an agent that knows them.
What I built
A bespoke personal operations platform that I actually run my practice on. It looks small on paper — a small CRM, an integration-toggle sheet, a secrets model, an audit log — but the part that matters is what runs it: an autonomous-AI-agent runtime (OpenClaw) that operates the platform on my behalf.
- The CRM is small on purpose. Contacts, projects, interactions — five flat tables instead of the dozen the SaaS equivalents have. Less surface for the agent to learn; less for me to maintain.
- Integrations sit behind explicit toggles, each with a budget. Email, calendar, docs — each one is opt-in, with a cost ceiling. The platform only spends what it's authorized to.
- Secrets live in one place, with one model. The agent never sees raw keys, only references. Rotation is on a schedule, not a memory.
- The agent is the operator. Most of what would be a click-through-three-apps task — "pull the last three notes on this contact", "who haven't I followed up with this week", "summarize today's emails by project" — goes to the agent, which uses the platform on my behalf and reports back.
- Every action is audited. Tool calls, budgets spent, decisions made — all logged, so the system stays auditable even when most of the work is done without me touching it.
The clean line: the platform stores the data; the agent does the operating; I delegate in plain language.
Why it matters
This is the workshop. The other cases here are systems built for clients or as products. This one is the stack I actually run my practice on, and it's where I find out what works before I ship it elsewhere. The decisions that get hard-won here — how to bound an agent's permissions, how to budget per task, where to put the audit log — are the ones that show up later in the client engagements as the parts I already know how to do safely.
It's also a deliberate counterpoint to the productized version of the same idea (Software of You). The product has to please many people; the daily driver only has to please me. Keeping both gives me the test bed and the showcase at once.
The seduction with an "AI agent for personal ops" is to give it broad permissions and trust the LLM to behave. That breaks the moment something important needs to stay private, or a vendor changes its API, or the agent spends a hundred dollars in tokens deciding what to do next. The hard part here is the *runtime*: explicit integration toggles (each priced), a strict secrets model where the agent only sees references, per-task budgets that hard-stop runaway loops, and a full audit log of every tool call. The CRM data model is the easy part. The agent runtime, budget, and audit story are what make this safe enough to use on real work every day.
Most one-person practices end up with a SaaS stack and a swivel chair. This is the opposite: one runtime, one CRM, explicit integration toggles, one secrets model, and an agent that does most of the actual operating. The work doesn't happen in a UI; it happens in delegation.
Still being worked out: where the agent is genuinely better than a five-second tap on a phone, and where it isn't. The runtime is the right model; the catalog of tasks that beat the manual baseline is the part being curated through daily use.