Vogliamo che Orkas sia la base su cui funziona un'azienda AI-native. Da questo obiettivo nasce subito una domanda: come collaborano più persone e più agenti sullo stesso progetto?
La risposta è parecchio diversa dal lavoro di squadra a cui siamo abituati. Per capire perché, conviene partire da come è nata la collaborazione tra persone. (Per la guida passo passo al prodotto, leggi Progetti condivisi: come persone e agenti AI lavorano insieme in Orkas. Questo articolo racconta il ragionamento che c'è dietro.)
La collaborazione tra persone è cresciuta attorno a due limiti umani
Primo, le persone hanno banda e memoria limitate. Possiamo assorbire solo una certa quantità di informazioni alla volta, e ricordarne solo una parte. Per questo i team devono comunicare di continuo: condividere aggiornamenti, allinearsi sugli obiettivi, allinearsi sui progressi. Riunioni settimanali, stand-up, report giornalieri e settimanali, “ci sentiamo un attimo?”, “allineiamoci”: tutto questo serve a compensare quel limite.
Secondo, molto deve avvenire faccia a faccia. Di persona i canali sono più delle sole parole: linguaggio del corpo, tono ed espressioni trasmettono tutti informazioni. Quando qualcuno dall'altra parte del tavolo dice “il piano mi sembra a posto”, senti se lo pensa davvero. Altrettanto importante, incontrarsi di persona crea fiducia. Ecco perché tanti team da remoto si ritrovano ancora di persona ogni tanto.
Cosa cambia quando arrivano gli agenti
In un team di persone e agenti, il lato umano della collaborazione conta ancora. Ma lavorare con gli agenti è molto diverso dal lavorare con le persone. Gli agenti hanno tre punti di forza evidenti e tre debolezze evidenti.
Tre punti di forza
Banda ampia ed esecuzione solida. Vale soprattutto per i compiti con obiettivi chiari e misurabili. E i compiti che gli agenti riescono a portare a termine diventano in fretta più lunghi, più difficili e più complessi. Presentando il proprio agente di programmazione, Meta riporta un compito di ottimizzazione di kernel GPU in cui l'agente ha lavorato fino a 24 ore ed effettuato più di 1.000 chiamate a strumenti (Meta). A ottobre 2026 Linus Torvalds ha pubblicato una serie di patch per il kernel Linux in cui codice, programmi di test e prima bozza del messaggio di commit erano stati scritti da Claude Code; le misurazioni le ha eseguite lui, sulla propria macchina (LWN).
Le conoscenze e gli strumenti del mondo, da un capo all'altro e attraverso più discipline. Il pre-addestramento ha già condensato nel modello le conoscenze del mondo. Con gli strumenti giusti, un agente può portare un lavoro dall'inizio alla fine attraversando più discipline: scrivere il PRD → progettare → sviluppare → testare → rilasciare. Quando lo stesso lavoro lo fanno le persone, servono prodotto, design, sviluppo e QA che lavorano insieme, con un nuovo giro di allineamento a ogni passaggio di consegne.
Poche debolezze umane, e nessuna fiducia da costruire prima. Un agente non si stanca, non ha giornate storte e non si vergogna di fare una domanda banale. Un nuovo agente può iniziare non appena ha il contesto del progetto. Niente periodo di rodaggio, nessun rapporto da costruire prima.
Tre debolezze
Ha bisogno di un contesto pulito. Un contesto sbagliato lo manda fuori strada. Ci è successo in prima persona: un campo della nostra dashboard di analytics diceva che i dati “non si possono collegare”, mentre in realtà si poteva; era il campo stesso a essere calcolato male. Due agenti diversi hanno letto quella riga, ed entrambi hanno abbandonato un'intera analisi del percorso utente. Una persona, davanti a quella conclusione, chiederebbe: “È ancora valido?”. Un agente di solito la prende per buona.
È debole nell'attribuire le cause sul lungo periodo. Quando più variabili influenzano il risultato nello stesso momento, dà facilmente la colpa a quella sbagliata, e le persone devono correggerlo. Per un periodo, alcune nuove pagine del nostro sito non venivano indicizzate da Google. Un agente ha concluso che “il sito non ha abbastanza autorevolezza, quindi Google non gli dedica crawl budget” e ha consigliato di puntare prima sui backlink. Abbiamo obiettato e verificato: la stragrande maggioranza delle pagine del sito era già indicizzata. Le poche che non lo erano sembravano piuttosto argomenti troppo lontani dai temi del sito. Il crawl budget non c'entrava nulla, e costruire backlink sarebbe stata la mossa sbagliata.
Si adatta male a un ambiente che cambia, soprattutto quando il cambiamento non è nei suoi dati di pre-addestramento. Un sito appena ridisegnato, una regola di piattaforma appena cambiata, un prodotto lanciato il mese scorso: una persona nota che “qui è cambiato qualcosa” e cambia approccio. Un agente spesso continua a basarsi su ciò che già sa e riprova la stessa cosa più e più volte.
Perché le app di chat non vanno bene
Le app di chat sono state pensate per persone che lavorano con altre persone: i messaggi scorrono uno dopo l'altro, @menzioni e conferme di lettura tengono tutti allineati, e le informazioni sono sparse tra i canali. Questo design compensa esattamente i due limiti visti sopra. Le persone hanno poca banda e memoria corta, quindi continuiamo a scrivere e continuiamo ad allinearci.
Per gli agenti è la forma sbagliata:
- Chiacchiere, discussioni strada facendo e piani poi abbandonati sono, per un agente, solo rumore di contesto.
- Un agente non ha bisogno di costruire fiducia conversando.
- Ciò di cui un agente ha davvero bisogno è un contesto pulito e un compito chiaro.
Per questo la collaborazione tra persone e agenti va ripensata. E man mano che gli agenti diventano più capaci, anche il nostro modo di collaborare continuerà a cambiare. In Orkas ci stiamo ancora lavorando.
Cosa fa Orkas: mantenere ciò che non è cambiato, ripensare ciò che è cambiato
Il nostro approccio è mantenere le parti della collaborazione che non sono cambiate e ripensare quelle che sono cambiate. Qui sotto c'è un progetto condiviso in Orkas; le quattro idee corrispondono alle quattro aree evidenziate.
1. Assegnare, passare di mano e rivedere il lavoro: Da fare
Esisteva molto prima degli agenti, e ne abbiamo ancora bisogno. Per ora, ogni compito nei nostri progetti ha un responsabile umano, ed è una persona a rispondere del risultato finale.
Nel prodotto funziona così. Ogni voce da fare viene assegnata a una persona, ed è lei a decidere quale agente svolge il lavoro. Solo il responsabile può avviare la voce; l'agente gira sul computer del responsabile, con il suo modello e i suoi crediti. Quando ha finito, l'agente sposta la voce in In attesa di conferma invece di segnarla da sé come completata. La voce è chiusa solo dopo che il responsabile l'ha controllata ed eventualmente modificata.
2. Condividere obiettivi, informazioni di base e contesto: Obiettivi e regole, Memoria
Qui persone e agenti condividono lo stesso contesto, così i fatti chiave restano allineati.
Le schede Obiettivi e regole e Memoria di un progetto sono condivise da tutte le conversazioni di questo progetto, e gli agenti le seguono ogni volta. Per esempio, inserisci in Obiettivi e regole una definizione come “retention mensile = nuovi utenti che tornano il mese successivo”, e registra le decisioni chiave nella memoria del progetto. Quando entrano un nuovo membro e i suoi agenti, fin dal primo giorno leggono esattamente le stesse cose.
3. Passarsi il lavoro tramite file, tenere separato il processo
La Biblioteca del progetto si sincronizza tra i membri, e una voce da fare può portare con sé qualsiasi file come allegato. Il lavoro si passa sotto forma di file, non di cronologia della chat.
Teniamo volutamente separata gran parte del processo intermedio, perché non diventi rumore di contesto dannoso per gli agenti. Le schede bloccate Attività e Automazione appartengono solo a te. Un agente può fare centinaia di passaggi e provare tre approcci prima di produrre un solo report. Il tuo collega riceve solo il report; il processo resta nelle tue attività e non finisce mai nel contesto dei suoi agenti.
4. Condividere gli agenti privati con il team
I membri possono condividere i propri agenti privati perché li usi il resto del team. Questi agenti portano con sé l'esperienza del loro proprietario e il suo giudizio sulla qualità. Condividerli rende tutti più veloci, e i problemi che emergono usandoli si possono correggere con l'autoevoluzione, alzando ciò che l'intero progetto è in grado di fare.
Quando un agente viene condiviso, Orkas ne impacchetta le istruzioni di lavoro e le abilità, comprese quelle che ha sviluppato da solo lavorando. La sua memoria e la cronologia delle chat non sono incluse. Quando chi l'ha condiviso aggiorna l'agente, i membri ricevono automaticamente la nuova versione.
Un problema aperto, ancora agli inizi
La collaborazione tra persone e agenti è ancora in una fase molto iniziale, e le risposte non sono ancora convergenti. Con il miglioramento dei modelli, buona parte di ciò che serve agli agenti per collaborare passerà nei modelli stessi.
Alcuni modelli lo fanno già in modo nativo: eseguono più sottoagenti in parallelo per esplorare un problema da angolazioni diverse, oppure prima pianificano e poi affidano l'esecuzione del piano a dei sottoagenti. Muse Spark Open, che Meta ha rilasciato con pesi aperti a ottobre 2026, è descritto come addestrato a scomporre il lavoro, affidarlo a sottoagenti e coordinarli (blog di PyTorch).
Quindi il nostro modo di collaborare cambierà man mano che i modelli migliorano. Le cose da fare, il contesto condiviso, il passaggio tramite file e gli agenti condivisi sono la nostra risposta a ciò che i modelli sanno fare oggi, non la forma definitiva.
In conclusione
Abbiamo mantenuto ciò che non è cambiato: qualcuno è responsabile del lavoro, qualcuno lo rivede, e obiettivi e contesto restano allineati. Abbiamo ripensato ciò che è cambiato: passarsi il lavoro tramite file, tenere separato il processo e trasformare l'esperienza e il gusto di ciascuno in agenti che il team può usare.
Stiamo ancora esplorando, e ci farebbe piacere confrontarci. Se guidi un team in cui persone e agenti lavorano insieme, provalo prima su un solo progetto. Orkas si può scaricare gratis per macOS e Windows.