Agent OS – Wie KI-Agenten das Unternehmenshandbuch zum Leben erwecken

Nach einem Telefonat mit einem Kunden saß ich vor meinem Rechner. Wir hatten eine knappe halbe Stunde lang besprochen, wie eine Erweiterung für sein bestehendes System aussehen könnte und welcher Aufwand dafür realistisch wäre. Anstatt die Notizen zusammenzufassen, das CRM zu öffnen und Vorlagen zusammenzusuchen, tippte ich einen einzigen Satz in Claude Code:

Schreib mir ein Angebot.

Wenige Minuten später lag das Dokument fertig vor mir. Der Text enthielt die Leistungsbeschreibung, den vereinbarten Preis, die Bindefrist, die passenden AGB, die technischen Abgrenzungen, das Anschreiben und den richtigen Ansprechpartner. Ohne eine einzige Rückfrage.

Das funktionierte, weil das Modell Zugriff auf den relevanten Kontext hatte: das Transkript des Telefonats, die Kundendaten, den Quellcode des aktuellen Systems, die Tickets in unserem Projektmanagement und das Unternehmenshandbuch von form4. In diesem Handbuch steht exakt, wie ein Angebot aufgebaut sein muss, wo die Dateivorlage liegt und nach welcher Systematik sich die Angebotsnummer zusammensetzt.

Struktur des Frameworks

Das Ergebnis fiel nicht zufällig so präzise aus. Bei form4 setzen wir auf ein internes Framework, das wir Agent OS nennen. Es baut direkt auf dem Harness von Claude Code auf. Unser Team arbeitet seit einiger Zeit daran, Fähigkeiten und Wissen in diesem Framework sauber zu strukturieren. Ich konnte den Befehl so absetzen, weil die Vorarbeit im System bereits erledigt war.

Das Framework besteht aus fünf Elementen: Playbooks für strukturierte Abläufe, Policies als übergeordnete Leitlinien, feste Rules, spezialisierte Agents und wiederverwendbare Skills. Technisch handelt es sich um Markdown-Dateien mit formalisierten Metadaten im Frontmatter. Jeder Artefakttyp ist klar klassifiziert. Das System regelt strikt, welcher Agent welche Skills aufrufen darf und wo Abhängigkeiten greifen.

Das Team pflegt dieses System über einen geregelten Contribution-Prozess. Wer einen Ablauf präzisiert oder eine neue Aufgabe strukturiert, erweitert die Skills. Dabei helfen wiederum spezialisierte Agents, die eigens dafür abgestellt sind, das Agent OS selbst zu warten und neue Bausteine regelkonform einzubinden.

Handbuch als Metamodell

Strukturell bildet das Framework schlicht unser Unternehmenshandbuch ab. Dieses Handbuch ist stark formalisiert und richtet sich nach ISO 9001 sowie ISO 27001. Es legt fest, was in welcher Reihenfolge zu geschehen hat.

Für ein Angebot bedeutet das fünf feste Schritte: das Anlegen des Deals im CRM, das Spezifizieren der Requirements, die Texterstellung des eigentlichen Angebots, die monetäre Neubewertung der Erfolgswahrscheinlichkeit im CRM und die finale Ablage der Datei unter einer definierten Nummer an einem festgelegten Ort.

Das Handbuch unterscheidet klar zwischen Artefakttypen wie dem Implementierungskonzept, dem Angebot, der Auftragsbestätigung, dem Betriebshandbuch und der Release-Dokumentation. Dazu kommen Prozesse, Aktivitäten und Einzelschritte. Die Skills im Framework sind im Grunde die technische Entsprechung dieser dokumentierten Aktivitäten. Ein interner Build-Prozess erzeugt aus diesem Metamodell schließlich die fertigen Konfigurationen, die der Harness ausführen kann.

Hürden klassischer Prozessarbeit

Ich habe schon immer viel Wert auf formalisierte Unternehmenshandbücher gelegt. Im Alltag bereitete das Arbeiten damit früher allerdings wenig Freude.

Der erste Grund war der schiere Aufwand für Formalitäten. Dateinamen nach Konvention vergeben, Verzeichnisse anlegen, Begleitmails tippen, Statusfelder im CRM pflegen, Berechnungen anstellen. Für deterministische Skripte sind viele dieser Zwischenschritte zu feingliedrig und zu wartungsintensiv. Zudem bricht klassische Automatisierung genau dort ab, wo Sprache ins Spiel kommt, etwa beim Verfassen einer verständlichen Leistungsbeschreibung.

Der zweite Grund war schlicht Langeweile. Wenn Entwickler oder Führungskräfte den halben Arbeitstag damit verbringen, Pflichtfelder in Webmasken zu füllen und PDF-Dateien umzubenennen, bleibt die Denkarbeit liegen. Das Konzipieren technischer Architekturen und die Arbeit am eigentlichen Kundensystem rücken in den Hintergrund.

Verlagerung an Agents

Genau an diesem Punkt ändern Sprachmodelle die Vorzeichen. Prozesse können maximal formal definiert bleiben, ohne dass Menschen jeden Handgriff manuell durchklicken müssen. Der Agent übernimmt die Ausführung innerhalb definierter Toleranzen, während feste Regeln das Geländer bilden.

Das ermöglicht Arbeitsweisen, die früher an Ressourcen gescheitert sind. Ein Beispiel ist das Review von Implementierungskonzepten. Vorgesehen war immer: Jedes Konzept wird geprüft, es entsteht eine Liste offener Punkte, diese Punkte werden fachlich bewertet, begründet und erst danach fließt die Korrektur in das Dokument ein. In der Praxis blieb dieser Ablauf oft liegen, weil selten zwei Entwickler gleichzeitig Zeit für einen solchen Durchlauf hatten.

Heute übernimmt ein Agent das Konzept, prüft es gegen die Vorgaben des Handbuchs und übergibt die Defektliste an einen zweiten Agenten, der das Ergebnis verifiziert.

Wir können nun all die Prozesse in das Handbuch aufnehmen, die bisher vermieden wurden, weil niemand die bürokratische Last tragen wollte. Das Handbuch liefert die Logik, das Agent OS stellt die Werkzeuge bereit, und die Modelle erledigen die Arbeitsschritte in den angebundenen Systemen.

Ein sauber dokumentierter Prozess ist die Voraussetzung dafür, dass Automatisierung mit Agenten überhaupt greifen kann. Das ist gewissermaßen eine Gegenbewegung zur viel propagierten Entbürokratisierung.