Hypers Company Brain: Wie man eine Wissensdatenbank für KI-Agenten gestaltet

Was mich bei Hyper innehalten ließ, war nicht der Begriff company brain. Es war die Art, wie es ein Problem benennt, in das viele Teams bereits laufen: KI-Agenten können inzwischen über mehrere Schritte Code ändern, E-Mails schreiben und Skripte ausführen, haben aber oft keine Ahnung, welchen Plan das Team gestern verworfen hat. Bitten Sie Codex, eine Checkout-Seite zu ändern, stützt es sich vielleicht auf Produktformulierungen aus einem alten PR. Bitten Sie Claude Code, eine API-Einschränkung zu prüfen, öffnet es womöglich wieder Drive und übersieht die spätere Slack-Entscheidung. Eine menschliche Kollegin ergänzt beiläufig: „Nutz den Plan nicht mehr.” Ein Agent entwickelt dieses gemeinsame Gedächtnis nicht von allein.

Ich würde Hyper zuerst als Architektur-Fallstudie behandeln. Es ist noch früh, und öffentliche Materialien sind nicht dasselbe wie eine Validierung durch Dritte. Trotzdem helfen die Details auf der YC-Seite und in der Launch-HN-Diskussion, zu klären, was eine Company-Wissensdatenbank für KI-Agenten wirklich leisten muss: Sie ist nicht nur Dokumentensuche und nicht nur ein MCP-Connector. Sie lässt Agenten im richtigen, aktuellen und berechtigungsbewussten Company-Kontext handeln.

Wo normales RAG hängen bleibt

Normales RAG ist gut darin, Chunks in Dokumenten zu finden. Sie zerlegen Markdown, PDFs und Webseiten in Chunks, embedden sie, rufen bei einer Anfrage ähnliche Inhalte ab und lassen das Modell eine Antwort verfassen. BetterLink hat diesen Weg in der RAG-+-Agent-Architektur behandelt, und er reicht für Wissens-Q&A, Support-FAQs und Codebase-Erklärungen.

Company-Kontext ist chaotischer. Der Agent muss nicht nur ähnliche Inhalte finden. Er muss auch wissen, ob der Inhalt noch gültig ist, wer ihn sehen darf und warum die Entscheidung getroffen wurde.

Alte und neue Informationen kollidieren

Nehmen Sie eine kleine Release-Entscheidung. Das Meeting am Montag sagt: „Freitag ausliefern.” Am Mittwoch ändert sich das Kundenfeedback, und der Product Owner verschiebt den Launch auf nächsten Montag. Eine Vektordatenbank kann beide Aussagen speichern. Welche zuerst kommt, hängt von Query, Embedding, Chunking und Ranking ab. Ruft der Agent die alte „Freitag”-Notiz ab, schreibt er weiter die falsche Ankündigung und plant die falsche Arbeit.

Ein sichereres Design behält beide Fakten, markiert den neuen aber als Ablösung des alten: wer es gesagt hat, wann, welcher Geltungsbereich betroffen ist und warum die vorige Schlussfolgerung ungültig wurde. Dann kann der Agent bei „Warum wurde das verschoben?” die Entscheidungshistorie nachverfolgen, statt den alten Kontext zu verlieren.

Berechtigungen müssen vor der Antwort greifen

Sobald eine Company-Wissensdatenbank einen handlungsfähigen Agenten speist, sind Berechtigungen kein Detail mehr. Sales, Support, Engineering und Leitung fragen vielleicht zum selben Kunden und sollten unterschiedliche Inhaltsumfänge erhalten. OpenAIs Hinweise zu Team-Connectors machen einen ähnlichen Punkt: ChatGPT sieht nur Inhalte, auf die der Nutzer bereits zugreifen darf, und Connectors respektieren bestehende Berechtigungsgrenzen.

Diese Prüfung sollte vor dem Retrieval geschehen, nicht nachdem das Modell den Kontext schon gesehen hat und brav sein soll. Filtern Sie unsichtbare Daten zuerst heraus; dann abrufen, ranken und injizieren. Sonst kann der Agent über Logs, Entwürfe oder Tool-Calls sensible Informationen verraten.

Agenten fehlt auch das Warum

Viele Company-Dokumente halten Ergebnisse fest, nicht Gründe. Ein Designplan wurde vielleicht verworfen, weil der Brand-Fit nicht passte, der Vertrieb Kundenwiderstand hörte, die technische Schuld zu hoch war oder dem Team damals einfach die Kapazität fehlte. Sieht der Agent nur das Ergebnis, wiederholt er den Fehler vielleicht in leicht anderem Kontext.

OpenAIs Memory-Update rahmt nützliches Gedächtnis als Kontext mitnehmen, Präferenzen befolgen und über die Zeit aktuell bleiben. Auf Company-Ebene würde ich eine Anforderung ergänzen: Das System sollte die Einschränkungen hinter einer Entscheidung erklären. Ohne diese Schicht sucht ein Agent nur schneller, versteht das Unternehmen aber nicht besser.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Was Hypers öffentliche Materialien zeigen

Es gibt ein paar Details in Hypers öffentlichem Launch, die mir wichtig sind. Sie beweisen nicht, dass das Produkt perfekt ist, aber sie sind konkreter als „Slack und Drive in eine Vektordatenbank kippen”.

Das erste Detail ist die Trennung von Episodes und Facts. Im HN-Launch-Thread beschreiben die Gründer Rohquellen als Episodes: Dokumente, E-Mails, Kalender, Slack, Granola-Notizen und so weiter. Facts sind die aus diesen Episodes extrahierte Bedeutung. Sie sind als Subject-Predicate-Object-Datensätze geformt, mit einer Plain Summary plus Zeitstempeln dafür, wann der Fakt eingeführt und wann er invalidiert wurde. Das Rohmaterial bleibt als Source of Truth verfügbar, während extrahierte Facts schnelleres Reasoning und Retrieval unterstützen.

Das zweite Detail sind Beziehungs-Edges zwischen Facts. Die öffentliche Diskussion erwähnt, dass Facts in tension zueinander stehen, voneinander derived sein oder durch einen neueren Fakt superseded werden können. Das ist für Agenten wichtig, denn Company-Kontext ist kein flacher Ordner von Notizen. Er ist eine Historie sich ändernder Entscheidungen.

Das dritte Detail ist hybrides Retrieval. Hyper erwähnte query expansion, embeddingbasierte semantische Suche, Postgres full-text search und reciprocal rank fusion. Nichts davon ist mystisch, aber es ist praktisch. Semantisches Retrieval ist gut bei Bedeutung. Full-Text-Suche ist besser für exakte Kundennamen, Ticket-IDs, Funktionsnamen und Vertragsnummern. Fusion reduziert die Abhängigkeit von einem einzigen Retrieval-Pfad.

Das vierte Detail ist Permission-Tagging. Jeder Fakt trägt Provenienz und Access-Control-Tags, und Retrieval wird nur gegen Facts und Episodes ausgewertet, auf die der Nutzer zugreifen darf. Ohne das wird ein Company Brain schnell zum Sicherheitsrisiko.

Das fünfte Detail ist die Aufteilung von Hooks und MCP. Die MCP-Dokumentation beschreibt MCP als offenen Standard, um KI-Anwendungen mit externen Systemen zu verbinden, und das OpenAI Agents SDK unterstützt ebenfalls mehrere MCP-Integrationen. MCP ist nützlich, wenn ein Agent aktiv ein Tool abfragt, hängt aber davon ab, dass der Agent erkennt, wann das Tool aufgerufen werden soll. Hyper sagte im HN-Thread, dass es für Tools wie Claude Code, Codex und Cursor zusätzlich Lifecycle-Hooks nutzt, um Kontext zu injizieren oder zu extrahieren, wenn eine Session startet, ein Prompt abgeschickt wird oder ein Agent-Turn endet. Dieser Trade-off ist umstritten, besonders bei der Installationstransparenz, aber er benennt ein reales Problem: Manchen Kontext kann man nicht davon abhängig machen, dass der Agent daran denkt, ihn abzufragen.

Ein Company Brain als prüfbare Bausteine bauen

Wenn Ihr Team noch keinen neuen Anbieter einführen will, können Sie trotzdem eine kleine Version bauen. Beginnen Sie nicht damit, jede Datenquelle anzubinden. Trennen Sie das System zuerst in Teile, die Sie tatsächlich prüfen können.

Source: Rohinputs müssen abspielbar sein

Die Quellschicht braucht am ersten Tag keine volle Abdeckung. Bessere Startpunkte sind Produktentscheidungs-Markdown, aktuelle PR-Zusammenfassungen, öffentliche Issues und Support-Wissensartikel. Slack-, E-Mail- und CRM-Daten sind dicht, aber auch verrauscht und berechtigungslastig. Fügen Sie sie später hinzu.

Jedes Quellelement sollte Basismetadaten tragen: Quelltyp, Original-URL oder Dateipfad, Erstellzeit, Aktualisierungszeit, Autor, Sichtbarkeitsbereich und einen Hash. Wird ein Fakt später falsch extrahiert, muss das Team zum Originaltext zurückkehren können.

Fact: Ein Fakt sollte mehr als eine Zusammenfassung sein

Ein brauchbarer Fakt braucht Felder wie Subject, Predicate, Object, Summary, Source, Einführungszeit, Invalidierungszeit, Berechtigungs-Tags, Konfidenz und menschliche Korrektureinträge. Das ist kein Feld-Horten. Es gibt dem Agenten Grenzen, wenn er antwortet.

Zum Beispiel:

Faktenextraktion gelingt beim ersten Versuch nicht perfekt, also brauchen Sie einen menschlichen Korrekturpfad. In der HN-Diskussion erwähnte Hypers Gründer auf die Frage nach unübersichtlichen, widersprüchlichen Daten reifer Firmen harte Korrekturen über ein MCP-Skill wie /correct. Diese Richtung lohnt sich zu kopieren: Lassen Sie einen Menschen ausdrücklich sagen „Das ist falsch; nimm stattdessen das” und behalten Sie die Korrekturspur.

Retrieval: Hybride Suche ist zuverlässiger als ein Pfad

Vektor-Retrieval ist nützlich für unscharfe Bedeutung, aber Kundennamen, SKUs, Ticket-IDs, Funktionsnamen und Vertragsnummern brauchen oft Keyword-Treffer. Ich würde Retrieval in drei Schritte teilen:

1. Nach Identität, Projekt, Datenquelle und Berechtigungen des Nutzers filtern.
2. Semantische Suche, Full-Text-Suche und Graph-Nachbarschaftserweiterung parallel laufen lassen.
3. Ergebnisse fusionieren oder reranken und nur eine kleine Menge hochrelevanter Facts injizieren.

Mehr Kontext ist nicht immer besser. Ist der Kontext zu breit, behandelt das Modell auch unrelevante Facts als Hinweise. Eine bessere Voreinstellung ist, 5-15 enge Facts mit Provenienz und Konfidenz zu injizieren. Fehlt die Information, soll der Agent nachfragen oder die Originalquelle prüfen.

Injection: MCP, Hooks und manueller Kontext haben verschiedene Grenzen

MCP ist ein Einstiegspunkt, kein vollständiges Memory-System. Es lässt Agenten auf Tools und Datenquellen zugreifen und kann Fähigkeiten wie search_company_facts, correct_fact oder get_decision_history bereitstellen. Sie können das Muster aus Agent Tool Calling erweitern und die Company-Wissensdatenbank als Tool bereitstellen.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Hooks sind stabiler, weil sie Kontext automatisch injizieren können, wenn eine Session startet oder ein Prompt abgeschickt wird, ohne auf einen Tool-Aufruf des Modells zu warten. Sie bergen auch Risiko. Nutzer müssen wissen, was installiert wurde, wann es läuft, was es liest und wie man es deaktiviert. Dieser Punkt löste in den HN-Kommentaren Widerspruch aus, und kleine Teams sollten Hinweise, Logs und Schalter sichtbar machen.

Manueller Kontext bleibt nützlich. Bei risikoreichen Aufgaben kann es sicherer sein, einen Menschen wählen zu lassen, welches Projektwissen für diesen Durchlauf erlaubt ist, als volle Automatisierung. AI-first heißt nicht, dass jeder Schritt unbeaufsichtigt sein muss.

Governance: Korrektur, Export und Audit früh entwerfen

Je nützlicher ein Company Brain wird, desto teurer ist die Migration weg davon. Auf HN wurden Vendor-Lock-in-Bedenken geäußert, und sie sind berechtigt. Wenn jeder Agent von derselben Wissensschicht abhängt, sind Export, Löschung, Backup und Audit keine Bonusfunktionen.

Ich würde diese Fragen während des Piloten stellen: Lassen sich Facts als JSON oder CSV exportieren? Lassen sich Roh-Episodes löschen? Löst eine Berechtigungsänderung ein erneutes Filtern aus? Gibt es ein Log, welcher Fakt von einem Agenten in welcher Aufgabe genutzt wurde? Überschreibt eine menschliche Korrektur einen alten Fakt oder bewahrt sie eine Historienkette? Früh fragen spart später Schulden.

Wie man zwischen den Optionen wählt

Diese Optionen lösen verschiedene Probleme, die Namen können also irreführen.

Wenn Mitarbeitende nur fragen „Wo ist die Spesenrichtlinie?”, reicht Enterprise Search oder normales RAG. Soll ein Agent Code ändern, E-Mails senden, Sales-Follow-ups schreiben oder Kundenrisiken zusammenfassen, braucht das System mehr: Ist dieser Fakt noch gültig? Ist die Quelle vertrauenswürdig? Darf der Nutzer ihn sehen? Braucht die Aktion eine Bestätigung?

OpenAIs Team-Connectors bringen bereits Inhalte aus Team-Tools in Gespräche. Das MCP-Ökosystem macht es Agenten leichter, sich mit mehr Tools zu verbinden. Ein Company Brain sitzt zwischen diesen Schichten: Es macht aus verstreuten Inhalten Company-Kontext, der laufend aktualisiert, nachvollziehbar, berechtigungsgefiltert und von verschiedenen Agenten wiederverwendbar ist.

Ein 7-Tage-Pilot: Mit einem engen Workflow starten

Sie müssen nicht das ganze Unternehmen anbinden, um ein Company Brain zu testen. Wählen Sie einen risikoarmen, häufigen Agent-Workflow und fahren Sie ihn eine Woche.

Tag 1-2: Workflow und Quellen wählen

Wählen Sie ein klar abgegrenztes Szenario, etwa „Codex bitten, eine kleine Funktion anhand der neuesten Produktvorgaben zu ändern” oder „einen Support-Agenten bitten, aus aktuellen Bug-Notizen einen Antwortentwurf zu erstellen”. Binden Sie nur drei Quelltypen an: Produktentscheidungs-Dokumente, aktuelle PR-Zusammenfassungen und öffentliche Issues. Starten Sie nicht mit allen Slack-, E-Mail- und CRM-Daten.

Schreiben Sie den verbotenen Bereich auf: keine echten E-Mails, keine Änderungen an Produktionskonfiguration, keine Finanz- oder HR-Daten und keine quellenlosen Fakten als Schlussfolgerungen.

Tag 3-4: Facts und Konfliktbeziehungen extrahieren

Extrahieren Sie 50-100 Facts aus diesen Quellen. Machen Sie einen Teil manuell, dann mit Modellunterstützung. Jeder Fakt sollte Quelle, Zeit, Berechtigungen und Konfidenz enthalten. Bei Konflikten löschen Sie den alten nicht vorschnell. Markieren Sie die Beziehung: supersedes, supplements, conflicts with oder needs confirmation.

Sie können mit einem einfachen Schema starten. Eine komplexe Graphdatenbank ist für einen Piloten nicht nötig. Postgres-Tabellen, JSONB, Full-Text-Indizes und Vektorerweiterungen tragen ein kleines Experiment. Hypers öffentliche Diskussion erwähnte auch, dass Postgres in solchen Systemen praktisch bleibt, weil strukturierte Metadaten und graphähnliche Beziehungen nah beieinander liegen können.

Tag 5-6: Kontext injizieren und Aufgaben wiederholen

Fügen Sie dem Agenten ein Tool oder einen Hook hinzu: Bei der aktuellen Aufgabe liefert es 5-15 relevante Facts mit Provenienz. Spielen Sie dann 20 echte Aufgaben durch und verfolgen Sie drei Zahlen:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

• Wie oft müssen Menschen noch Hintergrundkontext ergänzen?
• Wie oft zitiert der Agent veraltete oder falsche Facts?
• Erscheint ein unbefugter Fakt, oder bringt zu breiter Kontext den Agenten zum Abdriften?

Beurteilen Sie nicht nur, ob die Ausgabe poliert aussieht. Der Wert eines Company Brain liegt darin, wiederholte Erklärungen zu reduzieren, Fehler durch veraltete Fakten zu senken und den Agenten bei unvollständiger Evidenz vorsichtiger zu machen.

Tag 7: Ausweiten, pausieren oder Richtung ändern

Profitieren nur wenige der 20 Aufgaben, weiten Sie noch nicht auf das ganze Unternehmen aus. Der Workflow passt vielleicht nicht, oder die Faktenextraktion ist zu grob. Sinken Rückfragen, gehen veraltete Zitate zurück und erscheinen keine unbefugten Facts, fügen Sie eine weitere Quelle hinzu, etwa Meeting-Notizen oder einen kuratierten Slack-Kanal.

Der nächste Schritt ist, dies mit KI-Agent-Monitoring und Recovery zu kombinieren: Nutzt der Agent einen Fakt mit niedriger Konfidenz, einen widersprüchlichen Fakt oder eine risikoreiche Aktion, leiten Sie ihn zur menschlichen Bestätigung.

Vor der Einführung die Risiken klar benennen

Sobald eine Company-Wissensdatenbank an Agenten angebunden ist, ist sie kein reines Information-Retrieval-Projekt mehr. Einige Risiken sollten früh in den Plan geschrieben werden.

Das erste ist Datenschutz und Trainingsgrenzen. Hypers Gründer sagte in den HN-Kommentaren, man trainiere nicht auf gehosteten Daten und verkaufe sie nicht, und verwies auf FAQ und Datenschutzrichtlinie. Da die offizielle Datenschutzseite über meinen Crawler nicht lesbar war, würde ich keine Details ableiten. Teams sollten Verträge, Datenverarbeitungsbedingungen, Aufbewahrungsfristen und Löschworkflows prüfen, statt sich auf einen Launch-Post zu verlassen.

Das zweite ist Hook-Transparenz. Automatische Kontextinjektion ist zuverlässiger, als zu hoffen, dass ein Agent daran denkt, MCP aufzurufen, aber Nutzer müssen wissen, was auf ihren Maschinen installiert ist. Installationshinweise, Laufzeit-Logs, Deaktivierungsschalter und sichtbare Konfiguration sollten offensichtlich sein.

Das dritte ist verunreinigte Historie. Reife Firmen haben oft alte, widersprüchliche Dokumente, und neuer ist nicht immer autoritativer. In Rechts-, Finanz-, religiösen oder behördlichen Workflows kann ein älteres Dokument die maßgebliche Quelle sein. Das System darf nicht alles nach Aktualität ranken. Verschiedene Quellen und Rollen brauchen unterschiedliche Gewichte.

Das vierte ist Vendor-Lock-in. Je länger ein Company Brain genutzt wird, desto mehr ähnelt es einem Teil des Betriebssystems der Firma. Exportformate, Backup-Strategie, Self-Hosting-Optionen und Notfall-Exit-Pläne müssen früh geprüft werden. Ohne sie kann der kurzfristige Fluss zur langfristigen Falle werden.

Lassen Sie das System sagen, dass es unsicher ist

Mir gefällt die Richtung, in die Hyper drängt: Wenn Agenten tiefer in Team-Workflows vordringen, brauchen sie stabileren Company-Kontext, als normales Dokumenten-Retrieval bieten kann. Aber die Umsetzung sollte geerdet bleiben. Bevor Sie es ein Whole-Company-Brain nennen, stellen Sie sicher, dass das System alte und neue Fakten unterscheiden, zu Quellen zurückkehren, nach Berechtigungen filtern, menschliche Korrekturen annehmen und „Ich bin nicht sicher” sagen kann, wenn die Evidenz dünn ist.

Ein kleines Team kann mit einem engen Workflow starten: drei risikoarme Quelltypen, ein paar Dutzend Facts und 20 echte Aufgaben. Fahren Sie das zuerst, dann entscheiden Sie über die Ausweitung. Es ist weniger spektakulär, aber für Agenten, die echte Arbeit liefern müssen, viel näher an brauchbar.