Voice Agent Frameworks

Voice Agent Frameworks sind Programmier-Baukästen für sprachfähige KI-Assistenten, die am Telefon oder im Browser reden. Sie bündeln die Bausteine einer solchen Anwendung: Sprache zu Text (Speech-to-Text), Sprachmodell (Large Language Model, LLM), Werkzeug-Aufrufe (Tool-Use), Text zu Sprache (Text-to-Speech) sowie die Regeln, wer wann redet (Turn-Taking) und was passiert, wenn der Anrufer dazwischenredet (Interruption-Handling). Sie sind die Bau-Ebene, auf der Telefonie- und Sprach-Assistenten programmiert werden.

Was sind Voice Agent Frameworks?

Ein Voice Agent Framework steuert eine Echtzeit-Audio-Kette: Ein Anruf oder ein Browser-Fenster liefert einen laufenden Ton-Strom. Dieser Strom wird in Text umgewandelt, an ein Sprachmodell (LLM) übergeben, mit Werkzeug-Aufrufen (etwa Kalender oder Datenbank) ergänzt und in unter einer Sekunde als synthetische Sprach-Antwort zurückgespielt. Ohne Framework baut jedes Projekt diese Kette neu, inklusive der Erkennung, wann der Anrufer spricht (Voice Activity Detection, VAD), der Rede-Übergabe (Turn-Taking), der Unterbrechungs-Logik und der Telefon-Anbindung.

Typische Primitiven sind eine Session- oder Room-Abstraktion über WebRTC/SIP, eine Audio-Pipeline mit VAD (Voice Activity Detection), Turn-Taking- und Barge-in-Logik, ein LLM-Adapter mit Function Calling, austauschbare STT- und TTS-Provider sowie Telefonie-Integration über SIP-Trunks. Manche Frameworks setzen auf eine kaskadierte Pipeline (STT → LLM → TTS), andere binden ein Speech-to-Speech-Modell ein, das Audio direkt verarbeitet und Audio direkt erzeugt.

Der Markt teilt sich in drei Ausprägungen: Open-Source-Frameworks mit selbst betriebener Infrastruktur (LiveKit Agents, Pipecat, Vocode), Managed-Services mit gehosteter Runtime und Telefonnummer (Vapi, Retell AI) sowie anbieter-native APIs (OpenAI Realtime API, Google Gemini Live), die Audio-Ein- und Ausgabe direkt in ein Modell integrieren und Teile der Pipeline durch einen einzigen Aufruf ersetzen.

Der Begriff grenzt die Bau-Ebene von benachbarten Konzepten ab: von der laufenden Anwendung (Voice Agent), von den einzelnen Bausteinen (Voice Stack) und von textorientierten Agent Frameworks ohne Echtzeit-Audio-Constraints.

Abgrenzung zu Voice Agent, Voice Stack, ASR und Contact-Center

Der Begriff wird im Markt häufig mit angrenzenden Schichten des Voice-AI-Stacks vermischt. Die Bezeichnungen benennen unterschiedliche Rollen.

Ein Voice Agent ist das laufende Produkt, das ein Framework baut. Der Voice Stack ist die Menge der Bausteine, die das Framework orchestriert; ein Framework nutzt einen Voice Stack, ist aber nicht mit ihm identisch. Speech Recognition wird als Adapter eingebunden, kein Framework schreibt ASR selbst. Contact-Center-Software liegt eine Ebene darüber: Sie routet Anrufe, bindet CRM an und misst KPIs. Ein Voice-Agent-Framework baut einzelne Assistenten, die als weitere Ressource in ein Contact-Center integriert werden.

Textorientierte Agent Frameworks wie LangGraph, CrewAI oder das OpenAI Agents SDK bauen Agenten für Chat, E-Mail und Batch-Workflows, ohne Latenz-Budget im dreistelligen Millisekunden-Bereich, ohne Turn-Taking und ohne Telefonie. Voice-Frameworks erben Konzepte wie Function Calling und State-Handling, ergänzen aber die Echtzeit-Audio-Schicht.

Beispiel: Telefonie-Assistent für Terminbuchung

Ein Team baut einen Telefonie-Assistenten für die Terminbuchung einer Fachklinik. Anforderung: Anruf entgegennehmen, Anliegen klären, Kalender-Slots prüfen, Termin buchen, Bestätigung sprechen. Erwartete Antwort-Latenz unter 800 Millisekunden nach Sprech-Ende.

Die Wahl steht zwischen mehreren Frameworks. LiveKit Agents bringt WebRTC- und SIP-Anbindung mit, läuft self-hosted und bindet Deepgram als STT, GPT oder Claude als LLM sowie ElevenLabs, Cartesia oder Rime als TTS. Pipecat ist Python-First und pluggable für STT-, LLM- und TTS-Provider. Vapi und Retell AI liefern eine gehostete Runtime mit Telefonnummer, Dashboard und Provider-Auswahl über Konfiguration. Die OpenAI Realtime API verarbeitet Audio direkt im Modell, spart STT- und TTS-Schritt und senkt die Latenz, verringert dafür die Provider-Portabilität.

Das gewählte Framework orchestriert die Kette: Der eingehende SIP-Anruf öffnet einen Room, der Audio-Stream läuft durch das VAD, die Nutzer-Äußerung wird transkribiert, das LLM erhält den Turn plus die deklarierten Tools (get_available_slots, book_appointment, send_confirmation), entscheidet über einen Tool-Aufruf oder eine direkte Antwort, das Ergebnis fließt zurück, und die synthetisierte Sprach-Antwort geht als Audio zurück in den Room. Interruption-Handling stoppt die TTS-Wiedergabe, wenn der Anrufer während der Antwort spricht.

Die Framework-Wahl bestimmt drei operative Größen: das Latenz-Budget (eine kaskadierte Pipeline liegt typisch bei 600–1200 Millisekunden Round-Trip, ein Speech-to-Speech-Modell wie GPT-4o Realtime bei 300–500 Millisekunden), die Provider-Portabilität über austauschbare STT-/TTS-Adapter und das Betriebsmodell zwischen self-hosted und managed.