Immaginiamo un team con quaranta conversazioni aperte. In una, qualcuno chiede a un agente di preparare una proposta per un cliente. In un’altra, una collega chiede una stima di consegna. Una terza persona verifica se la stessa funzione può uscire questo mese.
Ogni conversazione comincia con una spiegazione. Questo è il cliente. Questo è ciò che abbiamo promesso. Questa è la decisione di ieri. Gli agenti iniziano a lavorare, ma ciascuno vede una parte diversa. Alla fine qualcuno nota che la proposta promette una data già esclusa nella discussione tecnica.
Poi un’attività finisce. La sua conversazione tace. Una settimana dopo, un’altra persona comincia un lavoro collegato e spiega di nuovo il contesto.
Costruendo i nostri agenti, tornavamo spesso a questa scena. Volevamo che il lavoro successivo partisse da quanto il team aveva già imparato. Questo ci ha portati a un progetto a sessione unica: una conversazione principale persistente, con Worker indipendenti che svolgono le singole attività.
I sottoagenti aiutano a dividere il lavoro. La sessione unica risponde a un’altra domanda: dove resta la comprensione di quel lavoro nel tempo? Usiamo entrambi. La conversazione principale dà continuità al team; i Worker danno a ogni lavoro uno spazio per procedere.
Una persona, un canale, un team
Poke ha dato all’agente personale una sede semplice: una persona, una conversazione (settembre 2025). Collegava e-mail, calendario e file di una persona a una conversazione testuale. La richiesta di una bozza o di spostare una riunione poteva iniziare nello stesso posto della precedente. La conversazione diventava così un luogo a cui tornare durante la giornata. Il rapporto personale era al centro dell’esperienza e ci mostrava concretamente la continuità tra lavori diversi.
Claude Tag ha portato un Claude in un canale (23 giugno 2026). Chiunque fosse nel canale poteva menzionare lo stesso agente, vederne il lavoro e riprendere da dove si era fermato un collega. Claude ricordava informazioni pertinenti e usava gli strumenti abilitati dagli amministratori. Il lancio descriveva anche l’apprendimento da altri canali e fonti, quando consentito. Ci interessava la conversazione condivisa: si poteva delegare dove già si discuteva il lavoro. Il nostro progetto usa la conversazione principale del team come punto di ritorno per discussioni e attività diverse.
Abbiamo scelto di esplorare un team, una conversazione. L’ambito segue il lavoro del team tra le discussioni. Una decisione sulla consegna può orientare la proposta, anche se i due lavori sono iniziati in luoghi diversi.
Il 28 aprile 2026 abbiamo pubblicato il primo articolo su Bridge, il nostro prodotto precedente. Questa parte della nostra esplorazione viene dopo Poke e prima di Claude Tag. Abbiamo proseguito nel prodotto attuale, Comma (1 ottobre 2026), dove questo progetto funziona oggi.
DeepSeek Harness ha presentato un’altra esplorazione il 31 ottobre 2026: Super-agent. Il suo lavoro proattivo nelle chat di gruppo segue la stessa direzione: trasferire il coordinamento dalle persone al sistema. Il prototipo di ricerca segue un progetto proprio.
L’articolo di progettazione di DeepSeek, §8.4, lascia aperte due questioni: compromissioni del cloud o iniezioni di prompt che espongono i dispositivi collegati, e credenziali che trapelano dal contesto del modello. La nostra risposta già in funzione per i contenuti è IFC: dichiarare le fonti, verificare i lettori della destinazione, rifiutare invii non consentiti e richiedere un’autorizzazione umana circoscritta quando serve.
Le credenziali seguono un percorso distinto. Il modello indica un riferimento; il livello di esecuzione ne risolve e inserisce il valore senza restituirlo al modello.
Ciò che il team porta avanti
Una nuova collega entra nel lavoro sulla proposta. Si unisce alla stessa conversazione principale usata dal resto del team. Può vedere le decisioni condivise, chiedere perché una data è cambiata e proseguire senza richiedere tre riassunti a tre persone. L’appartenenza allo spazio di lavoro dà accesso alla conversazione; i materiali alla base delle decisioni mantengono i propri permessi.
Un’attività conclusa conserva risultato e cronologia. Il team può aver scoperto che un cliente richiede un formato di esportazione insolito. Il rapporto torna al Router e una proposta successiva può richiamare la scoperta e la fonte. L’attività è finita, ma il team ha ancora un posto dove ritrovare ciò che ha imparato.
Il lavoro parallelo rende importante questo ritorno. Un Worker può leggere i requisiti del cliente mentre un altro indaga un limite tecnico. Se le scoperte arrivano attraverso una catena di racconti, una precisazione importante può scomparire. Ogni attività riporta i risultati insieme alla fonte. Il Router li riceve nello stesso contesto principale.
Questo ci ha dato un motivo per dividere l’harness in due ruoli. Uno segue la conversazione continua del team. Gli altri svolgono i singoli lavori.
Come Router e Worker si dividono il lavoro
Assegniamo a ogni spazio di lavoro un Router residente. Mantiene il contesto principale del team e segue richieste, cambiamenti nelle decisioni e risultati. Una richiesta sulla proposta arriva nello stesso contesto della discussione sulla consegna già in corso. Ogni messaggio in ingresso porta l’identità della conversazione e del messaggio di origine. Il Router condivide il contesto tra discussioni e conserva la provenienza di ciascun ingresso.
Il Router affida a un Worker un lavoro definito. Ogni attività apre una nuova sessione Worker con istruzioni e passaggio di consegne. Le cronologie degli altri Worker rimangono nelle rispettive sessioni. Più Worker possono indagare domande distinte contemporaneamente.
Definiamo ogni attività con un obiettivo, il contesto necessario e un risultato atteso. «Indaga questo cliente» lascia troppo implicito. «Verifica i requisiti di esportazione e proponi un formato, con fonti e domande aperte» dà al Worker un lavoro che può concludere e al Router un risultato utilizzabile.
Supponiamo che la proposta richieda sia la verifica del formato sia una stima di consegna. Possiamo affidarle a Worker distinti. Uno restituisce i requisiti del cliente. L’altro restituisce una stima e le relative ipotesi. Il Router riporta i risultati nella conversazione principale, dove il team può decidere. Il lavoro concluso ha una strada per tornare.
Ogni risposta visibile richiede un invio esplicito, anche nella conversazione principale. Il Router indica la destinazione e ne supera i controlli. L’output del modello e la fine di un turno non pubblicano una risposta. La regola vale anche quando un Worker riferisce un risultato o si rivolge a un altro partecipante. Leggere materiali fornisce contesto per l’attività; l’invio resta un’azione separata.
Controllo del flusso informativo
Le attività parallele riuniscono fonti con pubblici diversi. Ogni invio dichiara le fonti usate. Il controllo del flusso informativo, o IFC, verifica se i lettori della destinazione possono leggere quelle fonti.
Con l’applicazione dei controlli attiva, un invio rifiutato restituisce un motivo. L’agente può rimuovere il materiale riservato e riprovare, oppure ottenere l’approvazione umana richiesta per quell’ambito. Il nuovo tentativo deve correggere sia il contenuto sia le dichiarazioni delle fonti.
IFC offre al team un passaggio verificabile tra la preparazione di una risposta e la sua condivisione.
Tornando alla proposta, il Router può presentare la stima al team, chiedere la decisione ancora aperta e inviare la risposta concordata nel canale appropriato. Il lavoro del Worker ha confini definiti. La conversazione del team continua attraverso il passaggio di consegne.
Una nuova attività apre una nuova sessione Worker. Quando cambiamo sessione, trasferiamo il lavoro incompiuto e i suoi riferimenti alla successiva. Il team deve poter tornare alle decisioni precedenti.
Ciò che il team impara insieme
Le procedure riutilizzabili diventano skill condivise dal gruppo: istruzioni e risorse modificabili. L’agente creatore controlla le modifiche effettuate dagli agenti. Gli altri possono usare la skill senza riscriverla; una skill integrata in sola lettura può essere copiata e personalizzata. Le sessioni ricevono il catalogo del proprio ambito e aprono le istruzioni pertinenti.
Il Router mantiene memoria duratura di persone, ambienti, fatti generali ed episodi datati. La legge o la cerca quando serve. I Worker ordinari lavorano dai passaggi di consegne delle attività; i Triage Worker assegnati hanno accesso in lettura legato alla fonte. La scrittura della memoria spetta al Router.
Quando abilitato, Condensed Workspace dà a tutte le sessioni interne di Router e Worker lo stesso breve elenco di fatti attuali del gruppo. Il proprietario dello spazio di lavoro può modificarlo direttamente.
Gli aggiornamenti degli agenti ricevono un controllo consultivo: sono fatti attuali utili agli altri agenti? Revisioni e ultimo autore vengono registrati. Il proprietario può correggere o eliminare affermazioni, rendendo visibili e modificabili le ipotesi condivise. Un aggiornamento rifiutato può essere ritentato con il suo ID di rifiuto come deroga esplicita.
Il costo di una conversazione continua
Questa organizzazione mette sotto pressione la sessione principale. I Worker possono lavorare in parallelo, ma il Router deve comunque riunire i risultati. Una richiesta può arrivare mentre ne gestisce una precedente. Per le persone è una coda, qualunque sia il numero di Worker disponibili.
Stiamo ancora lavorando sulle code seriali. Delegare un’indagine lunga lascia al Router più spazio per rispondere, ma le decisioni collegate richiedono un ordine. Nella proposta, qualcuno deve fissare la data di consegna prima della promessa finale. Una conversazione condivisa rende più visibile questa dipendenza e dà al Router maggiore responsabilità nel far avanzare il lavoro.
Anche la cronologia ha un costo. Ogni attività conclusa aggiunge qualcosa che potrebbe servire in futuro, insieme a molto che non servirà più. Con la crescita della cronologia, trovare la decisione giusta e le sue ragioni richiede più lavoro.
Vogliamo ritrovare una vecchia decisione senza chiedere a un collega di ricostruire tutta la discussione. Le sue ragioni aiutano il team a capire quando va cambiata.
A questo punto è arrivata la nostra esplorazione. Abbiamo scelto una conversazione principale condivisa perché i team tornano sullo stesso lavoro attraverso persone e attività diverse. Quando qualcuno apre una discussione collegata, vogliamo che lo sforzo precedente del team sia ancora lì.
