> ## Documentation Index
> Fetch the complete documentation index at: https://koreai-content-gov.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# General Settings
General settings manage project membership, authentication keys, model availability, runtime behavior, data lifecycle, compile-time variables, and localization assets.
## Members
The **Members** page lets you view and manage who has access to your project and what they can do.
**Navigation**: **Project** → **Settings** → **Members**
The page displays a table of all project members with name, email, role, join date, and a **Remove** action. To add a new project member, click **Add Member**, select an existing workspace member, choose a role, and save.
**Project roles**
| Role | Capabilities |
| ------------- | ---------------------------------------------------------------------------------- |
| **Admin** | Full access: manage members, settings, agents, deployments. |
| **Developer** | Create and modify agents, tools, workflows, imports, and project resources. |
| **Tester** | Read project resources, create and read sessions, run simulations, view analytics. |
| **Viewer** | Read-only access to project resources, sessions, and analytics. |
Click **Remove** next to a member to revoke their access immediately.
***
## API Keys
The **API Keys** page lets you create and manage API keys for programmatic access to the project runtime.
**Navigation**: **Project** → **Settings** → **API Keys**
**Tabs**
| Tab | Purpose |
| ----------------- | ------------------------------------------------------------------------------------ |
| **SDK Keys** | Keys that client-side SDKs and web widgets use to interact with the project runtime. |
| **Platform Keys** | Keys for server-to-server integrations and administrative API access. |
To create a key, click **Create Key**, provide a descriptive name, and optionally set an expiration date. Each key entry shows the key name, a masked key prefix, and the last-used date. Click the **Delete** icon next to a key to revoke it permanently.
Use separate keys for each environment (development, staging, production) and rotate them regularly.
***
## Models
The **Model Configuration** page lets you configure which LLM models are available for agents in this project.
**Navigation**: **Project** → **Settings** → **Models**
Click **Add from Catalog** to browse models from your workspace catalog. The first model you add becomes the default for new agents. Click **Configure Workspace** to manage workspace-level model providers and registrations.
Each model entry shows the model name, provider, supported capabilities (chat, function calling, vision, streaming), token limits, and pricing information.
***
## Runtime Configuration
The **Runtime Configuration** page centralizes the behavioral controls that govern how your agent processes input, handles multi-intent turns, infers missing field values, converts currencies, generates filler messages, protects user data, and validates field values at runtime. Changes take effect for all agent deployments within the project.
**Navigation**: **Project** → **Settings** → **Runtime Config**
Use the **Reset to Defaults** button in the top-right corner to revert all settings to their factory values. Click **Save** to apply any changes.
Each configuration group appears as a collapsible card. Click a card header to expand or collapse it.
**Extraction Pipeline**
The **Extraction Pipeline** section controls how the platform extracts structured field values from raw user messages.
| Field | Description |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Extraction Strategy** | Determines the method the platform uses to extract field values from user input. `auto` selects the best-fit strategy. |
| **Correction Detection** | Sets the method the platform uses to detect when a user corrects a previously provided answer. `ml` uses a machine-learning classifier. |
| **NLU Provider** | Selects the NLU provider for entity extraction and intent detection. `standard` uses the platform's built-in NLU engine. |
| **Sidecar Timeout (ms)** | Maximum time in milliseconds the platform waits for a sidecar response before timing out. Default: `500`. |
| **Circuit Breaker Threshold** | Number of consecutive sidecar failures that trigger the circuit breaker, bypassing the sidecar until it recovers. Default: `5`. |
**Multi-Intent Recognition**
The **Multi-Intent Recognition** section configures how the platform detects and handles messages that express more than one user intent in a single turn.
| Field | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Enable Multi-Intent** | Toggles multi-intent detection on or off. When enabled, the platform attempts to identify and act on multiple intents in a single message. |
| **Strategy** | Defines the execution order for detected intents. `primary_queue` processes intents in priority order. |
| **Unknown Relationship Strategy** | Fallback strategy when the platform can't determine the relationship between detected intents. `parallel` processes all simultaneously. |
| **Max Intents** | Maximum number of intents the platform processes in a single turn. Default: `3`. |
| **Confidence Threshold** | Minimum confidence score (0–1) required to act on a detected intent. Default: `0.6`. |
| **Queue Max Age (ms)** | Maximum time in milliseconds a queued intent remains eligible for processing. Default: `600000`. |
**Field Inference**
The **Field Inference** section enables the platform to use an LLM to infer values for fields the user hasn't explicitly provided.
| Field | Description |
| ----------------------------- | --------------------------------------------------------------------------------------------------- |
| **Confidence Threshold** | Minimum confidence score (0–1) required to accept an inferred field value. Default: `0.8`. |
| **Require User Confirmation** | When enabled, the agent presents inferred values to the user for confirmation before applying them. |
| **Model Tier** | Selects the LLM tier for inference calls. `fast` uses a lower-latency model optimized for speed. |
| **Max Fields Per Pass** | Maximum number of fields the platform attempts to infer in a single LLM call. Default: `3`. |
**Currency Conversion**
| Field | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Currency Mode** | Sets the conversion mode. `static` uses fixed exchange rates configured in the platform rather than live API-based rates. |
**Reasoning Pipeline**
The **Reasoning Pipeline** is an experimental pre-reasoning layer that runs a lightweight classifier before each agent reasoning turn.
**Experimental Feature — Read Before Enabling**
* Requires a configured `tool_selection` model in your LLM provider settings.
* Adds one additional LLM call before each reasoning turn, typically 200–500 ms.
* If the pipeline model fails three consecutive times, the circuit breaker bypasses the pipeline for 60 seconds.
| Field | Description |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Enable Pipeline** | Activates the pre-reasoning classifier and tool filter. Disabled by default. Enable only after configuring a `tool_selection` model. |
**Filler Settings**
**Filler Settings** configure the transient status messages the platform sends to users while the agent processes a response.
| Field | Description |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Fillers Enabled** | Master toggle for the filler system. When off, the platform emits no filler messages. |
| **Chat Fillers** | When enabled, filler messages appear as transient `status_update` messages in chat clients. |
| **Voice Fillers** | When enabled, the agent speaks filler messages aloud on voice channels while processing. |
| **Chat Delay (ms)** | Minimum elapsed processing time before the platform emits a static chat filler. Default: `1200`. |
| **Voice Delay (ms)** | Minimum elapsed processing time before the platform emits a static voice filler. Default: `500`. |
| **Cooldown (ms)** | Minimum interval between consecutive static filler emissions in the same turn. Default: `3000`. |
| **Max Per Turn** | Maximum number of filler messages per agent turn. Default: `5`. |
| **Status Tags** | When enabled, the platform surfaces `` tags that the response model emits inline as filler messages. |
| **Generated Fillers** | When enabled, the platform uses a lightweight LLM call to generate contextual filler messages. Requires **Filler Model**. |
| **Filler Model** | The LLM the platform uses for contextual filler generation. Defaults to the project's runtime default model. |
| **Conversation History** | Number of recent messages (0–20) included in the filler generation prompt for context-aware fillers. Default: `0`. |
| **Previous Fillers** | Number of previously emitted fillers (0–20) included in the prompt to avoid repetition. Default: `0`. |
| **Filler Prompt** | Optional prompt-library override for contextual filler generation. Supports `{{userMessage}}`, `{{conversationHistory}}`, and `{{previousFillers}}` placeholders. |
**PII Redaction**
| Field | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Enable PII Protection** | Activates detection and redaction of PII types across conversations. Baseline credential scrubbing stays active even when off. |
| **Redact Input** | When enabled, the platform redacts PII in user messages before sending them to the LLM. |
| **Redact Output** | When enabled, the platform redacts PII in agent responses before delivering them to the user. |
**Lookup Tables**
The **Lookup Tables** section manages the reference tables the platform uses to validate field values and perform fuzzy matching during extraction.
**Project Canonical** tables defined here are the recommended source of truth for field validation. **Agent-local** `LOOKUP_TABLES` in individual agent configurations remain available for backward compatibility.
Click **+ Add Lookup Table** to create the first table.
***
## Data Retention
The **Data Retention** page configures how long eval transcripts, eval scores, and production score rows remain available for this project.
**Navigation**: **Project** → **Settings** → **Data Retention**
**Retention categories**
| Category | Description | Default |
| ----------------------- | -------------------------------------------------------------- | -------- |
| **Eval conversations** | Retention period for evaluation conversation transcripts. | 730 days |
| **Eval scores** | Duration for which the system stores evaluation score records. | 730 days |
| **Production scores** | Availability period for production scoring data. | 365 days |
| **Synthetic eval runs** | Retention period for synthetic evaluation run data. | 30 days |
**Retention Windows**
Below the summary cards, the **Retention Windows** section lets you edit the TTL (time-to-live) value in days for each category.
| Field | Description |
| ------------------------------------ | ------------------------------------------------------------- |
| **Eval conversation transcript TTL** | Number of days to retain evaluation conversation transcripts. |
| **Eval score TTL** | Number of days to retain evaluation score records. |
| **Production score TTL** | Number of days to retain production scoring data. |
| **Synthetic eval TTL** | Number of days to retain synthetic evaluation run data. |
Click **Save** to apply changes or **Reset** to restore all values to their defaults.
***
## Config Variables
The **Config Variables** page lets you define key-value pairs that the system resolves at compile time through `{{config.KEY}}` syntax.
**Navigation**: **Project** → **Settings** → **Config Variables**
Use config variables to store shared values such as API endpoints, feature flags, and persona-specific content that agents reference across the project. The page shows all defined variables with a filter-by-key search and namespace grouping. Click **Namespaces** to organize variables into logical groups.
### Add a Variable
Click **Add Variable** to create a new entry. Each variable includes the following fields:
| Field | Description |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Key** | Unique identifier for the variable (for example, `API_BASE_URL`). Reference in code as `{{config.KEY}}`. |
| **Value** | The value you assign to the key, which the platform resolves at compile time. |
| **Namespaces** | Logical grouping for the variable. Defaults to **Auto**. |
| **Description** | Optional description explaining the variable's purpose. |
Click the **checkmark** to save or the **×** to discard. You can override variables per deployment environment.
Config variables resolve at compile time. Changes require recompilation to take effect.
***
## Localization
The **Localization** page lets you manage locale JSON assets with a full-width editor and sync them through the existing Git integration.
**Navigation**: **Project** → **Settings** → **Localization**
The page displays the total number of assets, locales, and shared assets. The platform stores locale assets as project-level JSON files and exports them to Git under the same path contract that project import/export uses (for example, `locales/en/_shared.json` or `locales/fr/booking_agent.json`). If Git isn't connected, a status indicator shows **Git not connected** with a link to **Open Git Settings**.
### Create a Localization Asset
Click **New Asset** to open the asset editor. Complete the following fields:
| Field | Description |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Relative Path** | The locale file path in canonical `locale/asset.json` format (for example, `en/_shared.json`). Keep paths in this shape so Git, export, and import round-trip cleanly. |
| **Description** | Optional context for translators and reviewers. |
| **JSON Editor** | Full-width code editor for the locale JSON content. Edit the asset directly in the browser. |
Use **Upload JSON** to import an existing file, or **Prettify** to auto-format the JSON content. Click **Save** to create the asset.