Recording and privacy

By default, sessions record: audio, video frames, transcripts, and tool events are persisted server-side as session artifacts. That default is right for debugging, quality review, and the session debugging workflow — and wrong for some products. The switch is per run.

Recording opt-out

const session = await agent.start({ storeRecording: false });

async with agent.start(store_recording=False) as session:
    ...

let session = try await agent.start(storeRecording: false)

store_recording: false means the server writes nothing: no audio, no transcript artifact, no tool-event log. It's not redaction-after-the-fact — the artifacts are never created. The live session is unaffected; events still stream to your client, and anything you capture there is yours to govern.

Per-artifact control

store_recording is all-or-nothing, and some products need one class of artifact but not another — keep the audio for quality review while never persisting what was said, or keep the transcript while never storing a voice. Three fields address the classes separately.

const session = await agent.start({ storeAudio: true, storeTranscript: false });

async with agent.start(store_audio=True, store_transcript=False) as session:
    ...

let session = try await agent.start(storeAudio: true, storeTranscript: false)

Three rules decide what a run persists:

• An artifact field wins over store_recording. { storeRecording: false, storeAudio: true } persists the audio and nothing else — useful when the macro expresses your default and one class is the exception.
• Unset means "as much as allowed" — store_recording if you sent it, otherwise whatever the account's consents permit.
• A request can only narrow. Asking to store an artifact the account has opted out of does not store it. A session can always persist less than the account allows, never more.

That last rule is why these fields are safe to set from a client: the floor is the account's consent, not the request.

Policy choices

• Record (default) while you're building: recorded sessions are the raw material for debugging, prompt iteration, and evals.
• Don't record when the content is inherently sensitive — healthcare intake, financial details, screen share of arbitrary user desktops — or when your own privacy policy promises it.
• Decide per run, not per product. store_recording is a session param precisely so the same agent can record a QA test call and not record a real patient call.

Consent

Recording consent is a product obligation the SDK can't discharge for you, but the primitives line up:

• Put the disclosure where the conversation starts: in your UI before connecting, or in the agent's greeting for phone calls ("this call may be recorded…"). Call-recording disclosure is a legal requirement in many jurisdictions — treat the greeting as the compliance surface for outbound dials.
• If consent is asked inside the conversation, start the session with store_recording: false and restart recording-enabled (carrying context through resume_session_id) once the user agrees — the declined path never had artifacts to delete.
• Session state and transcripts you mirror client-side are outside store_recording's scope; apply your own retention policy to anything you copy out of the event stream.

What the client keeps regardless

store_recording governs the server. Your client still receives transcripts, tool events, and (if you consume them) raw audio frames in real time. If your product must guarantee "nothing retained anywhere", audit your own handlers too: don't log transcript events, don't buffer agent_audio() to disk, and scrub analytics payloads.