🏠 Verwaltung · Vertriebs-Demo

Wohngeld-Antragsbegleiter

Eine interaktive Demo, die zeigt, wie ein KI-Agent eine Wohngeldstelle entlastet — vom Antragseingang bis zum Bescheid-Entwurf, inklusive Sonderfall-Eskalation auf freie Quer-Fragen. Gebaut für ein Vertriebs-Gespräch mit einer Kreisverwaltung im Rhein-Sieg-Kreis.

Demo starten → Wie wurde das gebaut?

Was die Demo zeigt

Ein 4-Tab-Sachbearbeiter-Workflow mit drei Demo-Personen (Maria Schmidt · Wolfgang Müller · Sandra Krüger), die jeweils einen anderen Fall-Typ repräsentieren: Standardfall, Unvollständig-Fall, Sonderfall mit § 2 WoGG-Eskalation.

TAB 1
Antragseingang
TAB 2
Vollständigkeit
TAB 3
Berechnung
TAB 4
Bescheid

Highlights

Der Aha-Moment im Vertriebs-Termin: Der Agent weiß, wann er nicht entscheiden darf. Bei Sandras Sonderfall (§ 2 WoGG Vorrang Bürgergeld) zeigt er Eskalation an die Sachbearbeiterin statt zu rechnen. Das ist der Vertrauens-Anker — nicht "KI ersetzt", sondern "KI entlastet bei Routine, eskaliert bei Komplexität".

Wie wurde das gebaut?

Ein 2-Tage-Solo-Build mit Claude Opus 4.7 (1M Token Context) und einem strukturierten Agent-Workflow. Nicht Vibe-Coding — ein eigens entwickelter Phasen-Workflow mit TDD-Gates, atomaren Commits pro Task und Sub-Agent-Loops, die jede Phase autonom durchlaufen.

TL;DR

Build-Workflow im Überblick

Für jede Phase eine eigene Pipeline: Planner-Agent schreibt 5-7 atomare Plans mit Frontmatter und Acceptance-Criteria, Executor-Agent arbeitet sie ab mit TDD-Gates (RED-Commit für failing tests vor GREEN-Commit für Impl). Jeder Task ist ein atomarer git commit. Der Orchestrator stoppt nur bei echten Blocking-Checkpoints (z.B. Live-App-Verifikation).

HebelEffekt
Claude Opus 4.7 mit 1M Token ContextSub-Agent sieht alle Phase-Summaries & KB-Snippets — kein Kontext-Verlust
Strukturierte Acceptance-CriteriaSub-Agent verifiziert sich selbst per grep / Test / CLI-Assert
TDD-Gates & atomare CommitsKeine "hat doch funktioniert"-Halluzinationen, jeder Task einzeln rollback-bar
Persona-Konsistenz-Vertrag10 Code-Stellen pflegen 3 Personae synchron — Drift-Schutz via Coverage-Test

Reproduzierbarkeit auf weitere Vertikalen

Der Build-Workflow ist nicht wohngeld-spezifisch. Geschätzter Aufwand für eine nächste Demo-Vertikale (Reisebüro-Anfrage, Steuerberater-Belege, Handwerker-Angebot, …):

AufwandWas passiert
Tag 1PROJECT.md + Roadmap + Foundation/KB/Mock-Daten/LLM-Wrapper (50% aus Wohngeld-Demo direkt übernommen)
Tag 2Tab-Workflows der Vertikale (domain-spezifisch, Pattern identisch)
Tag 3 optionalQuer-Fragen + Eskalation + Demo-Skript + Pre-Demo-Checkliste

Implikation: Pro Prospect-Termin eine fachlich passende Demo bauen ist wirtschaftlich. Festpreis-Build fähig, marginale Hosting- und LLM-Kosten.

Demo-Charakter: Diese Anwendung ist eine Vertriebs-Demo, keine produktive Lösung. Mock-Daten klar als DEMO gekennzeichnet, kein Auth, keine Fachverfahrens-Integration. Ein Pilot mit echtem Datenanschluss wäre ein separater Schritt (~4-6 Wochen, Festpreis-kalkuliert).

Mehr technische Details, vollständige Build-Notes, Decision-Log und alle Pre-existing-Issue-Fixes: auf Anfrage als Direktlink zum privaten GitHub-Repository.

Eckdaten