The two are independent. Each has its own switch and saves separately, so turning one on or off does nothing to the other. Long calls where the agent loses track need on-call memory; repeat callers who shouldn’t have to introduce themselves twice need post-call memory. Plenty of agents want both, and a simple one-shot agent needs neither.
On-call memory
Pick the On-Call Memory sub-tab and turn on State Fields — the details the agent should track while it is talking. Nothing here is saved after the call: these values live and die with the conversation.

Post-call memory
Pick the Post-Call Memory sub-tab and turn on Post-Call Memory — Extract and persist call data. Once it is on, the agent reads each finished transcript and pulls out the fields you have defined, and what it finds is available on future calls with the same contact.

Extraction prompt


Extract only what is clearly stated or strongly implied in the transcript. Do not fabricate information.Keep that last line whatever else you change. Without it the model fills gaps with plausible guesses, and a wrong value on a contact profile is worse than a missing one. Press Save after editing.
Session fields


A field that records what is still missing is worth defining early: it turns the memory record into a to-do list for the next call.
Profile fields


Anything that changes call to call — mood, the reason for this call, what was agreed today — belongs in session fields. Putting it on the profile means each call overwrites the last one’s answer.
Memory scope


Organization-wide suits a set of agents working the same customer base — a caller who gave their intake preference to the sales agent doesn’t repeat it to the support agent. Narrow the scope when agents serve unrelated lines of business, or when one agent handles sensitive calls whose details shouldn’t surface elsewhere. Press Save after changing it.
