August 7, 2026. I am connecting VALESKA, the organizational-memory system I am building, to an assistant intended to sort Gmail messages. The useful question is not whether an AI can summarize an email. It is whether the assistant can check an earlier decision, record what it learns, and correct itself without turning repeated observations into apparently independent evidence. A desk clerk who files five copies of one letter has not received five letters.
This week's work makes that connection narrower and the memory operations more useful. It does not yet establish a dependable mail service. I need to keep three things separate in these notes: what the code offers, what the recorded tests exercised, and what remains to be demonstrated through the actual assistant.
A smaller door into memory
MCP, or Model Context Protocol, is a way for an AI application to call tools supplied by another system. In the desktop session examined here, the assistant did not have a general command line or a direct web-request tool. MCP supplied the connection it could use. That is a reason for a particular adapter, not a reason to expose every capability in VALESKA.
The adapter uses a dedicated service identity, restricts project search and recording, and offers no delete tool. This follows least privilege: give a worker the access its job needs, rather than the owner's whole filing cabinet. Those are useful design boundaries. They are not, by themselves, an independent security assessment of every lookup and correction path.
The August 5 commit records passing read checks and scope checks, plus a successful desktop connection and tool listing. That shows the door can be reached. It does not show a complete mailbox session carrying a fact through capture, correction, and later recall. I will not turn a connection log into a deployment claim.
One observation is still one observation
Another August 5 change adds idempotent capture to the memory API, the interface other software calls. Idempotent means a repeated request can return the original record rather than create another. Here it depends on the caller supplying the same retry identifier. It is not automatic recognition that two differently worded notes mean the same thing, nor evidence that simultaneous writes can never race.
The change also adds fetching a record by its identifier and exposes correction tools through MCP. Supersede means keeping the earlier record while linking a replacement to it, instead of quietly rewriting history. The commit reports a live development-database smoke test, a small functional check, covering capture, fetch, supersede, and a repeated request. That is concrete evidence for those operations in that setting.
There is an important unfinished connection. In the scoped Gmail adapter at its cited revision, the retry identifier is kept as descriptive context rather than passed to the API's retry control. Its own documentation warns that repeating a write can duplicate it. I therefore cannot claim the email assistant already inherits the API's tested retry behavior. The two pieces exist; their names do not prove they are joined.
Names must survive the journey
Today's capture-helper fix addresses accented text on Windows. The helper was reading incoming characters using a different encoding, the rules for interpreting text bytes, from the one the sender used. Some accented letters became corrupted before reaching the API. The commit records four previously failing inputs succeeding and checks that stored characters match. This is August 7 work, not a discovery borrowed from a later entry.
For a company evaluating AI memory, these are practical acceptance questions: can staff trace a saved statement, distinguish a correction from a duplicate, and recover names in the languages they actually use? My next test is the whole journey through the scoped assistant, including retries and later recall. Until then, I have useful components and specific test evidence, with an integration gap still visible. That is a more honest research result than calling the mailroom finished.
Historical basis: VALESKA commits b46cdc0 and 7296bfa, August 5, and 1a7ed54, August 7, 2026. Dates use America/Los_Angeles.