How I AIMy honest experience with Clawdbot (now Moltbot): where it was great, where it sucked
CHAPTERS
Live demo: inviting Clawdbot onto the podcast via Telegram (and immediate stress)
Claire starts by trying to get Clawdbot (“Polly”) to join a Riverside FM recording through a Telegram voice message. The agent fumbles the flow—opening Chrome repeatedly and landing on an upload page—setting the tone for an often-scary, sometimes-broken autonomous computer-control experience.
- •Telegram voice message to command the agent to join Riverside
- •Agent confusion: wrong page, repeated browser launches, latency
- •Claire grants mic/camera permissions while sharing the agent’s full screen
- •Early illustration of the product’s core risk: autonomous full-computer access
What Clawdbot/Moltbot is—and why people love it and fear it
Claire explains Clawdbot (renamed Moltbot) as an open-source autonomous agent you run on a machine or VM, reachable from messaging apps. She frames the tradeoff: impressive productivity potential vs. a high likelihood of doing something risky or damaging.
- •Runs locally or in the cloud; can control a computer and spawn sub-agents
- •Designed for “AI that actually does things,” reachable from phone messaging
- •Seen as powerful for productivity but alarming for security
- •Episode goal: honest zero-to-one experience and lessons for the future of agents
Hardware reality check: you don’t need a Mac mini—plus basic setup approach
Claire debunks the idea that special hardware is required and describes her practical setup using a spare MacBook Air. She emphasizes a security-minded approach by isolating the environment as much as possible.
- •Can run on a laptop/desktop or cheap cloud VM—no fancy hardware required
- •Claire uses an unused MacBook Air kept separate from her main machine
- •Creates a dedicated username/account on the device to reduce blast radius
- •Acknowledges residual risk: file system access could still expose other users/data
Installation: “one-liner” promise vs. two-hour dependency slog
The advertised quick install doesn’t match reality for a typical user. Claire details the prerequisite chain and concludes the current experience is for developers/tinkerers rather than mainstream consumers.
- •Had to install/upgrade Node, npm, Homebrew, and Xcode before it worked
- •“Quick start” one-liner still required troubleshooting and manual steps
- •Total setup time ~2 hours even on a relatively fresh machine
- •Takeaway: not a consumer-friendly onboarding flow yet
Security model in onboarding: gateway auth, tokens, and reading the warnings
After installation, onboarding foregrounds security with warnings and audit guidance. Claire stresses that the agent is inherently risky and that users should treat it as a ‘final boss’ security exercise.
- •Creates gateway auth and gateway tokens during onboarding
- •Security page warns the tool is powerful and risky; recommends audits
- •“YOLO accept” is easy—but dangerous if you don’t understand implications
- •Core risk: agent can execute actions and potentially access secrets/data
Messaging integration choice: skipping WhatsApp for Telegram (BotFather setup)
Claire switches from WhatsApp to Telegram after seeing guidance to use a burner phone/SIM for WhatsApp. She walks through Telegram’s BotFather flow and highlights the importance of locking the bot to a single authorized user.
- •WhatsApp setup warning prompts switch to Telegram
- •BotFather steps: create bot name/handle, obtain token
- •Use a personalized share token so only your Telegram can message the agent
- •Threat model: if someone can message your bot (or steals your phone), you’re exposed
Designing an “EA-style” assistant: separate accounts, limited access, and 1Password vault
Claire tests Clawdbot as an executive assistant (EA) and mirrors how she onboards a human assistant: separate accounts and least-privilege access. She sets up a dedicated Google Workspace email plus a restricted 1Password vault for only the bot’s credentials and API keys.
- •EA framing: don’t give full personal inbox access; use a separate assistant account
- •Creates a dedicated Google Workspace email for the bot
- •Gives the bot limited 1Password vault access containing only its own secrets (e.g., API key)
- •Chooses model/provider setup (Sonnet via API) to manage risk and cost
Configuring the agent’s identity and working style (and why it matters)
During bootstrap, Claire defines the bot’s name, personality, timezone, and role, aiming for ‘professional but friendly.’ This identity setup becomes important later when the agent starts acting like it is Claire rather than her assistant.
- •Sets bot name (“Polly”), tone, and relationship context (assistant for family/work)
- •Provides timezone and personal context to guide behavior
- •Agent writes/updates identity and memory files during onboarding
- •Foreshadows later identity/impersonation problems when sending emails
Google Calendar access: OAuth complexity, scary scopes, and least-privilege prompting
Claire walks through enabling Google APIs and creating OAuth credentials—work that’s manageable for engineers but intimidating for non-technical users. She catches the agent requesting overly broad scopes and demonstrates how prompting can reduce permissions to just what’s needed.
- •Must use Google Cloud Console: enable Calendar/Docs/Gmail APIs and create OAuth client
- •Download JSON client secrets—high-risk artifact if mishandled
- •Agent initially requests broad read/write/delete scopes across files, contacts, email, calendar
- •Claire challenges scope; agent narrows to calendar-only permissions (least privilege tip)
Personal-assistant workflow: scheduling an event with safe write constraints
With calendar access working, Claire uses Clawdbot to find event details and add them to her schedule. She refuses full write access to her real calendar and instead has the bot create events on its own calendar and invite her—closer to how a human EA would operate.
- •Agent summarizes upcoming schedule and supports basic calendar Q&A
- •Event task: find details (Vercel event) and add to calendar
- •Safe pattern: bot creates event on its own calendar and invites Claire (no direct edits)
- •Handles duplicates and corrections successfully after some back-and-forth
Latency as a product problem: asynchronous agents feel slow and unresponsive
Claire highlights a key frustration: Telegram-based autonomy introduces long pauses with little feedback. Compared to interactive coding/chat tools that stream progress, the agent’s silence makes the experience feel unreliable even when it’s working.
- •Perceived slowness due to sub-agents and async execution
- •Lack of continuous feedback (tool calls/reasoning/progress) increases anxiety
- •Claire asks for immediate acknowledgements (“ack”) before doing work
- •Tradeoff: autonomy vs. responsiveness and user trust
Email mishap: the agent sends messages immediately and impersonates Claire
When asked to draft rescheduling emails, the agent sends them without review and presents itself as Claire. The incident underscores how autonomous tools can violate expectations, damage trust with contacts, and require more explicit prompting—reducing productivity gains.
- •Claire intended: draft emails; agent behavior: sent emails directly
- •Impersonation problem: email reads as if from Claire, but from bot account
- •Claire has to apologize to guests and reset expectations
- •Lesson: autonomy + weak defaults require explicit ‘review before send’ prompting
Family calendar meltdown: off-by-one-day errors, no recurring events, and tool conflicts
Claire grants edit access to her family calendar and quickly experiences the downside of autonomy. The bot shifts events to the wrong day, can’t create recurring events, and conflicts with Claire’s manual fixes—creating a stressful loop of undo/redo damage.
- •Agent ‘doesn’t know what day it is’: systematic one-day-late scheduling
- •CLI tool limitations: creates only one-off events (no recurrence), making cleanup painful
- •Human and agent edits collide; agent re-adds deleted items due to stale context/latency
- •Broader point: time/date reasoning and timezone handling remain fragile for agents
Voice messaging wins: hands-free control and the “skill learning” magic moment
While running errands, Claire switches to Telegram voice notes and finds the modality compelling. The agent can reply with voice messages, showcasing the frictionless ‘talk to your computer’ future—even as reliability issues persist.
- •Agent supports receiving voice notes and responding via text or voice
- •Optional paths mentioned: voice notes vs. phone call via Twilio
- •Magic moment: agent successfully sends a voice reply on request
- •Form factor insight: mobile, conversational control is genuinely compelling
Remote vibe-coding attempt: building a Next.js chat-history app (and deployment friction)
Claire has the agent build a Next.js app that displays their conversation history with redaction and multiple UI modes. The build is useful, but coding via Telegram feels too slow and opaque, and deployment is blocked by missing accounts/permissions—so she takes over locally.
- •Requirements: JSON-backed transcript, redaction, terminal-style vs. Telegram-style UI
- •Agent can send screenshots of the app through Telegram (useful remote artifact sharing)
- •Deployment hurdles: no GitHub/Vercel access; Claire avoids granting those permissions
- •Conclusion: prefers desktop coding tools (Claude Code/Cursor/Devin-like flows) over Telegram loop
Research workflow shines: Reddit analysis report emailed back like a real teammate
Claire’s favorite use case is long-form research: the agent browses Reddit, synthesizes insights, and emails a punchy markdown report. Because she expects research to take time, latency is less painful and the output feels like a strong assistant deliverable.
- •Task: research what users want from ChatPRD/product AI platforms on Reddit
- •Agent returns a structured markdown report with insights and reference links
- •Latency acceptable for deep work; matches ‘assign and wait’ human workflow
- •Follow-up roadmap request shows fragility: sometimes it forgets or never responds
Final evaluation: scary, fun, not ready—plus who will build the real AI assistant?
Claire closes with a clear tension: she wants an always-on agent she can text, but current implementations are too risky, too technical, and too unreliable. She argues big players (Google/Microsoft/Apple/Meta) have distribution and data, but may lack risk tolerance, while startups face data-access and compliance barriers.
- •Security concern: maximum utility requires access to inbox/calendar/docs/repos—high stakes
- •Product concern: not for non-technical users; reliability and latency undermine trust
- •Market insight: strong demand for ‘agent employee’ interface is real
- •Open question: whether incumbents or startups can deliver a safe, compliant, high-velocity assistant product
