Skip to main content
Version: 0.9.13

Node catalogue

The Flow Designer canvas mixes two families of nodes. Conversation nodes are the steps that actually run when a session is in progress. Virtual nodes explain what surrounds the conversation — where the call comes in, which providers transcribe / generate / speak, what actions the agent can take.

Both are clickable; both have inspectors on the right.

Conversation nodes​

These are the steps that the runtime walks at call time, in transition order.

Voice agent (voice_agent)​

The headline conversation step: an LLM-driven AI agent that listens and speaks.

  • Instructions — the system prompt for the agent.
  • Tools — JavaScript actions the agent can call (defined as platform tools or inline).
  • Action capabilities — surfaced as small chips beneath the node (DTMF, external API, browser action, transfer, hangup, silence).
  • Transitions — outbound edges driven by the agent's decisions or tool results.

This is the most common node. A flow can have many of them in sequence (e.g. greeter → routing → specialist).

STT transcribe (stt_transcribe)​

Speech-to-text on a stand-alone basis (separate from the agent's own STT). Useful when you need a transcript for analysis or translation without involving an LLM.

  • Source language, chunking mode, optional translations.

Interpretation transform (interpretation_transform)​

Runs an interpretation / translation prompt against a chunk of text. Often paired with stt_transcribe upstream.

LLM query (llm_query)​

A one-shot LLM call without the conversation harness. Useful for short prompts that compute a value or branch.

TTS playback (tts_playback)​

Plays a fixed piece of text through the configured TTS provider. Used for greetings, fallbacks and farewells.

DTMF collect (dtmf_collect)​

Captures DTMF digits from the caller and writes them to a flow variable.

  • Max digits, terminator, timeout, result variable name.

Action request (action_request)​

Asks the connected client (browser SDK) to perform a browser action — open a URL, show a modal, fire a webhook on the page. Whether the flow waits for a result is configurable.

Webhook (webhook)​

External HTTP call from the flow. Request method, URL, headers, body, response parsing into variables.

Condition (condition)​

A branch point with one or more rule-based transitions. Inputs come from flow variables and previous step outputs.

Transfer (transfer)​

PSTN / SIP transfer to another destination. Method and target are configured per node. Requires an egress base number on the parent endpoint for number targets; optional Egress route (routingPool) selects a pool, or the default base-number trunk link applies. Full sip: / sips: URIs route by host and bypass pool selection. See How transfers use egress.

End (end)​

Marks the end of a flow. An optional reason is surfaced on the resulting conversation record.

Virtual nodes (the bits and pieces)​

These nodes are rendered from the flow definition to make the surrounding plumbing visible on the canvas. They are not "extra config" — clicking one opens the part of the flow settings that owns it.

Start node​

The root of the graph. Click it to open Flow Settings — that's where endpoints, the default provider, app-level settings, and language live.

When the flow has at least one endpoint the Start node displays a phone icon; otherwise it shows a "+" to invite you to add the first endpoint.

Entry Point​

One chip per endpoint on the flow. Three types are rendered:

  • Phone — inbound PSTN / SIP. Shows the base number + extension.
  • Web Voice — browser voice calls via the SDK. Shows the slug. Featurewebrtc
  • Web Chat — text / chat sessions via the SDK.

Clicking opens the Endpoint Inspector. Adding or removing endpoints is also done here.

Default Provider​

Up to four chips — one each for STT, LLM, TTS, and Realtime — visualising the providers that handle audio by default. Clicking any chip jumps straight into the relevant section of Flow Settings.

Voice agent nodes can override the default per node; the chips show what the rest of the flow falls back to.

Surface group​

A container that groups channels for browser sessions (Voice / Chat / Actions) or for phone calls. The chip indicates which channels are enabled, sourced from the Web Voice endpoint configuration.

Action capability​

Small chips attached to a voice_agent node summarising what the agent can do in addition to talking: collect DTMF, call an external API, ask the browser to perform an action, transfer, hang up, or pause. The chips are derived from the agent's tools and routing rules.

Side flow trigger​

When the flow definition contains side flows (sub-graphs triggered by an action or browser event), the canvas renders a trigger node so the side flow is reachable. Click it to drill into the side flow's nodes.

Managed LLM​

A special-purpose node used by managed LLM integrations (see Providers for the current catalogue). It encapsulates the provider connection, the managed action contract, and the transition handles that return control to the flow.

Use a Managed LLM node when the provider owns more of the live conversation than a normal voice-agent prompt does. For example, TOBi can return text responses asynchronously through the callback route and can also ask Delphi to run configured managed actions such as transfer or hangup. The node makes those provider-owned actions visible on the canvas instead of hiding them inside provider settings.

Managed LLM nodes usually expose:

  • Provider settings — bot / endpoint identity, callback settings, and provider-specific options.
  • Channel Data Forwarding — inbound and outbound rules that map SIP headers, bot channel data, or call variables into structured context. See Channel Data Forwarding rules.
  • Managed actions — child nodes for transfer and hangup actions that the provider may trigger.
  • Transitions — handles that route the flow after the managed interaction completes or an action outcome is known.

Managed action​

The transfer / hangup actions that belong to a managed LLM. Rendered as child nodes of the managed LLM with an enabled / disabled badge. Managed actions can be triggered from the provider callback or from sandbox/runtime commands, then follow the flow's configured transfer restrictions, failover, and inbound-readiness behavior.

Think of a managed action as a permissioned capability: the provider can request it, but Delphi still validates whether it is enabled, which method is allowed, which destination is permitted, and which transition should run next. Disabled managed action nodes remain visible so reviewers can see that the provider integration supports the action, even though this flow currently blocks it.

Failover and inbound-readiness behavior reuse the same managed transfer and hangup action model. Configure failover when a running managed interaction fails; configure inbound readiness when the platform should wait for the bot/provider before answering an inbound call.

Common managed actions:

ActionWhat it doesTypical configuration
TransferMoves the caller to a SIP/PSTN destination or egress route.Method, target, caller ID, announcement message, confirmation, ring timeout, headers.
HangupEnds the call after the provider decides the conversation is complete or should stop.Wait-for-silence behavior, farewell message, and whether the provider may override it.

Managed transfer actions use the same runtime transfer validation as canvas transfer nodes, so platform/team transfer restrictions and TelPro egress routing still apply. For callback fields such as transferTarget, transferSipHeaders, and hangupSipHeaders, see Managed callback actions.

Managed transfer​

Managed transfer lets the provider request a call handoff without hard-coding SIP details in the provider itself. The flow owner decides which transfer methods and destinations are allowed.

Key settings:

  • Enabled — whether this flow lets the provider request transfer at all.
  • Method — the SIP transfer style, such as sip_refer, sip_refer_replace, or sip_invite.
  • Target — fixed destination or variable-derived destination, depending on the inspector UI.
  • Message / play message — optional text to play before starting the transfer.
  • Confirmation — whether the provider may ask for confirmation before transfer.
  • Max ring time — how long the outbound leg may ring before the action fails or follows fallback behavior.
  • Caller ID — optional caller ID used on the outbound leg when supported by the trunk.
  • Header rules — outbound Channel Data Forwarding rules used to add transfer-specific SIP headers.

The transfer request is still checked against transfer restrictions and egress routing. If the target is blocked or no valid egress route exists, the action fails even when the managed action node is enabled.

Managed hangup​

Managed hangup lets the provider end the call when the conversation has reached a terminal state, for example after a farewell, abuse handling, or a no-further-input event.

Key settings:

  • Enabled — whether this flow lets the provider request hangup.
  • Wait for silence — waits for current TTS playback to finish before disconnecting, so farewell audio is not cut off.
  • Farewell message — optional message Delphi can play before ending the call.
  • Allow message override — whether the provider may replace the configured farewell with its own message.

Use hangup when the provider should control conversation closure. Use a normal End node when the flow itself decides that the conversation is complete.

How nodes connect​

Each conversation node exposes one or more transition handles on the right side. Edges connect a handle on the source to the next node — straight-through, branched, or back into a previous step. Transitions hold their own metadata (label, optional condition); click an edge to edit them.

Virtual nodes (entry point, default provider, surface group) connect into the conversation flow at fixed anchor points; they aren't directly editable as transitions.

See also​