Ein KI-Notebook für Power-User: ein Kernel, zwei Paar Hände

In den meisten KI-Analysewerkzeugen steckt eine falsche Wahl. Chat-Produkte behandeln jeden Nutzer als Business-User: Fragen rein, Antworten raus - und wer die eigentlichen Daten anfassen will, darf ein CSV exportieren und gehen. Notebook-Produkte machen den umgekehrten Fehler: Alle gelten als Engineers, und wer nur eine Antwort wollte, prallt an der leeren Zelle ab. Beide Designs teilen eine Annahme, die es abzulehnen lohnt - dass die Arbeit der KI und die Arbeit der Experten an verschiedenen Orten stattfinden.

Ihre besten Analysten sind Power-User. Sie lesen eine Brinson-Zerlegung schneller als jede Zusammenfassung davon, sie haben Meinungen zu Join-Keys, und sie werden keine Zahl akzeptieren - und sollten es nicht -, in die sie nicht hineingreifen können. Die Frage, die eine ernsthafte Plattform beantworten muss, ist nicht "Wie sorgen wir dafür, dass sie das nicht mehr brauchen?" Sondern: Wo docken sie an?

Eine Werkbank, zwei Paar Hände

In DataQube lautet die Antwort: am selben Ort, an dem der Agent arbeitet. Ein Thread ist kein Chat-Fenster mit einer API dahinter - er ist eine Werkbank mit einem laufenden Kernel, und das Gespräch ist die Art, wie an dieser Bank gearbeitet wird. Der Composer, der normale Fragen annimmt, nimmt auch /py und /sh. Fragen Sie auf Deutsch, und der Agent fragt ab, formt und rechnet; wechseln Sie in Code, und Sie sind in der selben Session - derselbe Kernel, die Variablen des Agenten intakt, seine Dataframes live im Speicher.

So sieht das aus - die Tool-Schritte des Agenten und eine Notebook-Zelle, in einem Strom:

Lauf wiederholen

Auf Basis realer Kundengespräche — alle Daten fiktiv.

Genau dort weitermachen, wo der Agent aufgehört hat

Die Übergabe ist der Punkt. Der Agent hat die Bestände des Quartals gezogen, die Benchmark mit dem richtigen Verzug verknüpft und die Attribution gerechnet - die langweiligen, fehleranfälligen achtzig Prozent. Eine Quant, die tiefer will, exportiert nichts, lädt nichts neu, rekonstruiert nichts. Sie öffnet eine Zelle und macht weiter:

1# /py — att is the agent's attribution frame, still live2top = drilldown(att[att.sector == "Industrials"], level="issuer")3top[["issuer", "selection_bp", "active_weight_bp"]].head(2)4 5#            issuer              selection_bp   active_weight_bp6# Kessler Industrietechnik AG          -41               1307# Nordbahn Systems SE                  -30               110

att ist der Dataframe des Agenten. Der Drilldown führt dessen Arbeit fort - hier bis auf Emittentenebene, zu den zwei Namen hinter dem Selektionsverlust des Sektors. Von hier kann die Quant die Daten anders schneiden, einen Faktor einbringen, den der Agent nicht berücksichtigt hat, oder den nächsten Analyseschritt komplett in Code prototypen - und der Agent nimmt es im Gespräch wieder auf, denn es ist eine Session. Das ist Co-Working im schlichtesten Sinn: zwei Arten von Expertise an denselben Werkzeugen auf derselben Bank, jede tut, was sie am besten kann.

Beide Arbeiten, ein Protokoll

Alles an der Werkbank landet im selben append-only Protokoll: die Queries des Agenten mit ihren Audit-Referenzen, die Zellen der Analystin mit ihren, verschränkt in der Reihenfolge, in der es tatsächlich geschah, und zugeordnet zu dem, der es getan hat. Nichts wird jemals still mutiert - bearbeiten Sie eine Zelle, entsteht eine Revision; nachgelagerte Ergebnisse gelten als veraltet, bis sie neu laufen; die alte Version bleibt. Erreicht eine Zahl aus diesem Thread ein Komitee, hat "Woher kommt das?" eine mechanische Antwort, die die menschlichen Beiträge einschließt: Gehen Sie das Log entlang, und der Emittenten-Drilldown der Quant steht direkt neben dem Attributionslauf des Agenten, jeder mit eigener Spur.

Diese Verschränkung macht Co-Working governierbar statt chaotisch. Der Code der Expertin ist kein Seitenkanal und kein privater Notizzettel - er steht im Protokoll, mit demselben Rang wie die Arbeit des Agenten, sichtbar für dieselben Reviewer unter denselben Audit-Garantien.

Wenn der Kernel weg ist

Eine laufende Session hat einen Kernel: Variablen im Speicher, Dataframes zum Hineingreifen. Sessions enden; Protokolle nicht. Öffnen Sie einen Thread vom März, und DataQube ist ehrlich über den Unterschied - die Zellen zeigen exakt, was lief und was es produzierte, als Aufzeichnungen, und nichts tut so, als wäre der März-Kernel noch warm. Es gibt keine stille Neuausführung gegen heutige Daten mit den Zeitstempeln vom März. Wollen Sie die Arbeit wieder live, ist das explizit: in einer frischen Session neu ausführen, mit neuen Ergebnissen als neuen Events - oder den Workflow extrahieren, wenn sie von selbst weiterlaufen soll.

Die Wette

Bauen Sie kein Chat-Produkt für die Vielen und verbannen Sie die Experten in ein anderes Tool. Bauen Sie eine Werkbank: Der Agent übernimmt die schwere Arbeit, Ihre schärfsten Leute bearbeiten dieselben Daten mit echtem Code, und alles, was beide getan haben, bleibt auf einem Protokoll. Das Thread-und-Notebook-Modul auf der Produktseite zeigt, wo das in der Plattform lebt - und wenn Sie eine Quant haben, die nicht glaubt, dass der Kernel wirklich geteilt ist, bringen Sie sie in eine Demo und lassen Sie sie tippen.