Passing data between assistants

Assistants in a call share variable values across completed handoffs. A destination can read those values even when its contextEngineeringPlan excludes earlier conversation messages. Start with the value’s source:

If the value comes from…	Use…	What happens
The handoff decision, such as classified intent	Handoff arguments	The outgoing model fills custom `function.parameters` in the handoff tool call. Every argument except `destination` is saved as a variable.
Conversation content that needs a dedicated extraction request	Destination schema extraction	Vapi extracts an object from the outgoing assistant’s currently available conversation and saves its properties.
A previous tool’s JSON response	Tool-result aliases	Aliases on the result-producing tool select fields to save. The raw response is not automatically saved as variables.
A standard call value or a value already saved	Liquid in the destination prompt	The destination reads it with `{{variableName}}`; Liquid does not create a value.

For the history modes, value precedence, configuration paths, and a two-hop example, see Pass context and variables.

Approach 1: Handoff arguments

Define custom function.parameters on the handoff tool when the outgoing assistant should supply a value as it routes the caller. The model fills these arguments in the same tool call that initiates the handoff. For example, a customerIntent argument becomes {{customerIntent}} for the destination; destination only selects where the handoff goes.

Configure custom parameters on a saved or inline handoff tool through the API or the Dashboard Tools page. A squad member’s Handoff Tools destination setting creates a handoff tool without custom function.parameters, so configure the tool itself when you need arguments. See the handoff argument example.

The model produces these values. For an ID from a database or another trusted system, extract the exact field from the result-producing tool with an alias instead of asking the model to repeat it.

Approach 2: Variable extraction

Put variableExtractionPlan.schema on the handoff destination when a value must be assembled from conversation content. Vapi makes a separate extraction request against the outgoing assistant’s available conversation and adds the returned top-level properties before the destination starts.

This path adds a model request at handoff time. Extraction is best effort: if the request fails or returns a non-object, the handoff continues without new extracted values. An earlier history filter can limit what the extraction request sees. See the destination schema example.

Approach 3: Liquid templating

Use Liquid when the value is already available. This includes supported standard call and time variables, custom values supplied at call start, handoff arguments, earlier schema extraction, and values selected from tool results with aliases.

You are the scheduling specialist. The caller's number is {{customer.number}}.
Their patient ID is {{patientId}} and their requested date is {{preferredDate}}.

The prompt only reads these values. If patientId came from a lookupPatient response, configure an alias on that tool to save the exact response field first. Check that a value exists before depending on it in the destination prompt.

Combining approaches

An A → B → C flow can use more than one method. A can hand off to B with a model-generated customerIntent argument. B can run a lookup tool with an alias that saves patientId, then hand off to C with contextEngineeringPlan.type set to none. C gets a fresh message history but can still render {{customerIntent}} and {{patientId}} from the shared variable bag. Later values with the same key replace earlier ones.

For destination setup, see the Handoff tool and Configure handoff destinations.