Puste okno czatu to kiepskie miejsce do prowadzenia consequential work. Składa pięć bardzo różnych pytań, czego chcesz, na co patrzysz, na czym to się opiera, co wolno ci zrobić i co już się wydarzyło, w jeden niezróżnicowany strumień. Dla zadań luźnych to wystarcza. Dla governowanych operacji, gdzie działania dotykają systems of record, a decyzje muszą być obronne, takie złożenie jest dokładnie tym, na co nie można sobie pozwolić.
Workspace Threada jest celowo rozłożony na pięć surfaces. Każda odpowiada na jedno z tych pytań, a utrzymywanie ich osobno sprawia, że praca nadaje się do review.
1. Intent bar: czego chcesz?
Praca w Threada zaczyna się od trwałego intent bar, a nie od głębokiej nawigacji. Opisujesz wynik w języku naturalnym, opcjonalnie ze strukturyzowanymi komendami, a runtime zamienia to w ustrukturyzowany, wykonywalny artifact: WorkItem z wyodrębnionymi entities, confidence score i risk flags.
To interakcja intent-first. Zamiast wymuszać na operatorze znajomość formularza, kolejki i workflow zanim zacznie, system przechwytuje cel i składa ścieżkę. Gdy brakuje informacji, pyta dokładnie o to, czego potrzebuje, zamiast pokazywać długi statyczny wizard z góry.
2. Adaptive canvas: nad czym pracujesz?
Canvas jest miejscem, gdzie WorkItem żyje i nabiera kształtu. Jest adaptacyjny: UI może składać tymczasowe formularze, porównania i panele decyzji, aby zebrać brakujący kontekst i zakończyć zadanie, zamiast renderować jeden stały layout dla każdego typu pracy.
Wygenerowany wynik domyślnie jest edytowalnym szkicem, a nie zatwierdzoną zmianą. Operator reviewuje, edytuje i decyduje. Controls są jawne, strefy lock i no-change, porównanie side-by-side, szybkie undo i version rollback, aby canvas był miejscem namysłu, a nie miejscem, gdzie pierwsza odpowiedź modelu staje się prawdą.
3. Evidence drawer: na czym to jest oparte?
Każdy consequential output powinien móc pokazać swoją pracę. Evidence drawer trzyma cytacje, retrieval traces i source attribution, które gruntują WorkItem. Gdy system nie może ugruntować odpowiedzi, mówi to wprost z fallback reason, zamiast wymyślać pewność.
To surface, która zmienia “trust the AI” w twierdzenie możliwe do inspekcji, a nie skok wiary. Operator nie musi wierzyć szkicowi; może otworzyć drawer i sprawdzić, na czym stał, jak świeże były źródła i skąd pochodzi każda teza.
4. Action controls: co możesz zrobić?
Czytanie i szkicowanie są bezpieczne. Działanie na świecie nie jest, więc controls surface jest governowana. To tutaj propozycje stają się zatwierdzeniami, a zatwierdzenia wykonanymi działaniami przeciw systemom zewnętrznym: refund, ticket, aktualizacja rekordu, access grant.
Governance jest tu wyrażone jako polityka, permissions, thresholds, approval gates i redlines, a nie rozrzucone przełączniki ustawień. Działania wysokiego ryzyka przechodzą przez jawną progresję proposed, approved, executing i auto-execute tylko tam, gdzie pozwala polityka. Kill switch na poziomie usługi może zatrzymać wykonanie przed wywołaniem connectora, zachowując stan do review. Controls surface to miejsce, gdzie ostrożność systemu staje się konkretna.
5. Run log: co się wydarzyło?
Run log jest timeline WorkItem: każda zmiana, każda akceptacja, każde działanie, każde zdarzenie AI participant, po kolei. To surface, gdzie receipts składają się w historię.
Kluczowe jest to, że działania AI pojawiają się jako osobne actor events, a nie są zwinięte w aktywność człowieka. Czytając run log, widać, kto zaproponował, kto zatwierdził i co wykonano, człowiek czy agent, bez zgadywania. Run log jest tym, co auditor czyta na koniec kwartału i tym, co operator czyta dziś, aby zrozumieć case przed sobą.
Dlaczego podział jest sednem
Łatwiej byłoby zbudować jedną surface i pozwolić wszystkiemu się zlać. Powód, by tego nie robić, jest taki, że consequential work wymaga rozdzielenia tych pytań.
Jeśli intent, evidence i action dzielą jedną surface, łatwo zadziałać na czymś, czego nigdy nie ugruntowano, albo zatwierdzić coś, czego podstawy nigdy nie widziano. Dając każdemu własną surface, Threada czyni ostrożną ścieżkę naturalną: nazwij intencję, ukształtuj szkic na canvas, sprawdź evidence, a potem działaj przez governowane controls, z run logiem zapisującym całość.
Pięć surfaces pozostaje stałych między packami i rolami; zmienia się to, co je wypełnia. Ta stabilność jest celowa. Operator, który nauczy się kształtu jednego workspace, zna kształt wszystkich, niezależnie od tego, czy prowadzi IT access provisioning, vendor security review czy procurement approval. Praca się zmienia. Sposób rozumowania o niej nie.