AI Agents

Core AI agent configuration and capabilities in Speaknode

AI agents are the core of Speaknode. Each agent is a configurable voice assistant that can hold real-time conversations with users.

Agent Configuration

Basic Settings

  • Title — agent name (up to 50 characters)
  • System Prompt — instructions that define agent behavior, personality, and knowledge. Supports dynamic variables with {{variable_name}} syntax
  • Temperature — controls randomness of LLM responses (0 = deterministic, 1 = creative)
  • Token Limit — maximum token usage per conversation

Language & Localization

Each agent supports multiple languages. Per language you configure:

  • First Message — greeting the agent says when the conversation starts
  • TTS Voice — text-to-speech voice and provider
  • Speech Speed — playback speed multiplier
  • Background Sound — ambient sound during conversation (silence, office, coffee shop, etc.)

The agent can automatically detect the user's language and switch to the appropriate locale.

LLM Model

Select the large language model that powers the agent's reasoning:

  • LLM provider and model version
  • Temperature and additional model-specific properties

The table below ranks the best LLM options for outbound voice sales scenarios — optimised for low latency, Russian language quality, and agent/tool-call reliability.

Loading models…

Key factors for voice:

  • Latency (TTFT) — time-to-first-token directly affects perceived responsiveness; reasoning models (chain-of-thought) add 300–800 ms
  • Russian quality — Qwen3 and GLM-4.7 are trained on large Cyrillic corpora
  • Controllability — how well the model follows persona, objection-handling scripts, and tool-call schemas without hallucinating extra steps
Per-model breakdown

🥇 Qwen3-30B-A3B (DeepInfra) — Alibaba's mid-tier MoE flagship: 30.5B total parameters with 3.3B active per token (8 of 128 experts routed), unified thinking / non-thinking modes (we use non-thinking for voice). In short turns it stays composed, avoids drifting into marketing tone, follows system-prompt rules tightly (independent IFEval ≈ 84.7%), and reliably calls tools per schema (BFCL v3 ≈ 65.1). Strong Russian — trained on substantial Cyrillic corpora, doesn't "slip" into English when the caller code-switches. Holds a sales-manager persona well: short replies, one question per turn, few digressions. The optimal baseline for Voice Sales by quality-vs-predictability.
Sources: Qwen3 technical report (arXiv 2505.09388), HuggingFace model card, BFCL v3 leaderboard.

🥈 GLM-4.7 non-reasoning (Cerebras) — Zhipu AI / Z.ai's agentic flagship, hosted on Cerebras chip-inference. On τ-bench (multi-turn agentic tasks — booking, retail scenarios) it scores ≈ 87.4%, one of the best results among open-weight models at this size. Conversationally it's "engineering-polite": closes steps cleanly, acknowledges what it heard, and dispatches tool calls eagerly (parallel + single tool-calling out of the box). Must be used strictly in non-reasoning mode — thinking blocks balloon illogically on short turns and wreck latency. Russian is weaker than Qwen3 (more visible English-construction calques), but if the dialog is scripted it copes.
Sources: Cerebras GLM-4.7 announcement, Cerebras inference docs, τ-bench paper (arXiv 2406.12045).

🥉 Gemini 3.1 Flash Lite (Google AI Studio) — Google's managed model with a 1M-token context and multimodal support (text/image/audio/video). The selling point is predictability: fewer open-weight surprises, stable Russian grammar, even tone-of-voice. Tool-calling works through structured outputs (no dedicated BFCL listing). We use it as a managed fallback — when an SLO needs to hold without our own infra it delivers a smooth result, but vs Qwen3/GLM-4.7 it loses on fine persona-following and complex agentic behaviour.
Sources: Google model card, Google Cloud blog.

4. Nemotron Super 49B (DeepInfra) — dense 49B model (NAS-compressed from Llama-3.3-70B via NVIDIA's "Puzzle" algorithm), 128K context, post-trained for reasoning, tool-calling, and RAG. In conversation it sounds "academic-expansive": likes to verbalise its chain of thought, takes explicit reasoning steps, which contradicts the "one short reply" Voice Sales instruction. Good fit for agents where output quality matters more than speed (long-call analysis, end-of-call summarisation, complex tool-result filtering). Overkill for a short sales-manager turn.
Sources: NVIDIA Nemotron model card, NVIDIA build page.

Fallback LLM models

Below the primary LLM picker in agent settings you can add up to two fallback models. Each row carries its own model + version, and the list is ordered: the runtime walks it top-to-bottom and uses the first model that responds successfully.

When the chain kicks in. A fallback is tried only when the previous model fails — provider outage, rate-limit / quota error, network timeout, an invalid-API-key response. A successful answer (even a slow one) does not trigger a fallback; we hand the response back to the user as soon as the active model produces one.

Why order matters.

  • The primary model runs on every turn. Pick the one whose voice quality and tool-calling behaviour you actually want callers to hear.
  • Fallback #1 is for the most likely failure mode of your primary. If the primary is hosted on Cerebras, fallback #1 might be a DeepInfra Qwen3 — different inference provider, similar persona behaviour, so the conversation stays close in tone.
  • Fallback #2 is the "no matter what" net. A managed Google / OpenAI model is a good pick here — different vendor entirely, predictable Russian, less risk of a multi-provider outage taking the agent down.

We don't change personas or system prompts between attempts — the same conversation history is replayed against the next model. Pick fallbacks whose answer style is close enough to the primary that a caller won't notice the swap mid-turn.

UI behaviour.

  • The picker on each row shows only LLMs that aren't already selected on this agent (primary or any other fallback), so you can't accidentally duplicate the chain.
  • Drag the handle on the left of a row () to change priority. The order in the UI is the order the runtime tries them.
  • A "Select this version" action inside the model tester drawer assigns the version directly into the row you clicked from.
  • The trash icon on the right removes a fallback row. Removing all rows is fine — the agent simply has no fallback and fails the turn if the primary fails.

Caveats.

  • Each fallback adds latency on the failure path (we wait for the primary to fail before attempting the next), so don't pile them on hoping they'll mask flaky behaviour — fix the primary instead.
  • Token usage and pricing are billed against whichever model actually responded, not the primary.
  • A fallback that's been retired by the provider stays in the row with an orange ⚠️ warning until you swap it out.

Speech-to-Text (STT)

Configure how the agent transcribes user speech:

  • STT model and provider
  • Model-specific properties

Voice Activity Detection (VAD)

Controls how the agent detects when the user is speaking:

  • VAD model selection
  • Sensitivity and timing parameters
  • Option to disable interruptions during the first message

Voice (TTS)

Configure the agent's speaking voice per language:

  • TTS provider
  • Voice selection and voice-specific settings
  • Speed adjustment
  • Background sound type and volume

Dynamic Variables

Agents support dynamic variables in system prompts and first messages. Variables are defined using OpenAPI schema and substituted at dispatch time.

Example system prompt:

You are a customer support agent for {{company_name}}.
The customer's name is {{customer_name}} and their order ID is {{order_id}}.

Variables can be passed via:

  • API dispatch call
  • URL parameters (for widget)
  • Campaign item data (for outbound calls)

Each variable has:

  • Name
  • Type (string, number, boolean, integer)
  • Description
  • Default/fallback value
  • Nullable flag

Agent Tools

Agents can call external APIs during a conversation. See Tools & Integrations for details.

Publishing

Agents can be published to make them accessible:

  • Published agent — accessible via public URL for testing
  • Widget — embeddable on any website
  • Phone number — linked to inbound/outbound telephony
  • API — dispatched programmatically

Agent Duplication

Any agent can be duplicated to create a copy with all settings preserved. Useful for creating variations or templates.

On this page