Guide · Definitions
Customer memory: the one record every AI worker reads and writes
AI workers are only as good as what they remember about a customer. This guide defines customer memory, separates it from a CRM record, a warehouse and a context graph, and shows how Heliyos builds and keeps one for every account.
By Soham Sarkar, Cofounder and CEOUpdated
Customer memory is one living record per account that every AI worker reads before it acts and writes to after, with the source of every fact attached. It holds what the team and its workers know about a customer: people, deals, commitments, open questions, preferences and history, assembled from emails, meetings, notes, signals and your knowledge base. A CRM record is a form people fill in. Customer memory is maintained by workers, cited by source, and shared by every worker and person on the account.
The one-line definition
Customer memory is the shared understanding of an account, kept as one record that workers consult before acting and update after. The word memory is deliberate. A good account executive does not reread every email before a call; they remember the champion changed roles, the renewal is in March, and the CFO asked for a security review. Customer memory gives workers that same recall and makes it inspectable.
Two properties make it memory rather than storage. First, it is read before every action and written after, so it is never stale by more than one event. Second, every fact carries its source: the email, the meeting transcript, the note, the enrichment call. A fact without a source is a guess, and workers should not act on guesses.
How customer memory differs from a CRM record
A CRM record is a set of fields that a person fills in: company, stage, amount, close date, next step. It is structured for reporting and it goes stale the moment the rep gets busy. Ask any revenue leader what they trust least in their stack and the CRM record is usually near the top of the list. The person who knows the fact is not the person with time to type it.
Customer memory keeps the fields, because reporting still matters, and adds three things a CRM record lacks.
- Narrative context: what was promised, what the customer worries about, who influences whom. The parts of an account that never fit in a dropdown.
- Provenance: each fact points at the email, meeting or note it came from, so a person can verify in one click and a worker can weigh how fresh it is.
- A write path for workers: after every email and meeting, a worker updates the memory and the change is visible as a worker action, not as an anonymous field edit.
How it differs from a data warehouse and a context graph
A data warehouse or customer data platform collects events from many systems for analysis. It is wide and historical, and it answers questions about segments, not about what to say to one customer tomorrow. Nobody reads a warehouse before sending a follow-up. Customer memory is narrow and current: one account, what matters now, ready to act on.
Day.ai uses the phrase context graph for a related idea, describing an LLM-optimised ontology built from permissioned ingestion of email, calendar, meetings and Slack, where each data point carries its sources and reasoning. The emphasis on provenance is the same and we think it is correct. The difference is in what the structure is for. A context graph is framed as infrastructure, a control plane that agents and models consume. Customer memory in Heliyos is framed as a record the team and its workers share, read in the same account view, and dispute when something looks wrong. The graph is a means. The memory is the thing people and workers both look at.
Attio calls its equivalent Universal Context, an AI context layer that logs itself. Again the direction is shared. The test for any of these is the same: open an account, pick a fact, and ask where it came from and who last updated it. If the answer is one click away, you have memory. If it is a query, you have a database.
How Heliyos builds customer memory
Heliyos keeps exactly one customer memory per account. It is assembled from the sources a revenue team already has, and it is kept current by a worker whose whole job is that.
- Email: Gmail and Outlook threads are read as they arrive. Commitments, questions, new contacts and sentiment are extracted with the message as the source.
- Meetings: Zoom, Meet and Teams calls are recorded and summarised, and decisions, action items and attendees are written to the memory with the transcript attached.
- Notes: what a person writes after a call or in a Notes page becomes part of the memory with the author and date.
- Signals: Watchlist and Scouts surface changes such as a funding round, a job change or a new executive appointment, and attach them to the account with the source.
- Knowledge: your pricing, security answers, case studies and playbooks live in Knowledge, so workers draw on company facts, not only account facts.
- Parker: the AI platform admin worker reads every email and meeting and updates company, people and deal records afterwards. Changes that matter, such as a deal stage move, go to Reviews first.
How workers use it
Every worker action starts with a read. Before Taylor drafts a follow-up, it reads the account memory: the last three threads, the meeting summary from Tuesday, the open security question, the preference for short emails. The draft reflects all of it, and the Reviews item shows which facts it relied on. A person approving the draft sees the evidence next to the text rather than hunting for it.
Every worker action ends with a write. If the customer replies and moves the timeline, the memory changes and the next worker to touch the account sees it. Ask Heliyos chat answers questions from the same memory, so a founder asking "where are we with Northwind" gets the same facts the workers are acting on. One memory means no worker and no person is working from an older version of the truth.
What goes wrong without it
Teams that add AI to a CRM without a shared memory see the same three failures. The first is contradiction: a drafting assistant proposes a discount the account manager already refused, because it read the record and not the thread. The second is repetition: two workers, or a worker and a person, both chase the same open question because neither saw the other had asked. The third is silent staleness: the AI acts confidently on a close date that moved two weeks ago, and nobody can tell from the output that the input was old.
Each failure has the same root. The AI read something other than what the team knows. Customer memory fixes it by making one record the thing everyone reads, and by stamping each fact with a source and a time so that a worker can tell fresh from stale and a reviewer can check in one click. It also makes mistakes diagnosable: when a draft is wrong, you can see which fact misled it and correct the fact, not only the draft.
The payoff shows up in review. When Taylor puts a follow-up in Reviews, the person approving it sees the facts it used beside the text. Approval takes seconds because the evidence is already there, and a correction improves every future action on the account rather than one email.
How to tell whether a product really has customer memory
Four checks, each taking under five minutes with a trial account connected to a real inbox.
- Source test: pick any fact on an account and find its source. One click or it is not memory.
- Freshness test: send yourself an email that changes a fact, such as a new close date. How long until the record reflects it, and who made the change?
- Read test: ask the AI to draft a follow-up. Does the draft reference something only the history could tell it?
- Shared test: do the chat, the record and the worker all give the same answer to the same question? If they disagree, there is more than one memory.
| Question | CRM record | Data warehouse | Customer memory |
|---|---|---|---|
| Who writes it? | The rep, when there is time | Pipelines from source systems | Workers after every email and meeting, plus people |
| What is it for? | Reporting and process | Analysis across many accounts | Acting on one account now |
| Does each fact carry a source? | Rarely | At the table level | Always, one click away |
| How fresh is it? | As fresh as the last data entry | As fresh as the last pipeline run | Never more than one event behind |
| Who reads it before acting? | The rep, if they look | Analysts | Every worker, every time |
| Example | Stage: Proposal | Events table, 40 columns | CFO asked for SOC 2 on 3 Oct (email), renewal March (meeting) |
Our verdict
If AI workers are going to act on your accounts, they need one memory they all read and write, with sources. Day.ai and Attio are building toward the same idea with their own framing and trade-offs. Heliyos makes customer memory the centre of the product: one record per account, built from email, meetings, notes, signals and Knowledge, kept current by Parker, and the first thing every worker reads.
FAQ
Questions people ask
- Is customer memory the same as a context graph?
- They overlap. A context graph describes the structure agents consume; customer memory describes the account record people and workers share. Heliyos leads with the record because the team has to read and trust it too.
- Does customer memory replace my CRM?
- It can, or it can sit beside HubSpot through two-way sync so your existing record stays current while workers act on the Heliyos memory.
- Who keeps customer memory up to date?
- Parker, the AI platform admin worker, updates company, people and deal records after every email and meeting. Anything consequential, such as a stage change, goes to Reviews first.
- Can I see where a fact came from?
- Yes. Every fact in the memory links to its source email, meeting, note or signal, and every worker change is shown as a worker action.
Deploy your first AI worker, today.
Closed beta, usage-based pricing, no seats. Join the waitlist and we review your request.