Quando Si Ferma?
Qualcuno compra un panino al prosciutto al bar.
Modelli senza vincolo d’azione:
15+ entità, 10+ eventi. Senza aver toccato fornitore del pane, frigo, dipendenti, turni.
Non c’è un punto di stop naturale. Si ferma quando definisci l’azione che il modello deve supportare.
Stessa realtà, granularità diversa
Azione: “Posso vendere panini oggi?”
Serve:
- Prosciutto → disponibile: sì/no
- Quantità → number
Stop. Non serve il fornitore.
Azione: “Perché finiamo il prosciutto troppo presto?”
Serve:
- Ordini → quando, quanto
- Consumo → vendite per giorno
- Sprechi → quanto buttato
- Fornitore → affidabilità
Non serve il cliente singolo. Il cliente è aggregato in “consumo giornaliero”.
Azione: “Questo fornitore è affidabile?”
Serve:
- Fornitore → entity
- Ordini storici → events
- Ritardi → metrics
Non serve il panino, il magazzino, il cliente.
Tre azioni sullo stesso dominio. Tre proiezioni diverse della stessa ontologia.
L’azione determina il confine.
La regola
Se aggiungere un’informazione non cambia una decisione, è rumore.
La maggior parte dei sistemi raccoglie dati. Pochissimi migliorano le decisioni.
La differenza è una domanda:
Quale azione cambia questa informazione?
Se nessuna, il sistema sta crescendo ma non sta pensando.
La dashboard che non decide
Un’azienda traccia centinaia di metriche. Revenue, churn, conversion rate, NPS, cohort analysis.
Il fatturato cala.
La decisione viene presa da tre persone in una stanza, con le stesse informazioni che avevano prima della dashboard.
La dashboard non ha cambiato la decisione. Ha solo fatto sembrare il sistema analitico.
Questo succede ovunque: ERP, data warehouse, AI analytics, agenti. Sistemi che accumulano informazioni senza migliorare azioni.
L’errore
Modellare per entità (fornitore, prodotto, cliente). Per processi (acquisto, vendita, magazzino). Per reparti (economato, vendita, amministrazione).
Il problema: le decisioni non emergono da questa decomposizione. Hai struttura senza azione. Aggiungi entità perché “potrebbero servire”.
Risultato: sistemi che descrivono la realtà in dettaglio crescente, senza cambiare nessuna decisione.
Agenti per decisione
Un agente unico su tutto il dominio ha lo stesso problema: deve context-switchare tra azioni incoerenti. L’ontologia esplode perché deve supportare tutte le decisioni alla massima granularità.
Un agente per vertical. Ogni vertical = un cluster di decisioni coerenti.
Agente Acquisti:
- Fornitore completo, ordine completo
- Decisioni: “questo fornitore è affidabile?”, “quando ordinare?”
Agente Vendite:
- Prodotto (solo: disponibile sì/no, quantità)
- Decisioni: “posso vendere oggi?”, “consumo anomalo?”
Agente Finance:
- Ledger, Banca, Budget. Niente Prodotto.
- Decisioni: “riconcilia movimenti banca vs ledger”, “varianza budget vs actual”
L’agente acquisti non sa quanto vendi oggi. L’agente vendite non sa chi è il fornitore. Ognuno porta la proiezione sufficiente per le sue decisioni.
Alcune decisioni attraversano vertical. Riconciliazione banca, controllo margini, forecasting cashflow. Agenti cross-vertical. Non è un errore. È fisiologico.
Ontologia core condivisa — un layer semantico che definisce vincoli e consistenza. Ogni agente accede alla proiezione che serve. L’intelligenza è distribuita: vive nel layer condiviso e negli agenti.
Stesso debito, layer diverso
La regola vale anche per gli agenti.
Quale decisione migliora se aggiungo questo agente?
Un agente che elimina trascrizione manuale di documenti. Decisione specifica, friction rimosso.
Poi la tentazione: previsioni, sentiment analysis, dashboard analytics, auto-ordering. Ognuno sposta il friction point. Non stai più risolvendo il problema originale. Stai mantenendo il sistema che lo risolve.
Logging, retry, idempotenza: baseline. Non costruire sistemi complessi per failure che non hai osservato.
La maggior parte dei sistemi parte dalle entità.
Prodotto. Cliente. Fornitore.
Crescono finché ogni dettaglio del business è rappresentato.
Poi falliscono nell’unica cosa che conta: decidere.
Perché il sistema è stato costruito per descrivere la realtà. Non per cambiare azioni.
La regola è più semplice:
Parti dall’azione. Modella solo quello che la cambia.
Tutto il resto è decorazione.