Die Engine


Ein Graph, keine Warteschlange

Wir führen dieses Unternehmen auf einem gerichteten Graphen, der über Sitzungen und Modellgenerationen hinweg bestehen bleibt; Zustand, Herkunftsnachweis und Governance liegen dabei im Graphen selbst und nicht im Fenster. Das Modell ist eine Komponente, die wir austauschen. Der Graph ist das Unternehmen.

Der Beleg ist nicht architektonisch, sondern historisch: Derselbe Graph hat dieses Unternehmen bereits durch Engine-Releases und Wechsel des zugrunde liegenden Modells geführt, während die laufende Arbeit, ihr Herkunftsnachweis und ihre Governance intakt blieben.

Ein Chat-Assistent beantwortet die Anfrage, die vor ihm liegt. Das ist die richtige Form für eine Frage mit einer Antwort und die falsche Form für Arbeit, die über Wochen läuft: Das Fenster schließt sich und der Zustand ist verloren, nichts bewegt sich, wenn nicht ein Mensch tippt, und die Zerlegung, in der der Großteil der Beurteilung steckt, bleibt beim Menschen. Der Assistent ist bei jedem Schritt schnell und in der gesamten Abfolge abwesend.

Wir bauen die Abfolge. Die Engine erweitert sitzungsgebundene Graphmuster zu einem persistenten Betriebsgraphen, der über Sitzungen, Releases und Modellgenerationen hinweg besteht. Sie ist eine direkte Erweiterung der Arbeit, auf der sie aufbaut: der seit 2023 von Forschungsgruppen veröffentlichten graph- und baumstrukturierten Schlussfolgerungsmethoden sowie der 2025 und 2026 von führenden Labs veröffentlichten Harness-Muster. Ein großer Teil dieser Arbeit konzentriert sich auf Schlussfolgern oder Orchestrierung innerhalb eines begrenzten Durchlaufs. Unser Ansatz bleibt über Durchläufe hinweg bestehen.

Knoten sind Arbeitseinheiten, Entscheidungen, Prüfungen und Ereignisse, jeweils mit einem festgelegten Verantwortlichen. Kanten sind Bedingungen: Ein Knoten wird ausführbar, wenn seine Abhängigkeiten erfüllt sind, nicht wenn ein Zeitplan gerade ansteht. Prüfknoten sind allem vorgeschaltet, was als Ergebnis zählt, sodass ein Bericht, der eine deterministische Vorprüfung nicht besteht, nie einen Integrator erreicht. Zusammenführungspunkte sind explizit, und genau das verhindert das klassische Scheitern paralleler Agenten, die alle hinter dem langsamsten anstehen.

Zwei Richtungen sind wichtiger als Geschwindigkeit. Rückwärts: Von jedem Ergebnis aus können Sie den Graphen bis zu der Entscheidung, der Regel und der Rolle zurückverfolgen, die es hervorgebracht haben. Vorwärts: Von einem Ziel aus können Sie zu den Zweigen gehen, die es tatsächlich voranbringen, und zu denen, die still geworden sind. Ein Board, das beides nicht kann, steuert nicht, sondern arbeitet nur.

Der Gewinn ist messbar, und wir messen ihn. Durch das Ersetzen einer geplanten Übergabe durch eine Ereigniskante sank die Zeit zwischen dem Abschluss einer Arbeitseinheit und der Integration ihres Ergebnisses von einem 60-Minuten-Polling-Zyklus auf 41 Sekunden – in Produktion, am 2. August 2026. Die Polling-Watchdogs blieben als Sicherheitsnetz bestehen und zählen, was sie auffangen; das Ziel für diesen Zähler ist null.

Provenienz: Hash-Ketten und Stempel

Jede Aktion wird vor ihrer Ausführung im Ledger erfasst, und das Ledger ist als Hash-Kette aufgebaut. Der Eintrag hält fest, wer gehandelt hat, in welcher Rolle und nach welcher Regel; die Kette macht unbemerkte nachträgliche Änderungen erkennbar, statt sie lediglich zu missbilligen. Für den Speicher gilt dieselbe Disziplin: Fakten werden so abgelegt, dass sie nach ihrer Bedeutung statt nach Dateinamen gefunden werden können; jeder Fakt trägt bei sich, wer ihn auf welcher Grundlage angegeben hat, und ein nächtlicher Durchlauf kennzeichnet überholte Fakten als nicht mehr aktuell, statt zwei Versionen der Wahrheit nebeneinander stehen zu lassen.

Wiederkehrende Abläufe laufen in einem Ausführungsrahmen mit Zeitstempel, der bei jeder Ausführung die Job-Identität, das Ergebnis und die Dauer erfasst. Damit kehren wir den üblichen Monitoring-Fehler um: Statt auf alte Logzeilen zu alarmieren, alarmieren wir bei einem fehlenden Zeitstempel. Ein Job, der nie gestartet ist, hinterlässt kein Log, das alt aussehen könnte.

Gates, Versionen und wer Releases freigeben darf

Die Engine wird wie Software versioniert und veröffentlicht, mit Rollback auf jedes frühere Tag sowie einem Manifest, das Abweichungen zwischen dem laufenden und dem deklarierten Zustand meldet. Ausgehende Vertriebs-E-Mails, Veröffentlichungen und Deployments passieren ein Gate, bevor sie das System verlassen. Änderungen werden nach Risiko klassifiziert; eine Änderung mit hohem Risiko stoppt, bis der Eigentümer sie auf seinem eigenen Telefon hinter einer Gerätesperre genehmigt. Dieser Bestätigungskanal hat ein eigenes Geheimnis, getrennt von der Telemetrie des Systems: Ein kompromittierter Telemetrieschlüssel verschafft nicht das Recht, eine Änderung zu genehmigen.

Eine Verhaltensregel sollten wir öffentlich festhalten, weil wir sie auf die teure Art gelernt haben: Prüfung und Freigabe befinden sich niemals in derselben Aufrufkette. Zuerst wird ein Urteil gelesen, und erst dann wird die Freigabe als separater Schritt entschieden. Das gilt auch um vier Uhr morgens.

Ein Board darüber, nicht nur eine Engine

Sechs Board-Mitglieder betreiben diese Engine; jedes verantwortet einen Bereich: Strategie, Finanzen, Handel, Produkt, Integrität, Marketing. Arbeit wird an die verantwortliche Person des zugehörigen Bereichs geleitet, ein separater Kritiker prüft sie gegen das Register, bevor sie als entschieden gilt, und die Ergebnisse werden anschließend daran gemessen, was tatsächlich geschehen ist. Dieser letzte Teil macht eine spätere Version besser statt nur neuer und unterscheidet ein System, das läuft, von einem System, das sich verbessert.

Weil dem Board die Engine gehört, verändert die Engine sich selbst. Erkenntnisse aus ihren eigenen Audits werden zu spezifizierter Arbeit mit messbaren Kriterien und einer Rollback-Bedingung, und die Korrekturen werden durch dieselben Gates wie alles andere veröffentlicht.

Ein zusätzlicher Blick von außen – ganz bewusst

Die Engine wird von einem externen, modellübergreifenden KI-Reviewer aus einer anderen Modellfamilie geprüft – anhand eines abgegrenzten Briefings, das keine Zugangsdaten, keine Dateipfade und keine Kundendaten enthält und ohne Zugriff auf das System. Ein interner Kritiker erkennt Abweichungen von einer schriftlichen Verfassung, kann aber keine falsche Annahme erkennen, die er selbst teilt.

Die Erkenntnisse des Reviewers kommen als Aufgaben zurück, jeweils mit Ausgangswerten, Akzeptanzkriterien und einer Rollback-Bedingung. Das macht aus einem Audit Arbeit statt einer Liste von Meinungen.

Was wir als Nächstes bauen

Denkräume. Eine begrenzte Abwägungsebene, die für jede Frage geöffnet wird, statt standardmäßig zu laufen. Die Forschung ist eindeutig, warum: Multi-Agenten-Debatten mit identischen Eingaben verbessern die erwartete Korrektheit nicht; schwächere Teilnehmende passen sich der Mehrheit an, statt eine korrekte Minderheitenposition zu vertreten; und Selbstreflexion erzeugt keine neuen Erkenntnisse mehr, sobald ein Modell von seiner ersten Antwort überzeugt ist. Daraus folgt das Design: heterogene Rahmungen und asymmetrische Informationen pro Teilnehmendem, ein Richter, der das Minderheitensignal schützt, verpflichtender Widerspruch und eine Premortem-Analyse bei jeder wichtigen Entscheidung sowie baumförmige Exploration mit Beschneiden und Zurückspringen bei folgenschweren Entscheidungen. Das Ergebnis des Raums geht in einen begrenzten Speicher, nicht in den allgemeinen Backlog: Ein Ideengenerator, der an ein System angeschlossen ist, das bereits schneller Arbeit erzeugt als abschließt, würde genau das Falsche verstärken.

Ein lokales Identitätsmodell. Ein kleines Modell auf unserer eigenen Hardware, dessen Aufgabe nicht darin besteht, Arbeit zu erzeugen, sondern Kontinuität zu bewahren: wer wir sind, was wir entschieden haben, was wir glaubten und auf welcher Evidenz. Eine Identität, die von der Modellgeneration eines einzelnen Anbieters abhängt, ist gemietet, nicht im Besitz. Dieses Modell wartet auf Hardware, und die Hardware wartet auf Umsatz.

Quellenangaben

Quellen, die beim Aufbau des oben Beschriebenen tatsächlich verwendet wurden. Nur Open Access. Die obige Architektur erweitert diese Arbeit; sie wiederholt sie nicht.

Graph- und baumstrukturierte Schlussfolgerungen sowie Agentenorchestrierung
Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models" (AAAI 2024, arXiv:2308.09687).
Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Princeton / Google DeepMind, 2023, arXiv:2305.10601).
Anthropic, dynamische Workflows und Harness-Design für agentische Systeme (2025-2026): industrielle Referenz für parallele Sub-Agenten und eine Prüfung vor der Ausgabe. Ein Großteil der veröffentlichten Arbeit konzentriert sich auf Schlussfolgerungen oder Orchestrierung innerhalb eines begrenzten Durchlaufs; unsere Organisation besteht dauerhaft, daher sind die Muster übertragbar, aber nicht kopierbar.
Der Fachdiskurs von 2026 über Graphentechnik für Agenten: Disziplin bei Knoten und Kanten, der False-Edge-Test, Prüfknoten, statische und dynamische Graphen, Topologie als Kostenhebel.

Deliberation und ihre dokumentierten Fehlermodi
Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate" (2023, arXiv:2305.14325).
Liang et al., "Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate" (Degeneration-of-Thought, arXiv:2305.19118).
Zheng et al., "Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models" (Google DeepMind, arXiv:2310.06117).
Zhou et al., "Self-Discover: Large Language Models Self-Compose Reasoning Structures" (Google DeepMind, arXiv:2402.03620).

Gedächtnis, Struktur und Präzedenzfälle
Sumers et al., "Cognitive Architectures for Language Agents" (CoALA, 2023, arXiv:2309.02427).
Swanson et al., das Virtual Lab: ein KI-Agententeam mit einem leitenden Agenten, Spezialisten und einem Kritiker-Agenten, das echte Forschungsergebnisse hervorbringt (Nature, 2024).
UC Berkeley RDI, Agentic AI F25 (Herbst 2025): Multi-Agenten-Strukturen, Agentengedächtnis, Einsatz in der Produktion, Evaluierungsdesign.

Governance und Sicherheit
NIST AI RMF 1.0 und das Generative AI Profile (NIST-AI-600-1).
OWASP Top 10 for LLM Applications 2025, insbesondere Prompt Injection, übermäßige Handlungsautonomie sowie Schwachstellen bei Vektoren und Embeddings.
EU AI Act (Verordnung (EU) 2024/1689), Artikel 50 zur Transparenz.


Was wir nicht veröffentlichen

Architekturdetails, interne Prozessmechanismen, der Zeitpunkt automatisierter Vorgänge und alles, was eine direkte Replikation des Systems ermöglichen würde. Der Test vor jeder Offenlegung: Könnte ein Wettbewerber anhand dieser Informationen dasselbe bauen? Wenn ja, wird es nicht veröffentlicht.

Wohin sich ein solches System entwickelt

Unsere Produkte sind der sichtbare Beweis. Die Engine konzipiert, entwickelt, liefert und unterstützt echte Software – durchgängig. Was darunterliegt, ist allgemeiner als jedes einzelne Produkt: ein agentisches System, das die eigenen Daten eines Unternehmens kontinuierlich und vollständig direkt an der Quelle liest und erkennt, was stichprobenbasierte, jährlich stattfindende Prüfungen nicht erkennen können.

Das weist auf etwas Größeres als Mietsoftware hin. Richtet man dieselbe Engine auf die Finanz- und Betriebssysteme eines Unternehmens aus, leistet sie kontinuierlich auf Basis der vollständigen Daten, was Due Diligence und Unternehmensanalyse einmal jährlich anhand einer Stichprobe zu erreichen versuchen: eine fortlaufende, unabhängige Einschätzung der tatsächlichen Unternehmensleistung und der Risikopositionen. Wir betreiben Offsite bereits auf diese Weise.

Wir finanzieren dies aus den Erträgen unserer Produkte. Wir führen keine Finanzierungsrunde durch, und die Engine steht nicht zum Verkauf. Wir entwickeln offen.

Quellen und eine allgemeine Beschreibung: Methodik.