Ein leeres Chat-Feld ist ein schlechter Ort, um folgenreiche Arbeit auszuführen. Es presst fünf sehr unterschiedliche Fragen —was wollen Sie, was betrachten Sie, worauf beruht es, was dürfen Sie tun und was ist bereits geschehen— in einen einzigen undifferenzierten Strom. Für beiläufige Aufgaben ist das in Ordnung. Für gesteuerte Vorgänge, bei denen Aktionen Systeme of Record berühren und Entscheidungen verteidigbar sein müssen, ist genau dieser Zusammenfall das, was Sie sich nicht leisten können.
Der Arbeitsbereich von Threada ist bewusst in fünf Oberflächen zerlegt. Jede beantwortet eine dieser Fragen, und sie getrennt zu halten ist das, was die Arbeit überprüfbar macht.
1. Die Intentionsleiste: Was wollen Sie?
Arbeit in Threada beginnt an einer beständigen Intentionsleiste statt durch tiefe Navigation. Sie formulieren das Ergebnis in natürlicher Sprache, optional mit strukturierten Befehlen, und das Runtime verwandelt es in ein strukturiertes, ausführbares Artefakt: ein WorkItem mit extrahierten Entitäten, einem Konfidenzwert und Risikomarkierungen.
Dies ist eine intentionsorientierte Interaktion. Statt den Operator zu zwingen, vor dem Beginn zu wissen, welches Formular, welche Warteschlange und welcher Workflow gilt, erfasst das System das Ziel und stellt den Weg zusammen. Wenn Informationen fehlen, fragt es genau nach dem, was es benötigt, anstatt vorab einen langen statischen Assistenten anzuzeigen.
2. Das adaptive Canvas: Woran arbeiten Sie?
Das Canvas ist der Ort, an dem das WorkItem lebt und Gestalt annimmt. Es ist adaptiv: Die Oberfläche kann temporäre Formulare, Vergleiche und Entscheidungspanels zusammenstellen, um fehlenden Kontext zu sammeln und die Aufgabe abzuschließen, statt für jede Art von Arbeit ein festes Layout darzustellen.
Erzeugte Ausgaben sind standardmäßig ein bearbeitbarer Entwurf, keine festgeschriebene Änderung. Der Operator prüft, bearbeitet und entscheidet. Die Steuerungs-Affordances sind explizit —Sperr- und Nicht-Ändern-Zonen, Vergleich nebeneinander, schnelles Rückgängigmachen und Versions-Rollback— sodass das Canvas ein Ort zum Abwägen ist und kein Ort, an dem die erste Vermutung des Modells zur Wahrheit wird.
3. Die Belegschublade: Worauf beruht es?
Jede folgenreiche Ausgabe sollte ihre Herleitung zeigen können. Die Belegschublade enthält die Zitate, Abrufspuren und Quellenzuordnung, die das WorkItem fundieren. Wenn das System eine Antwort nicht fundieren kann, sagt es das ausdrücklich mit einem Rückfallgrund, statt Konfidenz zu erfinden.
Dies ist die Oberfläche, die „der KI vertrauen” zu einer überprüfbaren Behauptung statt zu einem Vertrauenssprung macht. Ein Operator muss einem Entwurf nicht glauben; er kann die Schublade öffnen und prüfen, worauf er beruhte, wie aktuell die Quellen waren und woher jede Behauptung stammte.
4. Die Aktionssteuerung: Was dürfen Sie tun?
Lesen und Entwerfen ist sicher. Auf die Welt einzuwirken ist es nicht —daher ist die Steuerungsoberfläche gesteuert. Hier werden Vorschläge zu Genehmigungen und Genehmigungen zu ausgeführten Aktionen gegen externe Systeme: eine Erstattung, ein Ticket, eine Datensatzaktualisierung, eine Zugriffsgewährung.
Governance wird hier als Richtlinie ausgedrückt —Berechtigungen, Schwellenwerte, Genehmigungstore und Redlines— nicht als verstreute Einstellungsschalter. Hochrisiko-Aktionen durchlaufen einen expliziten Verlauf von vorgeschlagen, genehmigt, in Ausführung, und führen sich nur dort automatisch aus, wo eine Richtlinie es erlaubt. Ein Kill-Switch auf Service-Ebene kann die Ausführung anhalten, bevor irgendein Konnektor aufgerufen wird, und bewahrt dabei den Zustand zur Überprüfung. Die Steuerungsoberfläche ist der Ort, an dem die Vorsicht des Systems konkret wird.
5. Das Ausführungsprotokoll: Was ist geschehen?
Das Ausführungsprotokoll ist die Zeitleiste des WorkItems: jeder Übergang, jede Genehmigung, jede Aktion, jedes KI-Teilnehmerereignis, der Reihe nach. Es ist die Oberfläche, auf der sich Belege zu Historie ansammeln.
Entscheidend ist, dass KI-Aktionen als eigenständige Akteursereignisse erscheinen, nicht in menschliche Aktivität eingefaltet. Wenn Sie das Ausführungsprotokoll lesen, können Sie erkennen, wer vorgeschlagen, wer genehmigt und was ausgeführt hat —Mensch oder Agent— ohne zu raten. Das Ausführungsprotokoll ist das, was ein Prüfer am Ende des Quartals liest, und das, was ein Operator liest, um den Fall vor sich heute zu verstehen.
Warum die Aufteilung der Kern ist
Es wäre einfacher, eine einzige Oberfläche zu bauen und alles verschwimmen zu lassen. Der Grund, es nicht zu tun, ist, dass folgenreiche Arbeit verlangt, dass Sie diese Fragen getrennt halten.
Wenn Intention, Belege und Aktion sich eine Oberfläche teilen, wird es leicht, auf etwas einzuwirken, das Sie nie fundiert haben, oder etwas zu genehmigen, dessen Grundlage Sie nie gesehen haben. Indem Threada jeder ihre eigene Oberfläche gibt, macht es den sorgfältigen Weg zum natürlichen: die Intention formulieren, den Entwurf auf dem Canvas gestalten, die Belege prüfen und dann über gesteuerte Steuerungen handeln —wobei das Ausführungsprotokoll all das festhält.
Die fünf Oberflächen bleiben über Packs und Rollen hinweg konstant; was sie füllt, passt sich an. Diese Stabilität ist beabsichtigt. Ein Operator, der die Form eines Arbeitsbereichs lernt, hat die Form aller gelernt, ob er nun eine IT-Zugriffsbereitstellung, eine Sicherheitsprüfung eines Anbieters oder eine Beschaffungsgenehmigung durchführt. Die Arbeit ändert sich. Die Art, wie Sie über sie nachdenken, nicht.