Skip to main content
Der M9TZ Agent Blueprint ist ein wiederverwendbares Architekturmuster für den unternehmensweiten Einsatz von KI-Agenten. Der Kerngedanke ist klar: Jede Abteilung erhält eine eigene Agenten-Laufzeitumgebung, die auf die dokumentierten Arbeitsabläufe dieser Abteilung begrenzt ist. Agenten teilen keinen Zustand. Sie kommunizieren über definierte JSON-Nachrichtenstrukturen. Die Infrastruktur wird schrittweise aufgebaut — eine Abteilung nach der anderen, mit Validierung jeder Phase, bevor die nächste beginnt. Der Blueprint ist ein Konzept und eine Architektur, kein Produkt. Diese Dokumentation beschreibt das vollständige Muster — was ein Agent ist, wie er aufgebaut ist, wie Abteilungen miteinander verbunden werden und wie Altsysteme angebunden werden. Die Anwendung des Blueprints auf die spezifischen Systeme und Arbeitsabläufe einer Organisation ist der kostenpflichtige Beratungsanteil. Eine klare Erläuterung, was diese Dokumentation abdeckt und was ein Beratungsmandat umfasst, finden Sie unter Scope & Grenzen.

​
Was der Blueprint abdeckt

Agentendefinition

Ein Agent in diesem System ist prozessgebunden und SOP-gesteuert — auf eine Abteilung begrenzt, führt dokumentierte Verfahren aus und eskaliert an einen Menschen, wenn ein Fall außerhalb seines definierten Geltungsbereichs liegt.

Gestuftes Rollout-Modell

Abteilungen werden sequenziell in Betrieb genommen. Jede Phase wird validiert, bevor die nächste beginnt. Sie starten mit einer Abteilung auf einer VM und erweitern erst, wenn das Fundament solide ist.

Strukturierter abteilungsübergreifender Nachrichtenaustausch

Abteilungen koordinieren sich über definierte JSON-Nachrichtenstrukturen und nicht über direkte Aufrufe oder gemeinsame Datenbanken. Eingabeformate, Ausgabeformate und Routing-Regeln werden vereinbart, bevor zwei Laufzeitumgebungen verbunden werden.

Adaptermuster für externe Systeme

ERP-Systeme, CRM-Plattformen und Altsysteme werden über zweckgebundene Adapter an definierten Ein- und Ausgabepunkten angebunden. Die Agenten-Laufzeitumgebungen ändern sich nicht, wenn ein externes System hinzugefügt oder ersetzt wird.

​
Für wen dieser Blueprint relevant ist

Der Blueprint richtet sich an Personen, die abteilungsspezifische KI-Automatisierung in Organisationen konzipieren oder bewerten, in denen Konsistenz, Nachvollziehbarkeit und kontrollierte Handlungsbefugnis wichtiger sind als die Flexibilität eines Allzweck-KI-Systems.

Prozessdesigner und Architekten

Sie sind verantwortlich dafür, wie Arbeit zwischen Abteilungen fließt. Der Blueprint gibt Ihnen ein Muster dafür, wo Agenten passen, wie sie kommunizieren und wie das System wächst, ohne unhandhabbar zu werden.

Teams, die KI für spezifische Workflows evaluieren

Sie haben einen spezifischen, hochvolumigen Arbeitsablauf, den Sie automatisieren möchten. Der Blueprint zeigt, wie Sie diese Automatisierung auf eine einzelne Abteilung begrenzen, deren SOPs definieren und sie validieren, bevor Sie irgendetwas anderes anschließen.

Technische Projektverantwortliche

Sie beurteilen Machbarkeit und Integrationskomplexität. Der Blueprint deckt Laufzeitstruktur, Nachrichtenverträge, ERP/CRM-Adaptermuster und das Stufenmodell des Rollouts in ausreichender Tiefe für diese Beurteilung ab.

Betriebs- und Compliance-Verantwortliche

Sie benötigen Automatisierung, die konsistente, nachvollziehbare Ergebnisse liefert — keine ergebnisoffene KI-Entscheidungsfindung. Das SOP-gesteuerte Modell ist von Grund auf auf Nachvollziehbarkeit und kontrollierte Handlungsbefugnis ausgelegt.

​
Was das Stufenmodell in der Praxis bedeutet

Ein gestufter Rollout ist keine reine Projektmanagement-Präferenz — er ist eine strukturelle Eigenschaft des Blueprints. Jeder Abteilungsagent ist unabhängig einsetzbar, unabhängig testbar und unabhängig wartbar. Die Verbindung von Abteilungen über Nachrichtenstrukturen statt über direkte Aufrufe bedeutet:
  • Ein Problem im Agenten einer Abteilung pflanzt sich nicht auf andere fort
  • Eine neue Abteilung kann hinzugefügt werden, ohne bestehende Laufzeitumgebungen zu verändern
  • Ein externes System (Ihr ERP, Ihr CRM) kann durch Aktualisierung seines Adapters ersetzt werden — ohne dass die Agenten, die dessen Daten verarbeiten, neu gebaut werden müssen
Der Schnellstart zeigt, wie der erste Bereitstellungsschritt in der Praxis aussieht. Die Abteilungs-Playbooks zeigen, wie das Muster auf vier typische Abteilungstypen angewendet wird.

​
Was diese Dokumentation nicht abdeckt

Die Dokumentation beschreibt das Muster in einer Detailtiefe, die ausreicht, um es zu verstehen, zu evaluieren und eine Implementierung vorzubereiten. Sie deckt nicht ab:
  • Die spezifischen Verfahren, die Ihre Abteilungen befolgen sollen (das sind Ihre SOPs, nicht die des Blueprints)
  • Die spezifischen Werkzeuge, Plattformen oder Zugangsdaten, die in einer realen Bereitstellung verwendet werden (diese sind mandatsspezifisch)
  • Konfiguration realer Systeme oder schrittweise Bauanleitungen für eine Live-Umgebung
Beratungsmandate umfassen die Scoping-, Design- und Implementierungsarbeit, den Blueprint auf eine spezifische Organisation anzuwenden. Unter Beratungsprozess erfahren Sie, wie das abläuft.

​
Wie Sie fortfahren

Was ist ein Agent?

Die grundlegende Definition: Was ein Agent ist, woraus er besteht und warum das SOP-gesteuerte Modell für prozesskritische Workflows wichtig ist.

Schnellstart

Der erste praktische Schritt: Eine Abteilung, eine VM, eine validierte Agenten-Laufzeitumgebung. Was zuerst zu definieren ist und was vor dem Weitergehen zu prüfen ist.

Agentenstruktur

Wie ein Agent aufgebaut ist — das Drei-Schichten-Modell, die Komponenten jeder Schicht und wie sie in einer laufenden Bereitstellung zusammenpassen.

Beratungsprozess

Wie Mandate strukturiert werden — Phasen, Liefergegenstände, Verantwortlichkeiten und gegenseitige Verpflichtungen.