Company Brain: Wie ein Git-Repository zum Unternehmensgedächtnis für KI-Agenten wird

Das Wissen eines Unternehmens liegt selten an einem Ort. Produktentscheidungen stehen im Wiki, Kundenhistorien im CRM, Probleme im Ticketsystem und die wirklich wichtigen Nuancen in Gesprächsprotokollen, die nach dem Termin niemand mehr öffnet. In vielen Softwareunternehmen entsteht daraus ein bekanntes Muster: Vertrieb, Customer Success und Support laufen mit Produkt-, Code- und Analytics-Fragen zum Entwicklungsteam. Dort tippt jemand die Frage in den Coding-Agenten, wartet und schickt die Antwort zurück. Der Mensch wird zur Übersetzungsschicht für eine Maschine, die die Frage längst selbst beantworten könnte.

Der naheliegende Ausweg, einem KI-Agenten Zugriff auf alle Systeme zu geben und ihn suchen zu lassen, funktioniert in der Praxis schlechter als erwartet. Ein Ansatz, der sich in diesem Jahr unter dem Begriff Company Brain verbreitet, dreht die Logik um: Statt den Agenten zu den Daten zu schicken, werden die Daten zum Agenten geholt. Als Markdown-Dateien in einem Git-Repository, mit Werkzeugen, die in jedem Entwicklungsteam ohnehin vorhanden sind. Wir haben uns den Ansatz genau angesehen, weil er für die Entwicklung von KI-Anwendungen im Mittelstand eine ungewöhnlich gute Relation aus Aufwand und Nutzen verspricht. Dieser Beitrag erklärt, wie ein Company Brain entsteht, warum einfache Dateien hier leistungsfähiger sind als Vektorsuche, wie das Gedächtnis kontrolliert wächst, welche Angriffsmuster Sie kennen sollten, wo die Grenzen liegen und wie Sie pragmatisch starten.

Was ein Company Brain ist

Ein Company Brain ist ein privates Git-Repository, in das die relevanten Datenquellen eines Unternehmens regelmäßig als reine Textdateien synchronisiert werden: Wiki-Seiten, Hilfeartikel, Support-Tickets, Gesprächsprotokolle, Auszüge aus dem CRM, Teile des Quellcodes. Ein Coding-Agent, wie ihn Entwicklungsteams für die tägliche Arbeit einsetzen, navigiert dieses Repository so, wie er eine Codebasis navigiert: Er liest Dateien, sucht mit grep nach Begriffen und folgt Verweisen zwischen Dokumenten.

Das klingt unspektakulär, und genau das ist der Punkt. Drei Eigenschaften machen den Ansatz für Unternehmen interessant:

• Kein neues System. Es braucht keine Vektordatenbank, keine Wissensplattform und keinen weiteren Anbieter. Git, ein Coding-Agent und ein Chat-Kanal genügen.
• Dateien sind die Quelle der Wahrheit. Es gibt kein Datenbankschema, keinen Index, der veraltet, und keine Pipeline, die jemand debuggen muss. Der Hauptzweig des Repositorys ist der aktuelle Wissensstand, jede Änderung ist als Commit nachvollziehbar.
• Inspizierbar für Menschen. Jede Datei lässt sich öffnen, prüfen, korrigieren oder löschen. Was der Agent weiß, ist genau das, was im Repository steht.

Der Begriff wird inzwischen auch von Plattformanbietern besetzt, die darunter semantische Schichten, Wissensgraphen oder verwaltete Gedächtnissysteme verstehen. Diese Ansätze haben ihre Berechtigung, vor allem dort, wo Datendefinitionen unternehmensweit vereinheitlicht werden müssen. Für die meisten mittelständischen Unternehmen ist die schlanke Variante der bessere Einstieg: ein Repository, das in wenigen Stunden steht und dessen Nutzen sich sofort an echten Fragen prüfen lässt. Wie solche KI-Agenten für Unternehmen grundsätzlich arbeiten und welche Autonomiestufen sinnvoll sind, haben wir an anderer Stelle beschrieben.

Vom Wiki mit KI-Suche zum Repository

Der Weg zum Company Brain beginnt in vielen Unternehmen an derselben Stelle: beim Wiki. Die KI-Funktionen der gängigen Wissensplattformen sind inzwischen gut genug, um Produktrecherchen zu unterstützen oder zu einem Support-Fall die passenden Seiten zu finden, sofern das Team diszipliniert alles dort ablegt, bis hin zu Gesprächsaufzeichnungen und Ticket-Exporten. Für die Arbeit am Bildschirm reicht das. Für Automatisierung reicht es nicht, denn diese Assistenten lassen sich in der Regel nicht per API oder Webhook aufrufen. Wissen, das nur ein Mensch abfragen kann, bleibt im Arbeitsalltag ein Nachschlagewerk.

Der erste Schritt darüber hinaus ist typischerweise ein Support-Workflow: Ein neues Ticket löst per Webhook einen Cloud-Agenten aus, der die Codebasis liest und in einer internen Notiz vorschlägt, was die Ursache sein könnte, bevor jemand aus dem Support den Fall öffnet. Das funktioniert bemerkenswert gut für die Diagnose und bemerkenswert schlecht für Lösungsvorschläge. Der Agent kennt den Code, aber nicht die Geschichte: Welche ähnlichen Fälle gab es, was hat damals geholfen, was wurde dem Kunden zugesagt? Genau diese Lücke schließt das Repository. Tickets, Codebasis, Dokumentation und Hilfeartikel wandern als Dateien an einen Ort, und derselbe Agent, der vorher nur den Code sah, sieht jetzt den Kontext.

Von dort ist es ein kleiner Schritt zum unternehmensweiten Werkzeug. Ein Slack-Kanal, in dem alle dem Agenten Fragen stellen können, ist in den meisten Setups zunächst als Provisorium gedacht. Der Aufwand ist gering: Das Repository steht in rund zwei Stunden, die Anbindung des Kanals an einen Cloud-Agenten dauert Minuten. Sobald Teams sehen, dass Produktfragen, Analytics-Anfragen und Recherchen ohne Umweg über die Entwicklung beantwortet werden, wird aus dem Provisorium eine Priorität.

Warum Dateien und grep die klassische Vektorsuche schlagen

Die intuitive Architektur für Unternehmenswissen war in den letzten Jahren Retrieval-Augmented Generation (RAG): Dokumente werden in Abschnitte zerlegt, als Vektoren eingebettet und bei einer Frage nach Ähnlichkeit durchsucht. Die zweite Generation ersetzte den Vektorindex durch Werkzeuganbindungen über das Model Context Protocol (MCP): Der Agent bekommt für jedes System ein Suchwerkzeug und entscheidet selbst, wann er es aufruft.

Beide Wege haben ein gemeinsames Problem, das sich erst im Betrieb zeigt. Eine Vektorsuche liefert, was ähnlich klingt, nicht, was zutrifft. Und eine MCP-Suche macht es dem Agenten zu leicht, früh aufzuhören. Teams, die den Ansatz betreiben, berichten dasselbe Muster: Der Agent ruft das Suchwerkzeug auf, erhält drei Tickets und ein Gesprächsprotokoll, hält das für ausreichend und formuliert eine Schlussfolgerung. Nicht, weil es keine weiteren Belege gäbe, sondern weil das Werkzeug ihm keinen Grund gibt, weiterzusuchen.

Derselbe Agent verhält sich in einem Dateisystem anders. Mit grep findet er in einem gewachsenen Repository schnell zweihundert Dateien, in denen ein Thema vorkommt, öffnet fünfzig davon, folgt Querverweisen und baut sich ein Bild auf, bevor er antwortet. Das ist kein Zufall. Die aktuellen Modelle kennen diese Arbeitsweise aus dem Programmieren und bevorzugen Shell-Werkzeuge wie grep häufig gegenüber spezialisierten Suchwerkzeugen. Wer dem Agenten Unternehmenswissen in der Form einer Codebasis anbietet, nutzt eine seiner stärksten Fähigkeiten.

Auch die Anbieter der Modelle beschreiben diese Verschiebung. In den Empfehlungen zum Context Engineering für Agenten wird das Prinzip als Just-in-time-Kontext bezeichnet: Der Agent hält nur leichte Verweise wie Dateipfade im Kontext und lädt Inhalte erst dann, wenn er sie braucht. Vorab eingebettete Indizes werden dadurch nicht überflüssig, aber sie sind nicht mehr der einzige Weg.

Ob über den Dateien eine zusätzliche Suchschicht liegen sollte, ist eine Frage zweiter Ordnung, und die Praxis kennt beide Antworten. Teams, die mit grep auskommen, berichten, dass eine nachträglich ergänzte Vektorsuche wenig bringt und dem System seine Einfachheit nimmt. Andere legen eine lokale Hybridsuche über dieselben Markdown-Dateien: Das Open-Source-Werkzeug QMD etwa kombiniert Volltextsuche, Vektorsuche und Re-Ranking, läuft vollständig auf dem eigenen Rechner und wird vom Agenten wie jeder andere Kommandozeilenbefehl aufgerufen; seine Sammlungen lassen sich vor jeder Aktualisierung per Git synchronisieren. Der gemeinsame Nenner beider Varianten wiegt schwerer als ihr Unterschied: Das Wissen liegt als Dateien vor, und der Agent erreicht es über Werkzeuge, die er iterativ bedienen kann, statt über eine Sammlung von MCP-Servern, deren Ergebnis er einmal entgegennimmt und für vollständig hält.

Die letzte Zeile zeigt bereits den wichtigsten Trade-off. Darauf kommen wir bei der Sicherheit zurück.

Wie das Repository aufgebaut ist

Die Architektur lässt sich in fünf Schichten beschreiben.

Konnektoren. Für jede Datenquelle existiert ein kleines Skript, das Daten über die API des jeweiligen Systems abholt und als Markdown in einen eigenen Ordner schreibt, etwa context/wiki/ oder context/tickets/. Die Skripte sind bewusst schlicht gehalten: kein Build-Schritt, keine Abhängigkeit von einer Plattform. Ändert sich das Format einer Quelle, wird das Skript angepasst, nicht ein Datenmodell migriert. Die Prinzipien, die wir für eine robuste Datensynchronisation zwischen Systemen empfehlen, gelten hier eins zu eins: idempotente Läufe, klare Zuständigkeit je Quelle, Fehler sichtbar machen statt verschlucken.

Automatisierter Sync. Ein CI-Workflow, in der Regel GitHub Actions, führt die Konnektoren nach Zeitplan aus und committet das Ergebnis zurück ins Repository. Täglich reicht für die meisten Quellen. Der Git-Verlauf wird dabei zum Nebenprodukt mit hohem Wert: Ein Diff zeigt, welche Tickets neu sind, welche Wiki-Seiten sich geändert haben und welche Kundenakte gewachsen ist.

Kommandozeilenwerkzeuge für Live-Daten. Nicht alles gehört in Dateien. Kennzahlen aus dem Data-Warehouse, Transaktionen oder Bestände sind zu volatil und zu umfangreich für einen täglichen Export. Für solche Quellen bekommt der Agent in seiner Sandbox die passenden Kommandozeilenwerkzeuge installiert, etwa einen Client für das Data-Warehouse, und die Dateien im Repository enthalten die Kennungen, die er für gezielte Abfragen braucht. Die Erfahrung spricht hier für Kommandozeilen statt für MCP-Server: Manche Cloud-Agenten zeigen bei MCP-Anbindungen immer wieder Regressionen, während ein CLI stabil läuft und sich von jedem Teammitglied von Hand testen lässt.

Orientierung für den Agenten. Eine Datei auf oberster Ebene, typischerweise AGENTS.md, beschreibt, welche Ordner es gibt, was darin liegt und wie sie zu durchsuchen sind. Ergänzend definieren Skills wiederkehrende Aufgaben: Wie wird eine Kundenakte zusammengestellt, wie eine neue Quelle angebunden, wie ein Wochenbericht erzeugt. Dieses Format ist in kurzer Zeit auf dem Weg zum Standard, auch wenn die Anbieter der Agenten es noch nicht einheitlich unterstützen. Eine Studie der Universität Heidelberg zur Verbreitung solcher Kontextdateien in Open-Source-Projekten beschreibt AGENTS.md als werkzeugübergreifendes Format, das die herstellerspezifischen Varianten zusammenführt. Im Repository liegen die Skills einmal und werden per Symlink für Cursor, Claude Code und andere Agenten sichtbar gemacht.

Zugang für das Team. Der Agent läuft als Cloud-Instanz und ist an einen Slack-Kanal angebunden. Wer eine Frage hat, stellt sie dort, ohne eine Entwicklungsumgebung zu öffnen und ohne selbst Nutzer des Coding-Agenten zu sein. Wer tiefer arbeiten möchte, klont das Repository und nutzt den Agenten direkt.

Vier Praktiken, die aus Daten Wissen machen

Ein Repository voller roher Exporte ist noch kein Company Brain. Die erste Version darf so aussehen: alles hineinkippen, Werkzeuge installieren, den Agenten machen lassen. Der Unterschied zum reifen System entsteht danach in der Kuratierung, und dafür haben sich vier Praktiken bewährt:

1. Filtern. Nur synchronisieren, was Fragen beantwortet. Archivierte Projekte, automatische Benachrichtigungen und Bot-Kommentare lenken den Agenten ab und kosten Kontext.
2. Zusammenführen. Ein Ordner customers/ mit einer Datei je Kunde, in der CRM-Daten, Tickets und Gesprächsnotizen zusammenlaufen, ist deutlich nützlicher als drei getrennte Ordner. Bei jedem Update des Kontextes läuft ein Skript über alle Dateien, sammelt, was zu einem Kunden gehört, und erzeugt daraus eine Akte mit den Kerninformationen und Links zu allen zugehörigen Dateien.
3. Verlinken. Relative Links zwischen zusammengehörigen Dateien, in beide Richtungen: Die Kundenakte verweist auf jedes Ticket, das Ticket zurück auf die Akte. Jede Datei trägt zudem die Kennungen der Quellsysteme, damit der Agent bei Bedarf gezielt nachfragen kann. Der Agent navigiert dann, statt zu suchen, und verbraucht spürbar weniger Tokens, bis er den richtigen Kontext gefunden hat.
4. Ableiten. Ein Modell übernimmt nach Zeitplan Anreicherungsaufgaben: Tickets klassifizieren, Gespräche bewerten, strukturierte Felder aus Freitext extrahieren. Hier wird aus dem Gedächtnis ein aktives Teammitglied, das nachts vorarbeitet.

Was ein Company Brain im Alltag leistet

Der Nutzen zeigt sich weniger in spektakulären Einzelfällen als in der Summe kleiner Anfragen, die sonst ein Teammitglied unterbrechen würden:

• Vorbereitete Support-Antworten. Zu jedem neuen Ticket liegt bereits eine interne Notiz vor, die Ursache, ähnliche Fälle und frühere Lösungen zusammenfasst, bevor der Fall überhaupt geöffnet wird.
• Produktfragen aus Vertrieb und Customer Success. Unterstützt unser Produkt Szenario X? Was haben wir Kunde Y zu Feature Z zugesagt? Die Antwort kommt mit Verweis auf die Quelldatei.
• Analytics ohne Warteschlange. Wie viele Kunden nutzen Feature Z, und seit wann? Der Agent kennt die Kennungen aus den Akten und fragt das Data-Warehouse selbst ab.
• Kundenbriefings. Vor einem Termin liefert der Agent eine Zusammenfassung aller Berührungspunkte der letzten Monate, inklusive offener Tickets und der Stimmung im letzten Gespräch.
• Onboarding. Neue Teammitglieder stellen Fragen im Kanal, statt im Wiki zu graben. Und weil der Kanal öffentlich ist, lernen alle mit, welche Fragen der Agent gut beantwortet.

Der letzte Punkt ist mehr als ein angenehmer Nebeneffekt. Ein gemeinsamer Kanal macht sichtbar, was das Team vom Agenten erwartet und wo er scheitert. Diese Transparenz ist der schnellste Weg, das Repository dort zu verbessern, wo es tatsächlich Lücken hat.

Dass dieses Prinzip auch in großem Maßstab trägt, zeigt Shopify. Der interne Agent River, der Code liest, Pull-Requests eröffnet und das Data-Warehouse abfragt, arbeitet ausschließlich in öffentlichen Slack-Kanälen und lehnt Direktnachrichten ab; jede Konversation wird zum durchsuchbaren Transkript. In einem Zeitraum von 30 Tagen zählte das Unternehmen laut seinem Engineering-Blog knapp 60.000 Sessions in über 5.000 Kanälen mit mehr als 7.000 beteiligten Personen. Die öffentlichen Threads werden ausgewertet, und die Muster daraus fließen zurück in Skills, Prompts und Voreinstellungen des Agenten. Intern heißt das Modell Lehrwerkstatt: Wer zusieht, wie erfahrene Teammitglieder mit dem Agenten arbeiten, lernt dabei, was in keiner Dokumentation steht.

Wie das Gedächtnis lernt, ohne zu verwildern

Ein Repository lädt dazu ein, dass alle alles ändern. Genau das sollte nicht passieren, aus zwei Gründen: Nicht-technische Teammitglieder sollen nicht in Git arbeiten müssen, und Verhaltensänderungen des Agenten brauchen Kontrolle. Der Ansatz löst beides mit einer einfachen Regel. Wissen fließt über die synchronisierten Quellen in das Repository, also über das Wiki, das Ticketsystem und die Protokolle, die ohnehin alle pflegen. Verhalten ändert sich nur über Pull-Requests.

Konkret sieht das so aus: Wer eine wiederkehrende Art von Frage hat, bittet den Agenten im Kanal, dafür einen Skill anzulegen. Der Agent stellt die Rückfragen, die er für eine saubere Umsetzung braucht, schreibt die Skill-Datei und eröffnet einen Pull-Request. Eine Person, die das System versteht, prüft den Vorschlag und hilft beim Merge. Damit die Vorschläge von vornherein brauchbar sind, gibt es Skills, die beschreiben, wie Skills gebaut und wie sie geprüft werden. Das Ergebnis ist ein interner Katalog von Fähigkeiten, der als Markdown im Repository liegt, versioniert und nachvollziehbar wie Code. Wer möchte, dass der Agent etwas Neues kann, muss niemanden aus der Entwicklung bitten. Wer die Kontrolle über das Verhalten behalten will, hat sie über das Review.

Sicherheit: die gefährliche Dreierkombination

Ein Company Brain ist nützlich, weil es viel weiß. Genau deshalb verdient sein Betrieb mehr Sorgfalt als ein Chatbot mit Zugriff auf die öffentliche Website. Der Sicherheitsforscher Simon Willison hat das Risiko auf eine Formel gebracht, die sich als Lethal Trifecta etabliert hat: Ein Agent wird gefährlich, wenn drei Bedingungen gleichzeitig erfüllt sind.

1. Er hat Zugriff auf vertrauliche Daten. Bei einem Company Brain ist das der Zweck.
2. Er verarbeitet Inhalte, die nicht vertrauenswürdig sind. Tickets, Gesprächsnotizen und Wiki-Seiten können Anweisungen enthalten, die ein Angreifer platziert hat, etwa in einer Support-Anfrage.
3. Er kann nach außen kommunizieren. Ohne einen Kanal zur Außenwelt bleiben die ersten beiden Bedingungen weitgehend folgenlos.

Sprachmodelle können Anweisungen in Daten nicht zuverlässig von legitimen Anweisungen unterscheiden. Prompt Injection ist deshalb kein Fehler, der sich durch einen besseren Systemprompt beheben lässt, sondern eine strukturelle Eigenschaft. Wie sie in einem Company Brain konkret aussieht, zeigen die Sicherheitshinweise im nächsten Kapitel.

Jede Sicherheitsentscheidung sollte daran gemessen werden, ob sie eine der drei Bedingungen abschwächt, ohne den Nutzen des Agenten wesentlich zu beschneiden. Die drei Faktoren lassen sich einzeln behandeln; bei der externen Kommunikation gelingt das am leichtesten. In der Praxis bedeutet das, nach Wirkung sortiert:

• Netzwerkzugriff des Agenten abschalten, und zwar auf Ebene der Sandbox, nicht per Anweisung im Prompt. Ein manipulierter Agent hält sich nicht an seinen eigenen Prompt. Wo Verbindungen unvermeidbar sind, gilt eine Positivliste weniger, geprüfter Domains.
• Ausgabe begrenzen und beobachten. Kommuniziert der Agent nur über wenige, einsehbare Kanäle, lässt sich prüfen, was er sendet: durch einen zweiten Agenten ohne Zugriff auf vertrauliche Daten, der vor dem Versand gegenliest, oder durch eine nachgelagerte Kontrolle, die Auffälligkeiten meldet.
• Repository privat halten und Zugriff eng fassen. Der rohe Zugriff gehört zu den Personen, die ihn wirklich brauchen. Der Bot postet nur in einem festgelegten Kanal; das ergibt einen natürlichen Audit-Trail.
• Nur synchronisieren, was alle Mitarbeitenden sehen dürften. Der Agent kann alles zutage fördern, was im Repository liegt. Daten mit höherer Schutzstufe bleiben draußen oder wandern in ein separates Repository mit eigenem Zugriffskreis. Personenbezogene Daten werden vor dem Sync pseudonymisiert oder entfernt.
• Zugangsdaten als Kronjuwelen behandeln. Jeder Konnektor authentifiziert sich mit einem Token, der auf das Minimum beschränkt wird, nach Möglichkeit nur lesend. Ein geleakter Token wiegt schwerer als die synchronisierten Daten, weil er Live-Zugriff auf das Quellsystem gewährt.
• Lieferkette absichern. Sync-Skripte laufen mit Zugriff auf alle Secrets. Ein Mindestalter für Paketversionen (etwa fünf Tage seit ihrer Veröffentlichung) gibt der Community Zeit, bösartige Veröffentlichungen zu entdecken, bevor sie das eigene System erreichen.

Das Risiko wird dadurch nicht null. Der hilfreichste Vergleich ist der mit Mitarbeitenden: Auch ihnen räumt niemand das Recht ein, versehentlich die Datenbank zu löschen. Berechtigungen werden nach Aufgabe vergeben, Verhalten wird beobachtet, und trotzdem bleibt ein Rest, weil sich Menschen täuschen lassen. Das Ziel ist, den Aufwand für einen Angriff über seinen Nutzen zu heben und die wahrscheinlichen Fehlerfälle sichtbar, begrenzt und reparierbar zu machen. Wie sich diese Prinzipien auf Agenten im Entwicklungsprozess übertragen, beschreiben wir im Beitrag zur Sicherheit von AI Agents in der Entwicklung.

Sicherheitshinweise: Angriffsmuster, die Sie kennen sollten

Die Dreierkombination beschreibt das Risiko abstrakt. Im Betrieb begegnet es Ihnen in konkreten Mustern, und die meisten davon sehen im ersten Moment harmlos aus. In der OWASP-Liste der größten Risiken für LLM-Anwendungen steht Prompt Injection an erster Stelle, verbunden mit dem Hinweis, dass weder Retrieval noch Feintuning das Problem beseitigen und nur gestaffelte Maßnahmen helfen: minimale Rechte für Werkzeuge, Filterung von Ein- und Ausgaben, Freigabe durch Menschen bei riskanten Aktionen. Die folgende Übersicht zeigt, wie die wichtigsten Muster in einem Company Brain aussehen und welche Gegenmaßnahme jeweils greift.

Kein einzelner Punkt dieser Liste macht das System sicher. Die Muster zeigen aber, dass die wirksamen Gegenmaßnahmen fast immer in der Infrastruktur liegen und nicht im Prompt: Netzwerk, Rechte, Review, Sichtbarkeit. Wer die Übersicht beim Sicherheitsreview vor der Öffnung des Kanals durchgeht, hat die wahrscheinlichen Fehlerfälle abgedeckt.

Grenzen und Trade-offs

Der Ansatz ist bewusst einfach, und Einfachheit hat einen Preis. Wer ein Company Brain plant, sollte diese Punkte nüchtern gegen den Nutzen stellen.

Eine Zugriffsebene für alle. Ein Repository kennt keine feingranularen Rechte pro Nutzer und Dokument. Wer den Kanal nutzen darf, sieht potenziell alles, was synchronisiert wurde. Der Ansatz passt deshalb am besten zu Unternehmen, in denen Wissen intern standardmäßig geteilt wird. Wo Wissen stark nach Vertraulichkeitsstufen getrennt ist, braucht es entweder mehrere Repositories oder eine Architektur, in der die Berechtigungen des Quellsystems durchgereicht werden. Das spricht dann eher für MCP-Anbindungen mit Nutzerauthentifizierung, zumindest für die sensiblen Quellen. Und Persönliches bleibt in jedem Fall draußen: Direktnachrichten, Messenger-Verläufe und private Notizen gehören in ein persönliches Gedächtnis, nicht in das des Unternehmens.

Stand des letzten Syncs statt Live-Daten. Ein täglicher Sync bedeutet, dass der Agent in den Dateien den Stand des letzten Laufs kennt. Für Wiki, Tickets und Protokolle ist das unproblematisch. Für Bestände, Preise oder Kontostände ist es das nicht; solche Fragen gehören an die Kommandozeilenwerkzeuge oder an eine Live-Schnittstelle. Die sinnvolle Architektur ist hybrid: Dateien für das Gedächtnis, Werkzeuganbindungen für Aktionen und Echtzeitdaten.

Konnektoren sind der Engpass. Der Agent weiß nur, was ein Skript abholen kann. Systeme ohne brauchbare API oder Exportfunktion bleiben blinde Flecken. Diese Lücken sollten Sie vor dem Start kennen, nicht danach.

Kontextdateien sind kein Selbstläufer. Eine Untersuchung der ETH Zürich hat gemessen, was Kontextdateien wie AGENTS.md bei Coding-Aufgaben tatsächlich bewirken: Die Erfolgsquote stieg im Mittel nicht, die Inferenzkosten dagegen um über zwanzig Prozent. Konkrete Anweisungen wurden befolgt, allgemeine Repository-Übersichten halfen nicht. Übertragen auf das Company Brain heißt das: Eine gute AGENTS.md sagt dem Agenten, wie er suchen soll und was die Ordner bedeuten. Sie erzählt ihm nicht, was das Unternehmen tut. Jede Zeile Kontext kostet Aufmerksamkeit und Geld, also verdient sie eine Begründung.

Kuratierung braucht Verantwortliche. Filtern, Zusammenführen und Verlinken sind keine einmaligen Aufgaben. Ohne eine Person, die das Repository pflegt, die Pull-Requests der Skills prüft und die Fragen im Kanal beobachtet, verwildert es wie jedes Wiki. Der Vorteil gegenüber dem Wiki: Der Agent selbst kann bei der Pflege helfen, etwa indem er Widersprüche zwischen Dateien meldet.

Datenschutz. Sobald Kundendaten an einen Modellanbieter fließen, gelten die üblichen Anforderungen an Auftragsverarbeitung und Datenminimierung. Die Entscheidung, welche Felder vor dem Sync entfernt werden, ist keine technische, sondern eine organisatorische. Sie gehört an den Anfang des Projekts.

Kaufen oder bauen?

Der Markt bietet inzwischen fertige Wissensplattformen mit Rechteverwaltung, Compliance-Zertifikaten und Oberflächen für Fachabteilungen. Fertige Produkte sind die richtige Wahl, wenn feingranulare Berechtigungen nicht verhandelbar sind oder wenn im Unternehmen niemand ein Repository betreuen kann. Für Technologieunternehmen ist die Rechnung derzeit eine andere: Ein Cloud-Agent und ein Git-Repository voller Markdown-Dateien sind so günstig und so schnell aufgesetzt, dass ein Wechsel auf ein gekauftes Produkt eher einen Rückschritt bedeuten würde. Noch hat niemand das Thema durchgehend gelöst. In ein bis zwei Jahren wird es sehr wahrscheinlich ausgereifte Produkte geben, die viele der beschriebenen Probleme abnehmen, und dann verschiebt sich die Entscheidung. Bis dahin gewinnt das selbst gebaute Company Brain dort, wo Geschwindigkeit, Kontrolle und Unabhängigkeit zählen: Jede Zeile ist einsehbar, und das Wissen bleibt in einem offenen Format, das jeder künftige Agent und jedes künftige Produkt lesen kann. Aus unserer Erfahrung ist diese Unabhängigkeit vom Anbieter der unterschätzte Faktor.

So starten Sie pragmatisch

Ein Company Brain muss nicht als Großprojekt beginnen. Unsere Empfehlung folgt derselben Logik, die wir für jeden KI-Use-Case auf dem Weg zum Piloten vorschlagen: klein anfangen, an echten Fragen messen, dann ausbauen.

1. Zwei bis drei Quellen wählen, die den größten Hebel haben. Meist sind es Support-Tickets, Codebasis und Dokumentation, wenn der erste Anwendungsfall im Support liegt, oder Wiki und Gesprächsprotokolle, wenn es um Produkt- und Kundenwissen geht.
2. Privates Repository aufsetzen, Konnektoren anbinden, Sync per CI einrichten. Ein Nachmittag mit einem Coding-Agenten reicht; die Skripte schreibt er größtenteils selbst.
3. Eine AGENTS.md schreiben, die erklärt, was wo liegt. Kurz, konkret, mit Beispielen für gute Suchstrategien.
4. Mit zwanzig echten Fragen testen. Fragen, die im letzten Monat tatsächlich gestellt wurden. Wo der Agent scheitert, fehlt meist eine Quelle oder ein Querverweis, selten ein besseres Modell.
5. Kuratieren. Filtern, zusammenführen, verlinken. Erst jetzt lohnt es sich, den Kanal für das ganze Team zu öffnen.
6. Sicherheitsreview durchführen. Netzwerk der Sandbox, Positivliste, Tokens, Schutzstufen der Daten, Datenschutz und die Angriffsmuster aus den Sicherheitshinweisen. Vor der Öffnung, nicht danach.
7. Skills und Automatisierungen ergänzen. Erst wenn das Gedächtnis zuverlässig antwortet, kommen der Pull-Request-Prozess für neue Skills und nächtliche Ableitungen wie Ticket-Klassifikation oder Wochenberichte dazu.

Was Sie in dieser Reihenfolge vermeiden: alle Quellen auf einmal anbinden, den Kanal öffnen, bevor die Antworten belastbar sind, und das Sicherheitsreview auf später verschieben.

Ausblick: das Company Brain für Kunden

Die nächste Stufe zeichnet sich bereits ab. Heute läuft jede Kommunikation nach außen über einen Menschen, der die Antwort des Agenten prüft und weitergibt. Bei Support-Anfragen, Integrationsfragen und Produktdetails ist das ein Engpass, der wenig Wert stiftet: Der Mensch übersetzt, was das System längst weiß. Erste Unternehmen erproben deshalb eine abgespeckte Variante ihres Company Brains, die Kunden in gemeinsamen Kanälen direkt befragen können, ohne dass die vertraulichen Inhalte selbst nach außen gelangen.

Damit wird die gefährliche Dreierkombination von einem theoretischen zu einem konkreten Problem: Der Agent hat vertrauliche Daten, liest Nachrichten von Externen und antwortet ihnen. Die Kontrollen von oben bekommen dann eine andere Gewichtung. Der Datenzugriff dieser Variante wird beschnitten, die Ausgabe wird vor dem Versand geprüft, und der gemeinsame Kanal sorgt dafür, dass beide Seiten sehen, was gefragt und geantwortet wird. Wer einen Agenten über tausend Nachrichten hinweg manipulieren will, tut das nicht unbemerkt in einem Kanal, den das eigene Team und der Anbieter mitlesen. Vollständig gelöst ist das nicht. Aber es ist die Richtung, in die sich Kundenkommunikation entwickeln wird, und wer das interne Gedächtnis heute sauber aufbaut, hat den größten Teil der Vorarbeit für diesen Schritt bereits geleistet.

Fazit: Kontext ist die eigentliche Arbeit

Die Debatte um KI in Unternehmen kreist gern um Modelle. Das Company Brain zeigt, dass der Engpass woanders liegt: im Kontext, den ein Agent bekommt, und in der Form, in der er ihn bekommt. Ein Unternehmen zu führen bedeutet seit jeher, den richtigen Menschen zur richtigen Zeit die richtigen Informationen zu geben. Diese Fähigkeit wird in einer Organisation, in der Agenten mitarbeiten, nicht weniger wichtig, sondern zur Kernkompetenz.

Das Git-Repository als Unternehmensgedächtnis ist dafür ein bemerkenswert robustes Werkzeug. Es ist versioniert, inspizierbar, werkzeugunabhängig und in Stunden aufgebaut. Seine Schwächen (einheitliche Zugriffsebene, Stand des letzten Syncs, laufender Pflegebedarf) sind bekannt und beherrschbar. Wir arbeiten intern selbst mit versionierten Skills und Kontextdateien für unsere Agenten und sehen den Ansatz als natürliche Erweiterung dieser Praxis auf das gesamte Unternehmenswissen. Für Entscheider, die den Einstieg in Agentensysteme suchen, ohne sich an eine Plattform zu binden, ist er derzeit einer der bodenständigsten Wege: wenig Magie, viel Handwerk, schnell messbarer Nutzen.