Wachsende Wissensbestände: So bleibt ein CompanyOS übersichtlich

01

Umfang und Zugriffsaufwand sind unterschiedliche Größen

Ein CompanyOS wächst durch Produktwissen, Prozesse, technische Dokumentation, Entscheidungen und Projektarbeit. Viele Dateien können dabei sinnvoll sein: Eine getrennte Produktquelle lässt sich gezielt pflegen, und eine historische Entscheidung erklärt die Herkunft einer Regel. Problematisch wird der Umfang vor allem dann, wenn aktuelle Aufgaben zu viel davon erneut lesen oder widersprüchliche Quellen auflösen müssen.

Zur Beurteilung sind deshalb zwei Fragen hilfreich. Wie groß ist der gepflegte Bestand? Und welchen Teil davon benötigt ein gewöhnlicher Arbeitslauf? Die erste Frage beschreibt die Wissenslandschaft. Die zweite betrifft den laufenden Aufwand. Eine hohe Dateizahl beweist für sich weder eine schlechte Struktur noch einen überladenen Modellkontext.

Eine Bestandsaufnahme schafft einen Ausgangspunkt für weitere Prüfungen. Sie sollte Umfang, Zählgrenzen und Datum nennen. Daraus können gezielte Stichproben entstehen: Welche Einstiegspfade führen zur richtigen Quelle? Welche Dokumente enthalten veraltete Regeln? Welche Texte werden bei jeder Routine erneut geladen, obwohl sie nur für Sonderfälle relevant sind?

02

Das sem.-Beispiel: 526 Markdown-Dateien mit verschiedenen Aufgaben

Die lokale Metadatenzählung vom 8. Oktober 2026 erfasste im berücksichtigten sem.-Bestand 1.851 Dateien, darunter 526 Markdown-Dateien mit zusammen 2.980.742 Bytes. Das entspricht rund 2,98 MB in dezimaler Rechnung. Darin enthalten waren 18 AGENTS.md-Dateien und zehn SKILL.md-Einstiege; diese Gruppen werden nicht zusätzlich zur Markdown-Zahl addiert.

Die Verteilung hilft, den Bestand einzuordnen. 155 Markdown-Dateien lagen im Product OS, 100 im Business OS und 78 im Agentic OS. Die Workspaces enthielten 65, die verbliebenen Codebases 41 und der Skillbereich 25. Die übrigen 62 verteilten sich auf Unternehmens-Core, Datenverträge, gemeinsame Assets, gemeinsame Fähigkeiten und Root-Dokumente.

Agentic OS und Skillbereich umfassten damit zusammen 103 Markdown-Dateien. Dazu gehören Definitionen, Referenzen, Workflows, Prüfmaterial und Recherche. Die Entscheidungsdatei führte 39 Architekturentscheidungen einschließlich historischer oder abgelöster Entscheidungen. Diese Zahlen machen den Pflegeumfang sichtbar, sagen aber nicht, dass alle Texte in jedem Lauf benötigt werden.

03

Warum Input-Dateien eine genaue Definition brauchen

Als Input kann eine Fachquelle, eine Laufkarte, ein Skill oder eine Forschungsnotiz dienen. Der Dateibaum zeigt zunächst nur, dass diese Quellen vorhanden sind. Welche davon ein Modell wirklich gelesen hat, ergibt sich aus dem jeweiligen Lauf. Im eng definierten Research-Bereich des sem. Agentic OS lagen zwei Markdown-Dokumente; das ist keine vollständige Zählung aller möglichen Modellinputs.

Die Bestandserhebung nahm Archiv, eingeschränkte Datenbereiche, Abhängigkeiten und typische Build-, Cache-, Log- und Ausgabeverzeichnisse aus. Symbolische Links wurden nicht verfolgt, bekannte lokale Secret-Dateitypen ausgeschlossen. Externe private Git-Codebases lagen außerhalb des Scans. Gemessen wurden Dateipfade und Metadaten, keine eindeutigen Wissenseinheiten oder inhaltlichen Dubletten.

Für eine Aussage über Wachstum fehlt eine vergleichbare frühere Erhebung. Für eine Aussage über den Agentenkontext fehlen in dieser Zählung die tatsächlich geladenen Quellen. Solche Grenzen sind Teil einer brauchbaren Analyse: Sie verhindern, dass eine Bestandszahl versehentlich als Effizienzkennzahl verwendet wird.

04

Lösungsansatz: Bestand pflegen und Kontext gezielt auswählen

Ein übersichtlicher Einstieg sollte zunächst zum zuständigen Fachbereich führen und dort die wenigen benötigten Quellen benennen. Ein Routineprozess kann mit einer kompakten Laufkarte beginnen. Detailregeln werden nachgeladen, sobald ein konkreter Fall sie benötigt. Das ermöglicht einen umfangreichen Wissensbestand bei begrenztem Kontext je Aufgabe.

Die Quellenpflege folgt einer zweiten Logik. Verbindliche Regeln erhalten einen fachlichen Owner, einen erkennbaren Status und eine Versions- oder Datumsangabe. Temporäre Recherche bleibt als solche erkennbar. Wird eine Regel ersetzt, sollte der bisherige Text auf den aktuellen Einstieg verweisen und seine historische Rolle klar benennen. Eine Registry reicht als Navigationsindex; ausführliche Fachtexte bleiben am zuständigen Hauptort.

• Für häufige Aufgaben den tatsächlichen Lesepfad dokumentieren und unnötige Einstiegslektüre entfernen.
• Aktuelle Regel, Hintergrundreferenz, Entwurf und historischen Nachweis unterscheidbar halten.
• Mehrfach gepflegte Aussagen an einer verbindlichen Quelle zusammenführen und andernorts referenzieren.
• Änderungen an Fachregeln nur für die betroffenen Quellen und Prozesse nachprüfen.
• Dokumente nach Nutzung und Zuständigkeit prüfen; eine pauschale Zielzahl für Dateien vermeiden.

05

Den Zugang mit realen Aufgaben überprüfen

Ein einfacher Test besteht darin, mehrere typische Fragen vom Einstieg bis zur Antwort zu verfolgen. Dabei werden gelesene Dateien, widersprüchliche Aussagen, fehlende Quellen und nötige Rückfragen erfasst. Für einen Agentenlauf kommen Kontextumfang und fachliche Qualität hinzu. Dadurch lässt sich prüfen, ob kürzere Zugriffswege tatsächlich genügen.

Der Bestand muss dafür nicht pauschal verkleinert werden. Häufig lohnt sich zuerst eine bessere Trennung von Routineeinstieg und Hintergrundwissen. Die dokumentierten sem.-Korrekturen zu kompakten Laufkarten liefern dafür ein konkretes Beispiel. Ob diese Maßnahme Zeit spart, ist anschließend an vergleichbaren vollständigen Läufen zu messen.