Skip to main content

Intro

The Configuration section explains how Voxtronics bot configuration works and how to write the TOML files that define a runtime environment.

A Voxtronics bot is configured by composing named building blocks; each block has a clear responsibility. Together, they define how an incoming call is accepted, which assistant is used, which AI provider handles the conversation, and which actions the assistant is allowed to perform.

This documentation focuses on the Bot configuration and explains how to configure:

  • Providers
  • Transports
  • Modalities
  • Personas
  • Functions
  • Adapters
  • Policies
  • Profiles
  • Intent Routing
  • SIP Routing

The goal is to help users understand not only what each section means, but also how the sections relate to each other.

Configuration file format​

Voxtronics runtime configuration is written in TOML (and JSON).

TOML is used because it is readable, explicit, and works well for nested configuration.

A configuration file is organized into tables:

[providers.openai]
model = "gpt-realtime"
voice = "alloy"

[profiles.main]
persona = "concierge"
policy = "default"
realtime = "openai_realtime_voice"

The table name defines where the values belong.

For example:

[providers.openai]

defines the openai provider inside the providers registry.

[profiles.main]

defines the main profile inside the profiles registry.

Supported configuration style​

You will see three common styles.

Standard tables​

Use standard tables for named objects.

[personas.concierge]
instructions = "Be concise, friendly, and confirm caller intent before actions."
welcome_message = "Welcome to ACME services."

Inline tables​

Use inline tables for short configuration values.

deepgram_rt = { provider = "deepgram", transport = "deepgram_rt" }

Inline tables are useful when the object is small and easy to read on one line.

Array tables​

Use array tables when defining multiple ordered entries.

[[routing.sip]]
profile = "main"

[routing.sip.match]
called = ["1000", "concierge"]

Array tables are commonly used for routing rules and pipeline steps.

Logical dependency map​

The configuration can be read as a dependency graph.

  1. Incoming SIP call
  2. SIP routing selects profile
  3. Profile selects persona, policy, and modality
  4. Modality selects provider and transport
  5. Assistant handles the conversation
  6. Intent router selects adapter
  7. Adapter executes the action

Reference rules​

Many configuration values are references to named entries in other sections.

For example:

[profiles.main]
persona = "concierge"
policy = "concierge"
realtime = "deepgram_rt"

This requires:

personas.concierge
policies.concierge
realtime.deepgram_rt

Likewise:

[realtime]
deepgram_rt = { provider = "deepgram", transport = "deepgram_rt" }

requires:

providers.deepgram
transports.deepgram_rt

Suggested configuration workflow​

When creating a new environment, configure the runtime in this order:

  1. Store Providers secrets in the Vault.
  2. Define providers.
  3. Define transports.
  4. Bind them through modalities.
  5. Define the assistant behavior.
  6. Define Functions and Adapters.
  7. Define the Policy.
  8. Define the Profile.
  9. Define Intent routing.
  10. Define SIP routing.

This order reduces missing references and makes the runtime easier to reason about.