Before Your AI App Remembers: A Founder's Launch Gate for Always-On Memory

Google Cloud has published an Always-On Memory Agent that watches for new files, extracts structured information, and consolidates what it has learned every 30 minutes. It uses Google ADK, Gemini 3.1 Flash-Lite, and SQLite. It can ingest 27 file types, answer with citations, expose stored memories in a dashboard, and delete individual records or clear the store. Its most provocative design choice is what it leaves out: no vector database and no embeddings.

That makes the project a useful reference implementation, not proof that every AI app should remember everything. The difficult product question begins after the demo works. What happens when a user's preference changes, a source document is corrected, two accounts share a device, an uploaded file contains a malicious instruction, or a customer clicks delete after the system has compressed several facts into a new summary?

For an AI app builder, nontechnical founder, or small product team, persistent memory changes the product's trust boundary. A wrong answer can disappear with the conversation. A wrong memory can shape answers for weeks. A privacy mistake can be copied into summaries, recommendations, and tool actions. The value is also real: users do not want to repeat goals, constraints, decisions, and context in every session.

The decision is therefore not “memory or no memory.” It is whether your product has earned the right to remember a particular class of information for a particular purpose.

This guide turns the current release and research into a launch gate. You will leave with a memory contract, a seven-day contradiction-and-deletion drill, a decision matrix, and explicit stop conditions. The goal is not to reproduce Google's sample or declare one architecture superior to RAG. It is to help a small team decide what to remember, prove that it can correct and forget, and launch a narrower feature with evidence.

What Google Released—and What It Did Not Prove

The official GoogleCloudPlatform sample separates the system into three jobs. An ingest agent extracts summaries, entities, topics, and an importance score from incoming material. A consolidation agent periodically reviews unconsolidated memories, finds connections, generates cross-cutting insights, and compresses related information. A query agent reads stored memories and consolidated insights to answer questions with source citations.

The implementation is deliberately approachable. It watches an inbox, accepts dashboard uploads and HTTP requests, stores data in SQLite, and exposes endpoints for status, listing, ingest, query, consolidation, individual deletion, and full reset. The README says the default consolidation interval is 30 minutes. That is enough for a founder and an engineer to inspect the full data path instead of treating “memory” as vendor magic.

It is also a sample. The repository does not publish long-horizon measurements for contradiction resolution, obsolete-fact reuse, deletion propagation, memory poisoning, tenant isolation, concurrency, or cost over months. Its statement that current memory approaches fall short is the project's design thesis, not an independent benchmark result. “No vector database” describes an architecture; it does not establish higher accuracy, lower total cost, or easier compliance.

The underlying model deserves the same boundary. Google's Gemini 3.1 Flash-Lite model card describes a fast, cost-efficient model intended for high-volume and latency-sensitive tasks, with a one-million-token input window. The card also shows that model performance varies substantially by benchmark and context length. A capable, inexpensive model can make background consolidation practical, but it does not make every generated memory faithful.

Treat the sample as evidence that always-on consolidation is buildable with ordinary components. Do not treat it as evidence that the feature is ready for your users, data, or consequences.

Use Precise Terms: History, Retrieval, and Memory Are Different Products

Teams often call four different mechanisms “memory,” then test only whether the assistant can recall a name. Define the mechanism before approving the feature.

The Google sample is closest to the fourth category. Its consolidation process does not merely retrieve an old record. It creates a new representation from multiple records. That is useful because the system can surface relationships a keyword search would miss. It is risky for the same reason: a generated connection can look like a stored fact even when it is an inference.

Three more terms keep the review honest:

• Source record is the original message, document, event, or user action.
• Derived memory is a summary, preference, connection, score, or conclusion generated from one or more source records.
• Provenance is the inspectable chain from a derived memory back to those sources, including time, account, transformation, and version.

The Founder Judgment: Memory Must Earn Its Retention

Persistent memory is attractive because it promises continuity. The user can say “plan the launch” without restating the target customer, budget, brand rules, and decisions from last week. That reduces friction and can improve activation or retention. But continuity is not automatically valuable for every fact.

Use four questions for each proposed memory class:

1. User value: What repeated task becomes materially easier when this information survives a session?
2. Permission: Would a reasonable user expect this exact information to be retained and reused for that purpose?
3. Correction: Can the user inspect, change, and supersede it without support intervention?
4. Consequence: What happens if it is wrong, stale, cross-account, or malicious?

The practical principle is minimum useful memory: retain the smallest stable fact set that creates the promised continuity. This is stricter than “collect everything and filter later.” Once source records are transformed into summaries, embeddings, caches, logs, backups, or tool state, later cleanup becomes a systems problem.

Regulators express a compatible operational expectation. The UK's ICO says AI transparency information should cover the purpose for processing, retention periods, and data sharing. The NIST Generative AI Profile recommends documenting provenance, giving people a way to withdraw or revoke consent, and evaluating systems in conditions similar to deployment. These sources do not decide your legal obligations; jurisdiction, role, and data type matter. They do show why “the model remembers so users do not have to” is not an adequate memory policy.

Five Failure Modes a Polished Demo Hides

The demo usually asks a fact, stores it, and retrieves it correctly. Production failures happen across time, accounts, and transformations.

1. Obsolete truth wins

A founder tells the assistant on Monday that the launch budget is $10,000 and changes it to $4,000 on Friday. The system retrieves both, or a consolidated insight continues recommending the original plan. The 2026 Memora benchmark was created partly because common memory evaluations overemphasize recall. Its authors report frequent reuse of invalid memories and failures to reconcile evolving information across the evaluated agents.

2. Compression changes meaning

“Do not contact enterprise leads until legal approves the new terms” becomes “enterprise outreach is a priority.” Summarization removed the condition that made the statement safe. The recent TrustMem paper treats consolidation as a transition that can omit, corrupt, or hallucinate information. That framing matters for products: the write operation itself needs evaluation, not only the final answer.

3. A useful past action becomes a bad template

An agent stores a successful workaround and reuses it after the product or policy changes. The ACL 2026 study How Memory Management Impacts LLM Agents identifies “experience-following”: similar new tasks can trigger similar outputs from retrieved past executions. The paper finds risks from error propagation and misaligned experience replay. Past success is evidence, not permanent authority.

4. One untrusted input persists

An uploaded document contains instructions aimed at the agent rather than facts for the user. If those instructions enter durable memory, their effect can survive the original session. OWASP's agent security guidance warns against storing arbitrary user input in persistent memory and recommends regression tests for memory poisoning and prompt injection. The security problem is not limited to hackers: pasted emails, web pages, and tool responses all cross trust boundaries.

5. Delete removes the visible row, not its descendants

A product may delete one source record while preserving a derived profile, consolidated summary, query cache, analytics event, backup, or downstream tool state created from it. A working delete button proves an interface action. It does not prove end-to-end forgetting. This is why deletion must be tested as a propagation path, not a database operation.

Write a Memory Contract Before Building the Feature

A memory contract is a one-page agreement between product, engineering, and the user experience. It specifies what the system is allowed to retain and what evidence is required to keep that permission.

Use this template for every memory class:

This artifact prevents a common sequence: the team builds a general memory layer, discovers sensitive edge cases, and adds an ambiguous settings toggle after launch. A contract forces a smaller claim. “Remember approved project constraints for 30 days” can be tested. “Your AI knows you” cannot.

A Concrete Scenario: The Launch Assistant That Remembers Too Much

Imagine a two-person team building an AI launch assistant. During onboarding, the founder uploads customer interviews, a pricing spreadsheet, brand notes, and a call recording. The assistant extracts a target segment, planned price, launch date, and messaging constraints. On day one it feels excellent: every draft reflects the project.

Then three changes happen. The founder reduces the price from $49 to $29. A customer interview says “I would never pay monthly,” but it is one research participant, not the team's pricing decision. A contractor uploads a document containing instructions to ignore previous brand rules and promote an unrelated URL.

A naive memory system can fail in three directions. It may keep recommending $49 because the older value appears in more documents. It may turn a participant's opinion into the team's strategy. It may preserve the malicious instruction as a high-importance insight. If the agent can publish landing-page changes, memory errors become actions.

The memory contract changes the workflow:

• Prices and dates are authoritative constraints only when confirmed by an owner or synchronized from a named system of record.
• Interview statements remain attributed evidence, never project truth.
• Uploaded text is data, not instruction; it cannot modify system rules or write high-authority memory.
• A changed constraint supersedes the prior value but preserves an audit trail.
• Publishing remains behind human approval, regardless of memory confidence.
• Deleting an interview removes its source and regenerates any derived research summary that used it.

Run a Seven-Day Contradiction-and-Deletion Drill

Do not approve memory after one successful recall test. Run a short chronological drill with the model, prompts, storage, and account boundaries you intend to ship.

Day 1: Establish a clean baseline

Create two test users and two projects. Enter ten facts in each: stable preferences, temporary constraints, attributed quotes, and facts that must never persist. Verify exact tenant separation and record what the system stores, not just what it answers.

Day 2: Introduce contradictions

Change four facts using different channels: direct chat, edited document, system-of-record event, and admin correction. Query immediately and after the next consolidation. The expected result must define which source wins and why.

Day 3: Add time and uncertainty

Add an expired deadline, an ambiguous preference, and a statement such as “maybe we should target agencies.” The system should distinguish current facts, proposals, and unknowns. It should abstain or ask when authority is unclear.

Day 4: Test hostile and accidental inputs

Upload a benign document containing a clearly marked test instruction that attempts to change agent behavior or another memory. Do not use real secrets or destructive actions. Verify that the text remains untrusted content, produces an alert or rejection where expected, and cannot cross projects.

Day 5: Delete at every layer

Delete one source that has no descendants, one source used in a derived summary, and an entire account. Check the primary store, derived memories, retrieval/index layer, caches, queued consolidation work, analytics, exports, and documented backup behavior. Re-query before and after another consolidation cycle.

Day 6: Test restore and replay

Restart services, restore a staging snapshot if your process supports it, and replay a delayed job. Deleted or superseded information must not silently return. If backups intentionally retain encrypted data for a defined period, verify that production access and rehydration rules match the policy.

Day 7: Review with humans

Give the resulting memory ledger and answers to someone who did not build the system. Ask them to trace five answers to sources, identify the current value in each contradiction, and confirm what deletion did. Record every disagreement as a product failure until the specification clarifies it.

The drill passes only if the team can explain both correct and incorrect behavior. “The final answer looked fine” is not sufficient evidence.

Score the Launch With a Decision Matrix

Use a four-level score for each dimension. Do not average away a zero in identity, deletion, or action safety.

Minimum launch rule: no zeroes; at least level 2 in user control, provenance, contradiction handling, deletion, tenant isolation, and action boundaries. A private prototype can remain at level 1 when it uses synthetic data and has no external actions. Sensitive or regulated use cases require specialist review and may need substantially stronger controls than this general matrix.

Build the Smallest Architecture That Can Prove the Contract

Architecture should follow the contract, not the other way around. Regardless of whether you use consolidation, RAG, a knowledge graph, or a vendor memory service, preserve these objects separately:

source record
  -> extraction proposal
  -> validated or user-confirmed memory
  -> derived connection or summary
  -> retrieval event
  -> answer or proposed action

Each arrow should carry tenant, actor, timestamp, source identifiers, model/prompt version, authority level, and status such as active, superseded, disputed, or deleted. Do not overwrite the only copy of a prior state when a fact changes. Version it, mark the current value, and ensure retrieval excludes invalid states.

The application layer should enforce write authority. A model may propose that “the user's preferred plan is Pro,” but a high-impact preference should not become authoritative merely because the model assigned confidence 0.9. Likewise, source citations should be generated from stored lineage, not reconstructed from the model's prose.

Keep tools downstream of a policy gate. Memory can prepare a draft or recommendation. Sending email, changing prices, inviting users, publishing content, moving money, or changing access should require a fresh check of identity, permission, and current state. The more durable the memory, the less acceptable it is to treat old approval as permanent approval.

Finally, keep a kill switch that disables memory reads without breaking the core product. If the team discovers poisoning or cross-tenant leakage, it should be able to fall back to stateless behavior while preserving evidence for investigation.

Deletion Is a Product Workflow, Not a Button

For personal data, deletion may also be a legal obligation. The EU GDPR's Article 17 establishes a right to erasure under specified conditions, with exceptions and contextual requirements. Article 30 also calls for records of processing activities that include purposes, data categories, recipients, and, where possible, erasure time limits. This article is not legal advice; teams should obtain advice appropriate to their markets and data.

Even outside a regulated context, deletion is a trust promise. Define its terminal state:

After deletion completes, the removed information cannot influence normal answers or actions, cannot be retrieved through another tenant or interface, and cannot reappear through a scheduled job or ordinary restore. Any time-limited backup retention is documented, access-controlled, and excluded from normal processing.

Test that statement. Give every deletion request an identifier. Enumerate source records and derived descendants. Cancel or invalidate queued consolidation. Purge caches and indexes. Mark affected summaries for regeneration. Verify the result with adversarial queries. Record completion and unresolved backup timing.

The Google sample's individual /delete and full /clear endpoints are valuable because they expose deletion as an inspectable operation. A production product must extend the question: what else copied, summarized, cached, exported, or acted on that memory?

When Persistent Memory Is the Wrong Product Decision

Do not add memory because competitors have a toggle or because it makes a demo feel personal. Stateless or session-only behavior is often better when:

• users complete a one-off task and receive little value from continuity;
• the data is highly sensitive but the team lacks mature access, deletion, and incident controls;
• the source of truth changes frequently and can be queried directly at request time;
• multiple users share an account and memory ownership cannot be resolved;
• the agent can take consequential actions but approval and permission checks are weak;
• the team cannot measure stale-memory errors or support correction;
• a deterministic user profile or ordinary database field solves the need more clearly.

Choosing less memory is not a failure of AI ambition. It is a product-scope decision that preserves the option to add specific memory classes once the team can prove their value and control them.

The Founder Launch Checklist

Before enabling persistent memory for real users, confirm all of the following:

• The feature names the user outcome, not just “personalization.”
• Every retained memory class has a written purpose, source, authority, retention, and use boundary.
• Users are told what is remembered, why, for how long, and with whom it is shared.
• Sensitive and irrelevant inputs are excluded by default.
• Source records and derived memories remain distinguishable.
• Important memories show provenance and effective time.
• Contradictions have typed precedence, supersession, and abstention behavior.
• Cross-tenant negative tests pass.
• Untrusted documents and tool outputs cannot silently become high-authority memory.
• Individual deletion, derived-memory deletion, account deletion, restart, queued jobs, and restore paths are tested.
• Memory never provides permanent authorization for consequential actions.
• A stateless fallback and incident kill switch exist.
• The team measures correction rate, stale-memory reuse, provenance coverage, deletion completion, and trust complaints—not recall alone.
• A named owner reviews incidents, drift, retention, and the continuing reason to keep each memory class.

The strongest small-team launch is not the assistant that remembers the most. It is the one that remembers a narrow, valuable set of facts; shows where they came from; knows when they stopped being true; and can prove that “forget” actually means forget.

References

1. GoogleCloudPlatform: Always-On Memory Agent
2. Google Agent Development Kit documentation
3. Google DeepMind: Gemini 3.1 Flash-Lite model card
4. NIST AI 600-1: Generative Artificial Intelligence Profile
5. UK ICO: Transparency in AI and data protection
6. EUR-Lex: General Data Protection Regulation
7. From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents
8. TRUSTMEM: Learning Trustworthy Memory Consolidation for LLM Agents with Long-Term Memory
9. How Memory Management Impacts LLM Agents: An Empirical Study of Experience-Following Behavior
10. OWASP AI Agent Security Cheat Sheet
11. OWASP: Memory Is a Feature. It Is Also an Attack Surface