Prompt AI auto-miglioranti: il sistema con cui ottimizziamo gli agenti AI dei nostri clienti

Il prompt di un agente AI conversazionale non è mai finito. È una distribuzione di probabilità che sposta la media dei risultati, e quella media si può misurare, confrontare e migliorare sistematicamente — esattamente come si ottimizza un modello di machine learning.

Da qualche mese applichiamo questa idea agli agenti WhatsApp che costruiamo per i nostri clienti. Il sistema — ispirato al pattern Auto Research di Karpathy che avevamo già analizzato in dettaglio — lo abbiamo adattato a un problema radicalmente diverso dal machine learning: ottimizzare le istruzioni conversazionali di un agente AI che parla con persone reali su WhatsApp.

Il prodotto si chiama Ambra — il nostro agente per la riattivazione lead. Viene configurato e personalizzato per ogni cliente, e poi sottoposto a un ciclo di ottimizzazione automatica che, su tutti i clienti che lo usano, produce in media un +20-25% sullo score complessivo rispetto al prompt iniziale.

Di seguito come funziona il sistema, con i numeri reali di un caso rappresentativo: da 6.42 a 8.00, senza intervento umano tra un ciclo e l’altro.

Il problema: come misuri la qualità di una conversazione WhatsApp?

Ambra gestisce conversazioni su WhatsApp. Non risponde a domande tecniche o recupera dati da database — costruisce un rapporto con un lead, gestisce obiezioni, calibra il tono e spinge verso la prenotazione di un appuntamento. È un lavoro sottile, dove la differenza tra un agente efficace e uno mediocre si misura in sfumature: un messaggio troppo lungo, un tono troppo formale, una CTA troppo vaga.

Il problema è che le sfumature non si misurano facilmente. Come costruisci una metrica oggettiva per “suona naturale su WhatsApp”?

La risposta che abbiamo trovato è usare un LLM judge con una rubrica strutturata. Non un giudizio binario pass/fail — una valutazione su tre dimensioni con scale 0-10 e criteri espliciti per ogni livello.

Il peso maggiore sulla conversione non è casuale. Ambra ha un obiettivo primario: portare il lead a prenotare. Ma conversione senza chiarezza produce messaggi aggressivi che respingono. Conversione senza empatia produce messaggi robotici che non convertono. Le tre dimensioni si bilanciano a vicenda.

L’architettura del sistema

Il sistema è composto da tre pezzi fissi che non cambiano mai tra un esperimento e l’altro, più un elemento variabile che è esattamente quello che stiamo ottimizzando.

Fissi:

• 10 test case realistici — scenari rappresentativi delle conversazioni reali di Ambra: il lead entusiasta che poi scompare, il lead freddo e monosillabico, quello che ha già un fornitore, quello che chiede tempo, quello che risponde “non mi interessa” dopo due messaggi positivi. Costruiti sulla base di conversazioni reali, anonimizzate.
• Un LLM judge — Claude Sonnet con una rubrica dettagliata per ogni dimensione. La rubrica descrive cosa significa un 4, un 7, un 9 per conversion/clarity/empathy, così le valutazioni sono confrontabili tra esperimenti.
• La metrica aggregata — la formula pesata di cui sopra. È lo stesso numero che usiamo per confrontare baseline e challenger, decidere keep/discard, e costruire il log storico degli esperimenti.

Variabile:

• Il system prompt di Ambra — il file che l’agente legge per capire come comportarsi. È il “codice sorgente” della personalità e della strategia conversazionale. È l’unica cosa che cambia tra un esperimento e l’altro.

Per la simulazione delle risposte di Ambra usiamo Claude Haiku — economico, veloce, sufficiente per produrre variazioni realistiche nelle risposte. Sonnet è riservato al giudice, dove la qualità di valutazione ha impatto diretto sull’affidabilità degli esperimenti.

Il loop: come funziona in pratica

Il ciclo è quello del metodo scientifico, compresso in 5 passi che si ripetono in autonomia:

1. Ipotesi — l’agente sceglie una modifica da testare, selezionandola da un catalogo di idee prioritizzate: tono, strategia di conversione, gestione obiezioni, brevità, personalizzazione.
2. Modifica — edita il system prompt nel file ambra_system.md con la modifica scelta. Solo sezioni specifiche — la struttura generale rimane intatta.
3. Commit git — ogni esperimento ha il suo commit. Git funziona come memoria di stato: se il challener non batte il baseline, si fa git reset —hard HEAD~1 e si riparte dal migliore.
4. Valutazione — lo script genera le risposte di Ambra su tutti i 10 test case con Haiku, poi Sonnet giudica ognuna. Score aggregato in output.
5. Keep o discard — se il nuovo score supera il best_score corrente, si tiene il commit e si aggiorna il baseline. Altrimenti si scarta e si prova un’altra direzione.

L’analogia con l’ottimizzazione ML è precisa: il system prompt è il train.py, lo score complessivo è la validation loss, il loop è l’addestramento. La differenza è che invece di modificare pesi numerici, si modificano istruzioni in linguaggio naturale.

I risultati: cosa ha funzionato davvero

Il baseline di questo cliente era 6.42 (conversion 5.40 / clarity 8.00 / empathy 6.20). Un prompt già funzionante, scritto e raffinato a mano, con margini evidenti sulla conversione e sull’empatia — la situazione tipica con cui arriviamo al ciclo di ottimizzazione.

Tre modifiche hanno prodotto i salti più significativi:

Cosa impara il sistema che tu non vedresti mai

Il log degli esperimenti è, alla fine, più prezioso del prompt stesso. È una serie di ipotesi testate con esito documentato: cosa ha spostato l’ago, cosa non ha funzionato, perché. Questo log diventa un asset che accompagna il cliente: quando il business cambia e il prompt va riadattato, si riparte da un punto molto più avanzato.

Senza il loop automatico, queste modifiche si testano manualmente — una alla volta, con settimane di gap tra una versione e l’altra, senza una metrica che dica se è migliorato davvero o se si è solo confermato ciò che ci si aspettava. Fare questo su decine di clienti in parallelo sarebbe semplicemente impossibile. Il volume è il vantaggio: molti cicli autonomi per cliente, con un log strutturato, producono più conoscenza di mesi di ottimizzazione manuale episodica.

C’è però un limite che vale la pena nominare esplicitamente: le eval misurano quello che sai definire. Uno score 8.00 su conversion, clarity ed empathy non garantisce che Ambra stia costruendo relazioni autentiche o che stia operando in modo eticamente impeccabile in ogni scenario. Questi aspetti richiedono ancora supervisione umana — e probabilmente la richiederanno ancora a lungo.

L’optimizer sposta la media dei risultati misurabili. La responsabilità di definire cosa vale la pena misurare rimane umana.

Quando ha senso costruire un sistema del genere

Non ogni agente AI giustifica questo livello di infrastruttura. Il pattern ha senso quando:

• L’agente è in produzione su scala: se Ambra gestisce centinaia di conversazioni al giorno per un cliente, ogni punto di score complessivo si traduce in conversioni aggiuntive concrete. Il sistema si ripaga rapidamente, spesso con il primo cliente ottimizzato.
• Hai test case realistici e una rubrica solida: spazzatura entra, spazzatura esce. La qualità degli esperimenti dipende dalla qualità della metrica. Prima di costruire il loop, vale la pena passare del tempo a costruire test case rappresentativi e criteri di valutazione precisi.
• Il prompt è già funzionante ma vuoi il margine extra: questo non è uno strumento per trovare un prompt da zero. È uno strumento per ottimizzare un prompt che già funziona, estraendo il miglioramento che la scrittura manuale non riesce a raggiungere per mancanza di volume sperimentale.

Per chi lavora con agenti AI su processi aziendali critici, questo approccio — misurare prima di ottimizzare, testare prima di decidere — è la differenza tra credere che il proprio agente funzioni bene e saperlo.

Il pattern eval + loop automatico non è riservato ai grandi laboratori AI. Con strumenti accessibili e una metrica ben costruita, è applicabile a qualsiasi agente con un obiettivo misurabile. Ambra ne è la prova.