Hello team, Hope you are doing well. Quick updates on the memory work, after some discussion with suryaa. Since the last update, the memory layer has grown into a full loop. Here's what it does now, roughly in the order an agent experiences it:
When a session starts, the first schema or discovery call carries a one-time briefing: what dataverses and datasets exist, which are columnar, and a few ground rules for querying this cluster (project columns instead of SELECT *, backtick reserved names, that sort of thing). The idea is the model gets oriented before its first query instead of learning by trial and error. >From then on, recall is ambient. When the agent touches a dataset —queries it, fetches its schema, samples it — the notes we have about that dataset ride along with the result, and one hop further, notes about its indexes and datatype too. Notes are ranked: things that were verified against the cluster, or that keep proving useful, outrank one-off claims. Delivery bumps a usage counter, and notes nobody uses slowly decay and get archived. So the store is self-cleaning to a degree. There are three explicit tools as well: memory_search for digging through the store by subject, text, or following links between concepts; memory_write for the agent to save a note it thinks is worth keeping; and (new last week) remember_preference for durable query-writing rules — "prefer this dataverse", "never SELECT *" — which never decay and show up in that session briefing. Some capture happens with no model involvement at all. If a query against a dataset fails and a later one against the same dataset succeeds in the same session, the gateway pairs them up and stores the error and its fix as a note on that dataset. Every query outcome also lands in an episodic log, and a distillation pass turns cross-session patterns into notes: queries proven across sessions become grounded knowledge, errors that keep repeating without a fix become warnings. Nothing is ever deleted. Changed facts are superseded, so the history of what we believed and when is queryable. And the write path is narrow: writes are off by default, and when enabled the gateway accepts nothing on that path except inserts into the AgentMemory dataverse — every other statement it sends is still readonly=true. The newest piece is the automation. With writes enabled, each gateway launch runs a short housekeeping pass: create the store if it's missing, refresh the catalog-derived notes so schema changes are picked up, age out dead notes, run one distillation. It's bounded (60s cap, one runner even with several gateways up) and every step degrades gracefully. The goal was "point it at a cluster and it just works" — no cron jobs, no scripts to remember. The obvious question is whether any of this actually pays off, so I'm running a benchmark right now to find out. Same set of ten analysis questions over the Yelp dataset, answered three ways: an agent talking to the query service directly with no MCP at all, the MCP gateway with memory switched off, and the full setup with memory on. Each question runs in a fresh session and I'm comparing token consumption, number of tool calls, and whether the answers are actually right. I'll share the numbers on this thread once I have them. Feedback on the housekeeping on every launch -- convenient default, or too much work for a database tool? Thanks, Vivek
