So funktioniert’s

Von der Anfrage zur laufenden Pipeline

Kein Prompt-Handbuch, keine Warteschleife: ein Ablauf, der zuerst das Günstige versucht und nur dort teuer wird, wo es wirklich etwas zu entscheiden gibt – fünf Schritte, danach läuft es von allein weiter.

  1. Thema oder Aufgabe formulieren

    In normaler Sprache beschreiben, worum es geht – von einer einzelnen Aufgabe bis zu einem noch unausgereiften Thema („beobachte den Markt für X“).

  2. Workflow oder KI? Das System entscheidet

    ThinkShip prüft zuerst, ob ein deterministischer Workflow reicht – Cronjob, Trigger, Datenabgleich, 0 Tokens. Nur wenn wirklich Sprache, Bewertung oder eine Entscheidung gefragt ist, baut sich automatisch das passende Agenten-Team zusammen.

  3. Agenten arbeiten, Freigaben greifen

    Wo KI wirklich gebraucht wird, arbeiten Agenten parallel oder nacheinander, orientiert an der hinterlegten Drei-Stufen-Freigabe, mit Budget- und Token-Deckel.

  4. Ergebnisse & Audit-Trail

    Ergebnisse landen auf dem Taskboard, inklusive vollständigem Nachvollzug jeder Aktion und jedes Kosten-Postens – Workflow-Schritte und KI-Schritte getrennt sichtbar.

  5. Passiv weiterlaufen, ohne laufende KI-Kosten

    Wiederkehrende Themen laufen als Workflow im Passiv-Modus weiter – 0 Tokens, bis wirklich wieder eine Entscheidung ansteht. Niemand muss den Auftrag erneut erteilen.

Beispiel 1 · einfach

Ein einfacher Workflow

So sieht Schritt 2 im kleinsten Fall aus: derselbe Trigger kann drei ganz unterschiedliche Wege nehmen, je nachdem, ob es überhaupt etwas zu tun gibt.

Der einfache Fall: der Trigger prüft täglich. Ohne Treffer bleibt es beim Workflow für 0 Tokens. Bei einem Treffer bewertet die KI die Lage – und übergibt je nach Fall automatisch an das System zurück oder an einen Menschen zur Freigabe.

TriggerTäglich 04:00 · Cronjob
SystemKein Treffer · 0 Tokens
KIBewertet den Treffer
SystemAutomatisch erledigt · 0 Tokens
MenschFreigabe nötig
Beispiel 2 · komplex

Ein realistischer Workflow: Rechnungsprüfung

Es geht aber auch deutlich vielschichtiger: derselbe Trigger kann, je nach Ausgang, vier ganz unterschiedliche Wege nehmen – inklusive zweier Aufgaben, die gleichzeitig statt nacheinander laufen.

Und der reale Fall: eine tägliche Rechnungsprüfung. Beim Datenabgleich passt die Mehrheit sofort für 0 Tokens durch. Bei einer Abweichung laufen KI-Bewertung und ein System-Budget-Check gleichzeitig – parallel, nicht nacheinander – und je nach Schwere geht es zur kurzen Freigabe, zur Finance-Freigabe oder bei Verdacht direkt zur Compliance-Eskalation mit Audit.

TriggerRechnungseingang täglich prüfen
SystemDatenabgleich mit Bestellung
SystemWerte stimmen überein
SystemZahlung angestoßen · 0 Tokens
KIBewertet Art und Höhe der Abweichung
SystemBudget & Historie · parallel · 0 Tokens
SystemKorrektur automatisch vorgeschlagen
MenschKurz-Freigabe · Stufe 1
MenschFreigabe durch Finance · Stufe 2
KIEskalation an Compliance · Verdachtsfall
MenschFreigabe & Audit · Stufe 3

Technischer Unterbau

Technisch läuft ThinkShip als eigener Stack auf Ihrer Infrastruktur: Postgres, Keycloak, NATS, ein Model Broker sowie die Backend- und Frontend-Dienste. Ein Installer richtet alles automatisiert und wiederholbar ein – kein manueller Klick-Marathon durch Admin-Oberflächen.

Hardware-Richtwerte

Grobe Einordnung für die eigene Planung – drei Bausteine, die einzeln skalieren.

Kleines Kernsystem

4 vCPU · 8–16 GB RAM · 100 GB SSD

Postgres, Keycloak, NATS, Backend & Frontend – reicht für einen Piloten oder eine kleine Organisation auf einer einzelnen VM oder einem Mini-Server.

Worker

2 vCPU · 4 GB RAM je Worker

Zustandslos und horizontal skalierbar. Faustregel: etwa 1 Worker je 5 parallel laufenden Agenten-Aufgaben, je nach Auslastung dazuschalten.

Optionale lokale KI-Modelle

16–24 GB VRAM (klein) · 48 GB+ (groß)

Nur relevant bei lokal statt Cloud gehosteten Modellen. Kleinere, quantisierte Modelle (bis ca. 14B) laufen auf einer einzelnen Workstation-GPU; größere Modelle brauchen entsprechend mehr VRAM oder mehrere GPUs.

Richtwerte zur groben Einordnung, kein Sizing-Versprechen – die tatsächliche Auslastung hängt von Nutzerzahl, Parallelität und den gewählten Modellen ab.