WingQ: Eine Kommunikationszentrale für mehrere KI-Harnesses

Wenn ich mit einem Agenten arbeite, möchte ich den Auftrag und sein Ergebnis im Blick behalten. Welcher Harness den Lauf ausführt, ist dabei eine technische Entscheidung. Trotzdem bringen viele Werkzeuge ihren eigenen Chat, ihre eigene Sitzung und ihren eigenen Umgang mit Dateien mit.

WingQ ist meine Antwort darauf: eine gemeinsame Kommunikationszentrale, hinter der verschiedene Agenten-Laufzeiten arbeiten können. Ich muss mich dadurch nicht für alle Aufgaben auf einen einzigen Harness festlegen.

Oberfläche, Harness und Modell sind verschiedene Ebenen

Das Modell erzeugt Antworten und Werkzeugaufrufe. Der Harness organisiert den Arbeitslauf: Er hält die Sitzung, verarbeitet Ergebnisse und entscheidet innerhalb seiner Regeln, wie es weitergeht. WingQ ist die Ebene, auf der ich diesen Prozess anspreche und verfolge.

Diese Trennung ist im Alltag hilfreich. Ich kann ein lokales Modell über OpenCode verwenden und für einen anderen Ablauf NexClaw einsetzen. Die Kommunikation muss deshalb nicht jedes Mal in ein völlig anderes Produkt wechseln.

Dabei bleibt ein Modellwechsel etwas anderes als ein Harnesswechsel. Ein Modell kann hinter derselben API ausgetauscht werden. Ein anderer Harness bringt möglicherweise andere Werkzeuge, Zustände und Fähigkeiten mit.

Wie WingQ mit den Laufzeiten verbunden ist

Zwischen WingQ und den Harnesses sitzt in meinem Aufbau die AgentBridge. Ihr gemeinsamer Adapter beschreibt unter anderem Start, Zustand, Beginn eines Turns, Abbruch und Herunterfahren. Die Bridge ordnet eine Unterhaltung einer Laufzeit zu und reicht deren Ereignisse an die Oberfläche weiter.

Im Quellcode liegen Adapter für NexClaw, OpenCode, Claude SDK und eine ältere OpenClaw-Anbindung. Das belegt die Integrationswege. Es bedeutet nicht, dass jede Variante jederzeit aktiv ist oder jede Funktion gleich gut unterstützt.

Der Ablauf lässt sich vereinfacht so lesen:

WingQ-Unterhaltung
       ↓
AgentBridge und Laufzeit-Zuordnung
       ↓
passender Harness → Modell und Werkzeuge
       ↓
Ereignisse, Antworten und Dateien zurück nach WingQ

Die gemeinsame Schnittstelle ist der stabile Teil. Die Besonderheiten des jeweiligen Harnesses bleiben im Adapter.

Warum Fortschritt genauso wichtig ist wie die Antwort

Bei einem längeren Arbeitsauftrag reicht mir eine abschließende Textnachricht nicht. Ich möchte erkennen, ob etwas läuft, ob eine Rückfrage ansteht und ob ein Werkzeug tatsächlich erfolgreich war.

Dafür werden Laufzeitereignisse in ein gemeinsames Format gebracht. WingQ kann Fortschritt anzeigen, ohne jede interne Implementierung des Harnesses kennen zu müssen. Auch Unterläufe lassen sich in der Kommunikation sichtbar machen.

Ein Abbruch bleibt allerdings eine Fähigkeit mit Grenzen. Die gemeinsame Schnittstelle beschreibt ihn ausdrücklich als bestmöglichen Versuch. Eine Oberfläche kann nicht garantieren, dass ein fremder Prozess jede Arbeit sofort unterbricht. Diese Unterschiede sollten sichtbar bleiben.

Dateien gehören zum Gespräch

Ein Agentenlauf liefert oft mehr als Text: ein Bild, einen Entwurf oder ein Dokument. Deshalb gibt es in meinem System einen laufzeitunabhängigen Weg, Dateien einer WingQ-Unterhaltung zuzuordnen.

Das Ergebnis muss damit nicht ausschließlich in einem Terminalpfad oder einem eigenen Chat des Harnesses liegen. Es kann dort auftauchen, wo der Auftrag besprochen wird. Für mich ist diese Verbindung von Kommunikation und Artefakten einer der wichtigsten Vorteile.

Dabei darf eine gemeinsame Oberfläche nicht versehentlich alle Daten vermischen. Zuordnung, Sitzung und Zugriffsrechte gehören zur Datei genauso wie zur Nachricht.

Mehr als ein Fenster für Agenten

WingQ enthält außerdem klassische Chats, Gruppen und Channels, Mail sowie Meetings und Sprache. Dadurch können Aufgaben näher an dem Ort entstehen, an dem die zugehörige Kommunikation bereits stattfindet.

Ein typischer Anwendungsfall ist eine Mail, aus der ein nächster Arbeitsschritt hervorgeht: zusammenfassen, einen Antwortentwurf vorbereiten oder Informationen für ein Dokument zusammentragen. Der konkrete Agent braucht dafür passende Werkzeuge und Rechte. Die gemeinsame Oberfläche allein erledigt diese Integration noch nicht.

Auch Sprache ist ein eigener Weg in dieselbe Arbeitsumgebung. Die Voice-Pipe verarbeitet Audio und führt es in den Agentenablauf; die Einzelheiten beschreibe ich im Voice-Beitrag.

Was eine Zentrale nicht automatisch löst

Ein einheitlicher Chat bedeutet nicht, dass sich laufende Sitzungen beliebig zwischen Harnesses übertragen lassen. Verläufe, Werkzeugzustände und interne Speicher können unterschiedlich aufgebaut sein. Eine Zuordnung zur Laufzeit ist deshalb mehr als ein kosmetischer Schalter.

Auch Fehlermeldungen müssen erhalten bleiben. Wenn ein Harness keine bestimmte Funktion unterstützt, darf die Oberfläche keinen erfolgreichen Ablauf suggerieren. Die gemeinsame Kommunikation soll Unterschiede verständlich machen.

Schließlich entsteht zusätzliche Software, die gepflegt werden muss: Adapter, Ereignisübersetzung und Sitzungssynchronisation. Das lohnt sich für meinen Aufbau mit mehreren Laufzeiten. Für einen einzelnen, einfachen Chat wäre es viel Infrastruktur.

Was ich durch WingQ gewinne

Ich kann Harnesses weiterentwickeln und austauschen, während mein Kommunikationsort bestehen bleibt. Claude-basierte Abläufe, OpenCode und mein eigener NexClaw müssen nicht gegeneinander antreten, um als einziges Werkzeug übrig zu bleiben.

Für mich ist WingQ damit die Verbindung zwischen Gespräch und Arbeit: einen Auftrag formulieren, seinen Verlauf verstehen und das Ergebnis wiederfinden. Welche Laufzeit darunter am besten passt, kann ich je nach Aufgabe entscheiden.