Does Vapi Remember Between Calls?

No. A Vapi assistant remembers everything inside one call and nothing when the next call starts. Vapi keeps a record of every call, with its transcript, summary, and extracted structured data, but the assistant never reads that record on its own. Cross-call memory exists only if you store caller history outside Vapi and inject it when a new call begins.

What does Vapi remember during a call?

Within a single call, memory is complete. The assistant holds the full conversation as it unfolds: what the caller asked, what it answered, which tools it called, and what those tools returned.

That context lives in the call itself. When the caller hangs up, the context window that held it is gone. Nothing carries into the next call, even if the same person calls back five minutes later from the same number.

What does Vapi keep after a call ends?

Quite a lot, and this is where the confusion starts. After each call, Vapi stores:

1. The call record. Transcript, recording, timing, cost, and the assistant and phone number involved, all retrievable from the dashboard or the API.
2. A call summary. Call analysis generates a short summary of what happened, attached to the call record.
3. Structured outputs. You can define schemas for the data you care about, like a caller's name, account number, or issue type, and Vapi extracts and stores the results on the call artifact after the call.
4. A success evaluation. Vapi can score whether the call achieved its goal, using the rubric you configure.

All of that is genuinely useful for reporting, QA, and debugging. None of it is memory the assistant can use. It sits in Vapi's records, written for you to read, and a new call starts without any of it unless you deliberately fetch it and hand it over.

Why doesn't the next call know any of that?

Because a new call is a new model session. The assistant's behavior comes from its configuration: its prompt, its model, its tools, and any variable values supplied for that specific call. Call history is not part of that configuration, and there is no built-in setting that loads a caller's past calls into a new one.

Context can enter a call in only two ways:

• Values you pass at call creation. Outbound calls accept per-call variable values through assistant overrides, so anything the assistant should know has to exist in your own system first.
• Your server's answer at call start. For inbound calls, Vapi asks your server for the assistant configuration when the call begins, and whatever context that response carries is what the assistant starts with.

Either way, the memory lives in your stack, and Vapi consumes it one call at a time.

How do you give a Vapi assistant memory between calls?

You build a small loop around the two moments Vapi already gives you: the start of a call and the end of one.

1. Pick a caller key. The phone number is the obvious default; an account ID from your own system is better when one caller can ring from several numbers.
2. Save at call end. Vapi sends your server an end-of-call report event for every finished call. Use it to store the transcript, the summary, and the structured outputs under the caller key.
3. Recall at call start. Look up the caller key, pull the history relevant to this call, and return it in the call-start response, or attach it as variable values when you create an outbound call.
4. Inject a digest, not a dump. Put a compact brief into the starting context: who this caller is, what happened last time, what is still open. Keep full transcripts in your store for when the assistant needs detail.
5. Scope and prune deliberately. Keep each caller's history separate, decide how long you keep it, and make sure a caller asking to be forgotten actually deletes their stored history.

Run that loop and the second call feels different immediately: the assistant opens already knowing the caller's open issue instead of asking them to explain it again.

Where does a shared memory layer fit?

Steps 2 and 3 mean operating a store yourself: a database, an extraction step, a retrieval step, and the webhook service tying them together, per assistant and per client. A hosted memory layer replaces that middle part. The webhook handler you already run can talk to Vilix AI instead of a database you maintain: the agent you built connects with an API key as a Bearer token to its MCP endpoint, so the same save-at-end and recall-at-start pattern runs against hosted memory, with zero infrastructure on your side. Vilix AI stores full conversation history, not just extracted facts, and retrieval combines semantic search with keyword matching, so a caller is found by what they meant and by exact details like an order number. The memory is shared, too: the voice agent and the other tools working the same client read one store, corrected in one place, with the newest version winning. The free plan is free forever, the 7-day Pro trial needs no credit card, and you can export everything or delete it anytime.

How should you scope memory for a Vapi assistant?

Three scopes cover most builds:

• Per caller. Each phone number or account gets its own history. Right for support lines and receptionists, where one person's context must never leak into another person's call.
• Per assistant. Every caller shares one operational history. Right for a dispatch or booking desk that needs to know what the line has already handled today.
• Per client. If you build voice agents for several businesses, each client's callers and history stay in their own memory space, so one deployment never recalls another client's calls.

Pick the scope before you write the webhook. Retrofitting separation after histories have mixed is the painful version of this project.

Frequently asked questions

Does Vapi have a built-in memory setting I can turn on?

No. There is no switch that carries context from one call into the next. Vapi stores call records, summaries, and structured outputs after each call, but loading any of that into a future call is something your own server does, at call start.

Does the caller ID give the assistant memory automatically?

No. The caller's number arrives with the call, and it is the most useful lookup key you have, but Vapi does not use it to fetch past conversations. Your server receives the number and decides what history, if any, to inject.

Can structured outputs act as memory?

They are the best raw material for it. Structured outputs pull the facts you define out of every call and store them in a predictable shape. They become memory when your call-end handler saves them somewhere keyed by caller and your call-start handler reads them back into a new call.

How is this different from a knowledge base?

A knowledge base holds what your business knows: policies, prices, procedures, the same for every caller. Memory holds what happened with this caller: their last issue, their preferences, what was promised. A complete voice agent needs both.