9.000 $/Monat → 700 $/Monat

Eine Immobiliensuche lieferte 50 bis 500 Käufer. Der alte Weg erzeugte für jedes Ergebnis eine Ansprache, bevor der Nutzer jemanden für die Kontaktaufnahme auswählte.

Dadurch stiegen die Kosten mit den Suchergebnissen. Sie hätten mit der wesentlich kleineren Zahl der Personen steigen sollen, die tatsächlich eine Nachricht erhielten.

SendFlow erstellte den ersten Entwurf mit bis zu drei Wiederholungen. Ein Review Gate nahm ihn an oder lehnte ihn ab, ein Content Rewriter passte Ton und Details an, und ein Message Humanizer erzeugte zwei oder drei Varianten. Acht Worker-Threads führten diese Kette parallel aus und speicherten die Ausgabe in der Datenbank, bevor jemand auf Send klickte.

Suchergebnis
  -> SendFlow (bis zu drei Wiederholungen)
  -> Review Gate
  -> Content Rewriter
  -> Message Humanizer (2–3 Varianten)
  -> jedes Ergebnis speichern

Die Kette führte vier bis fünf Modellaufrufe pro Käufer aus. Bei einer Suche mit 500 Käufern bedeutete das rund 2.500 Modellaufrufe, bevor der Nutzer einen Empfänger auswählte.

Im Beispiel mit 500 Ergebnissen kontaktierten Nutzer etwa 100 Käufer. Rund 80 % der vorab berechneten Nachrichten wurden nie verwendet; damit blieben etwa 2.000 Aufrufe ohne nutzerseitiges Ergebnis. Promptoptimierung hätte jeden Aufruf günstiger machen können, aber nicht die ungenutzten Aufrufe gerechtfertigt.

Die überarbeitete Suche gab Käufer zurück, ohne eine Ansprache zu erzeugen. Eine ausdrückliche Aktion Regenerate with AI rief einen spezialisierten Agenten für den ausgewählten Kontakt auf. Der Anfragekontext umfasste Standort, Telefonnummer, Vornamen von Käufer und Absender, Markt, Käuferaktivität, formatierten Gesprächsverlauf und Käufer-ID; das Ergebnis blieb vor dem Senden bearbeitbar.

Suche nach 500 Käufern -> 0 Nachrichten erzeugen
Nutzer wählt einen Käufer -> Kontakt- und Gesprächskontext zusammenstellen
Regenerate with AI -> 1 Modellaufruf
ProgressReporter -> alle zwei Sekunden WebSocket-Aktualisierung
Bearbeitbares Ergebnis -> Nutzer entscheidet über das Senden

Die Implementierung entwickelte sich weiter. Ein Repository-Snapshot nutzte eine direkte REST-Anfrage, sobald sich das Panel des ausgewählten Kontakts öffnete; im späteren Ablauf aus der Artikelquelle wurde die Aktion erst nach einer ausdrücklichen Entscheidung des Nutzers ausgelöst und der Fortschritt über WebSocket gestreamt. Das sind Entwicklungsstufen des Produkts, nicht ein gleichzeitig vorhandener Codepfad.

Das Produkt verfügte über mehr als 25 spezialisierte Agent-Konfigurationen auf gpt-4.1-nano. Für jede Anfrage wurde eine Konfiguration ausgewählt; es handelte sich nicht um eine Kette aus 25 Agenten. ProgressReporter sendete während der Nachrichtenerstellung alle zwei Sekunden eine WebSocket-Aktualisierung.

Durch die Verlagerung der Erstellung hinter einen Klick wurde die Wartezeit sichtbar. Das Ergebnis blieb bearbeitbar, der Fortschritt wurde angezeigt, und die Erstellung erfolgte nur für den vom Nutzer ausgewählten Empfänger.

Im dokumentierten Beispiel mit 500 Käufern sanken die Aufrufe von etwa 2.500 auf etwa 100, also um 96 %. Die monatlichen Modellausgaben gingen von rund 9.000 auf rund 700 US-Dollar zurück. Diese gerundeten Monatswerte ergeben eine hochgerechnete jährliche Ausgabenminderung von rund 100.000 US-Dollar.

Die Änderung entfernte außerdem 1.218 Zeilen, darunter den 640-zeiligen Stapelprozessor. Durch das Löschen dieses Wegs entfielen auch seine Wiederholungen, Worker, Persistenz und Koordination mehrerer Agenten.

• Messen Sie, wie viel erzeugte Ausgabe Nutzer tatsächlich verwenden.
• Führen Sie aufwendige Arbeit erst aus, wenn das Produktereignis eintritt, das sie benötigt.
• Zeigen Sie sichtbaren Fortschritt, wenn bedarfsgesteuerte Arbeit nicht sofort abgeschlossen werden kann.
• Löschen Sie die Stapelarchitektur, sobald das Produkt nicht mehr von ihr abhängt.