Warum es mir bei KI um neue Möglichkeiten geht statt um billigere Fleißarbeit
Wenn über Künstliche Intelligenz in Unternehmen gesprochen wird, geht es meistens darum, bestehende Arbeit etwas schneller oder billiger zu erledigen. Jemand lässt sich eine E-Mail vorschreiben, fasst ein langes PDF zusammen oder spart ein paar Minuten bei einer Präsentation.
Jensen Huang, der Chef von NVIDIA, hat vor einiger Zeit sinngemäß gesagt: Wahre Produktivität entsteht dann, wenn man Dinge tun kann, die man vorher schlicht nicht tun konnte. Der Preis spielt dabei eine untergeordnete Rolle.
Genau diese Erfahrung mache ich jeden Tag bei NextChapterExperts Labs. Ich habe mein Beratungs- und Softwareunternehmen als Organisation mit 16 spezialisierten KI-Agenten aufgebaut. Der größte Gewinn für mich liegt aber kaum darin, dass ich mir ein paar Stunden Buchhaltung im Monat spare. Der eigentliche Durchbruch ist, dass ich als Einzelner, zusammen mit meinen vier internationalen Studierenden, heute Softwareprodukte entwickle und Kundenprojekte stemme, die ich früher allein niemals hätte anfassen können.
Was vorher für einen Einzelnen schlicht nicht machbar war
Früher musste ich mich als Berater und Architekt entscheiden: Entweder ich arbeite voll im laufenden SAP-Kundenprojekt, oder ich halte Vorlesungen an der Hochschule, oder ich setze mich monatelang hin und programmiere ein eigenes Softwareprodukt. Alles gleichzeitig ging physisch nicht.
Heute sieht meine Woche anders aus.
Wir haben in kurzer Zeit unseren Prozess-Simulator V2 gebaut, eine vollwertige Software für diskrete Ereignissimulation und mathematische Pareto-Optimierung, die aus einer Prozessbeschreibung sofort Engpässe und einen belastbaren Business Case für den CFO berechnet. Parallel dazu ist eine eigene Diagnose-Appliance für komplexe SAP-Fehler entstanden, die vor jeder Analyse lokal alle Kundendaten anonymisiert und dann gleichzeitig elf offizielle SAP-Primärquellen abfragt. Kein Mensch kann während einer Fehlersuche simultan hunderte SAP Notes, das Architecture Center, das Help Portal und GitHub-Repos lesen und abgleichen. Meine Agenten machen das in Sekunden.
Auf dieselbe Weise betreue ich Hochschulvorlesungen in sechs Ländern und nutze für wissenschaftliche Arbeiten ein zweistufiges Gutachtersystem, bei dem ein Agent bewertet und ein zweiter Agent jede einzelne Literaturquelle live gegen die Crossref-Datenbank prüft. Und wenn ich für einen Konzernkunden eine SAP-BTP-Strecke mit Principal Propagation konzipiere, fällt hinten kein loses Foliendeck heraus, sondern ein fertiges Paket aus XML-Policies, Skripten und einem knallharten Entwickler-Cheatsheet.
Ich mache heute also Dinge, für die man normalerweise ein mittelständisches Software- und Beratungshaus mit zwanzig Spezialisten bräuchte.
Wie meine Zentrale im Alltag funktioniert
Damit ich den Kopf für diese Entwicklung und für meine Kunden frei habe, läuft meine Verwaltung im Hintergrund über neun Stabs-Agenten im Headquarter. Ich tippe dafür auch keine langen Prompts mehr in ein Chatfenster, sondern spreche direkt per Mikrofon mit meiner Stabschefin Lucy (00 Lucy).
Lucy führt morgens mit mir ein kurzes Briefing durch, nimmt meine Aufträge per Sprache entgegen und verteilt sie an die zuständigen Stellen im Haus: Clara (01) kümmert sich um Kalender, Posteingang und Wiedervorlagen. Felix (02) prüft Eingangs- und Ausgangsrechnungen und hält meine Einnahmen-Überschuss-Rechnung aktuell. Justus (03) überwacht Kundenbestellungen, NDAs und SAP-Lizenzen, während Marco (04) meine Reisen und Belege abrechnet. Viktor (05) bereitet Angebote auf Basis meiner Vorlagen vor, Nora (06) pflegt unsere zweisprachige Webseite und Videos, Linus (07) achtet auf unsere interne IT-Struktur, Argus (08) prüft als unabhängiger Kontrolleur jeden Code-Commit und jedes Dokument auf Fehler, und Sophia (09) verwaltet unser Unternehmensgedächtnis.
Harte Leitplanken statt freilaufender Agenten
Wer schon einmal versucht hat, ein größeres Projekt über ein normales Chatfenster mit einem Sprachmodell zu steuern, kennt das Problem: Nach ein paar Stunden wird der Verlauf zu lang, das Modell vergisst frühere Absprachen, erfindet Zahlen dazu oder reißt mit einer Änderung an einer Stelle das halbe System an einer anderen Stelle ein.
Bei mir haben die Agenten deshalb keinen kreativen Freilauf, sondern bewegen sich in einem extrem engen Korsett aus technischen Guardrails und festen Regeln.
Kein Agent arbeitet in einem endlosen Sammel-Chat. Wenn ich Lucy eine Aufgabe gebe, startet sie für jeden Teilauftrag einen eigenen Subagenten mit einem kleinen, komplett isolierten Kontextfenster. Dieser Agent sieht nur die Daten und darf nur die Werkzeuge anfassen, die für genau diesen einen Arbeitsschritt freigegeben sind.
Außerdem darf ein Sprachmodell bei uns niemals selbst rechnen, buchen, Datenbanken direkt verändern oder wiederkehrende Abläufe frei improvisieren. Alles, was exakt sein muss, gießen wir in festen Python- oder TypeScript-Code. Über 460 solcher deterministischen Skripte laufen bei uns in einer strikten Fünf-Schichten-Onion-Architektur (0-infra bis 4-ui). Jede Eingabe und jede Ausgabe wird über harte Schemata geprüft. Und es gilt ein eisernes Gesetz: Keine einzige Codedatei darf länger als 200 Zeilen sein. Überschreitet eine Datei 200 Zeilen oder verletzt eine Schichtgrenze, bricht der Build sofort ab. Durch diese kurzen, übersichtlichen Dateien finden sich auch die Programmier-Agenten sofort zurecht, ohne Fehler einzubauen.
Dazu kommt eine unbestechliche Kontrollinstanz: Unser Prüfer-Agent Argus (08) schaut jedem anderen Agenten auf die Finger. Kein Code-Commit, kein Fachgutachten und kein Kunden-Dokument verlässt das System, ohne dass Argus die Architekturregeln, die Quellenbelege und die Sicherheitsvorgaben automatisch gegengeprüft hat. Und für alle Schritte mit Außenwirkung, etwa beim Versand einer E-Mail, einer Kalendereinladung oder einer Buchung, greift eine harte Freigabeschranke: Der Agent bereitet alles fix und fertig vor, aber der letzte Knopf liegt zwingend bei mir.
Sicherheit auf Leitungsebene und das 7-Schichten-Gedächtnis
Im SAP- und Konzernumfeld reicht es nicht, einem Cloud-Anbieter einfach zu vertrauen. Datenschutz muss technisch erzwungen werden.
Deshalb haben wir vor jeden externen Aufruf eine doppelte Sicherheitsschranke geschaltet: NVIDIA OpenShield und unseren selbst entwickelten Wire-Level HTTP-Egress-Monitor. Bevor irgendein Datenpaket meinen Rechner verlässt, werden Kundennamen, System-IDs, Mandantennummern, Passwörter und personenbezogene Daten lokal auf meinem System erkannt und sauber maskiert. Unser HTTP-Egress-Monitor hängt direkt auf der Leitungsebene, prüft jeden ausgehenden Request Byte für Byte und schreibt für jede Sitzung ein kryptografisch signiertes Prüfprotokoll (SHA-256). Ich kann damit jederzeit schwarz auf weiß belegen, dass kein einziges vertrauliches Kunden-Byte das Haus verlassen hat.
Genauso geordnet ist unser gemeinsames Unternehmensgedächtnis, das Sophia (09) verwaltet. Statt alle Dokumente in einen großen Topf zu werfen, trennt unser Company Brain sieben Schichten sauber voneinander: vom aktuellen Tagesstatus (Working Memory) über die Projekthistorie (Episodic Memory), unsere Stammdaten samt elf angebundener SAP-Primärquellen-Server (Semantic Memory) und über 50 ausführbare Standard-Workflows (Procedural Memory) bis hin zum bi-temporalen Knowledge Graph, dem unveränderlichen SHA-256 Audit-Ledger und einem AES-256-verschlüsselten Dokumententresor.
Läuft auf jeder beliebigen Hardware (und warum die 84,03 € nur eine Randnotiz sind)
Wenn man sieht, welche Softwareprodukte und Ergebnisse aus dieser Architektur entstehen, wäre es wirtschaftlich fast zweitrangig, ob das System im Monat hundert oder tausend Euro kostet.
Tatsächlich kostet mich der komplette laufende Betrieb inklusive 20 Terabyte Cloud-Speicher über den festen Google AI Ultra Plan aber nur 84,03 Euro netto im Monat. Weil 90 Prozent der Arbeit in unseren eigenen deterministischen Skripten erledigt werden, verbrennen wir keine teuren Pay-per-Token-APIs.
Noch wichtiger für uns und unsere Kunden ist aber die technische Unabhängigkeit, die aus dieser Bauweise folgt: Unsere gesamte Agenten-Architektur läuft auf jeder beliebigen Standard-Hardware. Sie läuft auf meinem ganz normalen Linux-Notebook unterwegs im Zug genauso wie auf einem kleinen Büro-Server, in einer privaten Cloud oder komplett abgeschottet im eigenen Rechenzentrum eines Kunden.
Weil die eigentliche Geschäftslogik, die Berechnungen und die Guardrails fest in unseren schlanken Skripten stecken und die Sprachmodelle immer nur winzige, präzise zugeschnittene Teilaufgaben abarbeiten, braucht man dafür auch keinen riesigen Supercomputer. Man kann wie ich über den festen Google-Plan arbeiten oder das System jederzeit auf ein lokales Open-Weights-Modell direkt auf der eigenen Hardware umschalten. Die lokalen Modelle werden von Quartal zu Quartal stärker, und unsere Architektur darunter bleibt auf jeder Maschine zu hundert Prozent dieselbe.
Vier produktive Lösungen und Ausblick auf Teil 2
Auf genau diesem Fundament sind in unserem Lab bereits vier produktive Software- und Beratungsprodukte entstanden, die wir in den kommenden vier Teilen dieser Serie im Detail zeigen:
In Teil 2 stellen wir gemeinsam mit unseren vier internationalen Studierenden unseren Prozess-Simulator V2 vor (Diskrete Ereignissimulation und mathematische Pareto-Optimierung). Teil 3 zeigt unsere Academic Governance & Review Engine (04 Erasmus) mit zweistufigem Prüfer-Board und Live-Crossref-Abgleich. In Teil 4 öffnen wir unsere SAP Problem-Solution Appliance (03 Magnus) mit lokalem Sanitizer und elf offiziellen SAP-Primärquellen-Servern. Und Teil 5 zeigt, wie wir mit 02 Conrad und 06 Nexus produktionsreife SAP BTP Integration Suite Flows, OAuth-XML-Policies und Principal-Propagation-Strecken in einem Bruchteil der bisherigen Projektzeit ausliefern.
Im nächsten Artikel öffnen wir gemeinsam mit unseren vier Studierenden die Motorhaube des Prozess-Simulators V2 (siehe Vorschau unten) und zeigen Schritt für Schritt, wie aus einer Prozessbeschreibung in wenigen Minuten ein mathematisches Simulationsmodell mit Live-Engpassanalyse und belastbarem CFO-Business-Case entsteht.
Sie möchten wissen, wie wir diese deterministische Agenten-Architektur oder unsere SAP-BTP- und Simulations-Engines in Ihrem Unternehmen einsetzen können? Schreiben Sie uns direkt über unsere Kontaktseite.