Skip to main content
Memory gives your agents continuity. When someone comes back for a second-round interview, a follow-up coaching call, or another sales conversation, the agent starts the call already knowing them instead of starting from scratch.

How it works

Memory is stored as facts, one per line, in a container named by a user_memory_tag.
  • At the start of a call, the agent reads its container and is told the facts as background knowledge, newest first.
  • At the end of a call, Waterr distills the transcript into the new facts it learned (role, preferences, decisions, people and things that matter to the person, open threads) and adds them to the container. Facts it already knew are skipped; a fact that changed is written as its new version.
The tag is what connects agents and people. Every agent in your workspace with memory on that runs a call under the same tag shares the same container — so a person’s sales agent, onboarding agent and support agent can all remember the same things about them, and one agent can hold memories for many people.

Which container a call uses

Tags are scoped to your workspace: the tag user_123 in your workspace is never the same container as user_123 in anyone else’s.

Enabling memory

1

Open your scenario

Navigate to the agent you want to remember people.
2

Go to Settings

Click the Settings tab.
3

Turn on Remember Participants

Under Participant Memory, toggle on Remember Participants.
Turn it on for every agent that should share memory. To see, add to, or erase what is remembered, open Developer › Memory in Studio.

Using your own tag

Use an identifier from your own system — your user id, a CRM record id — as the tag, and pass it when you start the call:
A tag can be up to 128 characters of letters, digits and . _ : @ + - / | =. You can only set a tag on calls to your own workspace’s agents, and on embeds it travels inside the signed token, so a web page can never choose whose memories a call reads.

Importing memories from other systems

Already know things about your users — in a CRM, a support tool, or another memory system? Import them under a tag and the first call starts with them:
Each entry is one fact; a multi-line string is split into one fact per line. Facts already in the container (ignoring case, spacing and bullets) are skipped, so re-running an import is safe. See the Memories API for reading and deleting.

What the agent is told

Facts are injected newest first, up to ~4,000 tokens. Older facts beyond that stay stored, and are shown in Studio as “stored, not sent”. When two facts disagree, the agent is told the newer one wins. You can steer how the agent uses memory in your meeting script:

Privacy & data handling

  • Opt-in per agent — off by default; nothing is read or written unless you turn it on.
  • Encrypted at rest — fact text and tags are AES-256 encrypted in the database.
  • Workspace-scoped — a container belongs to one workspace and is never visible to another.
  • Erasable — delete one fact or a whole container from Studio or the API. Deletions are recorded in your activity log.
  • Retention — your workspace’s memory retention window applies to every fact, imported ones included.
For broader controls, see Privacy and Data Encryption.

Limitations

  • Inbound phone calls aren’t remembered unless a tag is supplied — a phone number’s calls otherwise all run as its owner, and pooling every caller’s memory would leak it between them.
  • Meetings the agent joins in Google Meet, Zoom or Teams don’t use memory yet.
  • No in-place editing. To correct a fact, forget it and add the corrected version.