Personalization

The Personalization page decides what your agent may remember about each person between conversations — and, just as importantly, what it may never remember.

Navigate to Conversation → Personalization in the left sidebar.

Declare what this agent may remember about the people it talks to. Anything outside that list is never stored — which is what keeps the agent relevant, fast, and explainable.

How it works

You define a short list of Memory Fields — named slots such as preferred_branch, allergies, or language. When someone says something that fills one of those slots, the agent records it against their profile. In later conversations it reads those values back and uses them.

Three consequences follow from that design, and they are worth understanding before you configure anything:

• Nothing is captured that you did not ask for. A clinic agent that declares six fields about appointments will not quietly start storing someone's favourite football team, because there is nowhere to put it.
• Reading costs nothing extra. The fields are a fixed, known list, so recalling them is a single lookup rather than a search. No AI call happens on the way in.
• You can explain it. Every stored value keeps its origin, the verbatim quote it came from, when it was captured, and when it expires. If someone asks "how do you know that about me?", there is a real answer.

Remember things about each person

The master switch. Off by default.

Off by default. Nothing is stored until you declare below what may be remembered, and the person has agreed to it.

Turning it on captures nothing by itself: with no fields declared there is nowhere to put anything. Everything else on the page is configuration for this switch, so the rest appears only once it is on.

If your agent still has the retired personalization mechanism enabled, a warning appears here with a Switch it off button. That older mechanism stored data separately, is being retired, and feeds nothing on this page.

Underneath the switch the page splits in two:

The switch and the Save button sit outside both tabs, because one Save commits the settings and the field list together. Editing a field on one tab and adjusting a setting on the other is a single save, not two.

Memory Fields

The heart of the page. The list shows how many fields are declared against your limit, what each one is for, and how often it actually gets filled.

Each row shows the field's label and key, a one-line summary (Text · kept 180d · always included), and a Filled column giving aggregate counts — "38 of 210" — with no individual values. Fields carry a core chip when they are always included, and an orange sensitive chip for special-category data.

Declaring a field

Add field opens the editor. The important ones first:

Then the ones that decide when and how a field is used:

Choice and List fields take a comma-separated Options list. List fields additionally choose which items reach the prompt (most recently confirmed, all of them, or closest to the conversation) and how many — up to 25, which governs how many reach the prompt, not how many are stored.

Three switches finish the dialog: Core field (always included, never trimmed by the budget), Show prominently (given its own place on the person's memory page), and The person may correct it. The last two change presentation only — every field always appears in the person's data access and export regardless.

Apply stages the change; the page's single Save commits it.

Writing a good field

A field earns its place when it is a fact you would act on and it is stable enough to still be true next time. Good candidates are things a person would be mildly annoyed to repeat: which branch they use, what language they prefer, a dietary restriction. Poor candidates are anything that changes per conversation — that is what conversation context is for.

Keep values short; a slot holds a fact, not a note. Prefer Choice over Text where the answers are genuinely finite, so three spellings of the same thing do not accumulate. And set priority deliberately: it is the order in which the agent forgets under pressure.

Changing fields later

Editing the schema of an agent that already has profiles is the easiest way to damage data quietly.

Memory Fields follow your agent's draft and published versions, so you can add a field on the draft and try it before publishing. The stored data is shared between them, though — which means testing a draft agent writes to real profiles. Test with a test account, not a customer's.

Personalization AI Model

Used to pick out declared details from what the person says. It runs only when a turn actually contains something you asked the agent to remember.

That last clause is the cost story: turns that clearly contain nothing relevant are filtered out before any AI call, so most turns cost nothing extra. Leave this on Organization default unless you have a reason not to — the job is small and structured, and does not need your most capable model.

Prompt Budget (tokens)

The limit that actually binds: fields are trimmed by priority once memory exceeds this.

Default 400, and it may go as high as your organization's ceiling. This, not the field count, is the real constraint, because one List field can grow far larger than a single-value one.

How many fields you may declare is not set here. It is an organization setting — see The limits your organization sets below.

Confirm Before Storing

The agent asks the person before it writes anything down, rather than capturing it silently.

Off by default. Turning it on makes capture visible in the moment but slower; leaving it off means the person sees it only afterwards, on their own memory page. Which is appropriate depends on how sensitive your declared fields are.

Say Where It Came From

The agent says "based on what you told me earlier" when something it remembers shapes a reply.

On by default, and worth leaving on. An agent that silently knows things is unsettling in a way that one which explains itself is not.

The limits your organization sets

Two numbers bounding this page live on the organization rather than the agent, under Organization → Personalization. They are set by an organization Owner or Admin.

The field count is deliberately not an agent setting. Its whole purpose is to bound what a contributor may declare, and a limit the contributor could raise themselves would not be a limit — so the agent holds no number of its own, and the organization's is the only one.

Lowering either afterwards is safe for data already captured. Fields already declared are never erased by a limit lowered later; the agent simply cannot add more until it is back under. A prompt budget above a lowered ceiling is brought down to it.

Cost, incidentally, follows the fields people have actually filled rather than the number declared — twelve declared with three filled costs three.

What the person sees

The people being remembered are not passive here, and most of this is their right rather than a courtesy. Signed-in users of an agent with memory on get a Your memory link in the sidebar, opening a page that lists everything stored about them — each value with "Kept because: {your purpose}", its expiry, and the quote it came from.

There they can correct a field (where you allowed it), forget one, Download a copy, Erase everything, or Pause remembering — which stops reading and writing without erasing anything.

They can do all of it in plain conversation too, by simply asking: "what do you remember about me?", "forget my preferred branch", "stop remembering things about me". That path matters for people on WhatsApp and other messaging channels, who have no page to visit. It works from the very first turn — someone is entitled to ask what you know and be told "nothing".

Consent is asked once per agent. Rather than interrupting with a dialog, the agent raises it in conversation when one of your declared details would naturally come up, tells the person what it would keep and why, and asks. Nothing is written until they answer, and it does not press if they decline.

Both the link and the conversational controls appear only for signed-in people; anonymous participants have no profile to keep.

Who on your team can see it

By default nobody sees individual values — contributors see only the aggregate Filled counts above. That is deliberate: tuning a schema, the common task, does not require reading anyone's personal data.

Seeing one person's remembered data takes an explicit grant, is reached from that specific participant rather than browsed as a table, and is recorded every time. Two organization-level switches sit above it, both closed by default and changeable only by an organization Owner:

• Staff may view what agents remember about individual participants — while off, no contributor can open a participant's data whatever level they hold.
• Agents may declare special-category memory fields — while off, the Sensitivity dropdown here is disabled.

Those two carry a higher bar than the limits above, which an Admin may also set. The difference is what they decide: the switches say what personal data the organization is willing to process at all, while the limits only bound how much of it an agent may carry.

See Managing Agent Access for the five levels and who may grant them.

Saving Changes

Click Save. The switch, the numbers, and the field list save together. If the backend rejects something it reports every problem at once, quoting the field — for example "purpose is required on 'preferred_branch'".

Related pages

• Model & Context — the model that answers, and how much conversation history it carries
• Managing Agent Access — who on your team may read participant data
• Participants — where a participant's remembered data is opened from