Grok Bot is building server-synced memory for its AI coworkers

Finding

A new desktop binary adds server APIs for versioned per-Bot profiles and logs, giving the clearest look yet at how Grok Bot could carry memory across runtimes and devices.

How we verified

Methods: reverse engineering.

Version 0.39.0 introduces two previously absent methods in Grok Bot's service contract: ListGrokBotMemoryShards and PutGrokBotMemoryShard. Together, they define a way to retrieve and write versioned memory records associated with individual Bots.

The underlying schema is unusually revealing. Each GrokBotMemoryShard contains a Bot identifier, the execution harness responsible for it, a memory folder and a numeric version. The folder is split into a profile string and a map of keyed logs, both stored as text.

The write request sends a Bot ID and its memory folder to the server. The response returns a version number. The list request contains no filters and returns multiple shards, which suggests the server determines the user's accessible memory set from the authenticated session. The exact scope is not stated in the client.

RuntimeWire compared Grok Bot 0.39.0 with version 0.30.0. None of the memory-shard messages or methods appears in the older binary. The newer build also adds a rollout gate named grok_bot_server_memories, enabled in the client's fallback feature catalog.

RuntimeWire compared Grok Bot 0.39.0 with version 0.30.0. None of the memory-shard messages or methods appears in the older binary. The newer build also adds a rollout gate named grok_bot_server_memories, enabled in the client's fallback feature catalog.

Tested versions:

• Grok Bot 0.39.0

Reproduction

Reproduction does not apply to this reporting (document-driven).

Compare Grok Bot 0.39.0 with version 0.30.0

File hashes

• app(20260904-175745).asar 33,149,055 bytes 219b494cdd69c4b3353fc07509fd6cf590dc9cc3393a92f470352451603566ca

Company response

The company responded to RuntimeWire's questions.