Ho smesso di costruire agenti AI. Sto costruendo organizzazioni.

In breve. Per un anno ho costruito agenti AI sempre più bravi: prompt migliori, modelli migliori, contesti più ricchi. Poi ho messo tre-quattro agenti insieme in un'app vera, Arvo, e ho scoperto che il problema non era quanto erano bravi. Era che non avevano un'organizzazione: nessuno sapeva chi faceva cosa né come passarsi il lavoro. Da lì ho smesso di costruire agenti e ho iniziato a costruire organizzazioni. È la storia di un cambio di unità di misura, vissuta su un caso solo: prendetela come prova di esistenza, non come statistica. La tattica completa, con organigramma e handoff, è nella guida dedicata. Pubblicato il 3 ottobre 2026.

La credenza: bastava un agente davvero bravo

La mia teoria era confortevole: se ogni agente è abbastanza intelligente, la collaborazione emerge da sola. Passavo le settimane a migliorare il singolo: istruzioni più precise, esempi migliori, il modello più capace disponibile. E in demo funzionava sempre. Un agente bravo in demo sembra la promessa di un team bravo in produzione.

Mi sono accorto che era un errore di unità di misura quando in Arvo, la mia app di personal training, ho affiancato i primi agenti specialistici. Ognuno faceva bene il suo pezzo. Insieme facevano confusione: attese incrociate, lavoro rifatto due volte, e io in mezzo a fare da centralino umano. Il problema non era la bravura dei singoli. Era che stavo costruendo solisti e mi serviva un'orchestra senza aver scritto né spartiti né ruoli.

Cosa si è rotto passando da uno a tre-quattro

Con un agente solo tutto sembra semplice: un obiettivo, un contesto, un risultato. Con tre o quattro nascono problemi che sono gli stessi di un'organizzazione umana: chi fa cosa, come ci si passa il lavoro, chi controlla che il passaggio sia riuscito. È lo stesso muro che descrivo dal lato tecnico nella guida: oltre una certa soglia lo stato condiviso improvvisato implode e servono passaggi di consegne formali.

Qui secondo me la domanda interessante non è tecnica. È: perché mi aspettavo che funzionasse senza? Perché venivo da anni in cui l'unità di costruzione del software era la funzione, il modulo, il servizio: pezzi che si incastrano. Gli agenti non si incastrano. Si coordinano, oppure no. E il coordinamento non emerge dalla bravura: si disegna, come un organigramma.

Il caso Arvo: ruoli, non geni

In Arvo oggi le decisioni chiave passano da agenti specializzati: uno calcola la progressione set per set, uno sceglie gli esercizi in base ad attrezzatura e schemi, uno genera gli allenamenti dallo storico. Condividono una classe base astratta, ognuno ha un ruolo con input e output chiari, e girano su GPT-5-mini, un modello piccolo. Il principio scritto nel progetto è semplice: usare gli agenti per le decisioni, ridurre al minimo la logica hardcoded.

La cosa che non avevo capito all'inizio è che la parte importante non sono i singoli agenti, che pure funzionano. È la frase "ridurre al minimo la logica hardcoded": significa che il comportamento del sistema sta nei ruoli e nei passaggi, non nel codice che ho scritto io. Quando ho dovuto cambiare come veniva scelto un esercizio, non ho riscritto un agente bravo. Ho ridisegnato un passaggio. Costa meno, si verifica meglio, e soprattutto sopravvive al cambio del modello sotto: i ruoli restano, il motore si sostituisce.

Pensavo che il problema fosse trovare il modello giusto per ogni compito. Mi sono accorto che il problema era disegnare compiti che restano giusti anche quando il modello cambia.

Cosa ho smesso di fare

Ho smesso di valutare gli agenti uno per uno in demo. Ho smesso di scrivere logica di coordinamento hardcoded che solo io capisco. Ho smesso di chiedermi "quanto è bravo" e ho iniziato a chiedermi tre cose: il ruolo ha confini chiari? Il passaggio di consegne è formale e verificabile? Se spengo un agente e ne accendo un altro, il sistema regge?

È la stessa disciplina che applico alla fabbrica che ripara il software di notte e ai controlli progettati: un posto di guida alla volta, verdetti esterni, registro. L'organizzazione degli agenti e il controllo del loop sono due facce dello stesso disegno.

Cosa non prometto

Non prometto che basti disegnare un organigramma per far funzionare N agenti qualsiasi, né so dire quale sia il numero oltre cui serve un disegno diverso: la mia evidence arriva a una manciata di ruoli su un'app reale. E resta aperta la domanda se il disegno dell'organizzazione conti più della scelta del modello: la mia esperienza dice di sì, ma è una hypothesis, e sarà il tema di un prossimo articolo. Per ora, una prova di esistenza: ho smesso di costruire agenti bravi, ho costruito un'organizzazione piccola, e quella regge.

Domande frequenti

Quanti agenti servono prima di pensare all'organizzazione?

Nella mia esperienza il muro arriva tra tre e quattro. Sotto, la coordinazione improvvisata regge. Sopra, servono ruoli e handoff formali.

Devo usare un modello potente per ogni ruolo?

No, ed è uno dei vantaggi: con ruoli chiari e contesti piccoli, in Arvo i ruoli girano su un modello mini. La bravura sta nel disegno, non nella taglia del motore.

Da dove parto se ho un solo agente?

Non serve un organigramma subito. Serve una regola: ogni volta che aggiungi un agente, scrivi il suo ruolo e come riceve e consegna il lavoro. Al terzo, hai già un'organizzazione senza essertene accorto.