config.conversation decides what a new call starts with. It is the answer whenever someone wants an agent to remember, or to forget, earlier calls with the same person.
Set it on the agent that answers. A handoff target inherits the call already in progress; what it starts with is the handoff’s own context policy, which is a different field — see context policies.
Never write “remember our earlier calls” or “ignore anything from before” into the prompt. A model told to ignore what is in its context is being asked to do the impossible, and a model told to remember cannot see what was never loaded. Set the field.

​
context

​
"none" | "summary" | "transcript"
default:"\"none\""
How much of the past comes into a new call.
none — the default. Every call starts clean. The agent is pointed at a brand new conversation and is told nothing about earlier ones. Those earlier conversations are still saved against that caller and still readable in the dashboard and over the API; the agent does not see them. summary — the agent is told, as background, what happened on recent calls. One system message goes in ahead of everything else, oldest call first, each entry carrying the call’s timestamp, its duration, its outcome where analysis produced one, and the summary itself. It opens with a line that is doing real work:
The summaries come from every past call on that identity, whichever agent took it. A DID’s inbound agent gets changed, or a call is handed off, and the next agent is still briefed on what came before. The current call is excluded. Finding nothing is an ordinary empty result, not a failure: a caller whose earlier calls were all too short to analyse has nothing to be briefed on. transcript — one long conversation across every call. The stored timeline is replayed in full, and a marker is inserted where the replay stops:
Without that line a model reading a continued thread answers as though the last thing it read was said a moment ago. Times in the marker are UTC and say so.
transcript costs what it says: every turn of every past call is in the context of every turn of this one, and you pay for it on your own provider key each time. On a caller who rings weekly, prefer summary.

​
summary_limit

​
integer | null
default:"null"
How many recent calls summary describes. Minimum 1. Leave it empty for all of them. Read only under summary.
The limit keeps the newest calls, and they are then presented oldest first — the order a person tells a story in.

​
initialize_userdata

​
boolean
default:"true"
Start the call already knowing what the agent learned about this person before. Read under summary and transcript only.
This is about userdata, not the transcript. On, the call opens with the person’s contact record as its starting bag; anything the request supplied is layered on top and wins. Off, the call starts with only what the request supplied. A none call always starts empty regardless — it loads nothing, and that includes the contact record.

​
The two hard rules

summary needs call analysis with its summary switched on. Those summaries are what post-call analysis writes; without them the agent would start every call clean and look broken. Publish refuses it:
Both default to on, so this only bites when you have turned one off. In the dashboard, picking that mode switches them back on for you; over the API, the MCP server or a CoPilot, you set them yourself. See call analysis. A text agent is always transcript and cannot be changed. Saving a text agent with any other value normalizes it to transcript, except summary, which is refused outright:
A chat thread has no boundary anyone would recognise: a thread that goes quiet four times is four sessions, and summarizing each would summarize the same thread four times and bill for it four times. initialize_userdata is still a real choice on text — a text agent told not to start from what it knows about this person opens each cold conversation window with an empty bag.

​
How a person is identified

Memory hangs off the person, not the call. That identity is: A web call with no contact_key gets a freshly minted single-use one, so it has no history to continue and leaves none behind that a later call can find. Two calls from the same person arrive as two strangers. If you set conversation.context and your callers come back, send a contact_key. On a phone call the identity is the pair of numbers, so a caller who rings your other DID is a different identity, and a caller who rings from a second handset is too.

​
What each mode actually loads

​
Setting it

Remember that a write takes the whole config — read the current one, change it, send it back. See agent overview.

​
Next

Call analysis

The summaries summary mode reads, and how to switch them on.

Userdata

The contact record initialize_userdata loads.

Context policies

The other context field: what the next agent starts from on a handoff.