Call PutGrokBotMemoryShard and, on RuntimeWire's reading of the contract, the client sends an agent id plus the entire memory folder, and the server answers with a version number [4]. The request carries no delta [16]. The unit of write is the whole folder, profile string and keyed logs together [3][16], so the server owns history and the client owns only the copy it last uploaded. The version appears in the response and not in the request, which means the client contract as reported does not establish whether a write is checked against the version it replaces [17]. Two harnesses writing the same agent is a server-side question.
The dating is looser than a version number suggests. RuntimeWire's comparison is between packaged 0.30.0 and 0.39.0 [6], nine minor releases apart [14], and it comes from reverse engineering a 33,149,055-byte desktop archive rather than documentation [11]. That places the interface somewhere inside the window without saying when the server side went up or whether the gate is live for anyone [9].
Both memory fields are stored as text [3]. That is the right choice for anything a person will later have to read, and it is what makes the numeric version worth having, because a text folder can be diffed by a reviewer instead of inspected as an opaque blob.
Ask about the verb that is missing. The two operations RuntimeWire names are list and put [1], and the reporting describes no delete and no expiry [15]. Combine that with server-held versioning [2] and the resting behaviour of the system is accumulation.
There is also a question of scope that the binary does not answer. The list request carries no filters and returns multiple shards, from which RuntimeWire infers that the server derives the accessible set from the authenticated session, while noting the client does not state what that set is [5]. The client asks for everything and lets the server decide what everything means.
Whether the feature does the job it exists for comes down to the harness field. A shard binds a folder to an agent id and to the execution harness responsible for it [2], while RuntimeWire frames the interface as a route to carrying memory across sessions, devices and execution environments [12]. Both descriptions hold only if harness metadata is provenance. If it is part of the key, an agent restarted under a different harness reads an empty profile.
None of this waits on activation. The gate grok_bot_server_memories is enabled in the client's fallback feature catalog [7], RuntimeWire identified no desktop call site invoking either operation [8], and RuntimeWire notes that generated RPC definitions often ship ahead of the code consuming them [10]. The company answered RuntimeWire's questions [13]. What version 0.39.0 pins down is the shape of the record: per agent, per harness, versioned by the server, stored as readable text, with no described way to remove it.
