> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Overrides

> Prepare a narrow policy for caller-supplied conversation settings and distinguish permission flags from override values.

Overrides describe which settings a caller may supply when starting a conversation. Keep this policy narrow: a personalized first message usually needs less freedom than replacing the prompt or attached resources.

<Note>
  This guide covers policy authoring and read-back. The documented conversation-start paths are currently gated, so a saved override policy does not establish working session customization.
</Note>

## Policy flags and caller values

The agent's permission flags live under `platform_settings.overrides.conversation_config_override`. These are booleans that describe whether a setting may be overridden. They are different from the values a future session request would supply.

| Policy group | Fields that can be allowed |
| - | - |
| `agent` | `first_message`, `language`, `max_conversation_duration_message` |
| `agent.prompt` | `prompt`, `llm`, `tool_ids`, `native_mcp_server_ids`, `knowledge_base` |
| `conversation` | `text_only`, `max_duration_seconds` |
| `tts` | Supported speech override flags, including `voice_id` and `pronunciation_dictionary_locators` |
| `turn` | Supported turn-configuration override flags |

The individual permission flags default to `false`. Review the exact nested schema in [Get agent](/api-reference/agents-platform/get-agent) before adding a field.

## Prepare a least-access policy

<Steps>
  <Step title="Choose the necessary customization">
    Prefer [dynamic variables](/agents-platform/configure/personalization/dynamic-variables) for named text values. Only allow broader configuration replacement when the application has a clear need and can validate the caller's request.
  </Step>

  <Step title="Keep resource selection controlled">
    Treat prompt, model, tool, and knowledge overrides as significant changes. An allowed override does not grant access to another workspace's resources or replace authorization in the service handling an action.
  </Step>

  <Step title="Save the policy in a draft">
    Preserve the agent's other platform settings and save a complete [server draft](/agents-platform/deploy/versioning). Read back the permission flags and confirm that only the intended fields are allowed.
  </Step>

  <Step title="Prepare accepted and rejected examples">
    Record a valid caller request and a request that should be denied for each enabled field. Keep runtime verification pending until a supported conversation-start path is available.
  </Step>
</Steps>

Other flags under `platform_settings.overrides` include `enable_starting_workflow_node_id_from_client`, `enable_procedure_ids_from_client`, `custom_llm_extra_body`, and `enable_conversation_initiation_client_data_from_webhook`. They default to `false`. Enabling one does not release workflow execution, custom-model publication, or webhook delivery.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does allowing an override change the saved base value?" id="faq-overrides-base">
    The policy records permission to supply a conversation-specific value. Editing the base agent configuration is a separate operation; inspect both the policy and base settings in the draft.
  </Accordion>

  <Accordion title="Can an override bypass a publication restriction?" id="faq-overrides-gates">
    No. Do not use an override flag as a workaround for unavailable voice, custom-model, or conversation execution paths.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.