Agent behavior settings attributes

These are platform-level switches that control overall agent behavior, covering multi-location support, testing mode, HITL monitoring, calendar context injection, products and services compilation, and other runtime flags. They are hidden from the standard UI and only visible when you enable the Show Hidden toggle on the Attributes page. This article documents each attribute's purpose, type, default, and accepted values.

Business locations

Identifier: project_business_locations Type: String | Default: (empty)

::: ❗❗ IMPORTANT

This attribute is marked as important in the platform. If your AI Employee serves more than one physical location, you must configure this attribute for multi-location routing to work correctly. Leaving it empty disables location-aware reasoning and conversation location-switching. :::

Use this attribute to list all business locations when you operate in more than one place. It helps the AI Employee identify which location a user is asking about and route location-specific context correctly during conversations.

Enter one location per block and include the same core details for each location — name, address, phone number, and any location-specific notes. When multi-location mode is active, the platform transforms this field into internal location records used for location-aware reasoning and location switching during conversations.

Example format:

Downtown Office
Address: 100 Main St, Austin, TX
Phone: +1 (512) 555-0100

North Office
Address: 2400 Cedar Ave, Austin, TX
Phone: +1 (512) 555-0199

When locations are saved, the platform generates two derived system attributes automatically: a normalized index list (project_attributes_private_dynamic_business_locations_indexes) and a description map (project_attributes_private_dynamic_business_locations_object). These derived values power runtime location selection and are not intended to be edited manually.

Scenario

Identifier: project_attributes_scenario Type: Enum | Default: Default Scenario

This attribute selects which scenario set the AI Employee uses for your current business setup. Use Default Scenario for standard, system-managed behavior. Change to Custom Scenario only if your account is explicitly configured for a custom scenario workflow.

The value acts as a label dimension combined with project_business_industry for AKB topic selection, task-instruction retrieval, and intent-type-map template selection. It also scopes any RAG topics appended to the knowledge base so that content stays within the same industry and scenario context.

Possible values:

• Default Scenario — The AI Employee uses system-provided scenario mappings for your industry. Intent-type-map and AKB topic resolution follow standard industry defaults.
• Custom Scenario — The system expects a custom scenario configuration. If scenario-labeled intent-type-map templates are missing, the system falls back to industry default templates.

::: 🗒️ NOTE

When this setting is Custom Scenario, default restaurant workflow AKB topics are not auto-created during restaurant AKB initialization. If you switch to a custom scenario, verify your AKB content is in place before going live. :::

Calendar injection

Identifier: project_attributes_setting_calendar_injection_is_enabled Type: Boolean | Default: True

This attribute controls whether the system refreshes generated calendar context and injects it into a gated prompt path for date reasoning. When enabled, that path receives an up-to-date calendar block that improves how the AI Employee interprets date-related requests.

• True: The system refreshes generated calendar context during the background preparation cycle and injects calendar context in the gated prompt path.
• False: The gated prompt path skips calendar injection and the background generation step does not refresh calendar context. Previously stored calendar data can still appear in other prompt and runtime paths.

::: 🗒️ NOTE

Disabling this attribute does not globally remove calendar context from all runtime consumers. Other date-reasoning paths — such as availability checks, meeting setup, and structured extraction — may still reference previously generated calendar data. If your workflows are date-sensitive, test behavior carefully after disabling. :::

Keep this enabled unless you are intentionally managing date context another way. If you disable it, verify that all date-sensitive flows still behave as expected.

Products and services — structured representation

Identifier: project_attributes_setting_products_and_services_structured_representation_enabled Type: Boolean | Default: False

This attribute controls whether products and services data is compiled into a structured JSON-style format before runtime use. Enable it when your catalog is large or complex and you need more reliable service and product matching behavior.

• True: Runtime builds a structured JSON-style product and service representation from your offerings and not-offering lists.
• False: Runtime keeps a non-structured text representation of offering and not-offering items.

During attribute-preparation cycles, the compiled result is reused across prompt and context assembly as well as product and service validation paths. If both source product and service fields are empty, compiled output is cleared. If source values and mode are unchanged, recompilation is skipped.

HITL monitoring

Identifier: project_attributes_setting_hitl_monitoring_enabled Type: Boolean | Default: False

This attribute enables or disables Human-in-the-Loop (HITL) monitoring outputs for support and quality operations. Start with this disabled during early setup, then enable it once your team is ready to review and triage monitoring signals consistently.

• True: Session-ended monitoring payloads are sent to HITL reporting endpoints. Magic-browser reservation workflows can also emit extra operational alerts for manual checks.
• False: HITL-specific monitoring commands are not sent.

When enabled, end-session logic sends a send_hitl_report command through the API webhook connector with conversation and performance fields — including summary, success indicator, potential revenue, channel, and version metadata. In reservation-related magic-browser task handling, this flag also gates Slack notification dispatch for success and failure operational alerts.

::: 🗒️ NOTE

HITL monitoring and magic-browser alert emails (project_attributes_setting_magic_browser_alert_enabled) are independent paths. Disabling one does not disable the other. :::

HITL — magic browser alerting

Identifier: project_attributes_setting_magic_browser_alert_enabled Type: Boolean | Default: True

This attribute controls whether alert emails are sent when magic-browser task execution fails after retry attempts. Keep this enabled unless you already have an equivalent incident-alert channel in place, so that failed automated booking tasks are not missed.

• True: Failure alerts are emailed with task context for manual follow-up.
• False: No magic-browser failure alert email is sent.

When retries are exhausted, this flag gates sending an email_worker_send_email alert with an "ACTION REQUIRED" subject and diagnostic context, including business information, manager contacts, bot response, and task context. The recipient is a fixed internal operations mailbox — this setting controls whether the alert is sent, not where it is routed.

::: 🗒️ NOTE

This attribute is planned for future renaming and expansion so alerting can cover broader issue categories beyond magic-browser failures. :::

Testing — test mode

Identifier: project_attributes_setting_test_mode Type: Boolean | Default: False

::: ❗❗ IMPORTANT

This attribute is marked as important in the platform. Always verify that test mode is set to False before going live. Leaving it enabled in a production environment suppresses real booking and calendar actions and replaces them with simulated responses, which means appointments and meetings will not be created even if conversations appear successful. :::

This attribute switches booking and meeting scheduling flows into test behavior to reduce external side effects. Use it only for controlled validation of booking and calendar logic.

• True: Runtime suppresses selected external scheduling actions and uses simulated success paths and events. Mock events such as result_success and create_event_success_mock are injected in place of real outbound commands. Task-routing logic also switches to simulated worker-message behavior.
• False: Runtime sends real scheduling and task actions according to your configured booking and calendar integrations.

Conversation-side status and persona updates still run in test mode, so test sessions can closely resemble real end-to-end flow behavior. This makes it useful for validating booking logic without triggering live external calls.

Time format

Identifier: project_attributes_setting_time_format Type: Enum | Default: 12-hour format (hh:mm A)

This attribute defines how the AI Employee formats time values in availability-check payloads and availability response guidance. Match this format to your users' regional expectations and keep it consistent across all scheduling-related messages.

• 12-hour format (hh:mm A): Availability logic expects and presents times in 12-hour AM/PM style (for example, 2:30 PM).
• 24-hour format (HH:mm): Availability logic expects and presents times in 24-hour style (for example, 14:30).

Possible values:

• 12-hour format (hh:mm A)
• 24-hour format (HH:mm)

Runtime injects this format into booking and availability schemas and instructions, and uses it when composing user-facing guidance about available slots and requested times. This setting is especially relevant when project_attributes_setting_booking_check_availability_enabled is active, as generated booking payload expectations reference the configured time format directly.