Was ich baue, wenn
ich mir die Aufgabe
selbst stelle

Eine Ankündigung, die nach hinten losgehen kann. Sie beschreiben Ihr Vorhaben in einem Satz und legen ein paar eigene Unterlagen dazu — Marktanalysen, Reaktionen auf frühere Entscheidungen, Rückmeldungen aus dem Handel. Daraus baut HiveWeaver die Zielgruppe selbst und spielt die Ankündigung durch. Das mitgelieferte Beispiel ist ein Hersteller, der künftig kein Ladegerät mehr beilegt: Wie kommt das an, und bei wem besonders schlecht?

Eine Abstimmung vor der Abstimmung. Fünftausend Bürgerinnen und Bürger mit unterschiedlichen Lebenslagen, dazu eine Handvoll Stimmen mit Reichweite. Dieselbe Regelung wird in drei Fassungen durchgespielt — im Beispiel Vier-Tage-Woche, City-Maut und Schuluniformen. Am Ende sehen Sie nicht nur, welche Variante die meisten mitträgt, sondern auch, an welchem Argument die anderen scheitern.

Eine Kampagne über mehrere Kanäle. Derselbe Inhalt als Video, als Bildkampagne und als Fachbeitrag, jeweils gegen das Publikum, das dort tatsächlich unterwegs ist. Oder, eine Nummer größer: zehntausend Händler, die auf einen Ausgang wetten — der wahrscheinliche Preis stellt sich dabei von allein ein, ohne dass ihn jemand vorgibt.

Allen Beispielen gemeinsam ist, dass am Ende keine Bauchentscheidung steht, sondern ein ausformuliertes Ergebnis mit Begründung — und die Möglichkeit, jede einzelne Reaktion nachzulesen, die dazu geführt hat.

Termine eintragen, E-Mails beantworten und einsortieren, morgens um sechs eine Zusammenfassung schicken: Das übernimmt HiveWeaver ebenso, und passende Abläufe liegen als fertige Beispiele bei. Nur ist es nicht das, was die Plattform von anderen Systemen abhebt — solche Aufgaben lösen inzwischen viele.

Der Unterschied zeigt sich dort, wo viele Vorgänge gleichzeitig laufen und sich gegenseitig beeinflussen. Nehmen Sie die Reklamationsbearbeitung eines Großhändlers: täglich hunderte Fälle, die sich über Wochen ziehen, mit Rückfragen, Teillieferungen und Eskalationen. Bei HiveWeaver bekommt jeder Fall seinen eigenen Agenten, der ihn von Anfang bis Ende begleitet und sich merkt, was bisher geschah — kein Kontext, der bei jedem Aufruf neu zusammengesucht werden muss. Daneben stehen Rollen: eine Prüfinstanz, die Fachabteilung, die Freigabe. Die reden miteinander, statt eine starre Kette abzuarbeiten.

Ein Fall, in dem gerade nichts passiert, kostet dabei nichts. Deshalb können zehntausend Vorgänge gleichzeitig offen sein, ohne dass die Rechnung explodiert. Genau das ist der Unterschied zu einem Assistenten, den Sie pro Aufruf bezahlen und der nach jedem Aufruf wieder vergisst, worum es ging.

Der eigentliche Vorteil kommt aber davor. Bevor auch nur ein echter Kunde betroffen ist, lassen Sie denselben Ablauf gegen erfundene Kundschaft laufen — auch gegen die unangenehme Sorte, die das Formular falsch ausfüllt, dreimal nachhakt und am Ende storniert. Sie sehen, wo es klemmt, bessern nach, und schalten erst dann auf Echtbetrieb um. Es ist derselbe Ablauf, keine Testversion davon. Bei einem fertigen Assistenten schalten Sie live und hoffen.

Dazu kommt, woran solche Vorhaben im Unternehmen sonst scheitern: Alles kann im Haus bleiben, das Sprachmodell eingeschlossen. Jeder Schritt ist im Nachhinein belegbar — wer, wann, warum, zu welchen Kosten. Und alles, was Geld kostet oder sich nicht zurücknehmen lässt, wartet auf eine Freigabe, statt einfach zu passieren.

Bei KI-Projekten wird meist nicht die Technik zum Problem, sondern die Abrechnung am Monatsende. Deshalb ist bei HiveWeaver von vornherein festgelegt, welche Entscheidung ein Sprachmodell befragen darf und welche nicht.

Ein Beispiel aus den Beispielszenarien: Auf einem Marktplatz rechnet der Marktmacher nach festen Regeln — er braucht kein Modell, um Angebot und Nachfrage zusammenzubringen. Nur die Händler, die eine Stimmung einschätzen sollen, fragen tatsächlich nach. Der Löwenanteil der Vorgänge kostet damit nichts.

Genauso lässt sich innerhalb eines Durchlaufs unterscheiden: Die wenigen Stimmen mit Reichweite bekommen das teure, sorgfältige Modell — die tausend Zuhörer im Publikum ein günstiges. Das Ergebnis bleibt aussagekräftig, die Rechnung überschaubar.

Und weil zu jedem einzelnen Schritt festgehalten wird, was er gekostet hat, sehen Sie nach dem ersten Durchlauf schwarz auf weiß, wo das Geld hingeht — statt es am Monatsende zu erfahren.

Eine leere Distribution ist bereits eine vollständige Arbeitsoberfläche. Links eine Leiste mit den Werkzeugen, in der Mitte Bereiche, die sich per Ziehen teilen und in ein eigenes Fenster lösen lassen, darin Tabs mit Vorschau und Anheften. Dazu benannte Arbeitsumgebungen, die eine ganze Art zu arbeiten festhalten, eine Befehlspalette, ein Schnellöffner, Einstellungen mit Berechtigungen und ein Katalog, aus dem Nutzer Erweiterungen installieren.

Alles, was ein Mensch dort per Hand tut, kann der eigene Code ebenso: Jeder Bereich, jede Arbeitsumgebung, jeder Schalter ist zugleich ein Dienst, den das Produkt selbst aufruft. Wer eine eingebaute Schaltfläche abschaltet, bietet dieselbe Aktion aus der eigenen Werkzeugleiste an. Ein Schalter entfernt die Bedienung, nie die Fähigkeit.

Die Oberfläche läuft ohne Backend. Wo doch eines ist, greift sie über drei schmale Anschlüsse darauf zu: Einstellungen, Arbeitsstand und Anmeldung. Welche Technik dahinter steht, ist der Plattform gleichgültig.

Ein gutes Werkzeug weckt Ideen, und manche Nutzer würden sie selbst umsetzen, wenn sie könnten. Sie können es nicht, weil es keinen Weg hinein gibt. Einen zu öffnen bedeutet Abschottung, Berechtigungen, einen Katalog, Updates und eine Schnittstelle, die man verspricht nicht zu brechen. Das ist kein Feature, das ist ein halbes Jahr Arbeit.

LoomWeaver unterscheidet drei Stufen. Eigene Erweiterungen laufen fest eingebaut im Produkt. Fremder Code läuft abgeschottet in einem eigenen Rahmen ohne Zugriff auf die Seite, geschrieben in welchem Framework auch immer. Und aus einem kuratierten Katalog installieren Nutzer zur Laufzeit selbst, nach einem Dialog, der die angeforderten Berechtigungen aufzählt. Was der Nutzer selbst erlaubt hat, darf er auch wieder entziehen, abschalten und entfernen.

Alle drei Stufen nutzen denselben Vertrag hinter demselben Vermittler, der jede Berechtigung verweigert, bis sie ausdrücklich erteilt ist. Eine Erweiterung eine Stufe tiefer zu setzen, ist eine Vertrauensentscheidung, kein Umbau.

Eine Aktion wird in LoomWeaver genau einmal registriert. Daraus werden Schaltfläche, Tastenkürzel, Kontextmenü und Paletteneintrag, ohne dass man vier Listen pflegt. Mit einer einzigen Markierung wird dieselbe Aktion zusätzlich zum Werkzeug für einen KI-Agenten. Eine zweite Werkzeugliste neben der ersten gibt es nicht, deshalb kann sie auch nicht auseinanderlaufen.

Für die Verbindung zum Agenten setzt LoomWeaver auf AG-UI, ein offenes Protokoll zwischen einer Anwendung und einem agentischen Backend, das nicht von mir stammt. Ein Backend, das es spricht, bedient das Produkt ohne Zwischenschicht, und die Gegenseite lässt sich austauschen. Welches Modell arbeitet, welcher Transport, welcher Schlüssel: Das bleibt Ihre Entscheidung.

Jeder Aufruf geht durch dieselbe Stelle wie ein Klick, also erbt der Agent die Berechtigungen und die Zugangsregeln, die ohnehin gelten. Eine Ablehnung liest sich immer gleich, egal aus welchem Grund, sodass sich durch Fragen nichts darüber lernen lässt, was installiert ist. Sagt der Mensch Nein, wird die Oberfläche gar nicht erst gefragt.

Eine Eingabe wird nicht sofort abgearbeitet, sondern angenommen und quittiert. Die Oberfläche bekommt binnen Millisekunden ihre Bestätigung und wartet nicht darauf, dass im Hintergrund geschrieben, geprüft und ausgewertet wird. Für die Nutzerin fühlt sich die Anwendung damit auch dann flüssig an, wenn hinten viel zu tun ist.

Die eigentliche Arbeit verteilt ein Message Bus an Worker, die sich die Aufgaben untereinander aufteilen. Wächst die Last, stellen Sie weitere Worker daneben — auf denselben oder auf zusätzliche Server. Das ist der Unterschied zwischen „wir brauchen eine größere Maschine" und „wir starten drei weitere Instanzen", und er entscheidet später über die Cloud-Rechnung.

Damit mehrere Worker sich nicht gegenseitig ins Gehege kommen, sind die Datenströme fest auf 4096 Abschnitte verteilt. Für einen einzelnen Geschäftsvorfall schreibt immer genau ein Worker — über verschiedene Vorfälle hinweg läuft alles parallel. Auswertungen werden anschließend aktiv benachrichtigt, statt in einer Schleife nachzufragen, ob es etwas Neues gibt. Deshalb sind die Lesedaten praktisch sofort aktuell, ohne dass eine Datenbank im Leerlauf ständig abgefragt wird.

In .NET werden Methoden häufig dynamisch aufgerufen — bequem für den Entwickler, aber jeder einzelne Aufruf kostet. Bei einem Geschäftsvorfall mit zehn Einträgen fällt das nicht auf. Bei einem, der über Jahre gewachsen ist, summiert es sich mit jedem Eintrag. Stratara übersetzt diese Aufrufwege deshalb einmal in eine feste Funktion und ruft sie danach direkt auf. Was einmal aufgelöst wurde, bleibt aufgelöst.

Der Effekt lässt sich messen. Ein Geschäftsvorfall mit einer Million Einträgen wird in gut elf Millisekunden vollständig neu aufgebaut — und der Speicherbedarf bleibt dabei konstant bei 64 Byte, unabhängig von der Länge. Anders gesagt: Es entsteht kein Müll, den der Speicherverwalter später aufräumen müsste, egal wie lang die Historie wird.

Die Zahlen stammen von einem lüfterlosen MacBook Air, nicht von einem abgestimmten Server. Sie sind damit eher konservativ als geschönt — und jederzeit selbst nachmessbar, das Messprojekt liegt im Repository.

Jeder Eintrag trägt den Fingerabdruck seines Vorgängers. Wird ein Betrag später direkt in der Datenbank geändert — durch eine fehlerhafte Migration, ein eingespieltes Backup oder mit Absicht — passt der neu berechnete Fingerabdruck nicht mehr zum gespeicherten. Der nächste Prüflauf meldet nicht nur, dass etwas nicht stimmt, sondern nennt die genaue Stelle.

Eine solche Kette allein hält allerdings niemanden auf, der vollen Zugriff auf die Datenbank hat und einfach alle Fingerabdrücke neu berechnet. Deshalb lässt sich in regelmäßigen Abständen ein Prüfpunkt außerhalb der eigenen Infrastruktur verankern. Stratara hält diesen Punkt fest, die externe Quelle binden Sie an. Das sage ich lieber deutlich, als mit dem Wort „unveränderlich" mehr zu versprechen, als die Technik hergibt.

Wer die Daten einer einzelnen Person wirklich entfernen will, müsste sie überall gleichzeitig erwischen: in der Historie, in allen daraus abgeleiteten Auswertungen, in Zwischenständen, in jeder Kopie und in jedem Backup, das jemals gezogen wurde. Innerhalb der gesetzlichen Frist von 30 Tagen ist das kaum nachweisbar zu schaffen — ein übersehenes Backup genügt.

Stratara dreht die Aufgabe um. Die Daten jeder betroffenen Person liegen unter einem eigenen Schlüssel. Ein einziger Aufruf vernichtet diesen Schlüssel, und damit werden sämtliche Kopien in einem Zug unlesbar — auch die, an die technisch längst niemand mehr herankommt. Die Historie bleibt vollständig, die Person ist daraus aber nicht mehr rekonstruierbar.

Dasselbe Verfahren trägt noch zwei weitere Themen: Es trennt die Daten verschiedener Kunden kryptografisch voneinander, und es liefert die Schlüsselverwaltung, nach der Prüfer bei SOC 2 und ISO 27001 fragen.