I'm not an AI sceptic, that ship has sailed. Not since realising that Opus 4.5, with strict supervision, can produce better code than me. But Moltbot feels like the AI equivalent of primate-themed NFTs. Hand an AI agent your API keys? Email accounts? And shell access? Then let it wake itself up via cron to "do things" on your behalf. What could possibly go wrong?
Remember the Bored Apes and the whole NFT hype? A toy novelty dressed up as inevitable innovation, with 'everyone will be doing this soon' narratives obscuring real debate over whether anyone should be.
Not a Skeptic, But Not Convinced
Let me be clear about where I'm coming from. I'm not an AI sceptic. That ship has sailed. I use AI every day. Opus 4.5 under strict supervision produces better code than I can. The question isn't whether we should use AI. The question is whether we're using it at the right layer.
My day job is tech lead for a data and integrations team. Earlier in my career I worked with the Kendraio Foundation on interoperability, building systems that help data flow between services in structured, reliable ways. This background gives me a particular lens on what Moltbot is doing. That lens says: we've already solved many of these problems, and the solutions were boring on purpose.
When I see people giving an LLM access to their email and shell, scheduling it to wake up autonomously and "handle things", I don't see innovation. I see the same old integration problems we've been solving for decades, now wrapped in non-determinism and a security nightmare.
The Hidden (and not so hidden) Costs
The Moltbot discourse is heavy on enthusiasm and light on accounting. Let's talk about what actually happens when you run one of these things.
Financial costs are unpredictable. Token costs vary wildly based on input complexity. A simple task might cost pennies; parsing a complex email thread could burn through dollars. Failed attempts consume the budget with zero output. Debugging costs tokens because the AI has to examine its own errors. DataCamp estimates $10–150/month depending on usage, but that assumes things work. Multi-attempt workflows? Nobody's budgeting for "tried 47 times before success." Traditional integration costs are predictable. These are not.
Security costs are severe. The security picture here is genuinely alarming. Researchers have found hundreds of exposed Moltbot instances on the open internet. API keys, OAuth tokens, conversation histories: all accessible to anyone who knows where to look. In one demonstrated attack, a researcher sent a prompt injection via email to a Moltbot instance. The AI read the email, believed it was legitimate instructions, and forwarded the user's last five emails to an attacker address. It took five minutes.
The core issue isn't implementation bugs (though there are plenty). It's architectural. You're handing API keys to an unsupervised agent that processes untrusted input. Credentials are stored in plaintext JSON and Markdown files. Audit trails become "the AI decided to", which isn't going to fly in an enterprise environment where SOC2 or ISO compliance matters. Credential rotation becomes a nightmare when you don't know what the AI might have done with them. One security firm found that 22% of their enterprise customers have employees actively using Moltbot, likely without IT approval.
Operational costs compound silently. Context drift over extended runs means the AI gradually loses the thread of what it's supposed to be doing. Non-deterministic behaviour creates chaos in systems expecting predictability. Errors compound without human checkpoints. You don't discover the problem until the damage is done.
What Already Works
Here's the thing nobody in the Moltbot discourse wants to talk about: traditional integration patterns already solve deterministic workflow problems. They do it well. They've done it well for years.
Structured data transformations. Predictable API orchestration. Webhook-based triggers. Scheduled data syncs. Message queues. ETL pipelines. These aren't exciting, but they're deterministic, debuggable, and auditable. When something fails, you know what failed and why. When something succeeds, you can reproduce it.
There's no good reason to replace deterministic workflows with non-deterministic alternatives. "The AI handles it" is not an improvement over "the cron job runs this integration at 3am." The cron job will do the same thing every time. The AI might do something different because the phrasing of an email changed or because it hallucinated a slightly different interpretation of your intent.
Where AI Actually Adds Value
This isn't an argument against AI in integrations. It's an argument for using AI where it actually helps.
AI enables automations that weren't previously possible. The key is recognising what those are.
Unstructured data processing. Parsing inconsistent PDFs, emails, and documents. Extracting structured information from variable-format vendor data. Handling inputs that don't conform to expected schemas. Before LLMs, this required either brittle regex hell or expensive human processing. Now there's a middle option.
Natural language interfaces. Processing natural language inputs as workflow triggers. Intent classification for routing. Human-friendly interaction layers where the human is genuinely in the loop. "Hey, can you pull last week's sales data and send it to finance?" is a valuable capability when a human is there to confirm the action before it happens.
The key distinction: AI for unstructured-to-structured transformation, not for deterministic execution that traditional tools already handle reliably.
Some use cases may benefit from non-deterministic execution layers. Genuinely novel situations where the appropriate action isn't predictable. But this shouldn't be the default approach. It should be the exception, applied carefully, with human oversight.
The Pragmatic Path Forward
Before adding AI to an integration, ask two questions:
Does this undermine robustness? Consider the costs (financial, security, operational) against what you're gaining. If you're replacing a reliable cron job with an AI agent because it's cooler, you're making your system worse. If you're adding attack surface, non-determinism, and unpredictable costs to a workflow that worked fine without them, reconsider.
Does this unlock something previously impossible? Specifically: does this handle unstructured data or natural language in ways traditional integrations can't? If yes, there's potentially real value. If no, you're adding complexity for its own sake.
If the answer is yes to the first question and no to the second, stop.
The actual opportunity here is boring. Keep using traditional integrations where they work. Add AI where it unlocks new capabilities through unstructured data handling. Don't replace robust patterns with fragile ones just because AI is available.
We don't need to choose between "AI for everything" and "AI for nothing." We need engineering judgment about where it actually improves outcomes.
The Moltbot excitement feels like people rediscovering that automation is useful and then choosing the least reliable form of automation available. Yes, you can give an LLM access to your shell and let it wake up via cron to "help." You can also write the shell script. The shell script will work the same way every time.