Grok Bot is xAI’s take on persistent agents: each bot runs on its own cloud Linux machine, keeps context and routines over time, can stay active when your laptop is closed, and can message other bots. That makes it feel closer to a long-lived digital coworker than a chat window. People who had tried it said the async part is the real shift. You stop juggling worktrees and handoffs, and the bots can carry domain-specific context from one task to the next. A concrete example got a lot of attention: using a bot to contact fabric suppliers in Vietnam, negotiate, and get samples made for branded swag.
The core reaction was that this convenience comes with ugly economics and even uglier incentives. Always-on agents burn huge numbers of tokens, which several people read as a sign that today’s product only makes sense if compute gets dramatically cheaper. Others said the larger problem is social cost, not
token cost. A human can now spray serious-looking requests, outreach, and applications at machine scale, while recipients still pay the time cost of sorting them. That turns commerce, recruiting, and basic communication into bot-vs-bot filtering. Several people tied this to what they already see in hiring, where job ads attract floods of generated applicants and companies respond with more automation.
Security and trust dominated the rest of the conversation. The most alarming detail in the demo was not the
agent loop itself but the login model. Grok Bot appears to take over a browser session on its own
VM after the user logs in, which many readers saw as a session-hijacking architecture dressed up as convenience. The consensus was that
prompt injection is still nowhere near solved for anything with meaningful privileges. A low failure rate is still catastrophic when the bot can touch email, source code, bank accounts, or admin consoles. The more credible path people pointed to was separate bot identities with tightly scoped permissions, read-only defaults, and service-side enforcement rather than trusting long prompts or agents.md files as guardrails.
There was also a strong sense that the product itself is not especially differentiated technically. Many said this is basically hosted
OpenClaw or
Hermes with better packaging, persistent VMs, and first-class bot-to-bot communication. That still may be enough. Commercial convenience matters, and a lot of people will pay for a one-click setup instead of wiring together models, containers, browser automation, and monitoring themselves. But that cuts straight into the final objection: vendor trust. Even people open to agents said they would not hand this level of access to xAI or anything tied to Musk. So the thread landed in a pretty clear place. Persistent agents look real and useful for certain messy workflows, but the current way they authenticate, the cost profile they encourage, and the trust assumptions they require all look badly mismatched to the level of power they are being given.
x.ai
Fabric sourcing workflow screenshot
Login handoff screenshot