Hyper Company Brain: Engineering fuer AI-Agent-Wissensbasen

Wenn Sie Claude Code bitten, Code zu aendern, weiss es nicht, warum Ihr Team diesen Branch vor drei Monaten geloescht hat. Wenn Sie ChatGPT nach einer Produktentscheidung fragen, muss es erst wieder alle Dokumente lesen. Bei jedem Aufruf muessen Sie Projektgeschichte neu erklaeren. Genau hier liegt ein wichtiger Unterschied zwischen Agents und normalem RAG: RAG ist gut darin, statische Dokumente zu durchsuchen. Unternehmenswissen hat aber drei Dimensionen, die RAG nicht von Haus aus abbildet: Fact-Gueltigkeit, Rechteumfang und die Begruendungskette hinter Entscheidungen.

Auf Hacker News sagte Hyper, es wolle ein „Company Brain“ bauen. Das klingt erst einmal nach Marketing. Die Architekturdetails, die der Gruender im Launch-Thread genannt hat, sind aber technisch interessant: zweischichtige Memory aus episodes und facts, typed edges, ein Timestamp-Modell sowie hooks und MCP als zwei Injektionspfade. Das hier ist kein Produkttest. Ich nutze diese oeffentlichen Informationen, um das Designproblem von „Company Memory“ zu zerlegen: eine fuenfschichtige Design-Checkliste, einen 7-Tage-Pilotpfad und eine Risikotabelle fuer die Auswahl.

Drei Kontextarten, die normales RAG nicht auffangen kann

RAG durchsucht Dokumente, gibt Ausschnitte zurueck und laesst das Modell antworten. Dieser Ablauf funktioniert fuer statische Wissensbasen. Unternehmenswissen hat aber drei Dimensionen, die RAG standardmaessig nicht behandelt.

Klassisches RAG sortiert nach recency oder relevance. Es kann nicht erkennen, ob eine Information durch einen newer fact supersedes, also ersetzt, wurde. Hyper versieht jeden fact mit zwei Timestamps: introduced_at haelt das erste Auftreten fest, invalidated_at den Zeitpunkt der Ungueltigkeit. Beim Retrieval werden ungueltige facts herausgefiltert, statt sich auf das Aktualisierungsdatum eines Dokuments zu verlassen.

Rechteumfang ist in Organisationen mit mehreren Personen besonders sensibel. Ein Agent-Aufruf kann im Namen eines bestimmten Teammitglieds laufen. Dann sollte der Agent keine Inhalte ausserhalb dessen Projektbereich lesen. Hyper markiert die Sichtbarkeit jedes facts mit access-control tags. Die Retrieval-Schicht filtert die Ergebnisse anhand der Identitaet des Aufrufers, bevor sie etwas zurueckgibt. Das ist feiner als „Enterprise Search“, die oft nur Dokumentrechte kennt. Ein Company Brain braucht Fact-Rechte.

Entscheidungsgrund ist der schwierigste Teil fuer normales RAG. Wenn Sie fragen „Warum haben wir PostgreSQL statt MongoDB gewaehlt?“, findet RAG vielleicht den Ergebnisabschnitt im Architekturpapier. Dieser Abschnitt enthaelt aber nicht zwingend die technische Diskussion von vor drei Monaten, die Abwaegungen und die finale Entscheidungslogik. Hypers episodes-Schicht behaelt die originalen Gespraechsknoten. Die facts-Schicht verweist ueber einen derived from typed edge auf die Quell-episode. So kann Retrieval der Beziehung folgen und zur Begruendungskette zurueckgehen, nicht nur zum Ergebnis.

Hypers zweischichtige Memory-Architektur

Hyper organisiert Memory in zwei Schichten: Episodes als Rohspeicher und Facts als strukturierte Schicht. Darueber werden sie in einem Knowledge Graph verbunden.

Episodes-Schicht: Sie bewahrt originale Gespraechsknoten und verliert den Kontext nicht. Episodes sind die Provenienz-Anker fuer Facts. Wenn ein Agent einen Entscheidungsprozess nachvollziehen muss, kann er vom fact ueber den derived from edge zum urspruenglichen Gespraechsausschnitt zurueckgehen, statt nur eine zusammengefasste Schlussfolgerung zu lesen.

Facts-Schicht: Sie nutzt eine subject-predicate-object-Struktur. Jeder fact enthaelt Subjekt, Relation und Objekt, dazu Timestamps und typed edges. Der Gruender nannte oeffentlich drei Arten von typed edges:

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

Jetzt starten →Anzeige

Timestamp-Modell: Jeder fact hat zwei Zeitachsen. Die T-Achse beschreibt, wann das Ereignis passiert ist, etwa „die Entscheidung fiel im Maerz“. Die T’-Achse beschreibt, wann das System den fact aufgenommen hat, etwa „dieser fact wurde im Juni in die Wissensbasis geschrieben“. Diese Trennung ist wichtig, weil Unternehmenswissen oft verzoegert eingetragen wird. Ein Meeting-Ergebnis kann erst eine Woche spaeter dokumentiert werden. Das System muss unterscheiden, wann etwas passiert ist und wann es davon erfahren hat.

Kernpunkte der Architektur:

• Episodes werden nicht wegzusammengefasst, sondern behalten die originalen Gespraechsknoten, so die HN-Aussage des Gruenders plus der Zep-Paper-Kontext.
• Facts werden als Triples strukturiert, jeweils mit Timestamps und typed edges, wie im HN-Thread beschrieben.
• introduced_at / invalidated_at markieren den Fact-Lebenszyklus; die Retrieval-Schicht filtert ungueltige Inhalte.
• Der Knowledge Graph speichert mit typed edges Beziehungen, nicht nur facts. Genau das unterscheidet ihn von einer normalen Vektordatenbank.

Ziel dieser Architektur ist nicht, mehr Daten zu speichern. Sie soll Agents ermoeglichen, Kontext entlang von Beziehungen zu finden. Eine normale Vektordatenbank gibt aehnliche Ausschnitte zurueck, kennt aber keine logische Abhaengigkeit, Ersatzbeziehung oder Konfliktstelle zwischen Ausschnitten. Typed edges plus Timestamps geben den Retrieval-Ergebnissen Metadaten mit: woher dieser fact kommt, ob er noch gueltig ist und ob er ersetzt wurde.

Zwei Pfade: Retrieval und Injektion

Nachdem Wissen geschrieben wurde, haben Agents zwei Nutzungswege: Retrieval, also aktive Abfrage, und Injektion, also passives Empfangen von Kontext.

Retrieval-Mechanismus laut HN-Aussage des Gruenders:

• Postgres full-text search: Keyword-Matching fuer exakte Abfragen, etwa die Definition eines bestimmten API endpoint.
• Embedding Semantic Search: Vektoraehnlichkeit fuer unschaerfe Fragen, etwa „was war das letzte Ergebnis zur Performance-Optimierung?“
• Reciprocal Rank Fusion (RRF): kombiniert Full-Text- und Semantic-Recall und gibt eine aggregierte Rangfolge zurueck.
• Access-control tags filtering: schneidet Ergebnisse anhand der Aufruferidentitaet zu und sichert die Rechte-Grenzen.

Diese Kombination unterscheidet sich von einer reinen Vektordatenbank. Letztere macht nur semantischen Recall und kann bei exakten Keyword-Abfragen Treffer verpassen. Hyper kombiniert beide Recall-Wege ueber RRF und beruecksichtigt beim Ranking sowohl Keyword-Treffer als auch semantische Aehnlichkeit.

Vergleich der Injektionspfade: hooks und MCP sind zwei unterschiedliche Datenkanaele.

Beide Pfade koennen nebeneinander existieren. Der Hyper-Gruender sagte, hooks wuerden fuer Echtzeit-Kontextinjektion genutzt, etwa wenn beim Oeffnen von Claude Code Projektdokumente automatisch geladen werden. MCP sei fuer aktive Tool-Aufrufe des Agents gedacht, etwa eine Abfrage an Notion oder Gmail. Im Launch-Thread wurde aber auch die Transparenz von hooks hinterfragt: Weiss der Nutzer klar, welche Daten automatisch in die Agent-Konversation injiziert werden?

Bei der Auswahl sollten Sie zwei Dinge pruefen: ob hooks klare Installationshinweise haben und ob Admins den Rechteumfang des MCP server kontrollieren koennen. OpenAIs developer mode-Dokumentation erwaehnt, dass MCP apps eine Sicherheitspruefung brauchen und Enterprise-Plaene RBAC fuer Zugriffskontrolle nutzen koennen. Das MCP-Governance-Modell ist damit relativ reif. Die Transparenz von hooks haengt dagegen stark vom Produktdesign ab.

Fuenf-Schichten-Checkliste fuer ein Company Brain

Wenn Sie selbst bauen oder auswaehlen, pruefen Sie, ob alle fuenf Schichten eine Antwort haben. Jede fehlende Schicht zeigt sich spaeter im Betrieb.

Schicht 1: Datenquellen-Anbindung

• Tool-Auswahl: Notion, Gmail, Slack, GitHub, Linear, Jira, je nach Team-Workflow.
• Anbindungsart: webhooks fuer Echtzeit oder polling fuer periodische Abfrage. Webhooks reagieren schneller, muessen aber vom Zielsystem unterstuetzt werden.
• Datenbereinigung: Rauschen filtern, etwa private Plauderkanaele in Slack; sensible Informationen markieren; Encoding vereinheitlichen.
• Initialer Import: gesamte Historie oder nur neue Daten. Historische Daten enthalten oft viele veraltete facts.

Schicht 2: Fact-Schema

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

15 % Rabatt sichern →Anzeige

• Fact-Struktur: subject-predicate-object-Triples, einheitlich gespeichert.
• Timestamps: introduced_at fuer das erste Auftreten plus invalidated_at fuer den Ungueltigkeitszeitpunkt. Fehlt eines davon, laesst sich der Lebenszyklus kaum beurteilen.
• Typed edges: mindestens derived from fuer Provenienz, supersedes fuer Ersatz und tension fuer Konflikt.
• Konfliktstrategie: tension automatisch fuer menschliche Pruefung markieren oder je nach Timestamp den newer fact nutzen.

Schicht 3: Retrieval

• Recall-Mix: Full-Text (Keywords) + Semantic (Embedding) + RRF-Fusion. Reiner semantischer Recall kann exakte Abfragen verpassen.
• Rechtefilter: fact-level access-control tags, zugeschnitten auf die Identitaet des Aufrufers.
• Ranking-Strategie: recency, relevance und fact validity kombinieren und ungueltige facts filtern.
• Latenzziel: Retrieval-Antwort < 500 ms in der Praxis, sonst fuehlen sich Agent-Aufrufe merklich traege an.

Schicht 4: Injektion

• Pfadwahl: hooks fuer Echtzeit-Kontextinjektion, MCP fuer agenteninitiierte Abfragen. Beide Pfade koennen koexistieren.
• Agent-Kompatibilitaet: Claude Code, Cursor, ChatGPT und Codex muessen den gewaehlten Pfad unterstuetzen.
• Governance-Modell: hooks brauchen transparente Installationshinweise; MCP server-Rechte sollten von Admins kontrolliert werden.
• Kontrolle der Datenmenge: Laenge des injizierten Kontexts begrenzen, um Token-Grenzen nicht zu sprengen; facts mit hoher relevance priorisieren.

Schicht 5: Governance

• Rechtevererbung: Quellrechte muessen auf fact-level Sichtbarkeit gemappt werden. Facts aus einem privaten Slack-Channel duerfen nicht fuer alle sichtbar werden.
• Audit-Logs: Wer hat wann welchen fact injiziert, und wann hat ein Agent welche facts gelesen? Probleme brauchen Nachvollziehbarkeit.
• Menschliche Korrektur: falsche facts markieren, einen invalidated-Flow entwerfen und manuelle Klarstellungs-facts unterstuetzen.
• Datenexport: pruefen, ob der gesamte fact store als JSON/CSV exportierbar ist, um Lock-in zu bewerten.

Die Logik dieser Checkliste ist einfach. Die Datenquellen-Schicht klaert, woher Daten kommen. Die Fact-Schicht klaert, in welcher Struktur gespeichert wird. Die Retrieval-Schicht klaert, wie gefunden wird. Die Injektions-Schicht klaert, wie Kontext uebergeben wird. Die Governance-Schicht klaert, wer verwaltet und korrigiert. Fehlt eine Schicht, bleibt die Unternehmenswissensbasis in der Praxis stecken.

7-Tage-Pilotpfad

Ein kleines Team sollte in der ersten Woche nicht direkt ganz Slack, E-Mail oder CRM anschliessen. Die Rechte sind komplex und das Rauschen ist gross. Dadurch tauchen Governance-Probleme zu frueh auf. Starten Sie mit risikoarmen Quellen, validieren Sie Recall und Korrekturmechanismus und erweitern Sie erst danach.

Tag 1-2: Risikoarme Datenquellen waehlen

• Oeffentliche Notion-Dokumente, etwa Produkt-Roadmaps und technische Spezifikationen.
• GitHub README und Wiki, etwa Projektarchitektur und API-Dokumentation.
• Ausschliessen: private Slack-Channel, historische E-Mails, CRM-Kundendaten, weil sie rechtekritisch und verrauscht sind.

Tag 3: Fact-Schema entwerfen

• 3-5 Felder: subject, predicate, object, introduced_at, source.
• Nicht perfekt machen: Im Pilot geht es darum, den Retrieval-Pfad zu pruefen. Das Schema kann spaeter wachsen.
• Namensregeln festlegen: subject im einheitlichen Format, etwa „ProjectX“, predicate als Verb, etwa „uses“.

Tag 4-5: Retrieval und Injektion testen

• Retrieval-Test: 5-10 Queries vorbereiten und pruefen, ob wichtige facts gefunden werden.
• Injektions-Test: Einen Agent auswaehlen, etwa Claude Code oder Cursor, und pruefen, ob er injizierten Kontext lesen kann.
• Latenz messen: Ist die Retrieval-Antwort < 500 ms, und zitiert der Agent nach der Injektion facts korrekt?

Tag 6-7: Replay und menschliche Korrektur

• Historische Queries wiederholen und pruefen, ob falsche oder veraltete facts in den Ergebnissen auftauchen.
• Fehler erfassen: facts auflisten, die invalidated werden muessen, und den Markierungsflow entwerfen.
• Korrekturmechanismus bauen: Menschen koennen Klarstellungs-facts hinzufuegen und falsche facts mit invalidated_at markieren.

Was in der ersten Woche tabu ist:

• Kein Slack, keine E-Mail, kein CRM, weil Rechte und Rauschen zu komplex sind.
• Kein perfektes Schema verfolgen. Erst den Retrieval-Pfad pruefen, dann iterieren.
• Keine Produktionsdatenquellen anschliessen. Nutzen Sie Testdaten oder oeffentliche Dokumente.

Am Ende des Piloten sollten Sie drei Dinge haben: einen funktionierenden Retrieval-plus-Injection-Flow, 5-10 verifizierte facts und einen Korrekturprozess. Das sind die Voraussetzungen fuer mehr Datenquellen. Erst pruefen, ob das System finden, lesen und korrigieren kann; dann weitere Tools anschliessen.

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

Jetzt starten →Anzeige

Risikotabelle fuer die Auswahl

Pruefen Sie vor der Entscheidung sieben Risikodimensionen. Jede sollte eine Quelle und eine Vertrauensstufe haben.

Von diesen sieben Dimensionen sind Datenexport und Vendor Lock-in bei der Entscheidung besonders wichtig. Der Gruender sagte im Launch-Thread, dass Export unterstuetzt wird, aber ein vollstaendiges offizielles Commitment konnte ich nicht verifizieren. Deshalb muessen Sie klaeren, ob das Exportformat strukturiert ist, etwa JSON oder CSV, ob der komplette fact store mit typed edges und Timestamps exportiert werden kann und ob fuer eine Migration in ein anderes System zusaetzliche Bereinigung noetig waere.

Hook-Transparenz ist ein weiterer leicht uebersehener Punkt. Hooks injizieren Kontext auf Client-Seite. Nutzer wissen moeglicherweise nicht, welche Daten automatisch in die Agent-Konversation geladen wurden. Pruefen Sie, ob das Produkt klare Installationshinweise bietet und ob Nutzer den injizierten Datenumfang ansehen und steuern koennen.

Rechtevererbung hat mit access-control tags eine oeffentlich beschriebene technische Richtung, aber keine oeffentlichen Vererbungsregeln. Die praktischen Fragen sind konkret: Wie wird ein fact aus einem privaten Slack-Channel auf fact-level Sichtbarkeit gemappt? Wie werden CRM-Kundendaten pro Team zugeschnitten? Ob Kauf oder Eigenbau, diese Mapping-Logik braucht ein Design.

Naechste Schritte und weiterfuehrende Artikel

Wenn Sie tiefer in Agents und Wissensbasen einsteigen wollen, passen diese BetterLink-Artikel gut dazu:

• RAG + Agent: Architektur fuer die naechste Generation von AI-Anwendungen — wie Retrieval-Ergebnisse Agent-Entscheidungen antreiben.
• AI-Agent-Memory-Systeme: Damit Agents Kontext behalten — persoenliche Agent-Memory-Architektur und der Unterschied zu geteilter Company Memory.
• Workers AI + Vectorize RAG Tutorial — praktische Details zu Cloudflare Vectorize fuer kleine RAG-Systeme.
• AI-Agent-Monitoring und Selbstwiederherstellung — wie Memory und Ausfuehrung verbunden werden, damit Fehler erkannt und wiederholt werden koennen.
• Agent Tool Calling in der Praxis — MCP- und Tool-Calling-Details als Ergaenzung zum Injektionspfad.

Fazit

Hyper ist noch ein fruehes Produkt. Die oeffentlichen Architekturdetails, darunter zweischichtige Memory, typed edges, Timestamp-Modell sowie hooks und MCP als zwei Pfade, sind trotzdem ein gutes Beispiel, um „Company Memory“ zu verstehen. Fuer kleine Teams, die so ein System auswaehlen oder selbst bauen, stehen drei Punkte im Vordergrund: Datenexport, Hook-Transparenz und Konfliktbehandlung.

Starten Sie im Pilot mit einem engen Workflow: oeffentliche Notion-Dokumente oder ein GitHub README, dann Retrieval-Recall und Korrekturmechanismus testen, bevor Slack oder E-Mail angeschlossen werden. Jagen Sie am Anfang keinem perfekten Schema hinterher. Fact-Lebenszyklus, Rechtevererbung und menschliche Korrektur muessen in echten Tests wachsen.

Wenn Sie Claude Code oder Cursor schon nutzen, koennen Sie zuerst per hooks Projektdokumente injizieren und beobachten, ob der Agent facts korrekt zitiert. Danach geht es darum, Memory und Ausfuehrung zu schliessen: Agent-Monitoring und Selbstwiederherstellung, damit Fehler automatisch erkannt und erneut versucht werden koennen.