How to build a brand memory layer for AI on Google Cloud: the A‑to‑Z guide

Modern AI assistants are astonishingly capable and completely forgetful. Claude Code can refactor your stack, Google Antigravity can drive an agentic workflow, Codex can write a feature, and then the session ends and every one of them forgets your brand, your audiences, your last quarter’s creative learnings and the reason you stopped running that campaign in March. Each new chat begins from absolute zero, so you spend the first ten minutes re-explaining who you are. The intelligence is rented; the context evaporates.

A brand memory layer is the fix. It is a permanent, structured, governed store of everything your brand knows about itself, positioning, products, audiences, performance, creative, decisions and the reasoning behind them, that sits outside any single AI tool and that every tool can read on demand. Build it once and your assistants stop being clever strangers and start behaving like a senior team member who has been with you for years. This is the engine behind our proprietary Brand IQ method, and in this guide we will build one from scratch on Firebase and Google Cloud, the right way: enterprise-grade security from day one, and a strict agile process so it actually ships.

§01What a brand memory layer actually is

Forget the idea of a chatbot with a long conversation history, that is just a bigger short-term memory that still resets. A real brand memory layer is closer to how an expert human remembers: lots of small, atomic facts, each tagged with what kind of thing it is and when it was true, connected to the other facts it relates to, and retrievable by meaning rather than by exact keyword. It is a knowledge graph of your brand, not a transcript.

Three properties make it work. First, it is atomic: one fact per record, so memories can be updated, retired or contradicted without rewriting a whole document. Second, it is typed and dated: every record declares what it is (a positioning statement, an audience, a creative result, a decision) and when it applies, so the AI can tell durable truth from a stale snapshot. Third, it is linked: records reference each other, so retrieving one memory naturally surfaces the related ones. Get those three right and you have something an AI can reason over, not just recite.

“Forget the idea of a chatbot with a long conversation history, that is just a bigger short-term memory that still resets.”

§02The architecture, in plain terms

Everything we need is in the Google Cloud and Firebase family, which is why it is our default foundation, it gives you a managed document database, vector search, identity, encryption, compliance certifications and serverless compute without standing up a single server. Here is the whole system in one breath, before we build it piece by piece.

• Cloud Firestore (Firebase), the memory store itself: each atomic record is one document, with its metadata as fields. This is your “second brain”.
• Cloud Storage for Firebase, the vault for heavy assets: creative files, brand PDFs, exports and raw source material the records point to.
• Vertex AI text embeddings + Firestore vector search, the semantic recall: turns every record into a vector so the AI can find memories by meaning, not just keyword.
• Cloud Run + Cloud Functions, the ingestion pipeline and the retrieval API that the AI talks to.
• Identity Platform / Firebase Auth, IAM, Cloud KMS (CMEK), VPC Service Controls, Cloud DLP and Cloud Audit Logs, the governance layer that makes it safe to put real brand data in.
• A Model Context Protocol (MCP) server, the universal adapter that lets Claude Code, Google Antigravity, Codex or any assistant read and write the memory.

§03Run it like an agile team, not a science project

The fastest way to never finish a memory layer is to try to model your entire brand before you store a single fact. We build ours under a strict agile process for one reason: efficiency. You ship a thin, working, end-to-end slice early, prove an AI can read it, then compound. Each sprint produces something usable, not a pile of half-built schema.

Set the cadence before you write any code. One-week sprints if you have momentum, two if the team is part-time. A single prioritised backlog of small, independent, testable stories, each phrased as “as an AI assistant, I can recall X so that I can do Y”. A hard Definition of Done that every story must clear: the data is stored, secured, retrievable through the API, and verified by an actual AI query. A short review and retro at the end of each sprint to re-rank the backlog against what you learned. Discipline here is not bureaucracy; it is what stops the project sprawling.

§04Sprint 0, Inception: design the brand context taxonomy

Before any cloud resource, decide what kinds of memory your brand has. This is the single most valuable hour of the project, and it is pure thinking, not engineering. The goal is a small, named set of record types and the relationships between them, your proprietary brand schema. Resist the urge to invent fifty categories; start with the handful that an AI would need to make a good marketing decision.

A strong starting taxonomy for a D2C brand: Brand (positioning, voice, values, guardrails), Product (SKUs, claims, pricing, margins), Audience (segments, personas, objections), Channel (where you run and the rules of each), Creative (assets and the angle behind them), Performance (results, with the period they cover) and Decision (what you chose, when, and why). Every record will belong to exactly one type and carry a small block of metadata, a unique name, the type, a created and an effective date, a confidence or status, and links to related records. That metadata block is what turns a pile of text into a queryable memory.

• Name your record types, keep it under ten to start; you can extend later.
• Define the metadata every record carries: id/name, type, created date, effective/“as-of” date, status, source, and links.
• Define the relationships that matter, e.g. a Creative belongs to a Campaign, targets an Audience, and produced a Performance result.
• Write a one-page schema doc. This is the contract your whole build follows, and the Definition of Done for Sprint 0.

§05Provision the Google Cloud foundation, securely from the first command

Still in Sprint 0, stand up the platform. The trick is to bake in governance now, while the project is empty, rather than retrofitting it after real data is inside. Create a dedicated Google Cloud project so the memory layer’s billing, access and audit trail are cleanly isolated. Pin your data residency by choosing a regional location for Firestore and Storage up front (for an Australian brand, an australia‑southeast region), you cannot move it later, so decide deliberately.

Turn on the foundations in the same sitting: Firestore in Native mode, Cloud Storage, the Vertex AI API, Identity Platform, Cloud KMS, Cloud DLP and Cloud Audit Logs. Apply the principle of least privilege from the start, no human or service account gets broad “editor” on the project. Each piece of the system gets its own service account with the narrowest role it needs, and you, the owner, hold the keys.

• Create an isolated project and enable: Firestore, Cloud Storage, Vertex AI, Identity Platform, Cloud KMS, Cloud DLP, Audit Logs.
• Choose your region once and pin data residency for Firestore and Storage.
• Create a customer-managed encryption key (CMEK) in Cloud KMS so you, not just Google, control encryption at rest.
• Create one least-privilege service account per component (ingestion, retrieval API, embeddings), never a shared god-account.
• Enable Data Access audit logs so every read and write of brand memory is recorded from day one.

§06Sprint 1, The vertical slice: store one memory, read it from your AI

The first sprint has one job: prove the loop. Pick the single most useful record type, usually Brand positioning, and take it all the way through. Model it as a Firestore collection where each document is one atomic fact, with the metadata fields you defined in Sprint 0. Write three or four real positioning records by hand. Do not automate anything yet.

Then put the thinnest possible read path in front of it: a single Cloud Function or Cloud Run endpoint that, given a query, returns matching records as clean JSON. Call it from a script, confirm it returns your positioning. That is the whole sprint, and it is a genuine milestone, because the moment an AI can hit that endpoint, your brand has memory. Everything after this is making the memory richer, safer and easier to feed, not proving the concept.

• Create the Firestore collection for your first record type; add a handful of real records by hand.
• Stand up one retrieval endpoint on Cloud Run that returns records as JSON.
• Verify end-to-end with a real query. Definition of Done: an external caller can recall a brand fact.

§07Sprint 2, Ingestion and semantic recall

Hand-writing records does not scale, and exact-match lookup is too brittle for the way people and AIs actually ask questions. Sprint 2 solves both. Build an ingestion pipeline as a Cloud Function: it takes raw input, a campaign export, a brand doc, a meeting summary, normalises it into atomic records that fit your schema, and writes them to Firestore. Crucially, before anything is stored, run the text through Cloud DLP to detect and redact personal data, so customer PII never silently lands in the memory layer.

Then add semantic recall. For every record, call a Vertex AI embedding model to produce a vector and store it on the document, and enable Firestore’s vector search. Now retrieval works by meaning: a query like “why did our hero ad stop converting” surfaces the right Performance and Decision records even if those exact words were never written. Upgrade your retrieval endpoint to embed the incoming query, run a nearest-neighbour search, and return the most relevant memories. This is the moment the system starts to feel intelligent.

• Build a Cloud Function ingestion pipeline: normalise input into atomic records.
• Redact PII with Cloud DLP on the way in, privacy by design, not by audit.
• Embed every record with Vertex AI and store the vector on the document.
• Enable Firestore vector search and switch retrieval to nearest-neighbour by meaning.

§08Sprint 3, Build the knowledge graph

Atomic records are good; connected records are powerful. In Sprint 3 you turn the metadata “links” field into a real graph. When a record references another, a Creative that targets an Audience and produced a Performance result, store that relationship explicitly and traverse it at retrieval time. The payoff: ask about one thing and the layer returns the neighbourhood of related context, exactly the way a seasoned strategist remembers a campaign as a web of cause and effect, not an isolated stat.

Add one more record type to make the graph navigable: index records, lightweight maps that aggregate a topic and point to the detailed memories beneath it (“Q2 2026 acquisition learnings”, “our objection-handling playbook”). These are the entry points an AI uses to orient itself before drilling in, and they keep recall coherent as the store grows into thousands of records. With links and indexes in place, your brand memory is no longer a list, it is a model of your brand.

• Persist typed relationships between records and traverse them during retrieval.
• Return the related neighbourhood, not just the single best match.
• Add index/map records as orientation points over clusters of memory.

§09Sprint 4, Enterprise security, privacy and compliance

You have been building securely throughout; this sprint makes it airtight and provable, because a memory layer holds your most sensitive commercial context and it is about to be exposed to external AI tools. Google Cloud gives you the controls used by regulated enterprises, your job is to switch them on deliberately. Data is already encrypted in transit and at rest; with CMEK you hold the encryption keys yourself. Wrap the whole project in a VPC Service Controls perimeter so memory cannot be exfiltrated to a project outside your boundary, even if a credential leaks.

Lock identity and access down to the minimum. Every caller, human or AI, authenticates through Identity Platform and is authorised by least-privilege IAM, so an assistant can read the records it needs and nothing more. Cloud DLP keeps PII out of the store. Cloud Audit Logs record every access for a complete, tamper-evident trail. And because you provisioned regional residency in Sprint 0, your data stays where your compliance regime requires. The result lines up with the standards enterprises ask for, ISO 27001, SOC 2, PCI DSS, and with privacy regimes like the Australian Privacy Principles and GDPR. You own the vault and everything in it; it is portable and exportable at any time, with no lock-in.

• Customer-managed encryption keys (CMEK), you hold the keys, not just the provider.
• VPC Service Controls perimeter to prevent data exfiltration.
• Least-privilege IAM + Identity Platform auth on every read and write.
• Cloud DLP for PII, Audit Logs for a full access trail, pinned regional residency for data sovereignty.
• Built on infrastructure certified to ISO 27001, SOC 2 and PCI DSS; handling aligned to the Australian Privacy Principles and GDPR.

§10Connect your preferred AI: the MCP server

A memory layer is only as good as the tools that can reach it. Rather than build a bespoke integration for each assistant, expose your retrieval and write endpoints through a single Model Context Protocol (MCP) server. MCP is the emerging open standard for giving AI tools access to external context and actions, and the major assistants speak it. Build one small MCP server, host it on Cloud Run, that offers a handful of tools: search_memory (semantic recall), get_related (graph traversal), and write_memory (capture a new fact, governed by the same IAM and DLP rules). Authenticate it with a least-privilege service account so the AI gets exactly the access you grant.

With that one server live, every assistant connects the same way, point it at your MCP endpoint and your brand’s entire memory is available inside the tool. No more re-explaining who you are at the start of each session; the AI queries the layer, pulls the relevant positioning, audiences, performance and decisions, and works from real context.

• Claude Code, add your server under the MCP configuration (claude mcp add / .mcp.json); Claude can then call search_memory and write_memory directly in the terminal.
• Google Antigravity, register the same MCP endpoint as a context source in the agent’s tool configuration so its agents plan and act with your brand memory in scope.
• Codex, connect the MCP server in its config so completions and agentic runs are grounded in your records rather than guesses.
• Any other assistant, because it is standard MCP, ChatGPT, Gemini, or an in-house agent plug in with the same endpoint and credentials.

§11Operate it: the memory has to keep learning

A brand memory layer is not a project you finish; it is a system you run. Keep the agile cadence going after launch. Make capture a habit, every campaign result, every creative test, every strategic decision becomes a new record, ideally written straight from your AI tool via write_memory the moment it happens. Hold a short monthly review to retire stale records, resolve contradictions and re-rank what matters. The store compounds: the longer it runs, the more it behaves like an expert performance marketer who has watched your brand for years and forgotten nothing.

That is the whole arc, from an empty project to a governed, intelligent, continuously-learning memory that any AI can stand on. You have built the moat that rented intelligence cannot give you: not a smarter model, but a model that finally knows your brand.

§12Your next step: let us build your Brand Vault

Everything above is exactly how we build a memory layer for the D2C brands we work with, only we have already done the hard parts: the schema, the secured Google Cloud foundation, the ingestion pipeline, the knowledge graph and the MCP connection. We call the finished product the Brand Vault: a permanent, continuously-learning home for your data, creatives and performance that you own outright, plug into any AI, or let us run for you.

If you would rather not stand all of this up yourself, start with our free Context Strategy for AI. Tell us about your business and we will map your knowledge sources and hand you a knowledge graph, the blueprint for your own brand memory layer, free, with no obligation, and yours to keep.