Google adds Memory Bank controls for inspecting agent recall

Google has added a dedicated Memory Bank page to the Google Cloud console, giving developers a clearer place to inspect and configure the information their AI agents retain. The November 6 update covers standalone memory banks and adds controls to agents deployed in Agent Runtime.

The practical change is visibility. Teams can review stored facts, examine structured profiles, filter by scope and inspect revision history without treating every investigation as an SDK task. This is an interface and management update to an existing service, rather than the launch of agent memory itself.

Google’s release notes also describe configuration controls for generation, retrieval and retention, plus prefilled Python snippets for connecting a bank to Agent Development Kit.

Choose the memory lifecycle before connecting an agent

The first decision is where memory should live. Google supports standalone Memory Bank instances as well as memory built into Agent Runtime. Its setup documentation warns that deleting an Agent Runtime instance also removes its built-in memories.

For teams that regularly replace agent deployments, that dependency deserves attention before production data arrives. Document whether memory should disappear with the deployment or survive as a separately managed resource.

Some choices are difficult to revise later. An instance’s region and encryption settings cannot be changed after creation. The embedding model can be changed only before the first memory is stored. Customer-managed encryption keys are unavailable for the global endpoint.

A sensible rollout therefore starts with a test instance: confirm location, encryption and retrieval configuration, then connect the agent. Google requires billing, the Agent Platform API and the relevant IAM permissions.

Decide what belongs in a profile

The console distinguishes free-form memories from structured profiles. According to Google’s Memory Profiles guide, a profile follows a defined schema, with a model extracting relevant information and updating its fields as new material arrives.

That distinction helps developers choose how to represent different information. A preferred programming language fits a named field. A longer explanation of why a project chose one architecture may be more useful as a natural-language memory.

Profiles are maintained separately for each schema and scope. Each field has underlying memory records that developers can inspect, including its revision history.

There is an important migration limit: adding or changing a schema does not backfill profiles from earlier memories. Teams introducing a new field should test whether it is populated from newly supplied events before depending on it in application logic. A saved schema alone does not mean existing users have complete profiles.

Check scope before blaming retrieval

Google’s retrieval documentation makes scope matching explicit: retrieval returns memories with exactly the same scope as the request. A memory’s scope is fixed when it is created.

For example, an application that stores information under both a user and a project should not assume a user-only request will return it. Designing consistent scope keys is part of designing the memory system, not just a console-filtering preference.

Similarity search narrows results within that matching scope. Without similarity parameters, retrieval returns all matching memories, potentially across multiple pages.

That gives teams two separate checks when an agent appears to forget something: whether the request uses the correct scope, and whether the similarity query finds the relevant fact. Google also warns that converting a retrieval response to a list automatically fetches every page. Explicit pagination is worth testing on larger collections.

Keep enough history to explain a mistake

The current memory value does not tell the whole story. Google’s revision documentation describes immutable snapshots created when memories change. For generated memories, revisions also show information extracted before consolidation.

Revisions are enabled by default and normally expire after 365 days. Teams can adjust retention or disable them, but expired revisions are unavailable for inspection or rollback.

Operationally, retention should reflect how long a team needs to investigate an incorrect remembered preference or unexpected profile change. Keeping history gives reviewers something concrete to examine; choosing a short retention period means accepting a shorter investigation window.

The useful production test is modest: store a preference, change it, retrieve it under the intended scope, and inspect the recorded transition. The new console controls make that workflow easier to inspect. Whether the agent applies the resulting memory correctly still needs application-level testing.

For a comparison of different storage and review approaches, ByteForward’s guide to Anthropic’s agent memory research examines how notes are maintained and why remembered context still needs evaluation. The products have different controls, so test the workflow you plan to deploy.