How Grok Bot Works

This explains how Grok Bot processes a message end-to-end: the client displays the message immediately and saves it locally with a unique ID so retries are deduplicated, then the message enters a per-conversation queue. Direct user messages interrupt the turn in progress while other events wait; rapid messages are often throttled and grouped. The core loop runs as a durable Temporal workflow: every model call and tool call is a saved step, so work is durable, replayable, and resilient to crashes. Stateless worker processes load conversation state from a database (e.g., Postgres), execute turns, and then park the workflow waiting for a signal; worker claim timeouts let another worker resume stalled steps. Longer-running VM tasks run on Firecracker microVMs whose memory and disk are snapshotted and synced to object storage (S3/R2), making boots and restores fast and allowing disposable, patchable VMs.

Task routing and cost/control are explicit: small edits and quick commands run inline, while heavier jobs spawn helper durable workflows (general, computer, video, cloud coding) that run in background and post results back to the queue. One global SendToUser tool delivers output to clients. Safety is enforced by a separate review model that checks agent actions (shell commands, irreversible ops) and converts dangerous actions into drafts for user approval; external content is treated as data, not instructions. Performance is preserved via a stable prompt prefix for model caching, lazy-loaded skill code with only descriptions in prompts, a minimal main context, and context compaction when histories grow large.