Assistenten erstellen, testen und veröffentlichen

Ein Assistent enthält Name, Prompt, Begrüßung, Sprache, Anbieter-/Modellauswahl, Wissens- und Toolzuordnungen sowie weitere Gesprächseinstellungen. Die Speicherung eines Felds bedeutet nicht automatisch, dass eine Live-Laufzeit dieses Feld ausführt.

Prompt und Variablen

Beschreibe Rolle, Aufgaben, erlaubte Informationsquellen und den Umgang mit Unsicherheit. Variablen werden in Live-Prompts als {{ firma }} ersetzt. Die Werte stehen im variables-Objekt:

{
  "prompt": "Du bist die Assistenz von {{ firma }}. Antworte kurz.",
  "variables": {"firma": "Studio Linden"},
  "language": "de-DE",
  "model_provider": "openai",
  "knowledge_ids": [],
  "tool_ids": []
}

Nicht gesetzte Platzhalter bleiben sichtbar. Es wird kein Template-Code ausgeführt. Das ausgewählte Agentmodell wird verwendet; bei leerem Modellfeld dient eine Betreiber-Modellvariable wie OPENAI_MODEL als Standard. API-/Anbieterschlüssel gehören nicht in den Prompt oder die Assistentendaten.

Der Prompt darf bis zu 24.000 Zeichen lang sein und wird innerhalb dieser Grenze vollständig an den Liveadapter übergeben. Der Playground nimmt Nachrichten bis 6.000 Zeichen an und speichert maximal 100 Nachrichten pro Gespräch. Das gewählte Modell hat zusätzlich seine eigenen Kontext- und Ausgabegrenzen.

Entwurf und Versionen

Neue Assistenten entstehen als draft. Eine Veröffentlichung benötigt einen nicht leeren Prompt und legt eine neue Version mit Snapshot an. Das Widget und Live-Telefonie verwenden die jüngste veröffentlichte Version. Der Playground kann auch den aktuellen Entwurf bearbeiten.

Duplizieren erstellt einen neuen Entwurf mit kopierter Konfiguration. Ein Agent lässt sich erst löschen, wenn Kanal- und Kampagnenzuordnungen entfernt sind. Historische Gesprächseinträge enthalten weiterhin den damaligen Agentnamen; Versionen des gelöschten Agents werden entfernt.

Gesprächsregeln und Eskalation

Im Testmodus kann flow eine Liste aus trigger und reply enthalten. Enthält die Nutzernachricht den Trigger, wird die konfigurierte Antwort ausgegeben. Andere Flow-/Timingeinstellungen werden gespeichert, besitzen aber noch keine vollständige Live-Engine.

Für Twilio-Dialoge kann escalation.phone eine E.164-Nummer enthalten. Erkennt die Telefonroute einen entsprechenden Mitarbeiter-/Weiterleitungswunsch, verwendet sie Twilio Dial. Eine grafische Routing-Engine, Wartemusik und Carrierfailover sind noch nicht vorhanden. Bidirektionales Audio mit Unterbrechungen verwendet den separaten LiveKit-Pfad; eine frei gespeicherte Eskalationsregel aktiviert dort noch keine automatische SIP-Weiterleitung.

Im Textchat werden zugeordnete Tools manuell aufgerufen. Im Realtime-Voice-Pfad kann das Modell aktive Tools mit auto_execute=true und gültigem Parameterschema verwenden. Freigaben gelten für die veröffentlichte Agentversion; teste externe Aktionen zuerst separat über Tools.

Echtzeitvoice und DGX

Die Echtzeitfelder sind von der Text-LLM-Auswahl getrennt: voice_llm_provider (openai/groq), voice_model, realtime_tts_provider (cartesia/elevenlabs), realtime_voice und llm_route (cloud/hybrid). Leere Anbieter-/Modell-/Stimmfelder übernehmen den jeweiligen Betreiberstandard. Wird llm_route weggelassen, gilt der Arbeitsbereichstandard. API-Keys bleiben in der Betreiberumgebung.

Hybrid verwendet ausschließlich den vom Betreiber konfigurierten privaten DGX-Endpunkt und setzt eine funktionierende Cloudroute voraus. Vor der ersten Text-/Toolausgabe kann ein lokaler Fehler oder Starttimeout zum Cloudmodell wechseln; nach Teilausgabe wird die Antwort nicht erneut in der Cloud begonnen. Die Einrichtungsanleitung beschreibt die Reihenfolge.

Gesprächsbenachrichtigungen

notifications.enabled=true aktiviert die Erfassung ausgewählter Live-Gesprächsereignisse in einer dauerhaften SQLite-/PostgreSQL-Outbox. Konfiguriere eine Empfängeradresse in email und/oder einen erlaubten HTTPS-Endpunkt in webhook_url. Optional grenzt events die Ereignisse ein: conversation.started, conversation.updated, conversation.ended und conversation.reviewed. Ohne Liste gelten conversation.ended und conversation.reviewed. Demo-/Testgespräche werden nicht zum externen Versand eingereiht.

{
  "notifications": {
    "enabled": true,
    "events": ["conversation.started", "conversation.reviewed"],
    "email": "team@example.at",
    "webhook_url": "https://crm.example.at/events"
  }
}

Die Erfassung sendet noch keine Nachricht. Der Betreiber muss SMTP bzw. Webhook-Host-/Signaturkonfiguration und den Outboxworker einrichten. Eine aktive Livefreigabe des zugehörigen Arbeitsbereichs bleibt erforderlich. Das Modell führt dadurch keine autonomen Tools aus. Details und Wiederholungsverhalten stehen unter Anbieter.