Skip to main content
Two ways to define an assistant: store it on the platform, or send the whole config inline with every request.

​
Stored assistants

Create once on the portal or via POST /v1/realtime-assistants, get an assistantId, reference it everywhere: web sessions, phone calls, campaigns.
  • Your team can tweak the prompt on the portal and publish it, no deploy needed
  • Same assistant across web, phone and campaigns
  • What you publish is what’s live, one source of truth — see Draft and publish

​
Transient assistants

Send the full config in the request itself with POST /v1/realtime-assistants/adhoc/session (the API calls these adhoc). Nothing to manage on the portal — the throwaway record deletes itself.
  • The prompt lives in YOUR code, right next to your app logic
  • Iterate on instructions by editing code, no update call to us
  • Great for a dev loop: change prompt, run, listen, repeat
  • A/B test prompts without creating anything

​
The middle path (usually all you need)

Keep a stored assistant, override per call. Both fields go on the call request:
  • additionalInstructions: free-form instructions appended to the prompt, for THIS call only
  • variables: structured key/values (crop: cotton, visit day: Tuesday), rendered into the prompt as the caller record on every call and returned with the session details
Campaigns fill variables automatically from each contact’s details. Example: one field visit assistant, and every farmer gets their own crop and disease in the prompt. Transient or stored, calls get transcripts and analytics the same way.

​
Which one?

When unsure, I recommend stored + per-call overrides.