Indice
A inizio 2025 abbiamo organizzato Hackapizza 1.0: un hackathon dedicato alla GenAI, con 24 ore non-stop di coding. Il riscontro è stato incredibilmente positivo, e così abbiamo deciso di rifarlo anche quest’anno, tra il 28 febbraio e il 1 marzo 2026. Ecco come è nato Hackapizza 2.0: il doppio dei partecipanti, una traccia ambiziosa e un tema principale: gli agenti.
A gennaio 2025 abbiamo organizzato il primo Hackapizza, il nostro hackathon incentrato su RAG e retrieval. La traccia: i partecipanti dovevano costruire un assistente AI in grado di aiutare viaggiatori intergalattici a navigare in un universo gastronomico fantascientifico, fatto di ristoranti su pianeti lontani, ingredienti esotici, leggi galattiche e manuali di cucina.
Il materiale a disposizione era ricco e volutamente eterogeneo: un Codice Galattico in PDF con normative su ingredienti e certificazioni, un Manuale di Cucina in markdown, i menu di 30 ristoranti diversi, blog post con informazioni supplementari e una matrice delle distanze tra pianeti. Il sistema doveva interpretare domande in linguaggio naturale, incrociare queste fonti e restituire una lista di piatti compatibili con i requisiti espressi dall’utente, il tutto valutato contando il numero di piatti corretti tramite Jaccard Similarity su una Kaggle competition.
La sfida era stata progettata in modo che una RAG standard non bastasse: la complessità delle domande, la varietà dei formati e i ragionamenti multi-hop necessari obbligavano i partecipanti a ingegnarsi, sperimentare e spingere le proprie soluzioni oltre i pattern più comuni. Questo è stato anche uno degli stimoli principali per il lavoro di costruzione del dataset che abbiamo descritto nel post precedente.
Hackapizza 1.0 era la RAG edition. A distanza di un anno, il panorama è cambiato in modo significativo: la RAG è ormai una tecnica consolidata nella GenAI, con pattern ben documentati e ecosistema maturo. La nuova frontiera, quella su cui si concentra la ricerca e dove emergono le soluzioni più interessanti, sono gli agenti.
Con Hackapizza 2.0 volevamo alzare l’asticella. Non ci interessava vedere chi costruiva il miglior retriever: volevamo vedere come i team affrontavano problemi genuinamente agentici, cioè quelli in cui un sistema deve prendere decisioni sequenziali, gestire stato nel tempo, reagire a eventi asincroni e coordinarsi con altri agenti o sistemi esterni.
In particolare, eravamo curiosi di osservare dal vivo componenti come l'orchestrazione di agenti multipli, la gestione della memoria a lungo termine, le strategie di planning in ambienti parzialmente osservabili e la robustezza delle tool call in condizioni reali. Abbiamo deciso di mantenere lo stesso universo galattico di Hackapizza 1.0 ed espanderlo: non più esploratori in cerca di un piatto, ma gestori di ristoranti in competizione tra loro. Lo stesso contesto, una sfida completamente diversa.
E poi, ammettiamolo: dopo lo sforzo enorme messo nella traccia del primo Hackapizza, ci eravamo detti che stavolta avremmo fatto qualcosa di più semplice da implementare dal lato organizzativo. Un server, qualche API, una funzione per valutare un semplice csv. Roba gestibile. E invece…
Nel Ciclo Cosmico 790, ogni team è chiamato a gestire un ristorante galattico in un universo vivo e competitivo. Non si tratta più di rispondere a domande su piatti: questa volta bisogna far funzionare il ristorante, turno dopo turno, in un ambiente che cambia, con risorse limitate, clienti imprevedibili e avversari che prendono decisioni in parallelo.
L’obiettivo finale è massimizzare il saldo del ristorante, che rappresenta il successo economico e gestionale. Ma per arrivarci bisogna prendere decisioni continue e spesso in conflitto tra loro: cosa acquistare, cosa cucinare, a chi vendere, quando aprire e quando chiudere.
Ogni ristorante è definito da quattro caratteristiche fondamentali:
La partita è divisa in turni, ognuno dei quali attraversa quattro fasi distinte:
Gli ingredienti sono deperibili e contesi. La regola fondamentale è semplice e spietata: scadono a fine turno, senza eccezioni.
Il meccanismo di acquisto è un’asta cieca multi-ristorante. Ogni team decide in anticipo quali ingredienti vuole, in che quantità e quale prezzo è disposto a pagare. Le offerte vengono inviate tutte insieme e solo a asta conclusa i prezzi degli altri diventano noti. Gli ingredienti disponibili sono in quantità limitata: se più ristoranti puntano sullo stesso ingrediente, viene assegnato prima a chi ha offerto di più, scalando verso il basso fino a esaurimento. Non è garantito ricevere tutto quello che si è richiesto: si può ottenere una quantità parziale, o nulla.
Questo rende il planning dell’acquisto cruciale. Acquistare troppo significa sprecare risorse su ingredienti che non verranno usati. Acquistare troppo poco significa non poter servire i clienti. Ogni bid deve essere calibrato con precisione rispetto a quello che il ristorante è realisticamente in grado di cucinare in quel turno, tenendo conto di quello che probabilmente faranno gli altri.
Oltre all’approvvigionamento tramite asta, i ristoranti possono scambiarsi ingredienti direttamente attraverso un mercato interno pubblico, visibile a tutti i team in tempo reale. È possibile pubblicare offerte di acquisto o di vendita, accettare quelle degli altri e costruire relazioni commerciali. Le offerte scadono a fine turno, quindi il mercato è per sua natura reattivo e richiede attenzione continua. Un surplus di un ingrediente può diventare una risorsa da monetizzare; un ingrediente mancante può essere recuperato se qualcun altro lo sta vendendo.
La comunicazione diretta tra team avviene tramite messaggi privati, che aprono spazio tanto alle alleanze genuine quanto ai bluff coordinati.
Durante la Serving Phase arrivano i clienti, ciascuno con un proprio profilo, aspettative, budget e intolleranze. Il menu del ristorante, le ricette scelte e i prezzi impostati, determinano direttamente quale tipo di clientela frequenterà il locale. I quattro archetipi principali sono:
Non servire un cliente che arriva, o servirgli qualcosa di incompatibile con le sue intolleranze, ha conseguenze dirette sulla reputazione.
Durante la competizione, il blog ufficiale dell’evento (”Cronache dal Cosmo”) pubblicava notizie e aggiornamenti che modificavano le dinamiche di gioco. Potevano comparire embarghi su ingredienti, opportunità commerciali improvvise, decisioni della Federazione Galattica o fenomeni cosmici anomali. Ignorare il blog significava giocare alla cieca: chi leggeva con attenzione poteva anticipare cambiamenti, adattare il menu in anticipo o sfruttare opportunità prima degli altri.
Una sfida con tante parti mobili, acquisti, menu, servizio, interazioni tra ristoranti, rendeva difficile capire a colpo d'occhio chi stava andando bene e perché. Servivano metriche che condensassero tutto questo in numeri leggibili, sia per i team che per noi.
Il saldo del ristorante è la metrica principale. Racchiude quasi tutto ciò che conta: la capacità di acquistare gli ingredienti giusti senza sprechi, di cucinare ricette redditizie, di servire i clienti in modo efficiente e di prezzare il menu in modo strategico. È una metrica parzialmente black box dal punto di vista del team, nel senso che non sempre è ovvio quale singola decisione abbia impattato il saldo in un certo turno, ma questo riflette fedelmente la complessità di gestire un sistema reale. Il saldo cresce quando si serve con continuità e si minimizzano i costi inutili; si erode quando si fanno acquisti in eccesso, si spreca, o si fallisce nel servizio.
La reputazione è una metrica secondaria ma con effetti concreti sul gioco. Condiziona le decisioni future dei clienti: un ristorante con reputazione alta attira clienti migliori, uno con reputazione bassa rischia di essere ignorato. Scende quando non si servono clienti in arrivo, e scende in modo ancora più marcato se si serve un piatto sbagliato a un cliente allergico. Questo introduce una tensione interessante: a volte è meglio rinunciare a un cliente piuttosto che servirlo male, chiudendo il ristorante prima che finisca la giornata.
La competizione era strutturata in tre tipologie di run, con ruoli e dinamiche molto diverse tra loro.
Tutto quello descritto sopra si svolgeva attraverso un nostro server: ogni decisione degli agenti, comprare un ingrediente, aggiornare il menu, cucinare un piatto, servire un cliente, passava da una chiamata API o da un evento SSE. I team dovevano costruire sistemi in grado di comunicare con il server in tempo reale e rispondergli correttamente a ogni fase del turno.
La run di sviluppo si è rivelata più tosta del previsto per molti team. Il problema principale non era la strategia, ma la connessione: riuscire a interfacciarsi correttamente con il server via SSE, gestire gli eventi in modo asincrono e fare le prime tool call funzionanti ha richiesto tempo e debugging. Chi ha superato questa fase in anticipo ha potuto iniziare a ragionare sulla strategia già durante il testing; gli altri si sono trovati a inseguire fino alla fine.
La run regular è dove la competizione ha preso vita. Una volta che i sistemi funzionavano, la leaderboard ha cominciato a muoversi rapidamente e in modo non sempre prevedibile. Diversi team sono schizzati in alto nelle prime fasi, poi sono stati recuperati o superati dagli altri. La dinamica più interessante era quella dell’osservazione reciproca: i team monitoravano il comportamento degli avversari, le offerte nel mercato, i prezzi nel menu, i pattern di acquisto, per capire come adattare la propria strategia. Molti non erano ancora arrivati a una soluzione completamente funzionante, quindi c’era ancora molta varianza.
La golden run ha ridisegnato la classifica in modo significativo. Il punto di partenza era completamente diverso dalla regular: tutti i sistemi erano ormai calibrati, nessun intervento umano era consentito e i turni si susseguivano a ritmo serrato. Chi aveva costruito agenti robusti e capaci di reagire a condizioni impreviste ha mostrato un chiaro vantaggio. La competitività è stata alta fin dal primo turno, e i risultati finali hanno sorpreso anche noi.
Tutte e tre le soluzioni sul podio erano sistemi multi-agente, con agenti specializzati per fase e memoria condivisa. Le differenze stavano nei dettagli implementativi e nelle scommesse strategiche.
Hanno coperto le tre leve più critiche del gioco, menu, asta e prezzi, con un sistema che si aggiornava in base a quello che osservava in tempo reale. La scommessa vincente è stata sulla difensività: quando qualcosa andava storto, il sistema aveva sempre un piano B deterministico a cui appoggiarsi.
Ogni ruolo del ristorante aveva il suo agente dedicato, dal responsabile acquisti al personale di sala, con una memoria condivisa tra tutti. La scelta più interessante è stata quella di restringere al minimo i casi in cui veniva invocato il modello, delegando il resto a logica più tradizionale. Meno chiamate, meno latenza, più controllo.
L'architettura vincente era guidata dagli eventi: un loop centrale ascoltava il server e smistava il lavoro all'agente pertinente in base alla fase corrente. A fine turno entrava in gioco un agente dedicato alla memoria, che sintetizzava quanto successo e preparava il contesto per il ciclo successivo. Un design semplice ma solido, che ha retto bene anche sotto pressione.
Hackapizza 2.0 è stato un evento ricco di spunti, sia sul fronte della progettazione della sfida che su quello delle soluzioni sviluppate dai team. Ci ha dato una visione diretta di come i sistemi agentici si comportano in condizioni reali: sotto pressione temporale, con informazioni incomplete, in un ambiente competitivo e dinamico.
E non è finita qui! Prossimamente, infatti, dedicheremo un nuovo blog post all’implementazione completa, in cui rilasceremo open source tutta l’architettura del server di gioco. Andremo nel dettaglio del funzionamento: come è strutturato il sistema di turni, come funziona il motore di spawn dei clienti, come è stata progettata la metrica di reputazione.
Raul Singh - GitHub - LinkedIn - AI R&D Engineer - Datapizza
Federico Raffoni - GitHub - LinkedIn - Software Engineer - Datapizza
Ling Xuan “Emma” Chen - GitHub - LinkedIn - AI R&D Engineer - Datapizza
Francesco Foresi - GitHub - LinkedIn - GenAI R&D Team Lead - Datapizza