Vor einiger Zeit schrieb ich in meinem Essay «Die wichtigste Abteilung, die keine Firma besitzt» über ein Problem, das mich schon länger beschäftigt: Organisationen optimieren einzelne Bereiche, Prozesse und Entscheidungen. Fast niemand trägt jedoch die Verantwortung dafür, dass am Ende noch alles zusammenpasst.
Lokale Rationalität erzeugt noch keine globale Kohärenz.
Inzwischen begegnet mir dasselbe Problem in meiner eigenen technischen Infrastruktur. Je mehr Systeme, Repositories, Automationen und KI-Agenten hinzukommen, desto leichter entsteht eine besondere Form von Drift. Ein einzelner Argios-Task verbessert einen Runner. Ein anderer dokumentiert eine Ausnahme. Ein dritter baut für dasselbe Problem einen Workaround. Jede Entscheidung kann für sich vernünftig sein, während das Gesamtsystem langsam widersprüchlich wird.
Also begann ich, die Idee aus dem früheren Essay als Infrastrukturprinzip umzusetzen.
Ich baue mir ein «Consistency Department».
Eine Abteilung ohne Monopol
Das Consistency Department soll kein weiterer zentraler Monolith werden. Es ist auch keine neue oberste Source of Truth, die alle anderen Systeme entmündigt. Seine Aufgabe liegt in der Koordination: Es sucht projektübergreifend nach Widersprüchen, Drift und unnötiger Parallelentwicklung.
Die einzelnen Systeme behalten ihre Autorität. Mobula bleibt die fachliche Geschäftswahrheit für Kunden, Leistungen, Arbeit und Freigaben. Die Argio Knowledge Base bewahrt dauerhafte Standards und Zusammenhänge. Paladin beobachtet technische Zustände und Sicherheitsbefunde. Das operative Repository kennt Runner, Deployments und Infrastrukturzustände. Das Design System verantwortet die visuelle Konsistenz.
Das Consistency Department entscheidet nicht, welche dieser Quellen recht hat. Es prüft, welche Quelle für eine konkrete Frage überhaupt zuständig ist.
Wenn zwei Systeme dieselbe Sache unterschiedlich definieren, soll es den Konflikt erkennen. Wenn mehrere KI-Agenten unabhängig denselben Fehler lösen, soll es feststellen, ob daraus ein gemeinsamer Fix entstehen muss. Weicht ein Produkt bewusst von einem Standard ab, wird aus der scheinbaren Inkonsistenz eine dokumentierte Ausnahme mit einer nachvollziehbaren Begründung.
Konsistenz bedeutet dabei nicht Gleichförmigkeit. Unterschiedliche Systeme dürfen unterschiedliche Regeln besitzen. Problematisch wird es erst, wenn diese Unterschiede unbemerkt entstehen oder niemand mehr erklären kann, weshalb sie bestehen.
Mehr Agenten, mehr Drift
Besonders sichtbar wird das Problem bei mehreren parallel arbeitenden Argios-Instanzen. Ein einzelner Agent kennt seinen Auftrag und sein Repository. Er kann lokal eine ausgezeichnete Entscheidung treffen, ohne zu wissen, dass ein anderer Agent gerade an einer anderen Stelle eine ebenso plausible, aber widersprüchliche Lösung entwickelt.
Die Schwierigkeit liegt damit nicht im Mangel an Intelligenz. Sie entsteht aus begrenztem Kontext und verteilter Verantwortung.
Dafür braucht das System eine zusätzliche Koordinationsebene. Bei bestimmten Auslösern – etwa Änderungen an gemeinsamen Runnern, Schemas, Standards, Zugriffsmodellen oder mehreren Repositories gleichzeitig – soll ein Argios-Task den Consistency-Controller konsultieren. Dieser ordnet den Fall ein, bestimmt die zuständige Autorität und koordiniert bei Bedarf weitere laufende Tasks.
Der Controller löst das Problem nicht selbst. Er verhindert, dass mehrere gute lokale Lösungen unbemerkt zu einer schlechten gemeinsamen Architektur werden.
Delta statt Dauerprüfung
Koordination darf nicht bedeuten, sämtliche Systeme ständig vollständig zu durchsuchen. Das wäre teuer, langsam und würde selbst wieder zu einem neuen Monolithen führen.
Darum ist ein täglicher leichter Delta-Audit vorgesehen. Er betrachtet, was sich seit dem letzten Lauf verändert hat, und prüft gezielt jene Bereiche, in denen neue Widersprüche entstanden sein könnten.
Einmal pro Woche soll ein tieferer semantischer Audit folgen. Dabei geht es weniger um die klassische Frage, ob alle Tests grün sind. Er untersucht die Bedeutung der Veränderungen:
- Behaupten zwei Quellen inzwischen unterschiedliche Dinge über dieselbe Verantwortung?
- Verwendet ein Produkt noch einen alten Standard, nachdem der gemeinsame Vertrag geändert wurde?
- Taucht derselbe lokale Workaround plötzlich in mehreren Projekten auf?
- Besteht eine Ausnahme weiter, obwohl ihr ursprünglicher Grund verschwunden ist?
- Ist aus einer lokalen Lösung faktisch ein organisationsweiter Standard geworden, ohne dass dies bewusst entschieden wurde?
Ein solcher Audit sucht nicht primär nach defektem Code. Er sucht nach auseinanderlaufenden Wirklichkeiten.
Funktionsfähigkeit reicht nicht
Klassische Infrastruktur überwacht, ob Systeme funktionieren. Sie misst Verfügbarkeit, Fehlerquoten, Laufzeiten und Ressourcen. Diese Werte sind wichtig, beantworten aber nur einen Teil der Frage.
Alle Tests können grün sein, während zwei Repositories dieselbe Verantwortung unterschiedlich beschreiben. Jeder Runner kann für sich funktionieren, obwohl drei beinahe identische Implementierungen parallel gepflegt werden. Jede Dokumentation kann formal aktuell sein und trotzdem einem inzwischen abgelösten Architekturprinzip folgen.
Das Consistency Department soll deshalb zusätzlich überwachen, ob das Gesamtsystem noch Sinn ergibt.
Dafür muss es Veränderungen, Zuständigkeiten und Ausnahmen als eigene Informationen behandeln. Eine Abweichung ist nicht automatisch ein Fehler. Sie braucht jedoch einen Besitzer, einen Grund und einen Zeitpunkt, an dem ihre Berechtigung erneut geprüft wird. Sonst wird aus einer bewussten Ausnahme mit der Zeit ein unerklärter Sonderfall.
Kohärenz ist kein Zustand, den man einmal herstellt und danach besitzt. Sie muss mit jeder Veränderung neu verteidigt werden.
Vom Organisationsmodell zum Architekturprinzip
Damit schliesst sich für mich der Kreis zum früheren Essay. Ich hatte über Organisationen geschrieben, denen eine Instanz fehlt, die nicht primär einzelne Prozesse optimiert, sondern auf den Zusammenhang achtet.
Nun baue ich diese Idee als technische Infrastruktur.
Vielleicht ist das Konsistenzdepartement deshalb mehr als ein Gedankenexperiment für Unternehmen. Es könnte ein brauchbares Architekturprinzip für eine Welt sein, in der immer mehr autonome Systeme gleichzeitig Entscheidungen treffen.
Die Gefahr liegt nicht darin, dass diese Systeme einzeln zu wenig leisten. Sie entsteht, wenn jedes von ihnen lokal vernünftig handelt und niemand mehr prüft, was ihre Entscheidungen gemeinsam ergeben.
Viele autonome Systeme können gleichzeitig gute Entscheidungen treffen – und gerade dadurch gemeinsam Unsinn produzieren.