Der Beitrag ist der dritte Teil einer Serie über einen LangGraph-basierten Buchungsagenten, der einen 15-minütigen Buchungsprozess vollständig abwickelt – von der Preisberechnung über Zeitslot-Vorschläge bis zur Terminbestätigung. Zuvor lief der Agent mit zwei flüchtigen In-Memory-Strukturen: einem LangGraph-Checkpointer via `MemorySaver()` und einer `InMemoryBookingRepository`-Klasse, die Buchungen in einer mit `threading.RLock` gesicherten Python-Liste hielt. Das zentrale Problem dieser Architektur: Bei jedem Prozess-Neustart verschwinden Checkpoints und Buchungen, und verschiedene Sessions – etwa Streamlit und WhatsApp gleichzeitig – können die Verfügbarkeit nicht teilen, was zu Doppelbuchungen führen kann. Die Lösung ist ein Protocol-Interface namens `BookingRepository`, das `list_bookings` und `create_booking` definiert und sowohl von `InMemoryBookingRepository` als auch von `PostgresBookingRepository` implementiert wird. Die Wahl zwischen den beiden Backends erfolgt zur Laufzeit über die Umgebungsvariable `DATABASE_URL`: Ist sie gesetzt, nutzen sowohl die Buchungslogik als auch der LangGraph-Checkpointer PostgreSQL; andernfalls bleibt alles im Speicher. Das PostgreSQL-Schema besteht aus zwei Tabellen – `technicians` und `bookings` – und die `PostgresBookingRepository`-Klasse umfasst knapp 100 Zeilen Code. Der vollständige Quellcode ist im GitHub-Repository `customer-service-agent` verfügbar.