General settings - Kore.ai Docs

General settings govern project membership, authentication keys, model availability, runtime behavior, data lifecycle, compile-time variables, and localization assets.

Members

The Members page controls who reaches your project and what they can do inside it. Navigation: Project -> Settings -> Members The page lists every project member with their name, email, role, and join date. Select Add Member to grant access to an existing workspace member, then assign a role. Removing a member revokes their access at once rather than at their next sign-in.

Project roles

A role bundles the permissions a member holds everywhere in the project. Assign the narrowest role that still lets someone do their job, since the roles differ less in what they can see than in what they can change.

Role	Capabilities
Admin	Manages members, settings, agents, and deployments. Assign it to the people who own the project’s configuration, since this role can change anything the other three roles depend on.
Developer	Creates and modifies agents, tools, workflows, imports, and project resources. This is the working role for anyone building the agent.
Tester	Reads project resources, creates and reads sessions, runs simulations, and views analytics. It lets someone exercise the agent thoroughly without risking the configuration they’re testing.
Viewer	Reads project resources, sessions, and analytics. Use it for stakeholders who need reporting rather than the build.

API keys

The API Keys page issues and revokes the credentials that carry programmatic access to the project runtime. Navigation: Project -> Settings -> API Keys

Tab	Description
SDK Keys	Credentials that client-side SDKs and web widgets present to the project runtime. These travel to browsers and devices, so treat them as public and restrict them to the origins that need them.
Platform Keys	Credentials for server-to-server integrations and administrative API access. These stay on infrastructure you control and carry broader authority than SDK keys, so each key holds only the scopes you grant it.
JWT Apps	Client applications that authenticate to the platform with signed JSON Web Tokens (JWTs) instead of a static key. Each app fixes how its tokens are signed and what they must carry, and limits the scopes and environments they can reach.

SDK keys

The SDK Keys tab lists every SDK key in the project, with a count at the top. Each entry shows the key name, a masked prefix (for example, pk_c79197cb...), the origins the key accepts, and the date something last used it. The last-used date is the field that matters during an audit, because it identifies keys you can revoke without breaking anything. To create a key, select + New Key, then complete the fields and select New Key again to confirm.

Field	Description
Key name	Names the key so a later reader knows which application uses it, for example `Production SDK`.
Allowed origins	Optional. Restricts the key to the origins you list, one per line, for example `https://app.example.com`. Wildcards are supported, for example `https://.example.com`. Leave it empty to accept requests from any origin, shown on the key as All origins*. SDK keys travel to browsers, so restrict origins wherever you know where the SDK runs.

Select the pencil icon on a key to edit it, or the trash icon to delete it.

Platform keys

The Platform Keys tab lists every platform key in the project, with a count at the top. Each entry shows the following:

Detail	Description
Key name and status	The name you gave the key. A badge such as Revoked appears when the key is no longer valid.
Masked key	A masked prefix (for example, `abl_d778...`) that identifies the key without exposing it.
Created by	The user who created the key.
Created at	The date and time the key was created.
Lifecycle	When the key expires or, for a revoked key, when it was revoked.
Scopes	The scopes granted to the key. Select Show scopes to see each scope with its description, and Hide scopes to collapse the list.

A revoked key stays in the list for reference, and you can’t edit it. To create a key, select + New Key, then complete the fields and select New Key again to confirm.

Field	Description
Key name	Names the key after the integration that uses it, for example `Workflow Trigger Key`. A key per integration lets you revoke one without disturbing the others.
Scopes	Selects what the key is allowed to do. See Platform key scopes.
Payload encryption	Protects public API traffic across sessions, conversations, LLM logs, traces, and dashboard responses. Encrypt requests encrypts request parameters when you send them as a JSON body with POST. GET query strings are never encrypted. Encrypt responses returns encrypted response envelopes for supported public API reads. For how encryption works end to end, see Payload encryption under JWT apps.
Environments	Grants the key authority to deploy, promote, or roll back in the selected environments (dev, staging, production) through the CI/CD API. Leave all environments cleared for a key that only reads or builds releases. Grant production only to keys that need it.
Expiration	Sets when the key stops working: No expiration, 30 days, 90 days, or Custom date. A key that expires on a schedule limits the damage of a leak you never notice.

Platform key scopes

Scopes limit what a platform key can do. Grant the narrowest set that lets the integration work, because a key with broad scopes is a broad risk if it leaks. Scopes are grouped into the following categories:

Category	Description
Execution	Run the project’s agents and workflows and work with their sessions.
Management	Manage project resources through the API.
Knowledge Base	Work with knowledge base content through the API.
Analytics	Read analytics and reporting data.
Admin	Perform administrative operations on the project. Grant these rarely.

Deleting a key revokes it permanently and immediately. Anything still presenting that key stops working, so confirm the last-used date before you delete.

Issue a separate key for each environment and rotate them on a schedule. A single shared key means one compromise forces you to rotate everywhere at once.

JWT apps

A JWT app lets a client application authenticate with tokens it signs itself, so the platform never holds a long-lived key that the client has to send with every request. Use a JWT app when you need short-lived, verifiable credentials, one-time-use tokens, or encrypted payloads. The JWT Apps tab lists every JWT app in the project, with a count at the top. Each entry shows the following:

Detail	Description
App name and status	The name you gave the app, with a badge such as Active that shows whether the app can authenticate.
Client ID	The identifier the platform assigns to the app (for example, `cid_4fa3…e5df`). Your client uses it to identify the app when it presents a token.
Algorithm	The signing algorithm the app verifies tokens with.
Created by	The user who created the app.
Lifecycle	When the app expires, or No expiration.
Enforcement and access badges	The enforcement options that apply to the app (for example, JTI enforced), the scopes granted to it, and the environments it can reach.

Select Show scopes to see each scope with its key (for example, workflows.execute) and description, and Hide scopes to collapse the list. Use the icons on an entry to rotate, edit, or delete the app.

Create a JWT app

Select + New App to open the Create JWT App wizard. It has three steps: Signing, Scopes, and Access. Select Back to return to a previous step, and Create app on the last step to finish.

The signing algorithm and the enforcement options are fixed once you create the app, because every token issued against the app is bound by them. To change either, create a new app.

Step 1: Signing

Field	Description
App name	Required. Names the app after the application that uses it, for example `Claims Intake`.
Signing algorithm	Required. Sets how the platform verifies your tokens: RS256, RS512, HS256, or HS512. Every key you register is bound to the algorithm, so changing it means creating a new app.
JWKS URL	For RS256 and RS512, the URL of your JSON Web Key Set, for example `https://example.com/.well-known/jwks.json`. The platform fetches it to verify tokens.
Public key (PEM)	For RS256 and RS512, the public key itself. Paste the full PEM block, beginning with `-----BEGIN PUBLIC KEY-----`.

RS256 and RS512 verify tokens against your own key, so you must provide either a JWKS URL or a public key, but not both. Use a JWKS URL when you rotate keys, since the platform picks up new keys without a change to the app. Never send your private key. Under Enforcement, select the rules every token must meet:

Option	Description
Require a JTI claim	Each token must carry a unique `jti` and can be presented only once. A retry needs a freshly signed token. Use it to stop a captured token from being replayed.
Require an encrypted token	The signed token must arrive wrapped in a JWE envelope encrypted to the platform key. The platform rejects a bare signed token. see Introduction to JWT tokens
Require encrypted request and response bodies	Request bodies must arrive as a JOSE envelope encrypted to the platform key, and the platform returns response bodies encrypted. This is separate from token encryption: it protects the data, not the credential. See Payload encryption.

When you select Require encrypted request and response bodies, the following field appears:

Field	Description
Response encryption public key	Required. Paste the public key (PEM) that the platform encrypts responses to, beginning with `-----BEGIN PUBLIC KEY-----`. Only you hold the matching private key, so only your client can read the responses. Use a different key pair from your signing key, because reusing one key for both signing and encryption weakens both.

Streaming, attachment, and recording endpoints can’t carry an encrypted body, so the platform refuses requests to them from an app that requires encrypted bodies. You can’t change this enforcement after you create the app.

Step 2: Scopes Select the scopes the app can use. Scopes are grouped into the same categories as platform keys: Execution, Management, Knowledge Base, Analytics, and Admin. For the scopes in each category, see Platform key scopes. Grant the narrowest set that lets the application work. Step 3: Access

Field	Description
Project	Shows the ID of the project the app belongs to.
Environments	Grants the app authority in the selected environments (dev, staging, production). Leave all environments cleared to allow every environment the project exposes. Because an empty selection allows all environments, select environments explicitly for any app that shouldn’t reach production.
Expiration	Sets when the app stops working: No expiration, 30 days, 90 days, or Custom date. Select Pick a date to choose the date for a custom expiration.

Payload encryption

When you select Require encrypted request and response bodies, the platform accepts only encrypted request bodies from the app and returns encrypted response bodies. A request or response captured in transit or in a log is then unreadable without the matching key. It covers public API traffic for sessions, conversations, LLM logs, traces, and dashboard responses. Request bodies must arrive as a JOSE envelope encrypted to the platform key. The platform encrypts response bodies to the Response encryption public key you registered on the app, so only you can decrypt them with your private key. Encryption applies to the JSON body of POST requests. GET query strings are never encrypted, so don’t put sensitive values in them. Payload encryption protects the data rather than the credential, so it works alongside Require an encrypted token, not instead of it. Streaming, attachment, and recording endpoints can’t carry an encrypted body, so an app with this enforcement can’t use them. If your integration needs those endpoints, use a separate app without this enforcement.

Use a separate JWT app for each client application and environment, so you can revoke one without disturbing the others.

Models

Use the Models page to choose which models your project can use and which model handles each platform feature. It has two tabs:

Model Configs: choose the models available to the project.
Feature config: assign models to individual features.

Navigation: Project > Settings > Models

Model Configs

Use this tab to select the models your project can use. Only selected models appear in the project’s model pickers and feature routing. The Model access rollout banner at the top of the tab shows whether the project is limited to its selected models. See Model access rollout. Below the banner, two counters summarize the selection:

Counter	Description
Selected models	The number of models you’ve selected for the project.
Eligible models	The number of models your workspace makes available to the project.

The Selected models list shows every model you’ve selected. Each entry shows the following:

Detail	Description
Model name and connection	The model’s name and the connection it uses, for example `Claude Sonnet 4.5 · Connection 3`.
Provider and scope	The model’s provider (for example, `anthropic` or `openai`), and whether the model is Workspace-shared or Project-restricted.
Status	Whether the model’s connection works: Ready, Not tested, Connection failed, or Inactive.
Project default	A badge that marks the model the project uses as its default. See Project default.

Select the pencil icon on a model to edit its settings, or the X icon to remove it from the selection. The settings you can edit depend on the model. They can include:

Enable thinking
Compaction threshold
Verbosity
Max completion tokens

To change the selection, select Add models, choose from the eligible models, and then select Save selection. At the bottom of the tab, a counter shows how many eligible models you’ve selected, for example 2 of 43 eligible models selected. Only project administrators can change the selection. Other roles see the tab as read-only. If a selected model is no longer available to the project, the tab shows a warning. Select Remove unavailable models to clear them, and then replace them as needed.

Project default

The project default is the model the project uses when no more specific setting applies. It applies to this project only and doesn’t change the workspace.

Choose a default. Use the Project default (this project only) field next to Save selection. Select the field to open a list that contains No project default and each of the project’s selected models. A check mark shows the current default. The default must be one of the selected models. In a project that uses selected models only (see Model access rollout), you must choose a default before you can save more than one selected model.
If the default becomes unavailable. Features that use the project default switch to the next available selected model. Features assigned directly to a specific model don’t switch, and they stop working until you fix or replace that model. Once a project uses selected models only, the platform never uses a model that isn’t selected. The platform doesn’t retry a failed request with another model.

Model access rollout

The Model access rollout banner shows whether your project is limited to its selected models. New projects are limited from the start. Existing projects move over in stages, and the banner shows the current stage. When a project is limited to its selected models and has nothing left to resolve, the banner reads This project uses selected model bindings only. No unresolved references are recorded. The banner also shows the number of unresolved references. A warning banner means the project needs repair before it can be limited to selected models. The count isn’t an error in your current setup.

Feature config

Use this tab to assign models to platform features. Different features need different models. Assigning a smaller, faster model to simple tasks and a stronger model to complex ones lowers cost. The Per-operation routing switch turns feature routing on or off for the project. When it’s off, every feature uses the project default, and any saved tier models and overrides are kept but ignored. When it’s on, each feature uses the model assigned to its tier, so changing a tier’s model changes every feature on that tier. You can also assign a specific model to a single feature. Use overrides only when a feature needs something different, because they’re easy to forget. If feature routing is turned off for your whole deployment, the switch is unavailable and the tab shows a notice. Your saved settings are kept and apply again when routing is turned back on.

Tiers

Assign one of the project’s selected models to each tier.

Tier	Use it for
Fast	High-volume, simple tasks where low cost matters most.
Balanced	Everyday work.
Powerful	Complex tasks that need the best judgment, at higher cost and slower speed.
Voice	Real-time speech-to-speech conversations.

If a tier has no model, its features use the project default. If you configure a tier but no ready model matches it, the features on that tier can’t run. The page warns you about missing models and broken connections before you release the project.

Features

Features are grouped by area: Arch, Runtime, Knowledge, Insights, Evals, and Pipelines. Each row shows the following:

Column	Description
Tier or override	Whether the feature uses its tier’s model or a model you assigned directly. You can only assign selected models.
Resolves to	The model the feature actually uses. Check this column when troubleshooting.
From	Why that model was chosen: a feature override, a tier, or the project default.
Status	Whether the feature can run (see the following table).

Status	Meaning
Ready	The feature uses a working model.
Not tested, Connection failed, Inactive, Unknown	The model’s connection isn’t confirmed working. Check the model’s connection.
Not configured	No model is assigned.
Off	The feature is turned off.
Unavailable	The platform doesn’t support running this feature yet.

Select Why this model? on a row to see how the model was chosen. Select Save feature config to apply your changes.

Runtime configuration

The Runtime Configuration page holds the behavioral controls that govern how the project’s agents read input, handle multiple requests in one turn, fill in unstated values, tune voice latency, recover from failures, occupy callers during waits, expose their own activity, protect personal data, and bound their own tool use. Navigation: Project -> Settings -> Runtime Config Changes here apply to every agent deployment in the project, so treat this page as project-wide policy rather than per-agent tuning. Each group appears as a collapsible card. Select Save to apply changes, or Reset to defaults to return every setting on the page to its factory value.

Extraction pipeline

This section decides how the runtime turns a raw user message into structured field values.

Field	Description
Extraction Strategy	Chooses which extraction stages run and in what order. Language detection and resolution always run, whatever you choose. The default, Auto, runs the stages in sequence: pattern matching runs first, the ML model extracts fields the patterns didn’t match, and the LLM extracts anything still missing. Auto gives the best overall accuracy. Change it when your fields sit at one extreme or the other, either structured enough that a model call is waste, or conversational enough that patterns alone leave fields unfilled. The ML stage supports English, French, Spanish, Italian, and Portuguese. For other languages, extraction falls back to the LLM stage.
Confidence Threshold	Sets the minimum confidence an extracted entity needs before the runtime accepts it. Accepts values from 0.0 to 1.0 inclusive. Default: 0.50. Raise it when the agent accepts values the user didn’t give, and lower it when the agent keeps asking for values the user already supplied.
Include Confidence	Attaches confidence scores to extracted entity values. On by default. Turn it on when downstream logic or analytics needs to see how certain an extraction was.

Multi-intent recognition

Multi-Intent allows an agent to handle multiple customer requests instead of treating the conversation as having only one active request. The multi-intent configuration controls how these requests are identified, queued, offered, and completed.

Field	Description
Enable Multi-Intent	Turns on detection of several intents in one message. On by default. Turn it off for narrow transactional flows, where a second detected intent is more often a misread than a real request.
Multi-Intent engine	Determines how multi-intent requests are managed. Legacy uses the existing multi-intent behavior. Governed adds controls for managing pending requests, offers, and specialist interactions. Legacy is the default.
Pending request offers	Controls how pending requests are offered to the user while another request is being handled. For Governed mode.
Interpret replies to offers	Controls whether the runtime interprets the user’s response to a pending-request offer. Required in Governed mode.
Request view for specialists	Controls the level of access specialists have to the customer’s request: Off, Inspect, or Manage.
Offer reply model	Specifies the model used to generate responses when the runtime offers a pending request to the user.
Strategy	Sets the order in which the runtime works through detected intents. The choice decides whether the user gets a fast answer to their first request or waits while the agent works the whole message. Default: `primary_queue`.
Unknown Relationship Strategy	Chooses the fallback for same-turn supervisor routing when relationship data isn’t available. Relationship data normally decides ordering, so without it the runtime needs a standing instruction rather than a judgment. Default: `parallel`.
When’s a request finished?	Determines when the runtime considers one customer request complete before moving to the next queued request. Applies only to the `primary_queue` strategy. FLOW agents and agents with COMPLETE conditions always finish based on their completion conditions. Default: When the agent replies. Recommended: When the agent confirms it is done.
Capture every request in one routing decision	When enabled, the supervisor identifies all user requests during the initial routing decision so additional requests in the same message are not missed. Recommended when using two or more specialist agents.
Max Intents	Caps how many intents the runtime acts on in one turn. Default: 3. Each additional intent comes from a less certain reading of the message, so raising this raises the chance of acting on something the user didn’t ask for.
Confidence Threshold	Sets the minimum classifier confidence needed to act on a detected intent. Default: 0.6. Raise it when the agent answers requests the user didn’t make, and lower it when the agent ignores genuine second requests.
Queue Max Age (ms)	Sets how long a queued intent stays eligible for handling. Default: 600000 (10 minutes). It stops the agent from returning to a request the user has since abandoned or resolved another way.

Multi-intent strategies

Value	Behavior
`primary_queue`	Handles the first intent immediately and queues the rest, addressing them in sequence once the primary completes.
`sequential`	Addresses intents one at a time in detection order, finishing each before starting the next.
`parallel`	Dispatches all intents at once and resolves them concurrently.
`disambiguate`	Asks the user which request to handle first.
`auto`	Lets the runtime choose based on the intent relationship and conversation context.

ENABLED_WHEN and multi-intent routing: When multiple requests are routed in parallel or sequentially, ENABLED_WHEN is evaluated independently for each target route. Routes that do not satisfy their availability condition are excluded from the routing plan and are not executed.

Unknown relationship strategies

Value	Behavior
`sequential`	Addresses the intents one at a time in detection order.
`parallel`	Handles the intents concurrently.
`disambiguate`	Asks the user which intent to prioritize.

Learn More

Field inference

This section lets the runtime use an LLM to infer values the user hasn’t stated, which shortens conversations at the cost of occasionally guessing wrong.

Field	Description
Confidence Threshold	Sets the minimum confidence needed to accept an inferred value. Default: 0.8. Inference trades accuracy for fewer questions, and this field is where you set that trade.
Require User Confirmation	Presents inferred values to the user before the agent applies them. On by default. Keep it on wherever a wrong inference costs money or changes a record, since confirmation is far cheaper than reversal.
Model Tier	Selects the tier that serves inference calls. Default: `fast`. Inference runs often and on small decisions, so this choice affects per-turn latency more than most model settings.
Max Fields Per Pass	Caps how many fields one inference call attempts. Default: 3. Fewer fields per pass means more calls, each of them more reliable.

Currency conversion

This section decides where exchange rates come from when an agent quotes or converts an amount. Agents that never handle money can leave it alone.

Field	Description
Currency Mode	Selects whether the runtime converts currency using static rates held in the platform or live rates fetched from an API. Default: `static`. Static rates keep results reproducible across a conversation and across environments. Live rates keep them current. Choose on whether your users compare quotes over time.

Reasoning pipeline

The reasoning pipeline runs a lightweight classifier ahead of each reasoning turn so the runtime can route programmatically and narrow the tool set before the main model call.

Experimental feature. Read before enabling.

The pipeline needs a configured tool_selection model in your LLM provider settings. Without one, the pipeline skips silently rather than reporting an error.
It adds one extra LLM call before each reasoning turn, typically 200-500 ms. In parallel mode, the classifier and tool filter run simultaneously.
If the pipeline model fails three times in a row, a circuit breaker bypasses the pipeline for 60 seconds so the failure doesn’t add latency to every turn.

Field	Description
Enable Pipeline	Runs the classifier ahead of reasoning to enable short-circuit routing and tool filtering. Everything else in this section depends on it.
Execution Mode	Decides whether the classifier and tool filter run together or one after the other. Parallel runs them simultaneously, which costs less time. Sequential waits for the classifier result before deciding whether to run the tool filter at all. Default: `parallel`.
Pipeline Model	Selects the model that performs intent classification. Default uses the project’s `tool_selection` model. The pipeline runs on every turn, so this choice sets a recurring latency and cost floor for the whole project.
Short Circuit	Skips the reasoning loop when classifier confidence is very high. Most of the pipeline’s latency saving comes from here, and so does most of its risk, because no reasoning step follows to catch a misclassification.
Short Circuit Threshold	Sets the minimum confidence (0.0-1.0) a classification needs before the runtime routes programmatically. Default: 0.85. Treat it as the safety margin on short-circuiting.
Tool Filter	Reduces the tool set sent to the LLM based on classifier analysis. Large catalogs degrade tool selection accuracy, so filtering helps most in projects that expose many tools.
Max Tools	Caps how many tools reach the reasoning loop. Default: 6.
Keyword Veto	Overrides classifier routing when specific keywords appear. Use it for terms where you’d rather not depend on a classifier judgment at all.
Veto Keywords	Holds the comma-separated keywords that trigger the veto, for example `refund, cancel, complaint`.
Intent Bridge	Maps classifier output to session state so WHEN conditions and multi-intent dispatch can read it. Without it, the classifier’s work stays inside the pipeline and your authored logic can’t act on it.
Programmatic Threshold	Sets the confidence needed for Tier 1 actions, where the runtime declines or routes without a model call (auto-decline, auto-route). Default: 0.85.
Guided Threshold	Sets the confidence needed for Tier 2 guided reasoning, where the runtime keeps the reasoning loop but shapes it by hiding tools and adding routing hints. Default: 0.5. Set it below the programmatic threshold, since guided actions leave the model room to recover and programmatic ones don’t.
Out-of-Scope Decline	Declines out-of-scope queries programmatically, without an LLM call. It removes a model call from every off-topic turn, which pays off most on public channels where off-topic volume runs high.
Multi-Intent Signal	Injects multi-intent hints into the reasoning turn when the classifier detects two or more intents.

Tool call policy

This section bounds the deterministic CALL actions that tool lifecycle hooks invoke. The limits apply only to those hook-driven calls. Side-effecting target tools still run through the normal confirmation flow, so this section doesn’t weaken confirmation.

Field	Description
Boundary CALLs Enabled	Allows tool lifecycle hooks to invoke another tool deterministically. On by default. Turning it off removes an entire class of chained behavior, so confirm nothing depends on it before you do.
Max CALL Depth	Caps nested boundary CALL depth in a single turn. Default: 3. The runtime clamps this value to 5 even if you save a higher one, so use this field to set a stricter limit than the platform’s own, not a looser one.
Max CALLs Per Turn	Caps boundary CALL fan-out across one runtime turn. Default: 8. The runtime clamps this value to 20 even if you save a higher one. Fan-out limits matter more than depth limits, because a single wide hook can issue far more calls than a deep chain.

Streaming safety

This section sets project-level controls for how the runtime behaves when a safety check intervenes on a response that’s already streaming. It’s the one safety control where timing matters as much as outcome.

Existing projects stay on Legacy passthrough until you change this setting.

Field	Description
Safety Mode	Decides how the runtime handles final-output safety interventions for streaming responses. The difficulty is timing: by the time an intervention fires, part of the response may have reached the user. Review the value explicitly rather than assuming the project runs current behavior.

Safety modes

Value	Behavior
Legacy passthrough	Keeps the behavior that existed before this setting. Default for projects created before the setting was introduced.
Buffered	Holds streamed output back until the safety check completes, so nothing unchecked reaches the user. Adds delay before the first words appear.
Gated	Releases streamed output in stages as each portion passes the safety check.
Terminate forward	Stops sending further output when an intervention fires. Text already delivered stays with the user.
Retract capable	Allows the runtime to retract output already delivered when an intervention fires, on channels that support retraction.

Output item analytics

Runtime responses often carry repeated structures such as a list of results. This section captures those repeated scalar items so you can run independent analytics queries on them.

Mappings are project-scoped and additive. The runtime captures only the item arrays you configure and the scalar dimensions you declare. It doesn’t store raw response JSON in analytics rows.

A counter at the top shows how many mappings you’ve configured out of the 25 allowed. Select Add mapping to create one. Mappings only take effect for responses produced after you add them, so declare a dimension before you need it. You can’t recover a field retrospectively.

Field	Description
Mapping key	Names the stable analytics category for this item family. Queries group on this key, so keep it stable once collection starts. Renaming it splits your history into two unrelated series.
Item array path	Absolute response path to the repeated array, such as `$.items[*]`.
Item key path	Optional relative path, such as `id`, that gives each item a stable identity across responses. Set it when you need to follow the same item over time rather than count occurrences.
Max items	Caps the rows captured per response for this mapping. Default: 25. It bounds what an unusually large response costs you in analytics writes.
Description	Optional author-facing note explaining what the repeated item represents. It’s the only place a later reader learns why the mapping exists.
Item dimensions	Declares the scalar fields inside each item that the runtime records. A counter shows how many of the 50 allowed dimensions you’ve configured. Select Add dimension to declare one, each with a name, a path, and a type. The runtime doesn’t store fields you don’t declare. With no dimensions configured, rows still include the mapping, session, trace, and item metadata.

Select the trash icon on a mapping to delete it.

Voice low-latency profile

This section holds channel-scoped defaults for fast voice responses. It tunes model routing, reasoning, context size, and filler behavior for voice while preserving semantic response quality, and explicit developer overrides still take precedence. It appears for projects with a voice channel. When the project has an active voice channel but the recommended defaults aren’t applied, a banner reads Recommended voice defaults are not active. Select Apply recommended defaults to apply the low-latency profile in one step: fast model routing, inline gather, bounded context, and generative filler defaults.

Voice setting differences

The Voice setting differences table compares each voice setting’s current value with the recommended one, so you can apply the profile wholesale or adopt it setting by setting. Select Apply on a row to apply only that recommendation, or Apply recommended defaults to apply them all. The rows shown depend on the profile version and on which settings your project already has. The recommended profile changes these groups of settings:

Group	What the profile sets
Profile	Selects the `customer_service_voice_low_latency_v1` profile.
Model routing	Moves `response_gen`, `reasoning`, `coordination`, and `summarization` to the `fast` tier.
Reasoning	Turns extended reasoning off (`reasoning.enabled` = `false`) and sets effort to `none`.
Execution	Turns on inline gather (`execution.inline_gather`).
Compaction	Bounds how much context voice carries into each turn. Covers tool results (`compaction.tool_results`), prior turns (`compaction.prior_turns`), and prompt context (`compaction.prompt_context`). Tool results use structured compaction with a 16000-character maximum and a 4000-character structured threshold.
Fillers	Sets how spoken fillers are generated and bounded. Covers the generation strategy, native generative filler, the voice delay, pending-tool status nudges, output limits (tokens and characters), and the generation budget.
Session	Controls synchronous session compaction (`session.synchronousCompaction`). It stays off on the live voice path.

Each row carries a tag that tells you what kind of change it makes:

Tag	Meaning
`latency`	Changes speed or cost only.
`semantic_risk`	Can change how the agent reasons, so review these rows individually before you apply them. The reasoning settings carry this tag.
`operational`	Changes how the runtime operates rather than how fast it responds or how the agent reasons.

Applying the recommended defaults overwrites your current values for every row listed. To keep a setting, apply the rows one by one instead.

Profile settings

Field	Description
Profile	Shows the applied profile name and version, for example `customer_service_voice_low_latency_v1 · v1`. Versioned profile metadata is preserved in project export and import.
Voice model routing	Sets the model tier for each semantic operation on voice: `response_gen`, `reasoning`, `coordination`, `summarization`, `tool_selection`, `extraction`, and `validation`. Fast is the voice default for semantic operations. `realtime_voice` stays on the voice-capable tier (`voice`).
Reasoning/thinking	Toggle plus a level dropdown (`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`). The profile disables extended reasoning by default for latency. Explicit agent and project settings still win.
Inline gather	Merges entity gathering into the reasoning turn, which removes a separate model call.
Prompt context targets	Bounds voice prompt context before generation. Default values: 6000 and 16000. Required fields and semantic tool outputs remain subject to tool contracts.
Tool-result compaction	Uses structured projections first so voice doesn’t add a serial summarization call, while preserving essential tool fields. Settings: Strategy (`structured`), Max tool-result chars (16000), Structured threshold (4000), Recent results to keep (1), Tool description chars (80), and Summary timeout (ms) (1500).
Prior-turn compaction	Keeps a compact semantic preview of prior turns without running synchronous session compaction. Settings: Strategy (`compact`) and Assistant preview chars (120).
Prompt projection	Bounds projected context while retaining the current request and complete small structured results. Settings: Auto tool-result chars (2000), Projection strategy (`preview`), and Include complete small results (on).
Generative filler bounds	Sets the limits for generated fillers. The opener must be ready within the generation budget (at most 2 seconds) or the static fallback plays. Later lines in the same streamed batch can still arrive as follow-ups. Each line must be sayable in about 4 seconds. Defaults: 2000, 160, and 4000.

Filler strategy and coordination

Native speech-to-speech (S2S) fillers are preferred when the provider advertises the capability. Pipeline generation and static speech remain bounded fallbacks.

Field	Description
Generation source	Chooses where fillers come from. Default: `s2s_preferred_then_pipeline_llm`, which uses the provider’s native filler when available and falls back to a pipeline-generated one.
Earliest voice delay (ms)	Sets the earliest point at which a voice filler can play. Default: 300.
Follow-up gap (ms)	Sets the pause between a filler and the next follow-up line. Default: 1200.
Native S2S delay (ms)	Sets the delay before a native S2S filler plays. Default: 300.
Pending-tool nudges	Sets how many filler nudges can play while a tool is pending. Default: 1.
Pending-tool deadline (ms)	Sets how long the runtime waits on a pending tool before nudging. Default: 2000.
Max fillers per turn	Caps fillers in a single turn. Default: 5.
Allow native generative filler	Lets the provider’s native S2S generate fillers. On by default.
Allow pipeline generative filler	Lets the pipeline LLM generate fillers when native generation isn’t available. On by default.
Filler history messages	Sets how many recent messages the filler generator sees. Default: 0.
Previous fillers	Sets how many already-emitted fillers the generator sees, to avoid repetition. Default: 0.
Max output tokens	Caps the length of a generated filler. Default: 32.
Native S2S filler prompt	Optional provider instruction for native fillers, for example `Keep the caller informed briefly while the request is processing.` Immutable safety rules remain enforced by the runtime.

Synchronous session compaction stays disabled on the live voice path. Adjust prompt and tool-result projections instead, so the authoritative turn retains its semantic contract.

Channel recovery and graceful failure

The Channel Recovery and Graceful Failure policy defines how Runtime responds when model generation, tool execution, provider communication, or voice operations are delayed, interrupted, or fail. It enables channel-specific recovery behavior with bounded recovery, localized messages, sequential model fallback, and safe latency hedging, while preserving conversation state and preventing duplicate or invalid actions.

Recovery is opt-in per channel. Existing channels keep their current behavior until you enable this policy on that channel. Voice uses the voice adapter. Other channels use their native progress and response semantics.

Recovery policies are versioned. Publishing a policy doesn’t apply it to any channel until you turn on that channel’s opt-in.

Setting	Description
Policy Status	Sets whether the policy is in Draft or Published state, shown alongside the policy version (for example, v1). Runtime reads only published policies. Drafts are stored for review and don’t change live sessions.
Default Locale	Sets the fallback locale for a published recovery message when the caller’s locale isn’t available. Default: `en-US`.
Channel Opt-in	Turns recovery on for individual channels: Voice, Web chat, SDK/WebSocket, and Messaging. All channels are off by default, and only the channels you turn on apply this policy.
Parent turn deadline (ms)	Sets the hard upper bound for the complete recoverable interaction. Default: 30000. It’s separate from voice filler and TTS budgets. When the deadline is reached, Runtime stops waiting and begins the configured recovery flow.
Progress acknowledgement delay (ms)	Sets how long Runtime waits before emitting a bounded, channel-appropriate progress update. Default: 1200. This helps reduce perceived silence during recoverable delays.
Recovery retries	Sets the maximum retry attempts for policy-approved transient failures. Default: 1. Side effects and unknown outcomes are never blindly retried.
Allow progress updates	Keeps the interaction active with localized progress while authoritative work is pending. On by default.
Enable safe request hedging	Lets Runtime race duplicate requests to cut latency. Off by default. Runtime only races same-model, streaming, cancellable requests. Unknown or mutating tools fail closed, while platform-certified read-only tools use a plan-only race and execute at most one winner.
Sequential model fallback	Turns on fallback to alternate model or provider candidates after a recoverable model failure, with a field for how many candidates Runtime may try (default: 1). Runtime selects fallback candidates only after capability, safety, tool-contract, and channel checks.
Model/provider candidates	JSON array of ordered fallback model or provider candidates. Default: `[]`. Keep the logical model choice separate from provider selection, and mark hedge eligibility only for pure generation.
Localized recovery message catalog	JSON array of localized, versioned message records that Runtime uses during recoverable delays and failures. Each record has a `key` (for example, `recovery.tool_waiting`), `channel`, `locale`, `text`, `allowedVariables`, `maxCharacters`, `status`, and `version`. Use only allowlisted variables. The catalog rejects internal error codes and executable markup. Runtime picks the message that matches the conversation locale.

While the caller waits

This group configures what a caller experiences while the agent thinks or works: spoken filler phrases, background hold-music audio, or both together. The settings interact, so read the whole group before you change any one part.

How filler settings take effect. Agent no-input messages and channel-specific Gemini settings take precedence over these project defaults. Otherwise, Runtime uses project filler pools and timing, then localized platform defaults. Native realtime fillers are available only for the voice_realtime tier. Genesys realtime supports pending-tool fillers but not the native coordinator filler.

Filler settings

Fillers are transient chat and voice status messages the runtime emits while work is in progress. They exist because silence during a long turn reads as a failure, particularly on voice. When the agent is processing a request, Runtime waits for the configured delay before playing a filler message. Depending on the configuration and channel capabilities, it can play a static filler, generate a contextual filler, or use provider-native realtime fillers until the final response is ready.

Field	Description
Fillers Enabled	Master switch for the filler system. With it off, nothing else in this section emits anything.
Chat Fillers	Shows `status_update` messages in chat clients.
Voice Fillers	Speaks status updates on voice channels. Voice needs fillers more than chat does, because a chat user can see that something is in progress and a caller can’t.
Filler language default	Sets the fallback language for filler speech when the session has no explicit language. Use a BCP 47 tag such as `en-US`.
Filler language override	Forces all generated and static fillers to use this language, regardless of the session language. Use a BCP 47 tag such as `en-US`.
Chat Delay	Sets the delay before static chat fillers are emitted. Default: 1200 ms. Set it above the time a normal turn takes, so fillers mark genuinely slow turns rather than interrupting fast ones.
Voice Delay	Sets the delay before static voice fillers are emitted. Default: 500 ms. Callers tolerate silence for less time than chat users, so this typically sits below the chat delay.
Follow-up Gap	Voice only. Sets the pause after a filler finishes playing before the next generated follow-up line (800-3000 ms). Default: 1200 ms. Follow-ups continue until the answer starts or the per-turn limit is reached.
Native realtime turn delay	Sets the delay before the native Gemini realtime hold phrase. Default: 500 ms. It’s independent from normal voice fillers.
Cooldown	Sets the minimum interval between fillers across turns. Default: 3000 ms. Generated voice follow-ups within one turn are paced by the follow-up gap instead.
Max Per Turn	Caps fillers emitted during one turn. Default: 5.
Pending-tool status nudges	Sets the upper bound for native Gemini pending-tool progress messages per turn. Default: 3. Max Per Turn also limits the effective cap.
Contextual filler deadline	Sets the maximum wait (ms) for a generated pending-tool filler before the runtime uses the fallback, when static fillers are enabled. Default: 500.
Static Fillers	Use pre-written phrases when no contextual filler is available. On voice, static fillers open the wait when no generated line is ready and continue a long wait after the generated lines run out. Up to 3 generated lines can be used with the built-in or custom filler prompt. Turning this off means a long wait gets only the generated lines, and a line that fails checks is never replaced.
Localized static filler pools (JSON)	Locale-keyed phrase arrays used by chat, voice-pipeline, and native realtime fillers. On voice, each phrase is spoken at most once per turn, so add at least as many phrases per language as the maximum fillers per turn; when every phrase has been used, the caller hears no further fillers that turn.
Localized status-tag instruction (JSON)	Defines locale-specific instructions for generating status updates before tool calls.
Status Tags	Uses the status tags the response model emits as fillers, which lets the model say what it’s actually doing instead of emitting a generic wait message.
Generated Fillers	Enables LLM-generated contextual filler messages instead of static filler text. Runtime uses a lightweight model to generate wait messages that are relevant to the current conversation. This provides more natural progress updates while adding a small amount of processing time during long-running operations.
Include emitted filler in agent context	Lets later same-turn voice reasoning account for a contextual filler the runtime already emitted. It doesn’t add the filler to conversation history, so this changes what the agent knows within the turn rather than what the transcript records.
Filler Model	Selects the model that generates contextual fillers.
Output Tokens	Caps the response length for built-in contextual filler generation. Fillers should be short, and a low cap enforces that more reliably than the prompt does.
Prompt Override Tokens	Caps the response length when a filler prompt override is in use. Overrides usually ask for more than the built-in prompt does, which is why they carry a separate limit.
Conversation History	Sets how many recent messages the filler prompt includes. More history makes fillers more specific and each generation call more expensive.
Previous Fillers	Sets how many already-emitted fillers the prompt includes. Its purpose is avoiding repetition within a turn, so it matters most when the max per turn runs high.
Filler Prompt	Selects a prompt-library version that replaces the built-in filler prompt. Select Clone built-in to start from the platform’s prompt rather than an empty one. The prompt accepts placeholders for the user message, the conversation history, and previously emitted fillers.

Background audio

Background audio is looped hold music the voice gateway plays during compute waits. It covers silence without the agent having to say anything.

Field	Description
Background Audio Enabled	Plays uploaded hold audio while the agent works.
Audio File	Holds the WAV or MP3 clip the gateway fetches.
Start Delay	Sets the silence before the audio begins. This is the field that most often stops background audio from working: a spoken filler interrupts the audio, so a filler that arrives first prevents the audio from starting at all. Either lower this delay or raise the spoken filler delay so one has room to begin before the other.
When To Play	Chooses when background audio plays. Select at least one option. Between sentences plays only when barge-in is enabled and the text-to-speech voice supports streaming. When barge-in is disabled, background audio plays only Before the agent starts responding.

Greeting audio

Greeting clips play as soon as a call connects, ahead of the agent’s first turn. They cover the gap between answer and first response, which is the moment a caller is most likely to think the line is dead.

Activity updates

This section sets the visibility policy for what the runtime reveals about its own work. The policy is a ceiling rather than a guarantee, because channels apply only what they support. The exposure settings deserve particular care. Tool, workflow, and agent names describe your internal architecture, and a name that helps an internal user diagnose a problem tells an external user how your system is built.

Field	Description
Fillers	Exposes the status messages generated while runtime work is in progress.
Action Progress	Exposes progress for memory, knowledge, workflow, tool start, and retry events. It’s the safest form of progress reporting, since it says work is happening without saying what.
Tool Preview	Controls whether tool input and output previews are hidden or redacted. Previews can carry data the user supplied moments ago, so redaction and hiding aren’t equivalent choices.
Decisions	Exposes safe decision labels as action progress.
Thought Summaries	Exposes model and step thinking summaries when the runtime emits them. Summaries explain reasoning that the agent may not stand behind in its final answer, so exposing them can raise questions the response then contradicts.
System Notices	Exposes authentication, approval, and waiting-for-input notices. These usually need to stay visible, because they tell the user that the agent is waiting on them rather than working.
Debug Details	Exposes redacted debug activity meant for internal review.
Expose Tool Names	Shows tool names in activity messages.
Expose Workflow Names	Shows workflow and step names.
Expose Agent Names	Shows agent names where the channel supports it. In multi-agent projects this reveals that a handoff occurred, which reads as competence internally and as confusion externally.
Maximum Text	Caps visible characters per activity update.

Voice no-input defaults

This section sets what happens when a voice caller goes silent. Silence is ambiguous, since it can mean the caller is thinking, has walked away, or didn’t hear the prompt, and these settings decide how long the agent waits before treating it as a problem.

Field	Description
Enabled	Turns on no-input handling for voice sessions.
Mode	Chooses between authored prompts and contextual generated prompts. Generated prompts fall back to the authored and default prompts, so choosing them adds a behavior rather than replacing one.
Timeout	Sets the silence that must pass before a no-input prompt fires. Too short interrupts a caller who’s reading something out, and too long lets a caller believe the call has dropped.
Max Retries	Sets how many no-input prompts the agent issues before it takes the terminal action.
Relaxed Interval	Sets the extended timeout interval used in dynamic mode.
Play Order	Sets the order in which no-input messages play.
Play Style	Sets how messages repeat across retries. Repeating the same prompt signals a system that isn’t listening, so this choice affects how a stuck caller reads the failure.

Caller backchannel

This section sets the project default for caller backchannel acknowledgements. These are language-neutral sounds, such as “uh-huh”, that the runtime treats as acknowledgements rather than interruptions, so the agent keeps speaking. Every agent that doesn’t set its own backchannel inherits these defaults.

Field	Description
Enabled	Turns on backchannel handling for the project.
Phrases	Holds the acknowledgement phrases. This is one set for all callers, regardless of language, and the runtime sends it to the voice gateway. Type a phrase and press Enter to add it.

Backchannel is only effective with at least one phrase. If you turn it on without adding any, the page shows the warning Backchannel is on but has no phrases.

On hold

This section sets the project default for phrases a caller says to make the agent pause, such as asking it to wait a moment. Phrases are locale-aware. Every agent that doesn’t set its own on-hold behavior inherits these defaults. On hold runs entirely in the runtime and needs no gateway change.

Field	Description
Enabled	Turns on on-hold detection for the project.
All locales (base)	Holds phrases that apply in every language. Use it for phrases that work regardless of locale.
Add language	Adds a language-specific phrase list. Select a language, then add the phrases callers use to ask for a pause in that language.
Grace (ms)	Sets the grace period that applies to a hold. Default: 30000.
Max holds	Sets the maximum number of holds allowed. Default: 2.
Suppress reply	Controls whether the agent suppresses its reply when it detects an on-hold phrase. Off by default.

On hold is only effective with at least one phrase. If you turn it on without adding phrases in any language, the page shows the warning On-hold is on but has no phrases in any language.

Barge-in continuation window

When a caller interrupts (barges in) and speech recognition splits their sentence into separate phrase-finals, this section makes the runtime hold each one briefly and merge any follow-on phrase into a single turn. Without it, the agent would treat each fragment as its own turn and may answer a half-finished sentence. This is a project-wide default, and an agent can override it.

Field	Description
Enabled	Merges segmented barge-in speech into one turn. On by default. Turn it off to commit each phrase immediately, which is the legacy behavior.
Continuation window (ms)	Sets how long the runtime holds a barge-in final while waiting for a continuation before it commits. Range: 300-2000 ms. Default: 700. A longer window catches slower speakers but delays the agent’s response.
Maximum hold (ms)	Sets the absolute ceiling on how long one turn can be held, regardless of merges. Range: 500-8000 ms. Default: 2500.
Maximum merges	Sets the most phrase-finals the runtime folds into one committed turn. Range: 1-20. Default: 4.
Maximum characters	Sets the most characters of merged transcript before the runtime forces a commit. Range: 1-20000. Default: 2000.

Voice speech recognition

These are project-wide defaults. A channel connection can override them, so check the connection before you conclude the project value is what’s running.

Field	Description
Default minimum STT confidence	Rejects transcripts below this confidence and treats them as no-input. Confidence scores are provider-relative rather than absolute, so a value that works for one speech provider won’t carry over to another. Calibrate in staging before you set it in production, and set it to zero to disable the gate entirely.

Voice speech delivery

This setting controls how the voice gateway sequences the agent’s speech with transfers, hang-ups, and surveys.

Field	Description
Streaming-say speech delivery	Enables streaming speech delivery on Pipeline Voice channels, allowing the gateway to track when each response finishes before proceeding with transfers or hang-ups.

PII redaction

This section controls how the runtime handles personally identifiable information in conversations. Baseline credential and secret scrubbing protects logs and read APIs whether or not PII protection is on, so the settings here extend that protection rather than establishing it.

Field	Description
Enable PII Protection	Detects and redacts PII in conversations. It’s the switch the rest of this section depends on.
Redact Input	Redacts PII in user messages before they reach the model. Redaction is context-aware and exempts fields the agent is actively gathering, so turning it on doesn’t break a flow that legitimately asks for a phone number.
Redact Output	Redacts PII in agent responses before delivery. Its purpose is stopping the agent from echoing back PII the user already provided, which is a common way collected data reaches a transcript.
Classify explicit DTMF using project PII patterns	Matches a completed keypad entry to the project’s enabled PII patterns, so a recognized value carries a type and a validation status while anything else stays a generic token. Raw digits never reach the model either way, so this setting changes how an entry is labelled rather than whether it’s protected.
Detection methods allowed	Sets the ceiling on which detection engines the project’s patterns may use. Each pattern still selects its own method on the PII Protection page, so this field decides what’s available to them rather than what they do.

This redaction policy is project-wide. For a specific tool that needs to see the original, unredacted values despite it, see PII access (pii_access) in the ABL tools reference.

Lookup tables

Lookup tables are the reference data the runtime uses to validate field values and perform fuzzy matching during extraction.

Project lookup tables defined here are the canonical source for gather validation and fuzzy matching. Agent-local LOOKUP_TABLES remain available only as an experimental compatibility lane, so build new work on project tables.

Field	Description
Table Name	Names the table for reference from field validation.
Source	Selects where the table’s values come from, which decides whether you maintain them here or elsewhere.
Values	Holds the comma-separated values for an inline table.
Case Sensitive	Requires an exact case match. Leave it off for anything a user types, since typed input rarely matches your stored casing.
Fuzzy Match	Accepts near matches. It rescues misspellings and transcription errors at the cost of occasionally accepting a value the user didn’t mean, so it suits voice input more than typed input.

Data retention

The Data Retention page sets how long evaluation and scoring data stays available to this project. Navigation: Project -> Settings -> Data Retention Retention is a deletion policy rather than a storage preference. Once a window passes, the data is gone and no longer available for trend analysis, so set these values around the longest comparison you expect to run rather than the storage you expect to use.

Category	Description
Eval conversations	Holds evaluation conversation transcripts. Transcripts are what let you re-read a failed evaluation rather than only seeing that it failed.
Eval scores	Holds evaluation score records. Scores outlive their usefulness more slowly than transcripts, since trend comparison needs the numbers rather than the conversations.
Production scores	Holds production scoring data, which is the basis for the quality trends in Insights.
Synthetic eval runs	Holds synthetic evaluation run data. These runs are reproducible on demand, which is why they carry the shortest window.

The Retention Windows section below the summary sets the time-to-live in days for each category. Select Save to apply changes or Reset to restore defaults.

Config variables

The Config Variables page defines key-value pairs that the platform resolves at compile time through {{config.KEY}} syntax. Navigation: Project -> Settings -> Config Variables Use config variables for values that several agents share and that change between environments, such as endpoints, feature flags, and persona-specific content. The alternative is repeating the value in each agent, which turns an endpoint change into an audit.

Add a variable

Each variable is one key the platform substitutes wherever your agents reference it. The fields below define the key, its value, and the context a later reader needs. Select Add Variable, then complete the fields.

Field	Description
Key	Uniquely identifies the variable and forms the reference used in code. Changing a key later breaks every reference to it, so settle naming before the value spreads.
Value	Holds what the platform substitutes at compile time. You can override it per deployment environment, which is the mechanism that lets one project target different endpoints.
Namespaces	Groups related variables so a large set stays navigable.
Description	Explains what the variable is for. It’s the only context a later reader gets when deciding whether a variable is safe to change.

Config variables resolve at compile time rather than at runtime, so a changed value reaches your agents only after recompilation.

Localization

The Localization page manages locale JSON assets in Studio and syncs them through the project’s Git integration. Navigation: Project -> Settings -> Localization The platform stores locale assets as project-level JSON files and exports them to Git under the same path contract that project import and export use. Keeping paths in the canonical shape is what lets assets round-trip cleanly, so a path you improvise here becomes a merge problem later. Counters at the top report the assets, locales, and shared assets the project holds. A status indicator reports when Git isn’t connected, with a link to Open Git Settings. Until you connect Git, assets stay in project storage and don’t reach version control, which means no diffs and no review. Search by locale, file path, or description, and narrow the list by locale or by scope when the asset count grows past browsing.

Create a localization asset

An asset is one locale JSON file holding translated strings, either shared across the project or scoped to a single agent. Creating one here puts it under the same path contract Git and project export use. Select New Asset to open the editor, then complete the fields and select Create. Saving writes the asset into project storage and keeps the Git export path aligned.

Field	Description
Relative Path	Sets the locale file path in the canonical locale and asset shape. This path determines where the asset lands in Git and whether import and export find it again. The path also indicates whether the asset is shared by all agents or used by a specific agent.
Description	Gives translators and reviewers the context the JSON itself doesn’t carry.
JSON Editor	Edits the locale content directly. Select Upload JSON to bring in an existing file, or Prettify to reformat what’s there.

For shared messages : Use a shared locale asset for messages that can be used by multiple agents. For example: ‘locales/en/_shared.json`.
For Agent specific messages: Use an agent-specific locale asset for messages used by a particular agent. For example: ‘locales/en/agent_name.json, where agent_name` is the name of the agent which can use this asset.

Use Localized Messages in ABL

Reference localized messages in ABL using the {{locale.<key>}} syntax.

AGENT: SupportBot

FLOW: main
  LISTEN
  RESPOND: {{locale.greeting}}

  LISTEN
  RESPOND: {{locale.menu}}

The same localization key retrieves the message for the resolved language.

​Members

​Project roles

​API keys

​SDK keys

​Platform keys

​Platform key scopes

​JWT apps

​Create a JWT app

​Payload encryption

​Models

​Model Configs

​Project default

​Model access rollout

​Feature config

​Tiers

​Features

​Runtime configuration

​Extraction pipeline

​Multi-intent recognition

​Field inference

​Currency conversion

​Reasoning pipeline

​Tool call policy

​Streaming safety

​Output item analytics

​Voice low-latency profile

​Voice setting differences

​Profile settings

​Filler strategy and coordination

​Channel recovery and graceful failure

​While the caller waits

​Filler settings

​Background audio

​Greeting audio

​Activity updates

​Voice no-input defaults

​Caller backchannel

​On hold

​Barge-in continuation window

​Voice speech recognition

​Voice speech delivery

​PII redaction

​Lookup tables

​Data retention

​Config variables

​Add a variable

​Localization

​Create a localization asset

​Use Localized Messages in ABL

Members

Project roles

API keys

SDK keys

Platform keys

Platform key scopes

JWT apps

Create a JWT app

Payload encryption

Models

Model Configs

Project default

Model access rollout

Feature config

Tiers

Features

Runtime configuration

Extraction pipeline

Multi-intent recognition

Field inference

Currency conversion

Reasoning pipeline

Tool call policy

Streaming safety

Output item analytics

Voice low-latency profile

Voice setting differences

Profile settings

Filler strategy and coordination

Channel recovery and graceful failure

While the caller waits

Filler settings

Background audio

Greeting audio

Activity updates

Voice no-input defaults

Caller backchannel

On hold

Barge-in continuation window

Voice speech recognition

Voice speech delivery

PII redaction

Lookup tables

Data retention

Config variables

Add a variable

Localization

Create a localization asset

Use Localized Messages in ABL