Are the vapi agents aware of which mode the user is initiating the session from, i.e call vs chat? Because for us, depedning on the mode we'd want to communicate a bit differently. Wondering if just updating the system prompt with instructions on each mode will suffice?

Vapi distinguishes between call and chat modes by including headers in requests to your tools or backend. For example, MCP tool requests include

X-Call-Id

for calls and

X-Chat-Id

for chats. You can use this in your backend to set a mode-specific system prompt or logic. Example:

js
if (headers['X-Call-Id']) {
  // Set system prompt for call mode
} else if (headers['X-Chat-Id']) {
  // Set system prompt for chat mode
}

This lets you tailor communication style based on the session mode. According to the documentation, updating the system prompt alone may not suffice unless you pass the mode context yourself via your integration logic. Source: - [MCP Tool Documentation](https://docs.vapi.ai/tools/mcp)

Hi mathusan, - Vapi provides the transport context variable {{transport.conversationType}} you can use in the system prompt to let the assistant adapt behavior for "chat" vs "voice" (see docs: https://docs.vapi.ai/assistants/dynamic-variables). - For API flows: if you send chats using sessionId/previousChatId or calls via the /call endpoints, Vapi will set transport.conversationType automatically so the assistant can see the mode. Use that variable in your prompt to switch style/formatting (examples in the doc). - If your backend or tools receive MCP requests, the headers (e.g., X-Call-Id vs X-Chat-Id) are a reliable way to enforce mode-specific system prompts or server-side logic before forwarding to Vapi — useful when you need immediate programmatic control beyond the assistant's internal prompt. Recommendation: put mode-specific rules in the assistant prompt using {{transport.conversationType}} for most cases; use header-based mode detection in your integration when you must override or change system prompts/tool behavior mid-call.