Vertex AI Agent Engine Memory Bank: Prove Scope and Recall

Vertex AI Agent Engine Memory Bank can accept source events, generate a memory, and return it later. That sequence is useful, but a successful SDK call does not prove that the next agent turn received the right memory for the right identity. The reasonable default is to treat long term memory as a small evidence pipeline. Wait for the generation operation to finish. Check the reported action. Retrieve under the exact intended scope. Correlate the visible memory with the source event or revision. Keep similarity quality separate from basic persistence. Confirm that updates and deletions have converged before injecting a fact into a prompt. This article turns those steps into a content free health receipt. An executable eight case fixture produces two healthy cases, one still working, one degraded retrieval case, and four failures. The point is not to grade Google's service. It is to make your own integration distinguish pending work, a valid no op, a query miss, stale state, cross scope visibility, and a lifecycle mismatch. A completed request is only the first receipt Google's current Memory Bank overview separates sessions from long term memory. Session events provide source conversation history. GenerateMemories can extract and consolidate durable facts for a scope, while CreateMemory lets an agent write a fact directly. Later, RetrieveMemories supplies scoped memory to another turn. That flow has several observable boundaries: 1. the source event exists; 2. memory generation has started; 3. its long running operation is done; 4. the response says a memory was CREATED , UPDATED , or DELETED ; 5. the current resource is visible under the intended scope; 6. the appropriate retrieval path finds the expected revision; 7. the consuming agent actually uses only evidence that passed those checks. The generation documentation explicitly describes GenerateMemories as a long running operation. A completed response can report three different actions. CREATED means a new memory was added. UPDATED means consolidation changed an existing memory. DELETED means newer source information invalidated an existing memory. Do not flatten those actions into one Boolean called memory saved . More importantly, do not flatten an unfinished operation into failure. If operation.done is false, the work is still pending. Poll the existing operation within a deadline; starting another generation request merely because the first has not finished can create duplicated work or confusing consolidation. A minimal receipt can avoid storing conversation content: Hashing an operation or scope identifier reduces incidental exposure in a health log; it does not make a weak identifier safe. Keep raw user IDs, facts, prompts, credentials, and access tokens out of the receipt. The application still needs a protected mapping when an operator must investigate one failure. Exact scope and current revision must agree Memory Bank maintains an isolated collection for each scope. The current fetch documentation says scope based retrieval returns only memories with an exactly matching scope, independent of key order, and that a memory's scope is immutable. That is a strong service boundary, but your integration still chooses the scope. A mapping bug can ask for the wrong user, project, tenant, or agent identity and receive a technically valid result. Health therefore needs two comparisons: request scope: the exact normalized scope the task intended; returned scope: the scope attached to every visible memory. Any mismatch blocks injection. Relevance cannot override identity. A highly similar fact from another user is not a degraded result; it is an isolation failure. Revisions provide a second comparison. Google's revision documentation says memory creation and modification save immutable revisions by default. A current memory is the consolidated state; its child revisions preserve historical states and, for generated memories, the extracted and consolidated steps. Attach a content free source ID using revision labels or application metadata when your contract permits it. Then compare the expected source revision with the revision visible after generation. If the operation reports UPDATED for evt 106 but retrieval still exposes evt 099 , the safe state is stale or uncertain. It is not healthy merely because the fact sounds plausible. Deletion needs its own rule. The documented generation response can say DELETED , and fetching that deleted memory should return 404 . Revision resources remain inspectable for a limited recovery window after parent deletion. If a supposedly deleted fact remains visible to the consuming path, keep it out of context and reconcile the lifecycle. Conversely, a 404 after a documented deletion is evidence of convergence, not an availability incident. List and similarity search answer different questions Memory Bank exposes several fetch paths: Get retrieves one fully qualified memory resource; List enumerates memories in the bank and supports filters; scope based Retrieve returns all memories for an exact scope when no similarity parameters are supplied; similarity Retrieve ranks memories within an exact scope for a query. These paths should not share one undifferentiated memory found metric. Suppose GenerateMemories completed with UPDATED . A scoped list shows the expected current revision, but a similarity query returns no rows. The persistence plane is healthy: the memory exists under the intended identity. Query retrieval is degraded for this canary. Possible causes include a poor test query, an unexpectedly weak semantic match, filtering, or a top k choice. Treating the miss as lost persistence sends the operator toward the wrong repair and may provoke a duplicate write. The reverse conflict is more serious. If similarity retrieval returns a candidate but the current memory cannot be found through the expected scope or resource evidence, do not inject it. Search relevance is not a substitute for provenance and freshness. A useful canary therefore performs two reads: Do not use production memory text as a synthetic canary. Create a dedicated test identity, a non sensitive fact, an expiry policy, and a cleanup receipt. Keep canary traffic out of real user scopes. Replay eight awkward receipts before trusting green The artifact accompanying this article is memory bank health audit.mjs . It contains no credentials, prompts, or customer facts. It classifies eight synthetic operation, scope, revision, list, and retrieval receipts: The executed output is: Fixture case Verdict Why async pending working The generation operation is not done; poll it without duplicating work. clean write healthy Action, exact scope, revision, list, and retrieval agree. no topic noop healthy No eligible topic was expected, and no mutation appeared. similarity miss list hit degraded Persistence and freshness pass; the query path misses. wrong scope result fail Visible memory belongs to another scope. stale revision fail The visible revision does not match the source event. deleted still visible fail The operation says deleted, but consuming reads still expose the memory. created not fetchable fail Creation completed, but the expected memory is absent from scoped inventory. The no op case matters. Memory generation extracts only information that matches configured topics. An operation can finish without generating a memory when the source contains nothing eligible. If your test contract expected no durable fact, zero generated memories is healthy. A detector that pages on every empty response will pressure teams to persist noise. The query miss case matters for the opposite reason. The fixture marks it degraded, not failed, because a current exact scope list hit proves that persistence survived. The operator can tune the query, inspect filters, or use scoped retrieval without rewriting the memory. The four failing cases are intentionally not combined into “memory error.” They imply different safe actions: stop injection and review identity mapping for a scope breach; inspect revisions or wait for convergence for stale state; quarantine a fact whose deletion has not converged; verify names, scopes, and actions before retrying a completed but invisible write. This decision precedence keeps a relevant but unsafe fact from winning over identity or lifecycle evidence: Put the receipt at the context boundary The best place to enforce this rule is immediately before retrieved memory enters a model prompt, not only in a nightly storage check. A periodic check can prove the service was reachable earlier. The context boundary knows which identity, task, query, source revision, and freshness limit matter now. Use a bounded sequence: Normalize identity once. Build the exact scope from authenticated application identity, not model generated text. Hash the normalized scope for the health record. Carry one source correlation. Label the generation request or revision with an opaque event ID. Do not log the conversation content. Respect asynchronous work. Poll the operation name until it is done or the task deadline expires. Preserve working , waiting , and uncertain ; do not manufacture a failure or a second request. Reconcile inventory before relevance. Confirm the expected current memory under its exact scope, action, and revision. Then test the similarity path the agent will use. Verify lifecycle changes. For updates, require the expected current revision. For deletions, require absence from the consuming read path while retaining the authorized recovery reference only as long as policy allows. Make the injection decision explicit. Record allow , degrade , wait , or block plus the evidence timestamps. A successful model answer after unsafe injection does not retroactively make the memory healthy. This receipt still has limits. It cannot tell whether an extracted fact is true, useful, poisoned, or compliant with your retention policy. A matching revision label proves correlation only if the producer writes labels honestly. Similarity quality needs domain specific queries and human review. Access controls and adversarial tests remain necessary, especially because Google's overview warns that long term memory can carry prompt injection and memory poisoning risk into later sessions. Sidewisp's product direction treats memory continuity, freshness, identity boundaries, and outcome verification as operational health evidence around existing agent runtimes. It does not replace Vertex AI Agent Engine, IAM, your application, or your test suite. Sidewisp is currently in private preview. The public site and interactive demonstration are live; production agent health collection and a Vertex AI integration are not generally shipped.