Improve and Manage: articoli su ERP, agenti AI e organizzazione

L'ingresso della serie sugli agenti AI: che cosa distingue un agente dal software che conoscete, e da dove viene l'idea. Che cosa ci si guadagna, a che cosa stare attenti, e la mappa per orientarsi negli altri articoli.

Un agente non è un modello di linguaggio con un nome più ambizioso: è un modello circondato da quattro pezzi che decidono se funziona. Cosa fa ognuno, cosa sa fare davvero un agente e in quali casi conviene non costruirne uno.

Il modello capisce e produce testo. Tutto il resto - governare il ciclo, dare gli strumenti, costruire il contesto, ricordare, presidiare la sicurezza, registrare e misurare - lo fa lo strato che gli sta intorno. È lì che un agente riesce o fallisce, ed è la parte di cui si parla di meno.

Le otto forme che si trovano elencate in giro non sono otto alternative. Quattro sono topologie fra cui si sceglie, le altre sono controlli che si sovrappongono a qualunque topologia: distinguerle è metà della decisione.

Per anni ogni integrazione fra un agente AI e i sistemi aziendali è stata un progetto a sé. Poi, in meno di due anni, due protocolli si sono consolidati: MCP per parlare con gli strumenti, A2A per parlare fra agenti. Cosa sono, chi li governa, e come si misura la loro maturità: MCP lo espongono perfino gli ERP, A2A per ora lo mettono a catalogo.

La voce che pesa non è l'hardware, ma il numero di chiamate: un agente interroga il modello molte volte per un solo compito. Ogni chiamata rispedisce tutto quello che si sono detti fino a lì. Come si forma il costo, dove cresce da solo, e quali tre leve lo riducono davvero.

Un modello di linguaggio si compra in tre modi - a servizio, su macchine a noleggio, su macchine proprie - e si paga in un'unità nuova, il token. Le dieci decisioni della serie nell'ordine delle tre domande di chi firma: quanto costerà davvero, come si sceglie il fornitore, come ci si tutela. Per ognuna, la domanda da fare e il pezzo che spiega il perché.

Ci sono due modi per far fare qualcosa a un calcolatore: scrivergli le regole, o fargliele imparare dagli esempi. La seconda idea ha una data di nascita precisa e tre padri documentati: la macchina-bambina di Turing (1950), la congettura di Dartmouth (1955) e la dama di Samuel (1959) - con le citazioni verificate sugli originali, compresa quella famosa che nell'originale non c'è. Il primo pezzo della serie che arriva fino ai modelli di linguaggio.

Nel luglio del 1958 la Marina americana mostrò ai giornali un calcolatore che imparava da solo, e il New York Times promise una macchina cosciente. Dentro il clamore c'era un congegno preciso e piccolo: il percettrone di Frank Rosenblatt. Com'è fatto, la regola con cui impara, il teorema che ne garantisce la riuscita a una condizione - e il muro esatto, quattro punti senza retta, che fermò l'intero campo per un decennio.

Il percettrone si era fermato davanti a quattro punti che nessuna retta separa. Bastano tre percettroni impilati per superarli - e la tabella si rifà a mano in questa pagina. Poi le domande vere: perché serve una curva al posto del gradino, come si ripartisce l'errore sui pesi nascosti (la retropropagazione, con la storia giusta), la garanzia di Cybenko, i guai del mestiere - e il confronto misurato sugli stessi dati del percettrone.

Il token è l'unità con cui un modello legge, scrive e fa i conti - e chi decide dove finisce un token è il tokenizzatore. Il pezzo mette a duello due vocabolari - uno addestrato sui Promessi sposi, uno dei modelli di OpenAI - confronta le ricette in uso oggi e misura quanto l'italiano paghi in token più dell'inglese.

L'identificativo di un token è un indirizzo; l'embedding è la riga che quell'indirizzo seleziona in una matrice appresa. Da Bengio 2003 alla geometria di word2vec, fino a nanoGPT che somma l'embedding del token a quello della posizione - mentre il problema delle dipendenze lontane resta aperto e conduce al meccanismo dell'attenzione.

I vettori che entrano nel modello sanno quale token rappresentano e dove si trova, ma ognuno è ancora solo. L'attenzione li mette in relazione: domanda, chiave e valore, la softmax che pesa, la maschera causale e le teste multiple - il meccanismo che ha sostituito la ricorrenza nei modelli di linguaggio, e il prezzo quadratico che si porta dietro.

I pezzi sono già sul tavolo: l'embedding, l'attenzione, la softmax. Questo pezzo li monta, seguendo le trecento righe di nanoGPT: il blocco che alterna attenzione e MLP, le connessioni residue che tengono in piedi la pila, la testa d'uscita e la softmax che producono le probabilità del prossimo token, e la generazione, un token alla volta.

Il costo quadratico del pezzo sull'attenzione ha due risposte: la miscela di esperti e la cache di chiavi e valori. La prima riduce il calcolo per token attivandone pochi su tanti; la seconda il motore la riempie durante la generazione, per non rifare tutto da capo. Con i casi documentati di DeepSeek e Qwen - e la distinzione fra pesi, motore e addestramento.

La serie ha aperto la macchina e i suoi trucchi: ora la mappa dei modelli veri. Le tre forme del Transformer, il denso contro il misto, e la differenza decisiva per chi legge: DeepSeek, Qwen e GLM documentano l'architettura, GPT e Claude no. Come leggere la scheda di un modello sapendo che cosa può dire e che cosa tace.

La stessa architettura può produrre modelli molto diversi: il carattere arriva dall'addestramento. Le quattro fasi - preaddestramento, istruzione, rinforzo da preferenze umane, rinforzo con ricompense verificabili - e la svolta dei modelli di ragionamento, nati dall'ultima. Con l'avvertenza di casa: il dibattito sull'emergenza è aperto, e si dichiara.

Il bilancio del pezzo sulle evoluzioni ha separato tre livelli: architettura, motore, addestramento. Questo pezzo apre il motore: llama.cpp, vLLM, MLX, DwarfStar e gli altri, che cosa fanno e come si dividono i compiti - e la novità che sta cambiando il quadro, i pesi che arrivano dal disco invece che dalla memoria, con i vantaggi e i limiti di ogni approccio.

Il primo dei sei errori che affondano i progetti ERP: requisiti raccolti solo dai vertici, perimetro che si allarga senza governo, scadenze decise prima dei fatti. Quanto costa quando succede, e la forma concreta del rimedio.

Il secondo dei sei errori che affondano i progetti ERP: comprare sul prezzo iniziale. Le voci del costo totale di possesso una per una, la leva delle personalizzazioni, e il costo che nessuno mette a preventivo: quello di uscita.

Il terzo dei sei errori che affondano i progetti ERP: considerare i dati un trasloco. Cosa si migra e cosa no, la traduzione fra due modelli che non si somigliano, la strategia di passaggio, e la quadratura firmata che dice se è andata bene.

Il quarto dei sei errori che affondano i progetti ERP: aspettarsi che l'adozione sia spontanea. La sponsorship che ci mette la faccia, la regia tecnica della direzione IT, i key user col tempo prenotato, la resistenza letta come informazione, e la formazione sui casi propri.

Il quinto dei sei errori che affondano i progetti ERP: comprimere i test per tenere la data. Perché il ritardo di tutti finisce sempre sui test, il debito di collaudo che ne nasce, la catena dei test con una domanda per tipo, il piano che copre i cicli dell'azienda col suo pannello condiviso, e il criterio di uscita firmato.

L'ultimo dei sei errori che affondano i progetti ERP: smobilitare dopo il lancio. Il presidio rafforzato con un criterio per uscirne, il calendario delle prime volte, il passaggio dal progetto all'esercizio, e i numeri che dicono se il sistema vive.

Primo approfondimento della serie sugli errori nei progetti ERP: il governo della tecnologia, la regia interna che resta quando consulenti e fornitori se ne vanno. La conduzione, il filtro dei conflitti, i requisiti coperti, le interfacce, la conformità, l'AMS e il ciclo di vita.

Secondo approfondimento della serie sugli errori nei progetti ERP: quando conviene personalizzare il gestionale e quando no. La scala delle risposte a un bisogno, il core pulito che i produttori stessi impongono, le interfacce documentate che l'AI generativa rende convenienti, e la soluzione verticale per le modifiche che servono davvero.

Ogni azienda ha due modi di funzionare: quello scritto nelle procedure e quello che si impara guardando i colleghi. Il secondo comanda. Cosa dice davvero Edgar Schein sui tre livelli della cultura, dove nasce la resistenza che oggi frena l'adozione dell'AI, e la risposta alla domanda che conta: chi può cambiare una cultura, a quali condizioni, e da dove si comincia.

Un gruppo non ha sempre la stessa cultura: la costruisce per fasi. Ogni fase è governata da un presupposto dominante, cioè dalla convinzione che in quel momento tiene insieme tutti. Le quattro fasi di Schein, il bivio della maturità fra declino e reinvenzione, e il caso Netflix, dal noleggio per posta ai videogiochi.

La cultura non si governa a proclami: si governa nei punti dove prende forma. Schein li ha mappati - il fronte interno, i presupposti sul mondo, la missione tradotta in obiettivi, i mezzi, le misure, la correzione - e per ognuno questo pezzo porta un caso aziendale documentato, con le cifre verificate alla fonte: Toyota, Airbnb, Unilever, Zappos, ING, Patagonia.

Non esiste un solo modo giusto di guidare: è la tesi con cui Hersey e Blanchard, nel 1969, hanno fondato la leadership situazionale. La maturità di chi si guida ha due dimensioni, gli stili sono quattro, e il mestiere sta nel passare dall'uno all'altro seguendo la persona - coi limiti del modello in chiaro. L'ultimo pezzo della serie sulla cultura, dove le fasi del gruppo e gli stili di guida si specchiano.

In Europa usa l'intelligenza artificiale il 55% delle grandi imprese e il 17% delle piccole. È un divario più largo di quello che si osservò per il cloud e per l'analisi dei dati, e dice qualcosa di preciso su cosa manca davvero.

Il prezzo a token che pagate oggi non ripaga gli impianti che lo rendono possibile, e la via di fuga - ospitare il modello in casa - si chiude per la stessa ragione. Che cosa dicono i numeri sulla tenuta di questo mercato, e come si progetta sapendo che il prezzo può cambiare.