Das Gehirn der neuen Organisation
Wie Agenten, Wissen und Werkzeuge zu einem kontrollierten System werden
Warum ein KI-Agent allein noch keine agentische Organisation ergibt – und weshalb Quellen, Rechte und Handlungsmöglichkeiten wichtiger sind als die Zahl eingesetzter Modelle.
Im Maschinenraum
Im vorherigen Kapitel haben wir gefragt, welche Bürokratie wir schützen, automatisieren oder abschaffen sollten.
Jetzt betreten wir den Maschinenraum.
Denn sobald ein Agent tatsächlich Arbeit übernehmen soll, entstehen neue Fragen.
Er soll eine Verpackung prüfen.
Welche Verpackung?
Er soll einen regulatorischen Vorgang vorbereiten.
Mit welcher Fassung der Regel?
Er soll einen Lieferanten anschreiben.
Welchen Lieferanten?
Er soll entscheiden, ob ein Nachweis fehlt.
Woher weiß er, welcher Nachweis aktuell ist?
Und wenn zwei Quellen einander widersprechen?
Plötzlich geht es nicht mehr primär um künstliche Intelligenz.
Es geht um Organisationsarchitektur.
Der Agent ist nicht das Gehirn
In vielen Darstellungen agentischer Systeme steht der Agent selbst im Mittelpunkt.
Compliance-Agent.
Research-Agent.
Finance-Agent.
Projekt-Agent.
Die Logik ist verständlich.
Wir kennen Rollen aus Organisationen und übertragen sie auf Software.
Aber ein Rollenname löst noch kein organisatorisches Problem.
Jemand muss festlegen:
- welchen Auftrag ein Agent besitzt,
- welche Informationen er verwenden darf,
- welche Werkzeuge er aufrufen kann,
- welche Aktionen erlaubt sind,
- wie Unsicherheit behandelt wird,
- wann eskaliert wird,
- und wann ein Mensch übernehmen muss.
Die Organisation eines agentischen Systems entsteht also nicht automatisch durch die Agenten.
Sie entsteht durch die Architektur um sie herum.
Ciferecigo Perspektive Der Agent ist nicht das Gehirn der neuen Organisation. Er ist eine Funktion innerhalb eines größeren Wissens- und Handlungssystems.
Die Manufaktur weiß mehr, als ihre Systeme zeigen
Kehren wir zur Porzellanmanufaktur zurück.
Der Auftrag über 500 Geschirrsets liegt im ERP.
Theoretisch müsste ein Agent jetzt nur die Verpackungsdaten abrufen und prüfen.
Praktisch beginnt das Problem früher.
Die Informationen über die Verpackung liegen verteilt.
Das ERP kennt die Artikelnummer.
Eine Excel-Datei enthält Verpackungsgewichte.
Die aktuelle Kartonspezifikation liegt als PDF vor.
Ein Materialnachweis steckt in einer älteren E-Mail.
Eine interne Packanweisung zeigt eine andere Zahl an Zwischenlagen als die Stückliste.
Und Marek, der Verpackungsmeister, weiß aus Erfahrung Dinge über die reale Verpackung, die in keinem System stehen.
Das Unternehmen besitzt also Wissen.
Aber dieses Wissen bildet noch kein verlässliches System.
Der erste Wert einer agentischen Architektur besteht deshalb nicht darin, sofort Antworten zu geben.
Sondern darin, vier Fragen beantwortbar zu machen:
Was wissen wir?
Woher wissen wir es?
Was fehlt?
Und welcher Quelle dürfen wir für diese Frage vertrauen?
Kein universeller Datensee
Die Vorstellung eines universellen Unternehmensgedächtnisses klingt verlockend.
Alle Daten an einen Ort.
Alles verbunden.
Eine einzige Wahrheit.
Jeder Agent greift darauf zu.
In realen Organisationen ist dieses Bild problematisch.
Ein ERP besitzt einen anderen Zweck als ein CRM.
Eine technische Spezifikation einen anderen als eine E-Mail.
Ein Vertrag eine andere Autorität als eine PowerPoint-Präsentation.
Ein historischer Projektstand kann korrekt dokumentiert und trotzdem für die heutige Frage irrelevant sein.
Manche Informationen dürfen viele Menschen sehen.
Andere nur wenige.
Und manchmal widersprechen sich zwei Quellen.
Dieser Widerspruch ist keine Unsauberkeit, die einfach entfernt werden sollte.
Er kann genau die Information sein, die eine Entscheidung auslöst.
Das Ziel lautet deshalb nicht:
alles zentralisieren.
Sondern:
einen kontrollierten Wissensraum schaffen.
Die Daten dürfen dort bleiben, wo sie sinnvoll gepflegt werden.
Entscheidend ist, dass das System weiß:
**Was existiert? Wo liegt es? Was bedeutet es? Wer verantwortet es? Wer darf es für welchen Zweck verwenden?**
Von der Source of Truth zur Source of Authority
Für einzelne Datenobjekte kann eine eindeutige führende Quelle sinnvoll sein.
Der aktuelle Preis eines Produkts kann aus dem ERP stammen.
Der freigegebene technische Stand aus dem PLM.
Doch organisatorisches Wissen insgesamt besitzt selten eine einzige Wahrheit.
Für Agenten ist deshalb eine andere Frage entscheidender:
Welche Quelle ist für diese konkrete Frage maßgeblich?
Das ist die Source of Authority.
Im Porzellanfall könnte das bedeuten:
Für die reale Verpackungsversion gilt die freigegebene Packanweisung.
Für den verwendeten Kartontyp die Lieferantenspezifikation.
Für eine regulatorische Frage eine definierte autoritative Rechtsquelle.
Für die tatsächliche Transporterfahrung interne Qualitätsdaten und validierte Tests.
Der Agent muss diese Unterschiede kennen.
Sonst behandelt er Information nur als Text.
Vom Datenbestand zum Wissensraum
Damit Informationen sinnvoll verwendet werden können, entsteht zwischen Daten und Agent eine Wissensschicht.
Sie kann unterschiedliche Mechanismen kombinieren:
- Metadaten,
- Taxonomien,
- Suchindizes,
- Embeddings,
- Vektorsuche,
- Entitäten,
- Zugriffsregeln,
- Versionsinformationen,
- Wissensgraphen,
- Ontologien.
Nicht jede Organisation benötigt all diese Elemente.
Und nicht jedes Problem braucht eine Ontologie.
Embeddings können hervorragend dabei helfen, semantisch ähnliche Inhalte zu finden.
Eine explizite semantische Struktur wird besonders interessant, wenn Beziehungen selbst entscheidend sind.
Zum Beispiel:
Geschirrset 4711 verwendet → Verpackung PORZ-L
PORZ-L besteht aus → Karton / Zwischenlage / Folie / Klebeband
Klebeband KT-17 geliefert von → Lieferant X
KT-17 benötigt → aktuellen Materialnachweis
Das ist etwas anderes als Textähnlichkeit.
Das System kennt nicht nur Dokumente.
Es kennt einen Teil der organisatorischen Zusammenhänge.
Merksatz Embeddings helfen beim Finden. Semantische Modelle helfen beim Einordnen. Entscheidend ist nicht entweder/oder, sondern welche Struktur der Anwendungsfall benötigt.
RAG macht Wissen verfügbar – nicht wahr
Hier kommt Retrieval-Augmented Generation, kurz RAG, ins Spiel.
Das Prinzip ist einfach:
Bevor das Modell antwortet, sucht das System in definierten Quellen nach relevantem Material.
Dieses Material wird als Kontext für die Antwort bereitgestellt.
Das kann enorm nützlich sein.
Unser Verpackungsagent könnte beispielsweise aktuelle Spezifikationen, Lieferantendokumente, Packanweisungen und autorisierte regulatorische Quellen heranziehen.
Aber daraus folgt nicht:
RAG verhindert Halluzinationen.
Und schon gar nicht:
RAG erzeugt automatisch rechtssichere Antworten.
Das falsche Dokument kann gefunden werden.
Eine Quelle kann veraltet sein.
Ein Dokument kann selbst einen Fehler enthalten.
Ein relevanter Abschnitt kann fehlen.
Das Modell kann einen richtigen Text falsch interpretieren.
Darum braucht ein belastbares System zusätzliche Fragen:
Ist die Quelle aktuell?
Ist sie für diese Frage autoritativ?
Ist das Ergebnis durch die Quelle tatsächlich gedeckt?
Kann der Mensch die Quelle sehen?
Wie werden widersprüchliche Informationen behandelt?
Was passiert, wenn nichts Belastbares gefunden wird?
Ein gutes System darf an dieser Stelle nicht besonders überzeugend improvisieren.
Es muss sagen können:
Ich weiß es nicht.
Der falsche Nachweis
Genau das passiert in unserem Referenzfall.
Der Agent erkennt, dass für Klebeband KT-17 ein aktueller Nachweis fehlt.
Er fordert das Dokument beim Lieferanten an.
Drei Tage später trifft ein PDF ein.
Auf den ersten Blick sieht alles richtig aus.
Hersteller.
Material.
Konformitätserklärung.
Doch die Produktnummer lautet:
KT-16.
Die Vorgängerversion.
Ein schlechtes System könnte das Dokument aufgrund semantischer Ähnlichkeit dem Vorgang zuordnen.
Ein besseres System erkennt den Konflikt.
Es akzeptiert den Nachweis nicht.
Es markiert:
Version stimmt nicht mit verwendeter Komponente überein.
Und fordert erneut das passende Dokument an.
Das wirkt unspektakulär.
Aber genau an solchen Stellen entscheidet sich, ob ein agentisches System betriebliche Arbeit verbessert oder lediglich Fehler schneller produziert.
Wissen allein kann nichts tun
Bis hierhin kann unser Agent suchen, vergleichen und analysieren.
Aber eine agentische Organisation soll nicht nur Antworten erzeugen.
Sie soll Arbeit erledigen.
Dafür benötigt der Agent Werkzeuge.
Zum Beispiel:
- eine Datenbankabfrage,
- einen ERP-Endpunkt,
- ein Ticketsystem,
- einen Dokumentengenerator,
- eine E-Mail-Schnittstelle,
- eine Kalkulationsfunktion,
- einen Workflow,
- eine interne API.
Damit verändert sich das Risiko fundamental.
Ein falscher Text ist ein Informationsfehler.
Eine falsch versendete E-Mail ist bereits eine Handlung.
Eine veränderte Stammdatenposition ebenfalls.
Eine ausgelöste Bestellung erst recht.
Deshalb muss eine agentische Architektur strikt unterscheiden zwischen:
wissen
und
handeln.
Berechtigungen werden Teil der Architektur
Ein Agent benötigt nicht pauschal „Zugriff auf Unternehmensdaten“.
Er braucht genau den Zugriff, der für seinen Auftrag notwendig ist.
Dasselbe gilt für Werkzeuge.
Unser Agent darf möglicherweise:
einen Lieferantennachweis suchen,
eine fehlende Unterlage anfordern,
einen neuen Eingang dem Vorgang zuordnen.
Er darf deshalb aber noch lange nicht:
eine regulatorische Rolle endgültig festlegen,
eine neue Verpackung produktiv freigeben
oder eine rechtlich relevante Erklärung rechtsverbindlich abgeben.
Das führt zu einer einfachen Architekturregel:
So viel Kontext wie nötig. So wenig Handlungsmacht wie möglich.
Die Qualität eines agentischen Systems bemisst sich damit nicht nur daran, was es kann.
Sondern ebenso daran, was es nicht darf.
Mehr Agenten sind nicht automatisch mehr Intelligenz
Natürlich könnte man den Porzellanfall auch mit fünf Agenten lösen.
Ein Verpackungsagent.
Ein Compliance-Agent.
Ein Lieferantenagent.
Ein Qualitätsagent.
Ein Dokumentationsagent.
Vielleicht wäre das sinnvoll.
Vielleicht auch nicht.
Jeder zusätzliche Agent erzeugt neue Koordination:
Wer besitzt welche Information?
Wer entscheidet bei Widersprüchen?
Welche Ergebnisse dürfen weitergereicht werden?
Welcher Agent darf handeln?
Wo entsteht ein zusätzlicher Fehlerpfad?
Ciferecigo Perspektive Ein Agent sollte nicht deshalb auf fünf Agenten verteilt werden, weil fünf Agenten fortschrittlicher aussehen.
Manche Prozesse brauchen einen Agenten und drei gute Werkzeuge.
Andere mehrere spezialisierte Agenten.
Wieder andere sollten weiterhin deterministisch automatisiert werden.
Architektur folgt der Aufgabe – nicht dem Hype.
Ein Organisationsgedächtnis darf nicht alles glauben
Auch nach Abschluss des Verpackungsvorgangs entsteht eine wichtige Frage:
Was lernt das System daraus?
Nicht jedes Ergebnis darf automatisch zu neuem Organisationswissen werden.
Der falsche KT-16-Nachweis sollte nicht plötzlich als gültige Information für KT-17 gespeichert werden.
Eine vorläufige Verpackungsidee ist kein freigegebener Standard.
Eine Vermutung ist kein Fakt.
Eine menschliche Entscheidung kann später revidiert werden.
Organisationswissen braucht deshalb Provenienz.
Zu einer Information gehört:
woher sie stammt,
wer sie verantwortet,
wann sie entstanden ist,
welche Version gilt,
wie sicher sie ist,
und für welchen Zweck sie verwendet werden darf.
Dann wird Wissen nicht einfach gesammelt.
Es wird kuratiert.
Die sechs Schichten
Damit lässt sich das agentische System in sechs Schichten beschreiben:
1. Quellen
Wo liegen Daten und Wissen?
Im Porzellanfall:
ERP, Packanweisungen, Lieferantendokumente, Verträge, Qualitätsdaten, regulatorische Quellen.
2. Wissensstruktur
Wie werden Informationen eingeordnet und miteinander verbunden?
Produkt, Verpackung, Material, Lieferant, Version, Land, Rolle, Nachweis.
3. Retrieval & Kontext
Welche Informationen braucht dieser konkrete Auftrag?
Nicht der gesamte Unternehmensdatenbestand.
Sondern der relevante Ausschnitt.
4. Agenten & Orchestrierung
Wer verarbeitet den Kontext und plant den nächsten Schritt?
Ein einzelner Agent oder mehrere spezialisierte Funktionen.
5. Werkzeuge & Aktionen
Was darf das System tatsächlich tun?
Suchen.
Berechnen.
Dokumente zuordnen.
Lieferanten kontaktieren.
Workflows auslösen.
6. Governance & Beobachtbarkeit
Wie bleiben Verhalten und Verantwortung kontrollierbar?
Rechte.
Quellen.
Logs.
Freigaben.
Stopps.
Eskalationen.
Evaluation.
Diese sechs Schichten bilden kein technisches Rezept.
Sie sind ein Fragenmodell.
Eine Organisation kann damit für jeden Use Case prüfen, ob sie tatsächlich ein kontrollierbares System baut.
Das Gehirn besteht aus Verbindungen
Vielleicht ist deshalb schon der Titel dieses Kapitels etwas irreführend.
Das Gehirn der neuen Organisation ist kein einzelnes Modell.
Kein Datensee.
Keine Ontologie.
Kein Agent.
Und keine Plattform.
Es entsteht aus den Verbindungen zwischen:
**Wissen. Bedeutung. Rechten. Handlungen. Beobachtung. Verantwortung.**
Das macht die Architektur anspruchsvoller.
Aber auch realistischer.
Denn Unternehmen brauchen keine KI, die alles weiß.
Sie brauchen Systeme, die für eine konkrete Aufgabe genug wissen, ihre Quellen zeigen, kontrolliert handeln – und ihre Grenzen erkennen.
Weiter im Special
Teil 3 – Mensch und Maschine
Wenn das System weiß, worauf es zugreifen und was es tun darf, bleibt die schwierigere Frage:
Welche Funktion hat der Mensch darin?
Lassen Sie uns Ihre agentische Organisation gestalten.
Von der Analyse der Zeitfresser bis zum kontrollierten KI-Agenten im Team.
Projektanfragen