--- title: "Memory" url: "/memory" description: "How an agent remembers a contact across conversations, what has to be enabled first, and how to manage what is stored." productArea: memory audience: ["business-user", "admin"] plan: startup tags: ["memory"] lastReviewed: 2026-08-30 --- # Memory (/memory) With memory enabled, an agent remembers durable facts about a contact between conversations — preferences, stated facts, events — and uses the relevant ones on future turns. A returning customer does not have to repeat themselves. Without memory, every conversation starts fresh. ## Three things must be true [#three-things-must-be-true] Memory only runs when **all three** are in place. Turning on just one is not enough. 1. **Your plan includes it.** Memory is available from the **Startup** plan upwards. See [plans and limits](/organization). 2. **The agent has memory enabled** — the agent's **Settings** tab, under Intelligence Layer. 3. **The conversation is not excluded** — some channels or sessions can opt out, which is how `/reset` on [Telegram](/channels/telegram) starts a genuinely clean conversation. ## Set a business domain first [#set-a-business-domain-first] Before memory can be switched on, the agent needs a **business domain** selected in Settings. Memory extraction is domain-aware: the domain tells KlicForge what kinds of facts, entities and events are worth remembering for your business. Until a domain is chosen, the memory toggle stays locked. ## How it works [#how-it-works] Memory is **batch-driven, not per-turn**, which keeps its cost predictable: * A conversation is queued for extraction only once it **ends** — either explicitly, or when it goes idle long enough to expire. * A background job reads ended conversations, extracts durable facts, and marks them so they are not processed twice. * Long-lived channels like Telegram and the widget enter the queue when their conversation expires on idle. This means a fact a customer mentions will not be available in the *same* conversation's later turns as a memory — it is already in the conversation history for that. It becomes memory for *next* time. The whole conversation is read, however long it ran, so something stated in the opening turns is weighed the same as something stated at the end. ## What can be remembered [#what-can-be-remembered] A fact is only kept when it can be traced to the customer's own words. Every fact carries a quote, and that quote is checked against the conversation transcript before the fact is stored. Anything that cannot be matched is discarded rather than saved with a guess attached. The agent's own replies never count as evidence. If your agent summarises back — "so you are relocating in March" — that sentence cannot become a remembered fact on its own; the customer has to have said it. The practical effect is fewer remembered facts per conversation than an unchecked extraction would produce, and far less chance of a fact nobody stated. There is one deliberate exception, and it is labelled as one — see [Patterns](#patterns) below. ## Time and dates [#time-and-dates] Every remembered fact is dated, and anything with a time of its own — an appointment, a delivery, a deadline — also records **when it happens**, not just when it was mentioned. Two things follow from that: * **Relative wording is resolved when the fact is stored.** A customer saying "lunch tomorrow at 11" is remembered as the actual date, so it still reads correctly weeks later. * **Something that has already happened is marked as past**, and the agent weighs it far lower than a stable fact or an upcoming one. A past appointment can still be recalled if a customer asks about it — it just will not be offered as though it were still ahead. Where a customer never gave a specific time — "I still need to do the grocery run" — the agent records only when they last raised it, and treats it as stale once it has not come up for a while. It will not present it as something still scheduled. Preferences and stable facts do not fade this way. "Prefers email" stays as relevant a year on; last month's appointment does not. If a date is wrong, correct it on the fact itself in **Contacts → (contact) → Memory** — the **Occurs on** field. Clear it for a fact that has no date of its own. ## Patterns [#patterns] Some things a customer never says out loud. Somebody who has booked the same hotel on three separate trips has a preference, but they may never have put it in words — so nothing in the rules above would ever capture it, because there is no sentence to quote. **Patterns** are the exception. They are not extracted from what was said; they are counted from what happened. If [Business Intelligence](/intelligence) is on for the agent, every conversation already produces structured events — a booking, an order, an enquiry — and each one records the things it was about. When the same value comes up again and again for one contact, that repetition is the pattern. Open **Contacts → (contact) → Memory** and choose the **Patterns** view: > **hotel** > Marina Bay Sands — seen 3 times across 3 conversations A value has to come up **at least 3 times** to appear. Two is a coincidence. ### When a pattern becomes something the agent knows [#when-a-pattern-becomes-something-the-agent-knows] Showing you a pattern and telling the agent about it are two different bars, and the second one is higher. A pattern is promoted into an actual remembered preference overnight, once it has come up **3 or more times across at least 2 separate conversations**. Three mentions inside a single conversation is one story told at length, not a habit — so it stays on the Patterns view and goes no further. A promoted pattern reads as a plain sentence with the arithmetic left in: > Repeatedly chooses Marina Bay Sands for hotel (3 of 4 bookings). The fraction matters. "3 of 4" says the customer chose something else once; it does not claim more consistency than the record shows. The agent is always told that a pattern was **inferred from repeated behaviour, not stated** — so it can use it to make a suggestion without ever claiming the customer said it. That distinction is the whole reason patterns are kept separate from ordinary remembered facts. ### What this needs, and what it costs [#what-this-needs-and-what-it-costs] * **Business Intelligence must be on** for the agent, or there are no events to count and the Patterns view stays empty. The view itself works on every plan. * **There must be something on the events to count.** A pattern is a repeated [label](/intelligence#what-each-event-records) — a hotel, a product, a topic — so the Patterns view only fills up as fast as your events carry labels worth repeating. Attaching a [business domain](/agents/domain-packs) that fits your work is the single biggest thing you can do here: it tells extraction which labels each kind of event should record. * **Promotion into memory follows the memory rules** — the same three conditions above, so an agent with memory switched off never gains a pattern, on any plan below Startup. * **No extra interactions.** Counting is a database query and the sentence is assembled from the numbers, with no model involved. Patterns cost nothing on top of the events you already have. A promoted pattern appears alongside everything else on the contact's Memory page, and can be edited or removed there like any other remembered fact — and the decision sticks. Reword the sentence and the nightly count keeps your wording; archive it and it is not recreated, even if the customer repeats the behaviour. If the customer later states the preference outright, the stated version takes over. ## What the agent has to hand [#what-the-agent-has-to-hand] The agent always carries a short profile of the person it is talking to — durable things like their name, their role, and how they prefer to be contacted, plus any promoted [patterns](#patterns). That is what makes a returning customer feel recognised from the first message. A stated preference outranks an inferred one when there is only room for a few, so something the customer actually told you is never crowded out by something counted from their behaviour. Everything else — past appointments, errands, previous orders — is looked up only when it is relevant, so an ordinary question is not answered through a pile of old detail. Ask about something specific ("what did I order last time?") and the agent goes and finds it. ## Corrections [#corrections] When a customer changes something they told you earlier — a time moved, a figure revised — the newer version replaces the older one, and the old version is kept as superseded rather than sitting alongside the new one as a contradiction. ## Scopes [#scopes] Each remembered fact has a scope: | Scope | Meaning | | --------- | ----------------------------------- | | Workspace | Applies to every agent and contact | | Contact | Belongs to one [contact](/contacts) | | Session | Limited to a single conversation | ## Managing what is stored [#managing-what-is-stored] Admins can view and edit what an agent remembers about someone from **Contacts → (contact) → Memory**: individual facts and when each one happens, how they relate to each other, session summaries, a searchable graph, and the [patterns](#patterns) counted from their past events. The graph has a search box to find a node by name, and its legend doubles as a filter — click a kind to hide every node of it, and click again to bring it back. Memory stores what customers tell your agent. Review it before enabling memory on an agent that handles sensitive information, and remember that a contact's memory is part of what you must produce or delete if they exercise a data request. ## Rebuilding a contact's memory [#rebuilding-a-contacts-memory] Memory is built once per conversation, when that conversation ends. If memory was switched on after a contact's conversations had already happened, or older memories were captured before recent accuracy improvements, **Rebuild memory** on the contact's Memory page re-reads their past conversations and regenerates what the agent knows about them. Before anything runs you are shown how many conversations will be re-read and what that costs. A rebuild costs **1 interaction per conversation**, and is blocked rather than run if it would exceed your remaining monthly allowance. Old memories are **archived, not deleted** — including the people, companies and products your agents have identified, which are re-created from the same conversations rather than left as they were. That's what lets a rebuild clear out a duplicate or mis-identified entity. Any connection already drawn to an archived entity stops rendering until re-extraction reconnects it to the fresh copy. New memories appear over the following minutes as the rebuild progresses — a banner tracks how many conversations have been re-read so far and stays visible if you navigate away and come back. Clicking Rebuild twice does nothing the second time and costs nothing — conversations already queued for a rebuild are not counted again. Available to **owners and admins**. ## Cost [#cost] Extraction uses a model, and that usage is billed to your workspace. The per-agent toggle is the real cost control — only agents with memory on cause any extraction at all. A long conversation costs more to extract than a short one, because it is read in full rather than sampled. ## Related pages [#related-pages] * [Contacts](/contacts) * [Agents overview](/agents) * [Plans and usage](/organization)