Una casella chat vuota è un pessimo posto per gestire lavoro importante. Collassa cinque domande molto diverse, cioè che cosa vuoi, che cosa stai guardando, su che cosa si basa, che cosa sei autorizzato a fare e che cosa è già accaduto, in un unico flusso indifferenziato. Per attività casuali va bene. Per operazioni governate, dove le azioni toccano sistemi di registrazione e le decisioni devono essere difendibili, quel collasso è esattamente ciò che non puoi permetterti.
Il workspace di Threada è deliberatamente scomposto in cinque superfici. Ciascuna risponde a una di quelle domande, e tenerle distinte è ciò che rende il lavoro revisionabile.
1. La barra dell’intento: che cosa vuoi?
Il lavoro in Threada parte da una barra dell’intento persistente invece che da una navigazione profonda. Descrivi l’esito in linguaggio naturale, facoltativamente con comandi strutturati, e il runtime lo trasforma in un artefatto strutturato ed eseguibile: un WorkItem con entità estratte, punteggio di confidenza e flag di rischio.
Questa è interazione intent-first. Invece di costringere l’operatore a sapere quale modulo, quale coda e quale workflow servano prima di iniziare, il sistema cattura l’obiettivo e assembla il percorso. Quando manca informazione, chiede esattamente ciò che serve invece di presentare subito un lungo wizard statico.
2. Il canvas adattivo: su cosa stai lavorando?
Il canvas è dove vive e prende forma il WorkItem. È adattivo: la UI può assemblare moduli temporanei, confronti e pannelli decisionali per raccogliere il contesto mancante e completare l’attività, invece di renderizzare un layout fisso per ogni tipo di lavoro.
L’output generato parte come bozza modificabile, non come cambiamento già impegnato. L’operatore rivede, modifica e decide. Le affordance di controllo sono esplicite, con zone bloccate e senza cambiamento, confronto affiancato, undo rapido e rollback di versione, così il canvas è un posto per deliberare, non un posto dove la prima ipotesi del modello diventa verità.
3. Il drawer dell’evidenza: su cosa si basa?
Ogni output importante dovrebbe poter mostrare il proprio lavoro. Il drawer dell’evidenza contiene citazioni, tracce di recupero e attribuzione delle fonti che fondano il WorkItem. Quando il sistema non può fondare una risposta, lo dice esplicitamente con una ragione di fallback invece di inventare confidenza.
Questa è la superficie che rende “fidati dell’AI” un’affermazione ispezionabile invece che un salto di fede. Un operatore non deve credere a una bozza; può aprire il drawer e controllare su che cosa si reggeva, quanto erano fresche le fonti e da dove veniva ogni affermazione.
4. I controlli di azione: che cosa puoi fare?
Leggere e redigere è sicuro. Agire sul mondo non lo è, quindi la superficie dei controlli è governata. È dove le proposte diventano approvazioni e le approvazioni diventano azioni eseguite contro sistemi esterni: un rimborso, un ticket, un aggiornamento di record, una concessione di accesso.
Qui la governance si esprime come policy, cioè permessi, soglie, gate di approvazione e redline, non come toggle sparsi di impostazioni. Le azioni ad alto rischio attraversano una progressione esplicita proposta, approvata, in esecuzione, e si auto-eseguono solo dove una policy lo consente. Un kill switch a livello di servizio può fermare l’esecuzione prima che venga chiamato qualunque connettore, preservando lo stato per revisione. La superficie dei controlli è dove la cautela del sistema diventa concreta.
5. Il run log: che cosa è successo?
Il run log è la timeline del WorkItem: ogni transizione, ogni approvazione, ogni azione, ogni evento di partecipante AI, in ordine. È la superficie dove i receipt si accumulano in storia.
In modo cruciale, le azioni AI appaiono come eventi attore distinti, non fuse nell’attività umana. Quando leggi il run log puoi sapere chi ha proposto, chi ha approvato e che cosa è stato eseguito, umano o agente, senza indovinare. Il run log è ciò che un auditor legge a fine trimestre e ciò che un operatore legge per capire il caso davanti a sé oggi.
Perché la separazione è il punto
Sarebbe più semplice costruire una sola superficie e lasciare che tutto si confonda. La ragione per non farlo è che il lavoro importante richiede di tenere separate queste domande.
Se intento, evidenza e azione condividono una superficie, diventa facile agire su qualcosa che non hai mai fondato, o approvare qualcosa di cui non hai mai visto la base. Dando a ciascuna una superficie propria, Threada rende il percorso attento quello naturale: dichiara l’intento, modella la bozza sul canvas, controlla l’evidenza, poi agisci attraverso controlli governati, con il run log che registra tutto.
Le cinque superfici restano costanti attraverso pack e ruoli; ciò che le riempie si adatta. Questa stabilità è intenzionale. Un operatore che impara la forma di un workspace ha imparato la forma di tutti, che stia gestendo provisioning di accesso IT, una revisione di sicurezza fornitore o un’approvazione procurement. Il lavoro cambia. Il modo in cui ci ragioni no.