call2web ist eine Telefonhotline, bei der man anruft und dann von einem KI-Agenten begrüßt wird. Dieser führt dann ein Interview durch und sammelt Informationen über das Unternehmen oder die Website, die der User bauen möchte. Sobald der KI-Agent genug weiß, promptet er eine externe Plattform (v0), die aus den Angaben eine Website generiert welche dann deployed wird. Der Anrufer kriegt nach dem Deployment eine SMS mit der URL des Deployments. Nach zwei weiteren Minuten ruft der KI-Agent den Nutzer dann zurück und fragt nach Feedback zur Seite. Dieses wird dann eingearbeitet, die Website neu deployed und der Nutzer kriegt eine finale SMS mit seiner Website.Das Projekt kann also Anrufe empfangen und selbst auch Nummern anrufen und SMS verschicken, zusätzlich dazu Websites vibecoden und deployen. Um das Projekt in so kurzer Zeit umsetzen zu können habe ich auf viele externe Schnittstellen gesetzt: • Die Telefonnummer und der SIP Trunk kommen von twilio. • Aus der fonio Dokumentation habe ich herausgefunden, dass bei fonio mit LiveKit gearbeitet wird, also habe ich diese Plattform auch für das Call Session Management in meinen Tech Stack aufgenommen. • Die Erstellung der Website läuft über v0 (ähnlich wie Lovable von Vercel) • Die Websites selbst werden dann auf Vercel gehostet • TTS realisiere ich mit ElevenLabs und STT mit Deepgram • Zuletzt, damit der KI-Agent conversational ist und nicht nur ein Skript abliest, nutze ich die Groq API, um mit dem hohen Token Throughput geringe Latenz beim Antworten des Agenten zu garantieren.

Zur Orchestrierung solch eines komplexen, mehrschrittigen Workflows mit vielen externen Schnittstellen kommt in der App das Transactional Outbox Pattern zum Spiel. So gibt es eine Job Table und eine Commands Table. Ein Job hat einen State Eintrag, welcher immer in der gleichen Transaktion geupdated wird, in der auch Commands in die Commands Table geschrieben werden. Diese Commands werden dann von einem “Worker” nach und nach aufgenommen und abgearbeitet. Diese Architektur erlaubt es den Workflow konsistent zu halten, auch wenn einzelne Schritte oder Database-Requests fehlschlagen. Das Deployment der App läuft simpel über Docker Compose auf meinem eigenen Hetzner VPS. Nur der Traffic vom Hetzner VPS zur v0 API wird noch über eine kleine AWS Maschine proxied, da die Hetzner IPs von v0 geblockt sind.