Voice-Agenten architektonisch

Einordnung — was ein Voice-Agent heute leistet

Ein Voice-Agent ist ein programmierbarer Sprachassistent, der Telefonate entgegennimmt oder selbst initiiert, sich an der Konversation beteiligt und Backend-Systeme bedient — Termine bucht, Anfragen beantwortet, Auskünfte erteilt, Tickets eröffnet. Was vor drei Jahren noch eine Forschungsdemo war, ist heute ein produktiv einsetzbares Stück Software, in wenigen Wochen aufgebaut, mit einer Antwortqualität, die sich auf etwa 70 Prozent der Anrufe nicht von einem geschulten Servicemitarbeiter unterscheiden lässt.

Bei Tenvias ist das Thema keine theoretische Übung. Unser eigenes Produkt CityAI ist ein Voice-Agent für die kommunale Bürgertelefonie — ein telefonischer Servicekanal, der Anrufe rund um Personalausweise, Anmeldungen, Termine, allgemeine Auskünfte oder ÖPNV-Fragen entgegennimmt, klärt und entweder direkt beantwortet oder gezielt an eine Sachbearbeiterin weiterreicht. Aus dem täglichen Betrieb dieser Plattform speist sich der Inhalt dieses Artikels.

Drei Faktoren haben den Sprung von der Demo zur Produktivtauglichkeit ermöglicht. Erstens: die Latenz moderner Streaming-Provider ist auf ein Niveau gesunken, das natürliche Konversation erlaubt — unter einer Sekunde vom Ende einer Anfrage bis zur ersten Antwort-Silbe. Zweitens: moderne LLMs beherrschen Function Calling als First-Class-Feature und lassen sich damit als Brücke zwischen freier Sprache und strukturierten Backend-APIs einsetzen. Drittens: spezialisierte TTS-Anbieter wie ElevenLabs liefern synthetische Stimmen, die akustisch nicht mehr von Aufnahmen unterscheidbar sind — vorbei sind die Zeiten der monotonen Vorlese-Akustik aus dem Sprachportal der frühen 2010er.

Was diesen Artikel von der Marketing-Variante unterscheidet: wir zeigen die Architektur Schicht für Schicht, benennen die konkreten Anbieter mit ihren Stärken und Schwächen, drucken Code-Beispiele, die Sie übernehmen können, und sprechen die heiklen Themen offen aus — Datenschutz, Latenzgrenzen, die Frage „direkter LLM-Anbieter oder Aggregator", die Anbindung an OZG-Fachverfahren mit FIM-Schlüsseln. Wer am Ende eine eigene Sprach-Servicestelle aufbauen will, hat hier den Bauplan in den Händen.

Die Pipeline — STT, LLM, TTS

Jeder Voice-Agent — egal welcher Anbieter, welche Plattform — folgt derselben Drei-Schritt-Architektur. Sprache wird zu Text, Text wird zu Antwort, Antwort wird wieder zu Sprache. Was die Anbieter unterscheidet, ist nicht das Konzept, sondern die Implementierungs­tiefe.

STT — Speech-to-Text

Die erste Stufe wandelt das ankommende Audio in Text um. Klassisch ein neuronales Netz, das Audio-Frames als Mel-Spectrogramm einliest und Token sequenziell ausgibt. Moderne Anbieter — Deepgram (Nova-3), AssemblyAI (Universal-2), OpenAI Whisper, Azure Speech, Google Cloud STT — liefern Streaming-Transkripte: noch während der Anrufer spricht, kommen partielle Text-Fragmente zurück, die nach jedem neuen Wort verfeinert werden. Das ist entscheidend für die Latenz: der nächste Verarbeitungs­schritt kann mit dem Transkript starten, sobald die Anrufer-Äußerung endet — nicht erst nach einer Batch-Übersetzung.

Drei verwandte Begriffe gehören in dieselbe Stufe. VAD (Voice Activity Detection) erkennt, ob gerade jemand spricht. Endpointing entscheidet, wann eine Äußerung beendet ist — typischerweise nach einer 200–500-ms-Pause. Zu aggressives Endpointing schneidet Sätze ab, zu defensives macht den Agent zähflüssig. Barge-In bezeichnet die Fähigkeit des Anrufers, den Agenten zu unterbrechen — eine Eigenschaft, die in produktiven Setups absolut zwingend ist, weil sie den Unterschied zwischen „ich rede mit einer Maschine" und „ich rede mit einem Gegenüber" ausmacht.

LLM — die Sprachintelligenz

Die zweite Stufe empfängt den Transkript-Text, führt eine Konversationshistorie, generiert die Antwort und entscheidet darüber, ob ein Tool aufgerufen wird. Hier kommt das Large Language Model zum Einsatz — bei uns standardmäßig Anthropic Claude (Claude Sonnet 4.5 für die meisten Anwendungsfälle, gelegentlich Claude Opus für besonders anspruchsvolle Fachdomänen), in alternativen Setups OpenAI (GPT-4o, GPT-4.1) oder Google Gemini. Drei Eigenschaften zählen: deutsche Sprachqualität, Tool-Use-Disziplin, Streaming-Latenz.

TTS — Text-to-Speech

Die dritte Stufe wandelt die Antwort des LLMs in synthetische Sprache zurück. Der Markt wird seit etwa 2023 von ElevenLabs dominiert — eine Audio-Qualität, die in Blindtests von menschlichen Aufnahmen kaum zu unterscheiden ist, kombiniert mit einer Streaming-API, deren erste Audio-Frames in 150–300 ms eintreffen. Alternativen sind OpenAI TTS (Marktbreite, aber stilistisch weniger flexibel), Azure Neural Voices (regional gut, aber höhere Latenz), oder das aufkommende Cartesia Sonic mit besonders niedriger Latenz.

Wichtig dabei: die TTS-Stufe muss streamingfähig sein, sonst zerstört sie das gesamte Latenzbudget. Eine Batch-TTS, die den vollständigen LLM-Output abwartet und dann eine komplette MP3-Datei zurückgibt, kostet zusätzliche 800 ms — inakzeptabel für Konversation. Streaming-TTS bekommt vom LLM Text-Fragmente und produziert parallel Audio-Frames; die ersten Silben der Antwort sind hörbar, während das LLM noch weitere Sätze formuliert.

Latenzbudget — warum unter einer Sekunde der Maßstab ist

Die End-to-End-Latenz ist die wichtigste technische Kennzahl eines Voice-Agents. Sie entscheidet darüber, ob die Konversation natürlich klingt oder zäh wirkt. Faustregeln aus der Telefonie-Forschung: unter 500 ms ist exzellent, 500–800 ms ist gut, 800–1200 ms ist akzeptabel, alles über 1500 ms wird als störend empfunden — Anrufer beginnen, in die Stille zu sprechen, was die Erkennung weiter durcheinander bringt.

Optimierungs-Hebel

Vier Schrauben drehen das Latenzbudget am stärksten. Erstens: Streaming durchgängig. STT muss Partials liefern, LLM muss Token-Streaming unterstützen, TTS muss Text-Chunks akzeptieren. Wer irgendwo einen Batch-Schritt hat, verliert das Spiel. Zweitens: aggressives Endpointing. Eine Pause von 300 ms statt 500 ms vor dem Schließen einer Äußerung spart 200 ms vom Gesamtbudget — auf Kosten gelegentlich abgeschnittener Sätze. Die Konfiguration ist anwendungsabhängig: für strukturierte Anfragen (Termin, Adresse) eher kurz, für offene Anliegen eher länger. Drittens: Provider-Lokalisierung. Anthropic, OpenAI, Deepgram und ElevenLabs betreiben EU-Endpunkte — die zusätzliche Round-Trip-Zeit nach US-East-1 kostet je 80–120 ms pro Aufruf. Viertens: parallele Pipeline-Stufen. Sobald das LLM die ersten Wörter formuliert hat, beginnt die TTS-Synthese — nicht erst, wenn die Antwort vollständig ist.

Wenn das Budget reißt

Manchmal lässt sich die Latenz nicht weiter drücken — komplexe Tool-Aufrufe an träge Fachverfahren-APIs sind die häufigste Ursache. Hier hilft ein zweistufiger Antwort-Plan: das LLM gibt eine kurze Bestätigungs-Phrase aus („einen Moment bitte, ich schaue nach"), bevor der Tool-Call startet. Aus zwei Sekunden Stille werden zwei Sekunden Konversation — der Unterschied in der Anrufer-Wahrnehmung ist dramatisch.

Architektur — alle Bausteine in einem Bild

Bevor wir in die einzelnen Komponenten einsteigen, ein Gesamtbild. Die folgende Abbildung zeigt die typische Topologie eines produktiven Voice-Agent-Setups, wie es CityAI in Kunden-Installationen einsetzt.

Die Pipeline läuft im Normalfall folgendermaßen ab: (1) Anrufer wählt die Servicenummer, der Carrier routet die SIP-INVITE an den SIP-Trunk-Anbieter. (2) Der SIP-Trunk leitet das Gespräch — über die WebSocket-API von VAPI — an die Voice-Agent-Plattform weiter; die RTP-Audio-Pakete werden in Real-Time-Frames umgewandelt. (3) VAPI öffnet einen Streaming-Kanal zum STT-Provider und beginnt, Audio nach oben zu pushen; Transkript-Partials kommen zurück. (4) Sobald VAPI das Ende der Anrufer-Äußerung erkennt, übergibt es das finalisierte Transkript an das LLM. (5) Das LLM streamt entweder reinen Antwort-Text zurück (Standardfall) oder einen Tool-Call. (6) Bei einem Tool-Call routet die Function Bridge die Anfrage an das Fachverfahren, sammelt das Ergebnis und feedet es als Kontext zurück in den nächsten LLM-Aufruf. (7) Der finale Antwort-Text wird chunk-weise an die TTS gestreamt, die Audio-Frames produziert; VAPI mischt diese in den RTP-Stream zum Anrufer.

VAPI als Orchestrator

Die Voice-Agent-Plattform VAPI (vapi.ai) hat sich in unseren Projekten als der pragmatischste Weg etabliert, einen produktiven Sprachassistenten in Wochen statt Monaten aufzubauen. VAPI übernimmt die Aufgaben, die jeder selbst gebaute Voice-Agent früher oder später ohnehin lösen muss — und überlässt dem Entwickler die fachlichen Entscheidungen.

Was VAPI macht

Im Kern ist VAPI ein Multi-Provider-Orchestrator: die Plattform abstrahiert über STT-, LLM- und TTS-Anbieter und stellt eine einheitliche Konfigurationsschicht bereit. Konkret löst VAPI fünf Probleme. Erstens: die SIP-Anbindung — VAPI sprechen die gängigen SIP-Trunk-Anbieter (Twilio, Telnyx, Sipgate) nativ an; sowohl Inbound (Anrufer wählt eine Nummer) als auch Outbound (Agent ruft einen Bürger zurück) sind unterstützt. Zweitens: das Audio-Routing mit VAD, Endpointing und Barge-In — drei der nicht-trivialen Komponenten jeder produktiven Konversation. Drittens: die Provider-Abstraktion — Wechsel von Deepgram zu Whisper oder von Claude zu GPT-4 erfordert eine Konfigurationsänderung, keinen Code-Eingriff. Viertens: die Function-Call-Brücke — Tools werden als Webhook-URLs registriert; VAPI orchestriert Aufruf, Antwort-Verarbeitung und Re-Prompting des LLMs. Fünftens: Call-Logs, Aufnahmen und Transkripte für die operative Auswertung und für Audit-Anforderungen in regulierten Branchen.

Konfiguration als Assistant-Definition

Ein Voice-Agent in VAPI wird als „Assistant" definiert — ein JSON-Objekt, das alle Komponenten der Pipeline auf einmal beschreibt:

{
  "name": "buergertelefon-musterstadt",
  "firstMessage": "Servicestelle der Stadt Musterstadt, was kann ich fuer Sie tun?",

  "transcriber": {
    "provider": "deepgram",
    "model":    "nova-3",
    "language": "de",
    "endpointing": 350
  },

  "model": {
    "provider": "anthropic",
    "model":    "claude-sonnet-4-5",
    "temperature": 0.3,
    "maxTokens":   400,
    "systemPrompt": "Du bist die telefonische Servicestelle der Stadt Musterstadt. \
                      Sprich ausschliesslich Deutsch in der Sie-Form. \
                      Antworte praezise und freundlich. \
                      Wenn das Anliegen nicht klar ist, frage gezielt nach. \
                      Bei juristischen oder medizinischen Notfaellen \
                      leite an einen menschlichen Mitarbeiter weiter.",
    "tools": [
      { "type": "function", "function": { "name": "get_termin_verfuegbarkeit", ... } },
      { "type": "function", "function": { "name": "buche_termin",          ... } },
      { "type": "function", "function": { "name": "weiterleitung_an_sachbearbeiter", ... } }
    ]
  },

  "voice": {
    "provider":               "11labs",
    "voiceId":                "EXAVITQu4vr4xnSDxMaL",
    "model":                  "eleven_flash_v2_5",
    "stability":              0.5,
    "similarityBoost":        0.75,
    "optimizeStreamingLatency": 3
  },

  "serverUrl": "https://voice-agent.tenvias.de/webhooks/vapi",
  "recordingEnabled": false,
  "maxDurationSeconds": 600,
  "endCallPhrases": ["auf wiederhoeren", "tschuess", "danke vielmals"]
}

Drei Eigenschaften dieser Konfiguration sind in der Praxis entscheidend. Erstens: die System-Prompt-Sprache. Wir setzen den Agent immer explizit auf deutsche Sie-Form — sonst rutscht das LLM bei englisch-trainierten Modellen gelegentlich in englische Floskeln. Zweitens: endpointing: 350 als Standard — ein Mittelwert zwischen „schnell reagieren" und „Anrufer ausreden lassen". Für Anwendungen mit älterer Klientel erhöhen wir diesen Wert auf 500–600 ms. Drittens: recordingEnabled: false als Default — Aufnahmen werden nur mit expliziter Einwilligung des Anrufers aktiviert (siehe Datenschutz-Abschnitt).

Tool-Definitionen

Jedes Tool ist eine HTTPS-URL, die VAPI im Function-Call-Fall aufruft. Die Definition folgt der JSON-Schema-Konvention, die sowohl Anthropic als auch OpenAI verstehen — VAPI übersetzt zwischen Provider-Formaten transparent. Eine Tool-Spezifikation hat drei Teile: name, description (entscheidet, wie das LLM das Tool versteht — Qualität dieser Beschreibung ist matchentscheidend), und parameters mit den erwarteten Argumenten.

ElevenLabs für TTS

Synthetische Sprache ist 2025 erstmals in einer Qualität verfügbar, die im Doppelblindtest nicht zuverlässig von menschlichen Aufnahmen zu unterscheiden ist. ElevenLabs ist hier der Markt­führer — sowohl bei der Audio-Qualität als auch bei der Streaming-Latenz, die für Voice-Agents zwingend notwendig ist.

Modelle und ihre Trade-offs

ElevenLabs bietet derzeit drei Modell­familien, die sich in Qualität und Latenz unterscheiden. Flash v2.5 ist das Echtzeit-Modell — erste Audio-Frames in 75–150 ms, leicht reduzierte Prosodie gegenüber den höheren Modellen, aber für Konversation optimiert. Turbo v2.5 liegt in der Mitte — ca. 200 ms Latenz, deutlich natürlichere Akzente. Multilingual v2 ist das Qualitäts-Modell — 32 Sprachen, beste Stimmtreue, aber 300–500 ms TTFB. Für CityAI nutzen wir standardmäßig Flash v2.5; die wenigen Stellen, an denen längere vorgenerierte Ansagen ausgespielt werden (etwa rechtliche Hinweise zu Anrufaufzeichnung), produzieren wir mit dem Multilingual-Modell und cachen das Resultat.

Voice-Cloning für eine konsistente Markenstimme

Eine der relevanteren Funktionen für CityAI: Instant Voice Cloning erlaubt es, mit 60–90 Sekunden Sprachprobe eine eigene Stimme zu klonen. Für Kommunen ist das wertvoll, weil sich eine konsistente „städtische Servicestimme" über alle Kanäle (Voice-Agent, Sprachportal, On-Hold-Ansagen, Erklärvideos) etablieren lässt. Unsere Empfehlung: keine reale Person als Vorlage, sondern eine professionelle Sprecherin mit explizitem Lizenzvertrag — das vermeidet die nicht-trivialen rechtlichen Fragen um synthetische Reproduktion einer realen Stimme.

Streaming-API

Der entscheidende Endpoint für Voice-Agents ist die WebSocket-basierte Streaming-API. Text wird in Chunks vom LLM gestreamt, ElevenLabs liefert Audio-Frames zurück, sobald genügend Text für eine sinnvolle Synthese vorhanden ist. Ein minimal-funktionsfähiger Client in Node.js:

import WebSocket from 'ws';

const ws = new WebSocket(
  `wss://api.elevenlabs.io/v1/text-to-speech/${voiceId}/stream-input` +
  `?model_id=eleven_flash_v2_5&optimize_streaming_latency=3`,
  { headers: { 'xi-api-key': process.env.ELEVENLABS_API_KEY } }
);

ws.on('open', () => {
  // Initial-Frame: Voice Settings und Generation Config
  ws.send(JSON.stringify({
    text: ' ',                                       // Pflicht-Leerzeichen
    voice_settings:    { stability: 0.5, similarity_boost: 0.75 },
    generation_config: { chunk_length_schedule: [120, 160, 250, 290] }
  }));

  // LLM-Tokens chunkweise senden
  llmStream.on('text-chunk', (text) => {
    ws.send(JSON.stringify({ text, try_trigger_generation: true }));
  });

  // EOS-Signal, wenn LLM fertig ist
  llmStream.on('end', () => {
    ws.send(JSON.stringify({ text: '' }));
  });
});

ws.on('message', (data) => {
  const msg = JSON.parse(data);
  if (msg.audio) {
    const audioBytes = Buffer.from(msg.audio, 'base64');
    sipStream.write(audioBytes);                     // direkt in den RTP-Stream
  }
  if (msg.isFinal) {
    ws.close();
  }
});

Zwei Parameter steuern das Latenz-Qualitäts-Verhältnis. optimize_streaming_latency (0–4) — höhere Werte priorisieren niedrigere Latenz, leicht reduzierte Synthese-Qualität. Wir setzen üblicherweise 3. chunk_length_schedule — gibt vor, wie viele Zeichen ElevenLabs sammelt, bevor ein Audio-Chunk generiert wird. Kurz für niedrige Latenz, lang für glattere Prosodie.

Pricing und Datenresidenz

ElevenLabs bietet einen EU-Endpoint (EU-Frankfurt) — relevant für Datenschutz-Anforderungen in regulierten Setups. Das Pricing ist character-basiert, im niedrigen Promille-Bereich pro Sekunde Audio; bei einem typischen Voice-Agent landet man bei 2–5 Cent pro Minute Konversation, was im Vergleich zu LLM-Kosten bisher der kleinere Posten ist.

STT-Auswahl — Deepgram, Whisper und die Konkurrenz

Auf der STT-Seite ist der Markt heterogener als bei TTS. Vier Anbieter sind in regulierten Branchen relevant.

Deepgram

Unsere Default-Wahl für CityAI. Deepgram Nova-3 liefert deutschsprachige Transkripte mit Streaming-Partials in 100–200 ms, hat eine sehr gute Erkennungsrate auch bei dialektaler Färbung, und verfügt über eine EU-Hosting-Option (EU-Frankfurt). Pricing bei etwa 0,4 Cent pro Minute; der niedrigste am Markt für vergleichbare Qualität. Native Telefonie-Codec-Unterstützung (μ-law, A-law) erspart die Transkodierung.

OpenAI Whisper

Hervorragende Erkennungsqualität, breite Sprachunterstützung, aber zwei harte Limitierungen für Voice-Agents: erstens kein natives Streaming (Whisper-1 ist ein Batch-API-Endpoint, der die komplette Audio-Aufnahme abwartet), zweitens vergleichsweise hohe Latenz (500 ms bis 1 s nach Audio-Ende). Für Anwendungsfälle, in denen Streaming wichtig ist, scheidet Whisper als Live-STT aus — bleibt aber die richtige Wahl für asynchrone Transkription (Anruf-Auswertungen, Audit-Auswertungen, Schulungsmaterial).

AssemblyAI und Azure Speech

AssemblyAI Universal-2 ist speziell für Konversations-Use-Cases optimiert, mit guter Streaming-Performance und integrierten Features wie Speaker Diarization und Sentiment-Analyse — relevant, wenn eine zweite Auswertungs­ebene auf den Transkripten aufgesetzt werden soll. Azure Speech ist die Hyperscaler-Antwort — solide Qualität, Microsoft-eigenes EU-Hosting, gute Integration in den Microsoft-Cosmos.

Auswahl-Kriterien in der Praxis

Vier Fragen entscheiden in der Tenvias-Methodik. (1) Streaming oder nicht — Voice-Agent verlangt Streaming. (2) Deutsche Erkennungsrate auf realen Telefon-Mitschnitten (kein Studio-Audio!) — wir messen das per Word-Error-Rate auf einem internen Validierungs-Set mit etwa 200 deutschsprachigen Bürger-Anrufen. (3) Latenz inklusive Netzwerk-RTT zum EU-Endpoint. (4) Datenresidenz und AVV — alle vier oben genannten Anbieter bieten EU-Hosting, aber die Vertrags­detailtiefe (Verarbeitung zu Trainingszwecken, Aufbewahrungsfristen, Sub-Auftragsverarbeiter) unterscheidet sich erheblich.

Anthropic Claude — die Sprachintelligenz

Das LLM ist das Herz des Voice-Agents. Es führt die Konversation, wahrt den Kontext, entscheidet über Tool-Aufrufe und formuliert die finale Antwort. Bei CityAI setzen wir standardmäßig Anthropic Claude ein — aus drei Gründen, die im Folgenden beleuchtet werden.

Drei Gründe für Claude

Erstens: deutsche Konversation auf hohem Niveau. Claude ist in deutschen B2C-Konversationen merklich natürlicher als GPT-4 — flüssigere Sätze, weniger anglizistische Floskeln, treffender im Behördendeutsch. Subjektiver Eindruck, der sich in unseren A/B-Tests konsistent reproduziert. Zweitens: Tool-Use als First-Class-Feature. Claude trennt sauber zwischen Text-Antwort und Tool-Call, ist diszipliniert bei der Parameterextraktion und bietet ein klar definiertes Antwort-Format, das in Voice-Pipelines vorhersagbar zu parsen ist. Drittens: Anthropic bietet eine echte EU-Geschäftsbedingung mit klarem AVV, EU-Hosting auf AWS Frankfurt, und definierten Aufbewahrungsfristen — kritisch für Setups in regulierten Branchen.

Tool-Use mit Streaming

Der vollständige Aufruf gegen die Anthropic-API mit Tools und Streaming in Python:

import anthropic

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_termin_verfuegbarkeit",
        "description": (
            "Sucht freie Termine im Buergerbuero nach Anliegen und Zeitraum. "
            "Verwende dieses Tool, sobald der Anrufer einen konkreten "
            "Terminwunsch fuer ein bestimmtes Anliegen aeussert."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "anliegen": {
                    "type": "string",
                    "enum": ["personalausweis", "anmeldung",
                             "fuehrerschein", "eheschliessung"],
                    "description": "Art des Anliegens"
                },
                "ab_datum": {
                    "type": "string",
                    "format": "date",
                    "description": "Fruehestens verfuegbares Datum"
                }
            },
            "required": ["anliegen"]
        }
    },
    # ... weitere Tools (buche_termin, weiterleitung_an_sachbearbeiter)
]

system_prompt = (
    "Du bist die telefonische Servicestelle der Stadt Musterstadt. "
    "Sprich ausschliesslich Deutsch in der Sie-Form, klar und freundlich. "
    "Frage gezielt nach, wenn ein Anliegen unklar ist. "
    "Bei medizinischen Notfaellen leite an einen menschlichen "
    "Mitarbeiter weiter."
)

with client.messages.stream(
    model       = "claude-sonnet-4-5",
    max_tokens  = 400,
    system      = system_prompt,
    tools       = tools,
    messages    = conversation_history,
    temperature = 0.3,
) as stream:
    for event in stream:
        if event.type == "content_block_start":
            block = event.content_block
            if block.type == "tool_use":
                current_tool_call = { "name": block.name, "input": "" }

        elif event.type == "content_block_delta":
            delta = event.delta
            if delta.type == "text_delta":
                # Token direkt an die TTS streamen
                tts.send_chunk(delta.text)
            elif delta.type == "input_json_delta":
                # Tool-Input wird inkrementell uebertragen
                current_tool_call["input"] += delta.partial_json

        elif event.type == "content_block_stop":
            if current_tool_call:
                # Tool ausfuehren und Ergebnis in den naechsten Turn einspeisen
                result = execute_tool(current_tool_call)
                conversation_history.append({
                    "role": "assistant",
                    "content": [current_tool_call]
                })
                conversation_history.append({
                    "role": "user",
                    "content": [{
                        "type": "tool_result",
                        "tool_use_id": current_tool_call["id"],
                        "content": result
                    }]
                })

Vier Punkte sind hier praxisrelevant. Erstens: die description jedes Tools ist matchentscheidend für die Erkennung. Wir schreiben sie in vollen Sätzen, mit klaren Triggern („Verwende dieses Tool, sobald …") — eine knappe Beschreibung wie „bucht Termine" führt zu deutlich mehr Fehl­anwendungen. Zweitens: temperature=0.3 als Default — niedrig genug, um konsistente Antworten zu produzieren, hoch genug, um nicht roboterhaft zu klingen. Drittens: das Streaming-Event-Modell erlaubt es, sowohl Text-Antworten direkt an die TTS zu schicken als auch Tool-Calls inkrementell zu sammeln — beide Pfade laufen über denselben Event-Stream. Viertens: Tool-Results müssen als „user"-Message mit Typ tool_result in die Historie eingespeist werden, sonst verliert das LLM den Kontext.

Prompt-Caching für Konversations­historie

Anthropic unterstützt Prompt-Caching, das in Voice-Agents direkt Geld spart: der lange System-Prompt mit allen Tool-Definitionen wird einmal pro Konversation gecached, anschließend nur die neuen Konversations­turns abgerechnet. Bei einem fünfminütigen Anruf mit 20 Turns reduziert das die Token-Kosten typischerweise um 70–80 Prozent.

OpenAI Realtime API — die Speech-to-Speech-Alternative

OpenAI hat mit der Realtime API eine andere Architektur ins Spiel gebracht: kein separates STT/LLM/TTS, sondern ein einziger Endpunkt, der Audio entgegen­nimmt und Audio zurückliefert. Das Modell hört, denkt und spricht in einem Schritt — und liefert eine Konversations­qualität, die in puncto Prosodie und Sprachfluss die klassische Pipeline schlägt.

Vor- und Nachteile

Pro: geringere Latenz (keine drei separaten API-Aufrufe), natürlichere Konversation (das Modell „hört" Sprechtempo, Betonung, Emotion und antwortet entsprechend), eingebautes Barge-In-Handling, einfacheres Programmiermodell. Contra: Vendor-Lock-in auf OpenAI, weniger Kontrolle über einzelne Pipeline-Stufen, die Stimme ist auf die vordefinierten OpenAI-Stimmen beschränkt (keine eigenen Klone), AVV-Situation für EU-Kunden ist komplizierter als bei Anthropic. Letzteres ist der häufigste Grund, warum wir bei regulierten Branchen zur klassischen Pipeline tendieren — aber für interne Setups oder Anwendungen mit weniger sensiblen Daten ist die Realtime API ein ernsthafter Kandidat.

WebSocket-Setup

Die Realtime API ist eine bidirektionale WebSocket-Verbindung. Konfiguration und Audio-Stream in einem Snippet:

import WebSocket from 'ws';

const ws = new WebSocket(
  'wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview',
  {
    headers: {
      'Authorization': `Bearer ${process.env.OPENAI_API_KEY}`,
      'OpenAI-Beta':   'realtime=v1'
    }
  }
);

ws.on('open', () => {
  // Session-Konfiguration
  ws.send(JSON.stringify({
    type: 'session.update',
    session: {
      modalities:           ['audio', 'text'],
      voice:                'shimmer',
      input_audio_format:   'g711_ulaw',     // SIP-Standard
      output_audio_format:  'g711_ulaw',
      input_audio_transcription: { model: 'whisper-1' },
      instructions: 'Du bist die telefonische Servicestelle der ' +
                    'Stadt Musterstadt. Sprich Deutsch in der Sie-Form.',
      turn_detection: {
        type:                'server_vad',
        threshold:           0.5,
        prefix_padding_ms:   300,
        silence_duration_ms: 500
      },
      tools: [
        {
          type: 'function',
          name: 'get_termin_verfuegbarkeit',
          description: 'Sucht freie Termine im Buergerbuero ...',
          parameters: { /* JSON Schema wie bei Anthropic */ }
        }
      ]
    }
  }));
});

// Eingehendes SIP-Audio direkt in die Realtime-Session pumpen
sipStream.on('audio', (audioFrame) => {
  ws.send(JSON.stringify({
    type:  'input_audio_buffer.append',
    audio: audioFrame.toString('base64')
  }));
});

// Ausgehende Audio-Frames zurueck an SIP
ws.on('message', (data) => {
  const event = JSON.parse(data);
  if (event.type === 'response.audio.delta') {
    const audioBytes = Buffer.from(event.delta, 'base64');
    sipStream.write(audioBytes);
  }
  if (event.type === 'response.function_call_arguments.done') {
    // Tool-Call wurde fertig argumentiert
    const result = executeToolCall(event.name, event.arguments);
    ws.send(JSON.stringify({
      type: 'conversation.item.create',
      item: {
        type:    'function_call_output',
        call_id: event.call_id,
        output:  JSON.stringify(result)
      }
    }));
    ws.send(JSON.stringify({ type: 'response.create' }));
  }
});

Drei Eigenheiten dieses Setups. Erstens: das Audio-Format g711_ulaw ist der Standard-Codec der Telefonie — kein Transkodieren nötig, was 20–50 ms Latenz spart. Zweitens: turn_detection: server_vad bedeutet, dass OpenAI die VAD übernimmt — das ist bequem, aber weniger konfigurierbar als ein eigener VAD-Layer. Drittens: Tool-Calls funktionieren analog zu Anthropic — das Modell „spricht" einen Function-Call aus, der Server führt aus, das Ergebnis fließt zurück, das Modell setzt seine Antwort fort.

Wann Realtime, wann klassische Pipeline

Unsere Faustregel: Realtime API bei kurzen, dialogischen Anwendungen mit geringerer Daten­sensibilität (Demo-Setups, interne Tools, B2C-Anwendungen ohne Behörden­bezug). Klassische Pipeline bei regulierten Setups, eigenen Stimmen-Anforderungen und überall dort, wo der Wechsel des LLM- oder TTS-Anbieters perspektivisch möglich bleiben soll.

Telefonie und SIP-Anbindung

Bevor ein Voice-Agent überhaupt sprechen kann, muss er erreichbar sein. Die SIP-/Telefonie-Schicht ist konzeptionell trivial, in der Praxis aber die Stelle mit den meisten regulatorischen und integrativen Stolpersteinen.

Die Anbieter-Landschaft

Twilio ist der internationale Standard — sehr breite Feature-Palette, gute API, jahrelang stabil, US-zentriert. Für CityAI in deutschen Kommunen wegen der Daten­residenz-Frage nicht erste Wahl. Sipgate ist der deutsche Standardanbieter — komplettes EU-Hosting, gute Lokalisierung, akzeptable Preise, etwas weniger glatte API. Telnyx ist die preisgünstige Alternative mit guter Latenz und EU-Präsenz, jedoch ohne deutsche Vertragspräsenz. Eigene FreeSWITCH-/Asterisk-SBC sind die Option für Kunden, die SIP-Trunks selbst von der Telekom oder einem Konzern-eigenen Carrier beziehen und einen Session-Border-Controller im eigenen Rechenzentrum betreiben — typisch in Bankenumgebungen mit eigener Telefonie-Infrastruktur.

DID-Routing und Nummernportierung

Eine produktive Voice-Agent-Inbetrieb­nahme dauert nicht an der Software, sondern an zwei regulatorischen Schritten: der Nummern­portierung einer bestehenden Servicenummer zum SIP-Trunk-Anbieter (sechs bis zwölf Wochen, abhängig vom abgebenden Carrier) und der Direct-Inbound-Dial-Konfiguration (DID), die festlegt, welche eingehenden Anrufe an welchen Endpunkt geroutet werden. Beide Schritte gehören in jeden Roll-out-Plan als eigene Workstream — sonst hat man eine fertige Software ohne Anrufer.

Codec-Wahl

SIP-Telefonie nutzt traditionell zwei Codecs: G.711 (μ-law/A-law) mit 64 kbit/s — die historische ISDN-Qualität, breit unterstützt, keine Sprach­degradierung. Opus bei 24–48 kbit/s — moderner, besserer Kompromiss zwischen Bitrate und Qualität, aber nicht universell unterstützt. Für Voice-Agents in Deutschland ist G.711 die sichere Wahl; Opus lohnt sich, wenn der gesamte Pfad (SIP-Trunk, VAPI, STT, TTS) Opus durchgängig sprechen kann.

OZG-Anbindung, Datenschutz und EU-Hosting

In den regulierten Branchen, in denen Tenvias arbeitet, ist die technische Pipeline nur ein Teil der Aufgabe — die juristische und integrationsseitige Härtung ist mindestens so wichtig. Drei Themen entscheiden über die produktive Einsetzbarkeit.

Datenschutz und DSGVO

Anruf-Audio enthält praktisch immer personenbezogene Daten — der Klang der Stimme ist bereits ein biometrisches Merkmal nach Art. 9 DSGVO. Daraus folgen vier Pflichten. (1) Ansage zu Beginn des Gesprächs: Hinweis, dass es sich um einen KI-gestützten Sprachassistenten handelt, mit der Option, jederzeit zu einem Menschen weitergeleitet zu werden. (2) AVV mit jedem Pipeline-Anbieter — SIP-Trunk, VAPI, STT, LLM, TTS — und Prüfung der Sub-Auftrags­verarbeiter. (3) Datenminimierung: Audio-Frames werden nicht persistiert, Transkripte werden nach 30 Tagen automatisch gelöscht, Aufzeichnungen nur mit expliziter Einwilligung. (4) EU-Hosting: Anthropic AWS Frankfurt, OpenAI EU (sofern verfügbar), Deepgram EU, ElevenLabs EU-Frankfurt — alle vier Anbieter haben entsprechende Optionen, die in der API-Konfiguration explizit gesetzt werden müssen.

OZG-Fachverfahren-Anbindung

Die Brücke zum eigentlichen Mehrwert des Voice-Agents — von „spricht freundlich" zu „löst das Anliegen" — liegt in der Anbindung an die kommunalen Fachverfahren. Drei Standards sind hier relevant. XÖV (XML in der öffentlichen Verwaltung) ist die Familie standardisierter Datenformate für den Behördenaustausch. FIM (Föderales Informationsmanagement) liefert Schlüssel und Stammdaten zu Verwaltungsleistungen — wer mit FIM-Schlüsseln arbeitet, kann Anliegen über Behörden­grenzen hinweg eindeutig identifizieren. BundID oder das Servicekonto eines Landes liefern die Authentifizierung des Bürgers, sobald ein Vorgang die anonyme Auskunft verlässt und persönlich zugeordnet werden muss.

Ein FIM-konformer Tool-Call sieht in der Implementierung des Voice-Agents folgendermaßen aus:

import httpx
from datetime import date

FIM_SCHLUESSEL = {
    "personalausweis": "99036006001000",   # FIM-Leistungs­schluessel
    "anmeldung":       "99010002001000",
    "fuehrerschein":   "99117002001000",
    "eheschliessung":  "99089001001000",
}

def get_termin_verfuegbarkeit(anliegen: str,
                              ab_datum: str | None = None) -> dict:
    """Tool-Implementation: Termine ueber XOEV-konforme API abfragen."""
    fim_key = FIM_SCHLUESSEL.get(anliegen)
    if fim_key is None:
        return { "fehler": f"Unbekanntes Anliegen: {anliegen}" }

    response = httpx.get(
        f"{TERMINBUCHUNG_API}/verfuegbarkeit",
        params={
            "leistungsSchluessel": fim_key,
            "ab": ab_datum or date.today().isoformat(),
            "limit": 10
        },
        headers={
            "Authorization":        f"Bearer {service_token}",
            "X-FIM-Konformitaet":   "1.0",
            "X-Trace-Id":           current_trace_id()
        },
        timeout=4.0
    )
    response.raise_for_status()

    termine = response.json()["termine"]
    if not termine:
        return { "ergebnis": "keine_termine",
                 "hinweis": "In den naechsten 4 Wochen kein freier Termin." }

    return {
        "ergebnis": "verfuegbar",
        "naechster_termin": termine[0]["datum"],
        "alternativen":     [t["datum"] for t in termine[1:5]]
    }

Vier Eigenschaften dieses Tool-Codes sind relevant. Erstens: die Übersetzung von freier Sprache („ich brauche einen Personalausweis") in einen FIM-Leistungs­schlüssel passiert im Code, nicht im LLM-Prompt — das macht die Behörden­zuordnung deterministisch und prüfbar. Zweitens: der X-Trace-Id-Header propagiert die Anruf-ID in das Fachverfahren — bei einem Vorfall lässt sich der Anrufer­kontext sauber rekonstruieren (siehe unseren Artikel zu Logging im Enterprise-Umfeld). Drittens: der knappe timeout=4.0 stellt sicher, dass eine träge Fachverfahren-API den Agenten nicht über die Latenz­grenze schiebt — bei Überschreitung fängt der Agent das mit der „Moment-bitte"-Strategie ab. Viertens: die Rückgabe ist strukturiert in „ergebnis"-Codes, die das LLM in natürlich­sprachliche Antworten übersetzt — eine klare Trennung zwischen Daten­abfrage und Konversations­oberfläche.

Betrieb, Beobachtbarkeit und wann der Voice-Agent passt

Eine produktive Voice-Agent-Installation ist kein Set-and-Forget-System. Sie hat ähnliche Betriebs­anforderungen wie jede andere Plattform — plus drei Eigenheiten, die spezifisch sind.

Monitoring und Logging

Drei Metriken sind die wichtigsten. End-to-End-Latenz pro Konversations­turn — gemessen vom Ende der Anrufer-Äußerung bis zur ersten hörbaren Silbe. Tool-Call-Erfolgsrate — wie oft schlägt ein Aufruf an ein Fachverfahren fehl, wie oft führt das LLM einen Tool-Call aus, der gar nicht hätte stattfinden sollen. Eskalations­rate — wie oft wird das Gespräch an einen menschlichen Mitarbeiter weitergegeben, und aus welchem Grund. Diese drei Werte landen in einem Grafana-Dashboard (siehe unseren Artikel zu Zabbix und Grafana) mit Drill-Down auf Tagesverlauf und Anliegen-Kategorie.

Fallback auf menschliche Operatoren

Ein produktiver Voice-Agent muss eine saubere Weiterleitungs­strategie haben — sowohl explizit angefordert („Ich möchte mit einem Mitarbeiter sprechen") als auch implizit ausgelöst (medizinische Notfälle, juristische Fragen, drei Tool-Call-Fehl­schläge in Folge, Frustrations­anzeichen im Anrufer-Tonfall). Die Weiterleitung erfolgt über das SIP-REFER-Verfahren — der SIP-Trunk-Anbieter routet den Anruf um, idealerweise mit Übergabe der bisherigen Konversations­zusammenfassung als Bildschirm-Pop-up beim Operator (CRM-Integration).

Wann ein Voice-Agent passt

Aus Erfahrung mit CityAI und vergleichbaren Projekten: passend, wenn (a) ein hohes Anrufvolumen mit relativ strukturierten Anliegen vorliegt — Termine, Statusabfragen, allgemeine Auskünfte, Adressänderungen; (b) eine 24/7-Erreichbarkeit gewünscht ist, die mit menschlichen Mitarbeitern wirtschaftlich nicht abbildbar ist; (c) wiederkehrende Fragen einen großen Anteil ausmachen; (d) die Anbindung an existierende Fachverfahren über REST-APIs oder XÖV/FIM technisch möglich ist.

Weniger geeignet, wenn (a) jedes Anliegen individuell und beratungs­intensiv ist; (b) Krisen­situationen einen erheblichen Anteil ausmachen — Schuldnerberatung, Suchthilfe, psychosoziale Notfälle gehören in menschliche Hände; (c) die Bürgerschaft eine Altersstruktur hat, die mit synthetischen Stimmen prinzipielle Schwierigkeiten hat; (d) die Fachverfahren nicht maschinen­zugänglich sind und jede Anfrage einen manuellen Backend-Schritt erfordert.

Wirtschaftliche Einschätzung

Ein realistischer Betrieb mit 200 Anrufen pro Tag, durchschnittlich 4 Minuten pro Anruf, kommt auf laufende Kosten in der Größenordnung von 400–600 Euro pro Monat für die Provider-Gebühren (STT + LLM + TTS + SIP-Trunk). Hinzu kommen die einmaligen Aufbau­kosten und die laufende Pflege der Prompts, Tools und Fachverfahren-Integrationen. Im Vergleich zu einem menschlichen 24/7-Bürger­service ist das eine wirtschaftlich attraktive Konstellation, sobald die fachliche Eignung sicher­gestellt ist — was eine sorgfältige Anwendungsfall-Analyse verlangt, mit der jedes solche Projekt beginnen sollte.

In einer Kommune, mit der wir 2025 CityAI aufgesetzt haben, lag die Quote der vollständig vom Agenten beantworteten Anrufe nach drei Monaten bei 68 Prozent — die restlichen 32 Prozent gingen über die Weiterleitungs­logik an die Sachbearbeitung weiter, wobei das Gesprächs­protokoll bereits die fachliche Vorklärung enthielt. Der Servicestelle wurde damit die Routinearbeit abgenommen, ohne dass die anspruchsvollen Fälle in einen Bot-Engpass laufen. Genau diese Balance — Routine an die Maschine, Komplexität an den Menschen — ist der wirtschaftliche und ethische Sweet Spot eines produktiven Voice-Agents.