Remember Each User

In this step your agent starts remembering useful facts about each person between conversations, so they don't have to repeat themselves. Just as importantly, you decide what it may never remember.

In this tutorial you give Atlas, Kirana Group's operations assistant, two memory fields: the site a person works at (home_site) and their department (department). Kirana's approval answers depend on both. Once Atlas remembers them, a procurement officer at the Surabaya site no longer has to say "Surabaya" every time they ask which cost centre a capex request should use.

In the CMS, open 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. That is what keeps the agent relevant, fast, and explainable.

Before you start

• Your agent is live and people talk to it: see Preview and Publish Changes and the Stage 2 channels, such as Embed Chat on Your Website or Connect to WhatsApp.
• Memory is kept only for signed-in people; anonymous participants have no profile. See Participants.
• Check that your organization does not have Privacy Mode on: with it on, no memory is captured at all.
• Have a test account ready. Testing a draft agent writes to real profiles (see Changing fields later).

How it works

You define a short list of Memory Fields: named slots such as home_site, department, 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. Atlas declares two fields about where people work. It 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.

Step 1: Turn on Remember things about each person

At the top of the page is the master switch, Remember things about each person. It is off by default:

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

If the organization has Privacy Mode on, this switch has no effect. No memory is captured for any agent in the organization, regardless of what's declared here.

Turn it on. That 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 into two tabs:

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.

Step 2: Declare the memory fields

Open the Memory Fields tab and click Add field. The New memory field dialog opens. Fill it in for the first field, home_site:

Leave Core field off. Leave Show prominently and The person may correct it on. Click Apply.

Click Add field again and declare the second field with the same settings, except:

The list now shows both fields. The heading counts the declared fields against your organization's limit (2 of 12 declared). Each row shows the label and key, a one-line summary (Text · kept 180d · always included), the purpose, and a Filled column. Filled shows aggregate counts, such as "38 of 210", never individual values. It shows a dash until someone's value is stored. Fields carry a core chip when they are core fields, and an orange sensitive chip for special-category data. Use the pencil to edit a field and the bin to remove it.

Field settings

The dialog also offers these options:

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. The maximum is 25, and it governs how many items reach the prompt, not how many are stored.

Three switches finish the dialog:

• Core field: always included, and never trimmed by the token budget.
• Show prominently: given its own place on the person's memory page rather than sitting in the full list.
• The person may correct it: they can change the value themselves, and their correction is never overwritten by a guess.

The last two change presentation only. Every field always appears in the person's data access and export, whatever is set above.

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: the site they work at, their department, the language they prefer. Poor candidates are anything that changes per conversation, such as the amount of the request they are asking about. 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 site do not accumulate. Kirana could make home_site a Choice field that lists its sites; this tutorial uses Text to keep it short. 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 colleague's.

Step 3: Check the Configuration tab

Open the Configuration tab. For Atlas the defaults are right, so you only check them.

Prompt Budget (tokens)

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

Default 400. The note under the field shows how high your organization lets you go (here, up to 800). This, not the field count, is the real constraint, because one List field can grow far larger than a single-value one. Two short Text fields like Atlas's fit easily.

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 every capture visible in the moment but slower; leaving it off means the person sees it afterwards, on their own memory page. Which is appropriate depends on how sensitive your declared fields are. Atlas leaves it off. The person still agrees once before anything is stored (see What the person sees).

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.

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. Below the dropdown the CMS shows which model the default currently resolves to.

Step 4: Save

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 'home_site'".

Step 5: Let Atlas remember you in the preview

Open the preview while signed in with a test account, start a fresh conversation, and tell Atlas where you work:

I'm based at the Surabaya site and I work in Procurement.

Atlas does not store this straight away. It first asks for permission, along the lines of "May I remember those details?", and tells you what it would keep. Agree, for example with:

Yes, please remember that.

Details you gave before agreeing are not stored. The permission covers what you say from now on. Atlas does not go back and save the sentence you said before you agreed. Say the details again after you agree.

Start a new conversation and say it again:

I'm based at the Surabaya site and I work in Procurement.

Consent is asked once per agent, so Atlas does not ask again. It confirms that you are in Procurement at the Surabaya site and asks what it can help with. Both fields are now stored on your profile.

Check the result

1. Start another new conversation and ask a question where the site matters, without naming it:

   Which cost centre should my next capex request use?
   

   Atlas brings up the Surabaya site on its own and names its cost centre, CC-210. Because a request can be for a different project site, Atlas still checks which site this request is for, as its Interaction instructions tell it to do when the site changes the answer.

   

2. Ask "what do you remember about me?". Atlas should list your home site and department.

3. Open the Your memory link in the sidebar to see both values with their purpose, expiry, and the quote they came from. In the CMS, the Filled column of each field counts how many people have a value.

4. Publish the agent when the fields behave the way you want.

If a value is missing, check that you repeated the details after agreeing, that you are signed in, and that the field's Purpose and Type were saved.

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. It opens 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 home site", "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 comes up, tells the person what it would keep and why, and asks. Nothing is written until they answer, and what they said before agreeing is not saved afterwards. The agent 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. 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.

Next steps

• Next in the journey: Automate Tasks, so people can ask your agent to do work later on its own.
• Managing Agent Access: who on your team may read participant data.
• Model & Context: the model that answers, and how much conversation history it carries.
• Participants: where a participant's remembered data is opened from.
• Previous step: Test Tools Safely with Mocks.