How Grok Bot works: VM, Sand host, gateway, agents, subagents, tools, persistence, and failover

A developer has reconstructed the deployed architecture of Grok Bot, a stateful agent service that runs inside a Linux container, from recovered JavaScript bundles and runtime scripts. The reconstruction, covering 1,804 modules at commit 8740c03c8c6f14f28d1af653c2f0869da021b359, documents a host process (host-main.cjs) that owns conversations and checkpoints each turn, plus a separate exec-daemon providing controlled access to shells, files, terminals, MCP servers, browsers, and virtual desktops. The system is described as a durable coordinator connected to replaceable services, with inference handled by a Cursor-backed service.

Grok Bot is a stateful agent service that runs inside a Linux "box." The model is only one part of it. A host process accepts commands, owns conversations, assembles prompts, calls an inference backend, delegates tool work, checkpoints each turn, and publishes events. A separate execution daemon gives the host controlled access to shells, files, terminals, MCP servers, browsers, and virtual desktops. This document explains the deployed system recovered from the Grok Bot image and the local VM built to preserve and run that image. It keeps those two systems separate. The recovered source describes the original runtime. The clone-lab code describes the recovery VM, its routing, and its known parity gaps. The source reconstruction comes from the deployed host-main.cjs , five auxiliary host bundles, the separate exec-daemon bundle, exact unbundled runtime scripts, protocol reflection, and native binaries. The original TypeScript source maps were not present. Recovered JavaScript bodies are strong evidence of behavior, but they do not recover erased TypeScript annotations or every original import spelling. This document uses four labels: - Exact runtime source is a byte-identical script captured from the image. - Recovered source is a body extracted from a deployed JavaScript bundle. - Derived means a relationship can be reproduced mechanically from recovered files or protocols. - Inference means several sources support an architectural conclusion that no single source states as a contract. The canonical recovered tree contains 1,804 modules. The clean developer-facing projection divides them into sand-host , exec-daemon , dune , and 36 @anysphere/ workspace packages. These counts come from the reconstruction at commit 8740c03c8c6f14f28d1af653c2f0869da021b359 . Grok client or control plane | | authenticated HTTP command | long-lived SSE event stream v +----------------------- Linux box ------------------------+ | | | host-main.cjs | | +---------------- SandHost ---------------------------+ | | | gateway - transcript manager - per-agent runner | | | | | | | | | | | +- inference RPC | | | | | +- Task children | | | | | +- approvals | | | | | +- tools | | | | v | | | | store.db + blob DB + transcript projections | | | +------------------------------------------------------+ | | | authenticated ConnectRPC/WS | | v | | exec-daemon | | +- shell and file operations | | +- PTY and tmux sessions | | +- MCP subprocesses | | +- X11 computer use and screenshots | | | | sand-window-router - per-display exec daemons | | sand-supervisor - host, Xvfb, Chrome, VNC, noVNC | +-----------------------------------------------------------+ | | short-lived access token v Cursor-backed inference service The useful mental model is a durable coordinator connected to replaceable services. host-main.cjs decides what a turn means. The inference backend generates model steps. exec-daemon performs operating-system work. The gateway translates client commands and streams state changes. No one component is the whole bot. The captured deployment ran as a Docker-style container. /tini was PID 1 and started pod-daemon . pod-daemon created processes on demand and parented the long-lived Sand runtime. The observed process tree was: /tini └── /pod-daemon gRPC process creation, TCP 26500 └── sand-exit-watch top-level child ownership ├── supervise-exec-daemon │ └── exec-daemon ConnectRPC 1337, PTY WS 1338 ├── supervise-sand-supervisor │ └── sand-supervisor.mjs │ ├── host-main.cjs HTTP/SSE gateway 1340 │ ├── x11vnc children │ └── fork noVNC router TCP 6081 ├── sand-window-router.mjs TCP 1339 ├── sand-session-sync.mjs ├── browser authentication and cookie helpers ├── desktop :1 primary agent desktop └── desktops :2, :3, :4 forked task desktops pod-daemon is below the hosting control plane and above the application. It is useful for creating a process inside the box, but it is not the conversational API. The client experience enters through host-main.cjs on port 1340. The VM boundary matters. Same-user processes inside the box can often reach loopback listeners, inspect process metadata, and share X11 state. Display numbers separate desktops and browser profiles. They are not separate operating-system users or security principals. The recovered entry point recovered-monorepo-final/src/host/main.ts acquires a host lock, starts SandHost , resolves gateway settings, starts the server, writes discovery data, and installs shutdown handlers. The composition root in recovered-monorepo-final/src/host/sand-host.ts loads extensions, restores transcript state, creates runner services, wires events, and exposes the gateway API. The exact sand-supervisor.mjs script owns a wider dependency graph. It starts or re-adopts the host and desktop processes, writes health snapshots, detects crash loops, and probes the VNC path. supervise-exec-daemon separately restarts the primary execution daemon and checks its listener. The host adds an authenticated ping because an open TCP port does not prove that the daemon event loop can answer. Shutdown and upgrade are coordinated states. The host stops new work, expires pending approvals, checkpoints active turns at safe boundaries, records agents that need continuation, and lets the replacement process consume those resume markers. recovered-monorepo-final/src/host/gateway-server.ts provides HTTP authentication, body-size limits, JSON command routing, health, SSE, avatars, local-exec queues, WebAuthn queues, and upgrade preparation. The dispatch table in recovered-monorepo-final/src/host/gateway-protocol.ts maps command names to methods in recovered-monorepo-final/src/host/host-gateway-api.ts . The ordinary command path is: php POST /api/<command - check the browser Origin and Host policy - verify the bearer token in constant time when auth is configured - enforce the request-body limit and parse JSON - resolve <command in the dispatch table - call the host API adapter - mutate or read the owning subsystem - return JSON The gateway covers messages, transcripts, named agents, rooms, channels, automations, workflows, memories, settings, permissions, approvals, secrets, plugins, skills, box state, and updates. It does not execute model tokens or shell commands. It routes requests to the services that own those operations. sendPrompt returns after the transcript manager durably accepts the prompt. It normally returns { "accepted": true } before inference finishes. Replies arrive as later transcript events over GET /events . This split is why the gateway has clientNonce and promptAcceptanceStatus . A client that times out after sending a prompt cannot know whether the server committed it. The correct retry sequence is: 1. Open and authenticate GET /events. 2. Generate one clientNonce for the logical prompt. 3. POST /api/sendPrompt with the agent ID, prompt, and clientNonce. 4. If the response is ambiguous, call promptAcceptanceStatus. 5. Retry only the identical payload with the identical nonce when needed. 6. Follow transcript events until the turn settles or waits for input. Changing the payload while reusing a nonce is a conflict. Generating a new nonce for an ambiguous retry risks running the mutation twice. createAgent has its own bounded in-memory nonce ledger. It prevents concurrent duplicate creation requests from minting more than one agent while the operation is active. GET /events is a long-lived Server-Sent Events stream with heartbeat, optional gzip, and optional channel filtering. SandHost.wireEvents fans out changes to transcripts, agents, outlines, subagents, asynchronous tasks, memory, automations, workflows, trays, and box state. The client therefore does not poll one "run" object for everything. It sends commands and observes a stream of domain events. This is how prompt acceptance can return fast while thinking, tool calls, child agents, approvals, and final messages continue in the background. The main turn path spans the gateway, transcript manager, runner, inference transport, tools, and persistence: php prompt accepted and enqueued - allocate request ID, trace, and cancellation generation - snapshot privacy mode and agent profile - build the ConversationAction - create main and summarization inference sessions - discover MCP tools - restore or skip a transcript checkpoint - ensure that the agent has a box - compose the tool-bearing agent - stream model steps - text and reasoning parts - tool calls - approval pauses - Task child dispatches - persist step checkpoints - settle as success, awaiting-user, aborted, quiesced, or error - persist final state and emit events recovered-monorepo-final/src/host/runner/prompt-collector-glue.ts combines the visible message with reply context, attachments, recent messages, profile changes, automation markers, trusted hidden context, and unanswered questions. recovered-monorepo-final/src/host/runner/turn-run-shell.ts then creates the model sessions and drives the turn. MCP discovery degrades to no MCP tools if discovery fails. That failure does not erase the conversation. First-token deadlines and retry policy belong to the runner, while transport-specific request and stream conversion belong to the inference layer. Each run has an ownership generation. A cancelled or superseded run cannot write over a newer generation. The transcript manager also checks whether a replacement run can deliver a superseding user message before it cancels the old run. This guard prevents a fast cancellation from stranding the new message. The runner records step checkpoints separately from the final turn state. A widget request, secret request, approval request, or forced upgrade can pause at a committed boundary. After restart or user input, the host resumes from that boundary instead of blindly replaying the whole turn. This is an exactly-once approximation, not a universal transaction across the model, filesystem, network, and third-party APIs. Side-effecting tools still need idempotency. The checkpoint prevents many accidental repeats by recording which step completed before the host continues. recovered-monorepo-final/src/host/extensions/auth/credential-renewer.ts exchanges a renewal credential for a short-lived access token. It refreshes before expiry, coalesces concurrent refresh requests, backs off after errors, and redacts diagnostics. recovered-monorepo-final/src/host/extensions/auth/auth-service.ts keeps the access token in memory and rejects a token that is too close to expiry. recovered-monorepo-final/src/host/extensions/inference/inference-service.ts combines authentication, settings, experiments, default-model selection, and special models for browser or computer work. cursor-session.ts creates the Cursor-backed prompt session. The protobuf client serializes messages, tools, parameters, lineage, and provenance, then converts streamed response parts into typed text, reasoning, tool, metadata, usage, and error events. The runner creates a separate summarization session. General Task children inherit the normal host model selection. Media-review children may force a specialized model. Inference credentials and execution credentials have different jobs. A shell in the box can perform an approved command without receiving the host's renewal credential or short-lived model token. This separation limits how much authority a tool subprocess needs. The user-visible agent list contains durable named agents. The gateway can create, open, update, duplicate, interrupt, and delete them. A named agent owns persistent conversation state, profile, schedules, memory, source identity, box assignment, and permission state. Host startup reloads these agents. A Task subagent is a logical child session created for one delegated job. It is not a new VM and usually is not a separate operating-system process. php parent model calls Task - review the proposed delegation against the parent conversation - create a child SandAgentRunner - assign child transcript and request identities - record parent, type, tool call, title, and lineage - arm the parent's pending wake and a stall watchdog - run the child in the background - publish child status and outline events - on completion, capture the result and free any desktop window - revive the parent with a completion event - parent model reads the result and continues recovered-monorepo-final/src/host/runner/turn-agent-composition.ts creates the child runner with shared host services for inference, box access, MCP, policy, and events. The child gets distinct transcript and request identity plus the parent's provenance. The recovered composition disables nested Task configuration inside a Task child, so the ordinary child cannot recursively fan out another level. recovered-monorepo-final/src/host/runner/subagent-runtime.ts keeps separate maps for live sessions, run promises, metadata, registry status, outlines, watchdogs, pending steering messages, and abort state. Steering records a message, interrupts the current child turn, and starts a new turn on the same child context after settlement. Stopping a child clears the pending wake, interrupts the turn, and suppresses later parent revival. The host can offer several child types: - A general-purpose child handles research or coding in the background. - A browserUse child drives Chrome at the page and element level. - A computerUse child operates the whole X11 desktop through screenshots and input events. - Media-review children use specialized prompts and may select a different model. Computer-use windows are scarce resources. The host allocates a display to the child and releases it when the child settles. Browser use and computer use are separate tools because DOM-level automation is faster and less disruptive, while pixel-level control works with native applications and hostile web interfaces. The recovered host also exposes cloud-agent launch and watch tools. A cloud coding agent is not a durable named Sand agent and is not an in-process Task child. It can run on a separate remote worker or VM with its own checkout, generated branch, transcript, status, and artifacts. The parent watches or imports its result through the cloud-agent service. The three categories have different ownership: | Category | Runner location | Machine | Durable state | How completion appears | |---|---|---|---|---| | Named Sand agent | SandHost | Its assigned box | Per-agent directory, SQLite, and blobs | Direct transcript and SSE updates | | Task child | Another SandAgentRunner in the same host | Reuses the parent's box, with an optional fork display | Child conversation state plus live runtime maps | Completion wake revives the parent | | Cloud coding agent | Remote cloud-agent service | Separate worker or VM | Remote transcript, branch, and artifacts | Parent watches and imports the result | The generic Task package contains richer resume and cloud-placement concepts than the recovered Sand background adapter visibly persists. The code proves steering a live Sand child and delivering its completion. It does not, by itself, prove that a completed child's private runner can resume after a host restart. That behavior needs a live-runtime test before publication as a durable guarantee. The host composes separate review providers for host shell, box shell, MCP, computer use, automation writes, cloud-agent operations, and Task launch. A review can allow an action, block it, or pause the turn for the user. php model proposes an action - surface-specific policy and auto-review - allow: execute the exact action - deny: return the refusal - needs user: persist approval request and pause - gateway receives resolution - resume from the checkpoint or expire the request The runtime permits only one pending approval at a time for an audited turn. Task launch is reviewed in the real parent context before the child sees the delegated prompt. The child must still pass review for each concrete shell, MCP, browser, or desktop action it proposes. Execution-side permissions merge administrator, user, repository, and hardcoded policy. The daemon checks parsed commands, redirects, delete protection, sandbox availability, workspace access, extra paths, and network policy. Approval is best understood as permission for one exact proposed action, not a permanent grant for a tool category. exec-daemon starts two authenticated servers. The HTTP ConnectRPC server exposes execution and control services. The WebSocket server exposes PTY operations such as spawn, attach, input, resize, list, and terminate. Optional tmux services keep terminal sessions alive across individual requests. The control service covers health, capabilities, direct file operations, diffs, artifacts, environment refresh, plugin operations, and MCP loading. The execution service carries typed streaming envelopes to registered resource executors. Shell, files, MCP, and computer use share transport, but each has its own executor and policy. Shell sessions can persist executable Bash, zsh, or PowerShell state. Before each command, the daemon unsets old conversation and agent-store variables and injects the current request's server-derived values. This ordering prevents an older shell snapshot from impersonating a later conversation. The sandbox policy describes workspace read or write access, read boundaries, extra read-only and read-write paths, protected mappings, temporary-directory rules, and network rules. Hardcoded policy protects Git hooks, agent settings, SSH material, and other executable configuration. If sandbox enforcement is required but unavailable, a safe replica must fail closed rather than run unrestricted. MCP servers run as workload processes behind the execution daemon. The host discovers their tools for each turn and presents those tools to the model. MCP has its own sandbox policy and approval path. A long-lived railway mcp or XcodeBuildMCP process in the observed box was workload state, not a boot daemon. Each desktop is an Xvfb display with a window manager, compositor, dock, VNC server, and a Chrome profile. For display N = 2 , the exact runtime maps ports as follows: exec ConnectRPC: 14000 + N PTY WebSocket: 13600 + N VNC: 5900 + N Chrome CDP: 9222 + N recovered-monorepo-final/src/host/box/box-windows.ts allocates the display and mints an owner token. Requests carry x-sand-display . Fork routes also carry x-sand-window-owner , which must match the token bound to that display. sand-window-router.mjs selects either the primary daemon or the daemon for that display. Local computer use sends X11 input and captures screenshots. Browser use talks to the browser at a page level. sand-session-sync.mjs connects to live Chrome instances over loopback CDP and mirrors cookies, including HttpOnly cookies, plus localStorage. It does not mirror IndexedDB. A per-display busy lease delays page reloads while computer use is acting. Session sync makes login state convenient across an agent's windows, but it expands the authentication trust domain. The display token protects routing. It does not turn each display into a separate user account or filesystem boundary. Each durable agent has a SQLite store.db with key-value state, legacy blobs, and transcript entries. A separate strict SQLite blob database stores content-addressed conversation payloads. A root in the agent state points to the reachable payload graph. php store.db +- current root and transcript metadata | +- conversation-blobs.db | +- transcript JSONL journal and mirror +- search-index.db profile, memory, routines, workflows, and store snapshots +- box-store manifest and immutable uploaded objects The JSONL transcript and search index are projections. The host can rebuild them from canonical agent and blob state. Search corruption must not decide whether a conversation exists. Database recovery quarantines damaged files, salvages rows that can be read independently, verifies replacements, and only then installs them. The blob store uses Node worker threads. AgentWorkerPool creates one worker per blob-database path, up to its capacity, and evicts idle workers. The worker owns blob reads, writes, checkpoint-root lookup, stale-root cleanup, garbage collection, legacy retirement, flush, and close. These are storage workers. They are unrelated to model Task children, which are SandAgentRunner objects in the host process. Live SQLite files are captured through database-safe immutable snapshots. Box-store hydration uses manifests and an explicit completeness state. Deletion propagation starts only after a trusted baseline exists, which prevents a partial download from being mistaken for an authoritative empty state. Profiles use atomic profile.json updates. Memory is split into agent, shared-user, and project scopes with single-writer shards. Automations store definitions and a bounded run history. Workflows merge user, managed, and plugin-owned definitions without discarding ownership. Agent identity, source identity, conversation identity, box identity, Task child identity, and automation-run identity are distinct. Treating any two as the same ID would break routing or persistence isolation. Schedules, listeners, and backend events feed a trigger hub. The hub creates a durable wake for a named agent and sends it through the ordinary turn queue. The turn gets automation provenance and a trusted or untrusted origin marker, then uses the same runner, tools, approvals, checkpoints, transcript, and inference path as an interactive prompt. At startup, the host reconciles definitions, rearms pending wakes, and retries acknowledgements that did not complete. During upgrade, it suspends new scheduler wakes while backend events remain queued for the replacement process. Deleting a named agent also deletes its schedules. There is no separate "automation agent runtime." Automation is another producer of durable turns. The captured /dev/vda was a 128 GiB ext4 container filesystem. It had no partition table, bootloader, or kernel, so it could not boot as a VM. The clone uses a Debian 12 x86-64 wrapper disk to supply the missing operating-system pieces. Apple Silicon Mac └── QEMU x86-64 with TCG translation ├── writable Debian 12 wrapper disk ├── captured ext4 disk attached read-only └── reconstructed Docker overlay ├── 66 captured lower layers, read-only ├── /var/lib/grok-clone/upper, writable └── /mnt/grok-container, merged chroot grok-clone-mount.service reconstructs the overlay and mounts /proc , /dev , and /sys into the merged tree. grok-pod-daemon.service runs the captured /tini and pod-daemon . grok-supervisor.service reads the protected captured environment, enters the chroot, drops to UID and GID 1000, and executes the original Node runtime and sand-supervisor.mjs . The original evidence disk remains read-only. Local transcripts and runtime changes land in /var/lib/grok-clone/upper . This design preserves the capture while giving the restored application a writable filesystem. The supervisor environment contains credential-bearing state and is stored as a root-owned mode 0600 NUL-separated file. The launcher reads it before chroot , sets the box identity, drops privileges, and passes it directly to the process. The scripts do not print the values. At the 2026-08-18 runtime audit, the clone had the restored named agents, gateway, transcripts, external inference, pod-daemon, window router, and several desktop components. Single-turn and multi-turn conversations worked. The audit did not prove full platform parity. The main exec daemon, per-window exec daemons, PTY WebSockets, session sync, cookie persistence, and one desktop were missing or not validated at that capture. Current clone-lab scripts have continued to change after that audit. For example, the current window-router launcher deliberately points its primary route at local port 1337, while the noVNC bridge maps restored display 4 to both historical and local tokens. Those scripts express the intended current topology. They do not, by themselves, prove that every daemon is running in a live VM now. QEMU uses software CPU translation because the guest is x86-64 and the Mac is Arm. Short turns work, but CPU-heavy tool runs can starve the emulated gateway. Running the disks on an x86-64 KVM host would preserve the binaries and remove most of that translation cost. The clone lab keeps the original gateway address stable while allowing a local VM to serve requests. A streaming proxy on the original box selects either the original host-main.cjs or an SSH path to the local clone. php client - original stable address :1340 - firewall redirect :21341 - streaming gateway proxy +- original host-main :1340 - reverse SSH :21340 - Mac forward :31340 - local VM host-main :1340 An authenticated SSE connection pins the selected backend. Concurrent commands use the same backend while that event stream is open. This affinity prevents a client from sending a prompt to the local transcript while listening for its result on the original host. Failover is active/passive. It never mirrors a mutating request and never replays a request that may have been partially sent. Both gateway processes may be alive, but only one receives a given client session. This rule matters because both copies use the same logical agent IDs. Mirroring would create duplicate tool actions and divergent transcripts. Gateway failover covers the HTTP and SSE service on port 1340. It does not automatically cover pod-daemon, exec ConnectRPC, PTY WebSockets, window routing, noVNC, raw VNC, Chrome CDP, Docker, or unknown provider services. Gateway parity is not platform parity. The system relies on layered capabilities rather than one universal login: - The external gateway checks browser origin and bearer authentication. - Internal execution RPC checks a daemon bearer token. - Fork-window routes require a display and owner token. - Model access uses a short-lived token held by the host. - Shell and MCP actions pass policy and approval checks. - The sandbox constrains filesystem and network access when the platform supports enforcement. - The VM or container remains the final boundary for same-user processes, X11, loopback services, and a browser launched without its own kernel sandbox. The observed original box also exposed an unauthenticated Docker HTTP API on port 2375 and an unidentified plaintext gRPC listener on port 50052. Neither belongs in a safe public clone. Docker API access is close to container-administrator access. The unknown service must remain blocked until its owner and authentication contract are identified. Raw VNC was loopback-only and had no VNC password. Its protection came from network reachability and the SSH or noVNC boundary. CDP, daemon tokens, owner-token files, process environments, and X sockets also need loopback binding or stronger OS isolation. Several mechanisms combine to make the product look like one persistent agent: 1. The gateway accepts commands fast and SSE streams every later state change. 2. Durable named agents retain transcripts, profiles, memory, workflows, and box state across turns and host restarts. 3. Step checkpoints let approvals, secret requests, widgets, cancellations, and upgrades pause without restarting the entire turn. 4. Task children work in the background and wake the parent when they finish. 5. Persistent shells, MCP processes, browser profiles, cookies, and desktops let tools continue where an earlier turn stopped. 6. Automations enter the same queue as user prompts, so unattended work follows the same persistence and policy rules. 7. Active/passive routing keeps commands and events on one stateful gateway copy. The apparent single bot is therefore a coordinated set of state machines. The conversation, model stream, Task children, approval request, shell, desktop, and automation can each be in a different state. SandHost joins them through stable identities, checkpoints, event fanout, and explicit ownership. client opens /events client sends sendPrompt with clientNonce gateway authenticates and durably accepts transcript manager emits the user message runner restores context and builds the prompt inference streams text runner checkpoints and persists the assistant message SSE delivers transcript changes to the client model proposes Shell host and execution policy inspect the exact command review requires the user runner checkpoints and emits an approval request client resolves it through the gateway runner resumes exec-daemon runs the command under the computed sandbox policy typed output returns to the model model finishes and the transcript settles parent calls Task type=browserUse parent-context review accepts the delegation host creates child runner and child transcript identity child receives browser tools and a routed Chrome session child works while parent is suspended on a pending wake child result and outline are stored host revives the parent parent reads the result and answers the user host loads automation definitions trigger hub rearms an unfulfilled wake wake enters the named agent's ordinary queue runner marks automation provenance in the prompt turn uses the normal inference, tools, approvals, and checkpoints result is persisted and acknowledgement is retried until settled The main source roots used for this explanation are: - Gateway and composition: src/host/main.ts , sand-host.ts , gateway-server.ts , gateway-protocol.ts , and host-gateway-api.ts . - Turns: src/host/extensions/transcript/transcript-manager.ts , turn-runtime.ts , src/host/runner/sand-agent-runner.ts , turn-run-shell.ts , and prompt-collector-glue.ts . - Task children: src/host/runner/subagent-runtime.ts , turn-agent-composition.ts , and tools/sand-subagent-management-tools.ts . - Inference: src/host/extensions/auth/ , src/host/extensions/inference/ , and packages/chat-inference-proto/dist/ . - Execution: exec-daemon/src/ , packages/agent-exec/dist/ , packages/local-exec/dist/ , and packages/shell-exec/dist/ . - Persistence: src/host/extensions/session/ , src/host/agent-isolation/ , src/host/extensions/content-search/ , and src/host/extensions/box-store-sync/ . - Exact deployment scripts: exact-runtime-source/runtime/ . Operational VM and failover claims come from wtfsayo/grok-bot-clone-lab at commit 2b1c877038b56a35b7643bf5082ae88a60f7b685 , especially docs/GROK-BOT-CLONE-HANDBOOK.md , docs/GROK-BOT-DAEMONS-AND-INGRESS.md , systemd/ , and failover/ . Those documents sanitize tokens, private addresses, agent IDs, transcripts, and disk locations. The recovered system does not include the hosting provider's external control plane, the original host's vsock service, or a bootable source disk. Some native components can be described only through symbols, protocols, literals, call graphs, and disassembly because their source and debug metadata were absent. The reconstruction is still enough to explain the application architecture with high confidence: a durable host owns conversation semantics, a gateway owns client transport, an inference service owns model transport and tokens, an execution daemon owns operating-system effects, and supervisors keep the box and its desktops alive. The Grok Bot experience appears when those parts share identities, checkpoints, and events without sharing more authority than each part needs.