Context

Claire Vo, the host of How I AI, is a heavy operator-user of AI agents: she runs multiple businesses and keeps roughly 30 personal agents running at once. This solo episode is a hands-on teardown of why she moved almost her entire agent setup off OpenClaw (a multiplayer autonomous-agent tool she had covered for months) onto Grok Bot, a newer multi-agent platform built around the Grok models. The value for a PM is not the specific tool. It is a real user narrating, in detail, which product decisions made one agent platform stick and the other one fail, plus a working library of jobs she now hands to agents. If you build or buy agentic products, this is field notes on what "usable" actually means once someone lives inside the tool every day.

The Big Idea

A more powerful agent platform lost to a simpler one because it was too hard to maintain. For agents, out-of-the-box usability and low upkeep beat raw capability, even for a highly technical user.

Claire is technical enough to run OpenClaw over SSH into a Mac mini with a dedicated "rescue" agent babysitting the others, and she still abandoned it. Grok Bot won by making the common path work with almost no setup, which let her actually deploy dozens of agents instead of fighting to keep a few alive.

Key Insights

1. Usability beat capability for adoption

Claire says OpenClaw set the standard for what an autonomous teammate can do, and in some ways still wins: it was more proactive out of the box and supported multiplayer, so several people could share one agent. She left anyway. The reason was pure operational drag: keeping her OpenClaw agents alive required so much manual upkeep that even she, running Tailscale and SSH into a Mac mini with a babysitter agent, found it "just too hard." Grok Bot's pitch, in her words, is "everything works out of the box, 90%," and that was enough to switch. The lesson for PMs: for an agent product, the gap between "impressive in a demo" and "still running in month three" is where adoption is actually won or lost.

2. One bot, one name, one job

Her whole mental model is treating each agent like a hire, not a chat window. She defines a separate bot per job, gives it a specific name, and scopes its context to that job: Chief for chief-of-staff work, a PR closer for code review, a support agent for the help desk. Grok Bot leans into this, even inferring a new bot's job from the name you give it. The PM takeaway is about scoping: narrow, named, single-purpose agents were easier to reason about, tune, and trust than one general assistant trying to do everything.

3. Ask for permissions just in time

The connector experience is what she says made her fall in love with the platform. There is a settings screen for plugins (Gmail, Calendar, Drive, GitHub, Sentry, and so on), but she almost never opens it. Instead a bot prompts her to connect exactly the plugin it needs, at the moment it needs it, through a quick OAuth flow. She also calls out multi-account support as a killer feature: one bot can hold six-plus email accounts and multiple Slack workspaces and move between them. The design principle: pull the user into setup only when a task actually requires it, rather than front-loading a configuration wall before any value appears.

4. Put an approval gate on risky actions

For actions that spend money or change code, Grok Bot uses what she calls a request-and-approve flow, and she loves it. When her support agent Holly needs to refund a customer, it does not just act. It surfaces a button ("should I refund or not?"), and on approval fires an "agent action" she can open in Stripe. The same pattern gates code changes, which go out as pull requests she reviews. The insight: full autonomy is not the goal for irreversible actions. A human-in-the-loop approval step on money and code is what let her actually delegate those jobs instead of watching them nervously.

5. A home agent should reduce screen time

Claire is explicit that for a personal or household agent, spending time with the agent is a failure state. The goal is to get her off the computer and with her family. So TradBot, her family agent, prints a physical "kitchen table newspaper" each morning on an HP printer: the day's schedule, per-kid homework and reminders, weather, and a few kid-friendly news items to talk about at breakfast. It also pings at 2:30pm to coordinate school pickup and sends a Friday preview of the weekend's scattered sports logistics. The counterintuitive product metric: success is measured by less engagement with the tool, not more.

6. Proactivity is a feature you design

Moving platforms exposed how much "proactivity" is an explicit design choice, not a given. OpenClaw had a "heartbeat" that made agents feel naturally proactive out of the box, though it was hard to maintain. Grok Bot was the opposite: Claire had to tell Chief several times to put work on a schedule and ask why it was not already acting, until she set up explicit routines (scheduled runs). She hits the same theme on tone: the Grok model is tuned to be brief and token-efficient, so it over-compresses and sometimes becomes hard to understand, the mirror image of a verbose model that rambles. Both proactivity and voice are dials a PM has to set deliberately.

7. Let agents improve their own docs

Holly, the migrated support agent, does more than answer tickets. Once a week she looks back over seven days of support conversations and proposes additions to the support playbook and the public docs, so more issues become self-service over time. This closes a loop most support setups leave open: the same questions keep arriving because nobody updates the docs. Since migrating, Claire has had multiple customers ask to leave reviews praising support quality, which she says had never happened before.

Mental Models & Frameworks

The three primitives of an agent platform

Claire breaks Grok Bot into three building blocks, and it doubles as a checklist for evaluating any agent tool:

• Bots: named, scoped agents, each defined for a specific job, like hiring a colleague.
• Plugins: the combination of skills and connectors (Gmail, GitHub, Slack, and so on) that let a bot reach into your stack.
• Computer and routines: each bot gets its own cloud virtual machine to browse, log in, and run code, plus routines, which are scheduled times it does work automatically.

Use it to compare platforms feature-for-feature: who can act (computer), what they can touch (plugins), and how work gets triggered (routines).

Have AI put you to work

Her reframe for the security and compliance agent: "We can put AI to work, or we can have AI put us to work in a more effective way." Her SOC 2 bot logs into the compliance dashboard, checks that monitors are green, triages new vulnerabilities into pull requests, and taps her on the shoulder about personnel tasks like account audits and contractor offboarding. She still drives the controls; the agent makes sure the right work reaches her at the right time. The model: an agent's job is not only to do tasks, but to route the tasks only a human can close back to that human, on time.

Trade-offs & Nuance

Simplicity versus power

Grok Bot's simplicity is exactly what she loves and exactly where it is weaker. It looks like a stripped-down mix of iMessage and a terminal, and it is currently single-player: you cannot put a Grok Bot in a group chat, which OpenClaw allowed. She badly wants shared agents back and notes a bot-template-sharing feature is not the same as two people chatting with one shared bot. The trade-off: the minimal surface that made Grok Bot easy to adopt is the same design that dropped the multiplayer capability she misses.

Brevity versus clarity in tone

A model tuned for short, token-efficient output is not automatically better. Claire finds Grok compresses sentences so hard it "says crazy stuff" and becomes hard to parse, which is just a different failure than an over-long, verbose voice. Her fix was to have the agent study her real sent emails and extract her actual voice (short, warm, funny, opens with "hey," signs off with a "C," never an em dash). Even then she only trusts it to write on her behalf for low-stakes messages.

Common Mistakes

Choosing an agent tool on capability alone

The tempting mistake is to pick the most powerful, most autonomous agent platform. Claire's experience is a caution: the more capable OpenClaw lost to the simpler Grok Bot because capability you cannot maintain is capability you do not use. For a team evaluating agent tools, the better question is not "what is the ceiling?" but "what will still be running, unattended, in three months?"

Practical Application

Assign one named agent per job

Instead of one catch-all assistant, stand up separate agents with clear names and narrow scopes: an inbox-and-calendar chief of staff, a PR closer, a support responder. Narrow scope made each one easier to tune and trust, and the name itself becomes a shorthand for its job.

Train an agent on your own voice

Before letting any agent write on your behalf, point it at a real corpus of your sent messages and have it extract your actual voice: length, greeting, sign-off, tone, quirks. Claire got a usable voice profile this way but still limits agent-written messages to low-stakes replies, which is a sensible boundary to copy.

Gate money and code behind approval

For any agent that can spend money or change code, require an explicit approval step rather than full autonomy. Claire's refunds surface an approve/deny button that then executes in Stripe, and code changes arrive as pull requests she reviews. Build the gate before you widen the agent's permissions, not after.

Run a daily PR-closer routine

Her "Look Good To Me" bot runs daily across open pull requests and works the queue: what to merge, close, or rebase, responding to comments and even kicking off Cursor cloud coding jobs to do rebases. She cleared roughly 50 stale PRs in one Friday pass. A PM or eng lead can set up a similar scheduled sweep so review backlog does not quietly pile up.

Print a brief to pull people off screens

TradBot's physical morning newspaper is a portable idea: an agent-generated daily brief delivered somewhere other than a screen (printed, or emailed to a Kindle) so people read it without opening a laptop. The same shape works for a team standup digest or a weekly ops summary when the goal is attention, not another dashboard tab.

Questions to Consider

• For the AI tools your team is evaluating or building, are you judging them on peak capability in a demo, or on how much upkeep they need to still be running unattended in three months?
• Which of your recurring jobs would be better handled by several narrow, named single-purpose agents than by one general assistant, and what is the scope of each?
• Where in your product does an agent take an irreversible action (a payment, a send, a code change) without a human approval step, and should it?
• For any assistant that acts on a user's behalf, how would you capture that user's real voice or preferences instead of a generic default?
• If you built a personal or household agent, would you measure it by engagement, or by how much time it saves the user away from the tool entirely?

Bottom Line

Claire Vo replaced a more powerful agent platform with a simpler one because the powerful one was too much work to keep running, even for an expert. For agentic products, the deciding factors were low-maintenance usability, narrow single-purpose agents, just-in-time permissions, and human approval on risky actions, not the size of the feature list.

Tools & Products

Notable Quotes

"We can put AI to work, or we can have AI put us to work in a more effective way." (Claire Vo)

"The ideal thing for an agent for a home is to get you off your computer and with your family." (Claire Vo)