Telefon-Assistent auf AWS — POC

KI-Telefonassistent mit Amazon Connect als Voice-Frontend und Bedrock Claude als Brain. Erstmal Proof of Concept in av-production — Region eu-central-1. Budget ist 10 EUR, das reicht für ein lauffähiges Prototyping-Setup, nicht für Dauerbetrieb mit deutscher Nummer.

Ziel

Anrufer spricht mit dem Bot, der versteht das Anliegen, antwortet sinnvoll auf Deutsch, kann optional über Lambda+MCP-Bridge auf bestehende Tools zugreifen (Papierkram, Kalender, etc. — siehe _index).

Aktiver Use-Case (seit 2026-05-09): Demo-Telefonbot für Aylem Eat & Meet (Döner-Restaurant in Hamm, Hammerstr. 101, Online-Bestellung über aylem.orderstork.com). Der Bot nimmt Reservierungswünsche auf, gibt Adresse/Spezialitäten an, verweist für Bestellungen auf die Website. System Prompt + Greeting in index.py.

Andere POC-Kandidaten geparkt: AV-FAQ/Triage-Bot, Voit Voice Interface.

Architektur

flowchart LR
    C[Anrufer] --> N[Phone Number<br/>oder Browser Soft-Phone]
    N --> CC[Amazon Connect<br/>Contact Flow]
    CC --> LX[Lex V2 Bot<br/>FallbackIntent]
    LX --> LM[Lambda Hook]
    LM --> BR[Bedrock<br/>Claude Sonnet 4.5]
    LM --> DDB[(DynamoDB<br/>Session State)]
    BR --> LM
    LM --> PY[Polly Neural<br/>Vicki DE]
    PY --> CC
    CC --> C

Service-Begründung:

• Amazon Connect statt Eigenbau (Chime SDK + selbst gestrickt) — die Voice-Pipeline, Telco-Integration und Contact-Flows sind out-of-the-box
• Lex V2 als Voice-Gateway, ein einziger AMAZON.FallbackIntent der alles an Lambda weitergibt — wir wollen LLM-Antworten, kein klassisches Slot-Filling
• Bedrock Claude Sonnet 4.5 statt Lex-Antworten — echtes Verstehen statt Keyword-Matching
• Polly Neural Vicki für DE-Voice-Output (klingt am natürlichsten)
• Lambda + DynamoDB für State und ggf. Tool-Calls

Account und Region

Phasen

Phase 0 — Soft-Phone-POC ✅ erledigt 2026-05-09

Alle Ressourcen stehen, End-to-End-Smoke-Test gegen das live-Alias war grün (Lex Runtime → Lambda → Bedrock liefert deutsche, natürlich klingende Antwort zurück).

Smoke-Test (Lex Runtime API):

• Input: “Hallo, ich rufe an wegen einem Beratungstermin fuer mein Restaurant”
• Output: “Hallo! Sehr gerne helfe ich Ihnen weiter. Für welchen Bereich Ihres Restaurants interessieren Sie sich denn — geht es um Reservierungssysteme, Kundenservice oder etwas anderes?”
• Confidence Intent TalkToAssistant: 0.81

Test ohne Phone Number — wo Marvin reingucken kann:

• Lex Console Test (Text + Mic): https://eu-central-1.console.aws.amazon.com/lexv2/home?region=eu-central-1#bots/YOOLVJ4JWB/draft/intents → “Test” Button rechts oben
• Connect Console: https://av-voice-poc.my.connect.aws — erstmal nur Admin (Marvin als ROOT-Admin), Soft-Phone-Test braucht zusätzlich einen Connect-User (kann via API nachgelegt werden)

Aylem-Test-Outputs (gegen Lex Runtime Alias live, 2026-05-09):

Bekannte Schwachstelle (zum Tunen): Bot hat in Test 2 “die Karte wechselt regelmaessig” gesagt — das war keine fixe Stammdaten-Aussage, sondern Inferenz aus dem System-Prompt. Bei einem echten Restaurant-Einsatz wuerde ich solche Aussagen rausnehmen oder durch verifizierte Fakten ersetzen.

Quirks die ich gelernt habe:

• Lex V2 Build failed initial — die de_DE Locale verlangt mindestens einen Custom Intent mit Sample-Utterances. FallbackIntent allein reicht nicht. Daher TalkToAssistant als Catch-All-Intent mit 5 Sample-Utterances dazu.
• UpdateContactTextToSpeechVoice Action im Connect-Flow hat keine GlobalVoice-Property (entgegen mancher Tutorials). Korrekte Parameter: TextToSpeechVoice (string) + TextToSpeechEngine (string). Plus jeder Action ausser DisconnectParticipant braucht eine Errors-Liste mit mindestens NoMatchingError.
• Lambda-Code-Update via update-function-code braucht ~5 Sek bis LastUpdateStatus: Successful. Vorher kommt noch der alte Code zurueck.

Phase 0.5 — ElevenLabs-Pivot (parallel zu Phase 0, started 2026-05-09)

Stimmqualitaet von Polly Generative Vicki ist okay, aber ElevenLabs liefert deutlich natuerlicheres DACH-Customer-Care-Sprachgefuehl und bringt das Conversational-AI-Framework (Voice + ASR + LLM + Tool-Calls) in einem Paket. AWS-First-Default fuer Stimme bewusst overruled — Phase-0-Stack bleibt als A/B-Backup parallel laufen, kostet idle ~0.

Setup im Browser-Widget-Modus (komplett client-side, kein Backend):

Voice-Auswahl-Prozess (2026-05-09):

• Drei conversational-orientierte DE-Stimmen aus shared library evaluiert: Johanna (DACH customer care), Ela (junge customer support), Martin (maennlich phone support).
• Default-Empfehlung: Johanna — explizit fuer DACH-Markt designed, mittlere Stimmlage, balance Herzlichkeit/Professionalitaet.
• Stimm-Previews zum Vergleichen liegen in voice-samples:
  • 01-johanna-customer-care.mp3 · 02-ela-empathetic.mp3 · 03-martin-conversational.mp3
  • 04-aylem-text-default-hope.mp3 (ElevenLabs-Default-Voice, zeigt wie der Aylem-Text klingt)
• afplay-Befehl fuer schnelles Vorhoeren: afplay intern/projekte/telefon-assistent-aws/voice-samples/01-johanna-customer-care.mp3

Integration in Demo-Webapp:

• Neue Route /elevenlabs auf server.py — liefert elevenlabs.html mit Convai-Widget (<elevenlabs-convai agent-id="agent_4201kr530ct7es7rpm6k9ejtdbpc">).
• Polly-Version (/) bleibt unveraendert, oben rechts gibt es einen Switch-Link zwischen den beiden Stacks → A/B im selben Browser ohne Reload-Tricks.
• ElevenLabs-Pfad braucht keine AWS-Credentials, nur Internet — Widget verbindet per WebRTC direkt zur ElevenLabs-API.

Bekannte Limits / Open Loops:

• ElevenLabs Free-Tier kann shared-library voices NICHT via TTS-API generieren (paid plan required) — Voice-Cloning oder Conversational-AI laufen aber, weil letzteres die Voice direkt im Agent-Render verwendet. Fuer langfristige Produktion ist Subscription noetig.
• Tool-Webhooks zeigen auf Placeholder-URL — Agent simuliert Antworten bei Tool-Calls bis das echt gehostet ist. Naechster Schritt: Lambda-Endpunkt aylem-tools-handler mit book_reservation + take_order, vor API Gateway, in den Agent-Tools die URL ersetzen.
• API-Key wurde im Chat geteilt — nach POC-Abschluss rotieren (ElevenLabs Dashboard → Profile → API Keys).
• Cartesia API-Key (Phase 0.6) ebenfalls im Chat geteilt 2026-05-09 — bei POC-Abschluss zusammen mit dem ElevenLabs-Key rotieren (Cartesia Dashboard → API Keys).

Cross-Refs:

• MCP-Setup: elevenlabs
• Voice-Sample-Ordner: voice-samples
• A/B-Webapp: README.md

Phase 0.6 — Cartesia + LiveKit-Pivot (started 2026-05-09)

Drittes Voice-Stack-Variante neben Phase 0 (Polly) und Phase 0.5 (ElevenLabs ConvAI). Hier wird die ConvAI-Bundle-Idee aufgebrochen — statt einem Vendor fuer alles haben wir eine pluggable Pipeline ueber LiveKit Agents (Open Source). Vorteil: jede Pipeline-Stage (STT, LLM, TTS) ist tauschbar.

Die urspruenglich geplante dynamische Emotion-Steuerung ueber Cartesia-Controls ist am 2026-05-12 deaktiviert worden — der tts_node-Override hat ~1 s pro Antwort gekostet, und die Controls haben unter der aktiven api_version ohnehin nicht gegriffen. Der Slot ist offen, siehe README im livekit-agent-Ordner fuer den Re-Add-Pfad.

Pipeline (Stand 2026-05-11):

Browser /cartesia (LiveKit Web SDK)
  ↓ WebRTC + Token vom Flask-Backend (/api/cartesia-token)
LiveKit Cloud (managed, Region "Germany 2", Free-Tier 10k min/Mo)
  ↑↓ Audio
Python Worker (livekit-agent/agent.py)
  ├─ silero VAD
  ├─ Deepgram nova-3 (de) — STT
  ├─ Bedrock Claude Haiku 4.5 EU (eu-central-1, T 0.0, cache_system=True) — LLM
  │    ↳ System-Prompt zwingt jede Antwort mit [emotion:tag] zu starten
  ├─ tts_node-Override: parst Tag, mappt auf Cartesia controls
  └─ Cartesia Sonic 2 (de Voice "Viktoria - Phone Conversationalist") — TTS

Latenz-Tuning aktiv: preemptive_generation, min_endpointing_delay=0.2,
max_endpointing_delay=4.0, min_consecutive_speech_delay=0.1.

LLM wurde am 2026-05-09 von OpenAI gpt-4o-mini auf Bedrock Claude Haiku 4.5 EU umgestellt (DSGVO-Pfad fuer Audio+LLM ohne US-Hop, STT/TTS bleiben US bei Deepgram + Cartesia).

Code/Files:

Emotion-Mapping (frueher in agent.py → EMOTION_MAP): am 2026-05-12 ausgebaut, siehe README im livekit-agent-Ordner fuer Re-Add-Pfad.

Stack-Voraussetzungen die Marvin selbst anlegen muss:

LiveKit + Deepgram + Cartesia Keys in livekit-agent/.env.local, AWS via AWS_PROFILE=av-production (shared credentials file). OpenAI-Key ist nicht mehr noetig seit LLM-Pivot auf Bedrock am 2026-05-09.

Cross-Vergleich der drei Stacks:

A/B/C-Switch in den Webapps: Header oben rechts auf jeder Seite hat Schnellzugriff auf die anderen beiden Stacks.

Phase 0.7 — Tools auf MCP umgestellt (Brain+MCPs Modell, 2026-05-09)

Konsequenz aus ADR keine-eigene-plattform: Tools duerfen nicht mehr inline im Worker-Code leben (das waere wieder Voit-Pattern), sondern in einem MCP-Server der quer ueber Voice-Bot, Claude Code/Desktop, zukuenftige Web-Frontends nutzbar ist.

Was das bedeutet:

• Wenn ich denselben MCP in Claude Code als .mcp.json-Eintrag registriere, kann ich aus Claude Code heraus auch „buch mir einen Tisch fuer 4 am Samstag um 19 Uhr” sagen — gleicher Tool-Layer wie der Voice-Bot
• Wenn ein zweiter Kunde (Friseur) kommt: gleicher MCP, anderer Worker-Konfig, andere Persona, anderes Frontend (z.B. Whatsapp statt Voice)
• Wenn der Voice-Vendor wechselt (z.B. ElevenLabs ConvAI statt LiveKit): MCP bleibt, nur Worker tauscht

Phase B Roadmap fuer den MCP (siehe README.md):

• Cal.com-Integration in book_reservation (statt Mock)
• Multi-Tenant (tenant_id als Argument oder Auth-Header)
• Markdown-Knowledge-Base-Loader fuer get_services (pro Tenant)
• Notification-Tool (Email/SMS an Team)
• HTTP/SSE-Transport fuer hosted Production (av-production Fargate)

Stand 2026-05-10 — vollstaendige Open-Loop-Liste:

Phase 1 — Mit echter Nummer (Tag 3+, ~5 EUR)

Erst wenn Phase 0 sauber läuft.

• US-Nummer claimen ($1/Monat)ODERDE-Nummer($3/Monat) — Entscheidung abhängig vom Use-Case
• Phone Number an Contact Flow binden
• 30–50 Test-Anrufe als reale Demo

Phase 2 — Tool-Anbindung (außerhalb 10€-Budget)

• MCP-Bridge: Lambda ruft lokal/remote MCPs (Papierkram, Calendar) — interessant wenn FAQ-Bot Tickets/Termine anfassen soll
• Conversation-Logging in S3 für Eval

Kostenschätzung (Größenordnung)

Pro Test-Call (2 Min Sprechzeit, ~10 Turns):

10 EUR ≈ $11 → ca 50 Calls Phase 0 Soft-Phone, oder ~30 Calls + DE-Nummer für 1 Monat.

Bei diesen Größen sind die Kosten dominiert von Lex/Bedrock/Polly, nicht von Connect selbst.

Sicherheit / Hygiene

• Bedrock-Invocation-Logging aktivieren (analog av-becker)
• Conversation-Logs (S3) ohne PII speichern oder gar nicht — Personenbezug raus
• Cost-Alarm av-production-monthly-cost ist bereits scharf (110 USD/Monat) — POC sollte locker drunter bleiben
• Kein Mitschnitt von Audio in Phase 0 — erst klären ob nötig (DSGVO §9 Audio = besondere Kategorie)

Offene Fragen

1. Use-Case A oder B? (Default: A — FAQ/Triage für Agentic-Ventures)
2. Soft-Phone-only oder gleich Nummer? (Empfehlung: erst Soft-Phone, Nummer in Phase 1)
3. Audio-Mitschnitt? Connect kann Calls aufzeichnen — für Eval nützlich, DSGVO-konform aber nur mit klarer Ansage am Anfang. Default: aus.
4. MCP-Tool-Anbindung im POC oder erst Phase 2? Empfehlung: erst Phase 2 — POC zeigt sonst zu wenig Voice-Kompetenz und zu viel Plumbing.

Nächste Schritte (konkret)

1. Bestätigung Use-Case (A vorgeschlagen)
2. aws sso login --profile av-prod und Bedrock-Modell-Access für Claude Sonnet 4.5 in eu-central-1 aktivieren (Console: Bedrock → Model access → Manage)
3. Connect Instance via Console oder Terraform anlegen
4. Lex V2 Bot mit FallbackIntent + DE-Locale
5. Lambda (Python) Skeleton — empfange Lex-Event, baue Prompt, rufe Bedrock, return Text
6. Contact Flow zusammenklicken, Soft-Phone-Test

Risiken

• Lex DE-Locale Eigenheiten: deutsche Lex-Bots haben weniger Built-in Slot-Types als en-US — sollte für Fallback-only egal sein
• Latenz: Bedrock-Call + Polly TTS kann 3–5s dauern, das ist im Telefon-Kontext spürbar. Streaming-Antwort über Bedrock + Polly Speech Marks könnte gegensteuern, ist aber Komplexität für Phase 2
• eu-central-1 Bedrock-Verfügbarkeit: Claude Sonnet 4.5 ist dort verfügbar (über EU Cross-Region Inference Profile), aber checken bevor wir starten

Related

• AWS-Account: _index
• Bedrock-Erfahrung: av-becker
• Hosting-Strategie: aws-multi-account-strategie
• LLM-Hosting EU: llm-hosting-eu-optionen
• Konvergenz-Kandidat: roadmap—multi-channel — Brainstorm 2026-05-18 hat receptionist als Multi-Channel-Plattform entschieden. Bei Re-Eval 2026-07-01 die Frage klaeren: Telefon-Assistent in receptionist einschmelzen (Amazon Connect = VoiceTransport), bewusst zwei Voice-Stacks parallel, oder Telefon-Assistent decommissionieren. Brainstorm-Doc: 2026-05-18-multi-channel-receptionist-requirements.md.