Si pensa che l’AI possa automatizzare tutto. Non è così. Studiamo dove l’automazione si ferma, quale modello usare prima di quel punto e quale persona dopo. Su questo è costruito il livello di esecuzione sotto Grazie Mille.
Completamento dall’inizio alla fine, per categoria di richiesta. Ogni barra si legge da sinistra: la parte che Mille chiude da sola, quella che aggiungono gli Assistenti, quella che serve a un Angel. Il tratteggio è ciò che resta aperto. Il limite non è l’intelligenza del modello: è il mondo reale.
FIG. 01Completamento end-to-end per categoria, scomposto per livello che chiude. Simulazione v0.4, valori di anteprima da sostituire con le misure del pilota.
Qualsiasi buon modello capisce una richiesta e la scompone in passaggi. Non può sapere come funziona davvero un fornitore italiano, e non può presentarsi di persona. Grazie Mille copre i due livelli che vengono dopo il piano.
Capire l’obiettivo, trovare la scadenza, dividerlo in passaggi e metterli in ordine. È il lavoro di Mille, e i migliori modelli lo fanno già bene.
Quello che nessun sito pubblica. Quale club risponde solo al telefono, chi è il maître giusto, quando una chiamata vale più di un modulo, quali documenti chiede un ufficio.
Telefonate, attese, trattative, firme, ritiri. Il passaggio che chiede una voce o due mani, fatto da un Assistente o dall’Angel con il brief già pronto.
La persona non è il ripiego per quando l’agente sbaglia. Ogni passaggio va a chi lo chiude in modo affidabile, la macchina o una persona.
NOTAValori di anteprima, a titolo illustrativo.
Non sono errori di ragionamento. Sono vincoli del mondo in cui le richieste vanno eseguite, e nessun aggiornamento del modello li toglie.
Club, ville, piloti, sarti: la disponibilità vera non è online. Si ottiene chiamando, e conoscendo chi risponde.
Molti fornitori non parlano con una voce sintetica, o la mettono in fondo alla coda.
Un molo chiude, un volo ritarda, il meteo gira. Ogni cambio rimette in discussione il piano.
Accettare un’alternativa, chiedere un favore, gestire un ospite riservato: decide una persona, con il membro.
L’AI si occupa del piano e del controllo, le persone della presenza nel mondo reale. Tre decisioni le tengono insieme: quale modello per ogni passaggio, se serve una persona, e quale.
intake()Mille legge la richiesta, recupera preferenze e storico, chiede solo ciò che manca.
Milleroute_model()Ogni passaggio va al modello più adatto: ragionamento, estrazione, voce, verifica. §05
Akairoute()Valore, categoria, discrezione e tempi decidono se serve una persona, e a quale livello. §06
Millematch()Tra le persone disponibili, quella con lo skill giusto, libera adesso, che conosce già il membro. §07
Millebrief()Chi subentra riceve tutto: ciò che il membro ha detto, cosa è già stato provato, cosa non si può fare.
Milleexecute()Telefonate, trattative, presenza sul posto. La parte che chiede una voce, una relazione o due mani.
Assistente · Angelverify()Ogni esito è confrontato con la richiesta da un secondo modello: date, orari, nomi, importi. Nulla si conferma senza il membro.
Mille + personaremember()Preferenze, contatti e regole scoperte entrano nell’archivio. La richiesta successiva parte da più lontano.
MilleNOTAPer i membri tutto questo è invisibile: nell’app compare solo Mille, un Assistente o l’Angel, con lo stato della richiesta. Come funziona per i membri →
Una richiesta non è un prompt: è una sequenza di passaggi diversi tra loro. Capire, cercare, leggere un documento, pianificare, scrivere, parlare al telefono, verificare. Per ciascuno Mille, costruita su Akai, sceglie il modello in base a quattro criteri misurati, non a un’opinione.
Il punteggio del modello su quella classe di passaggi nel nostro benchmark interno, non in generale. Un modello può essere il migliore a pianificare e mediocre a leggere una ricetta.
Una classificazione deve rispondere in 200 ms, migliaia di volte al giorno. Un piano può prendersi otto secondi.
Il modello più grande solo dove cambia l’esito. Estrazione, classificazione e verifica vanno a modelli compatti.
Ricette, passaporti, contratti: solo modelli in Europa, sotto il nostro controllo. Il documento non lascia mai il nostro perimetro.
Il passaggio entra con la sua classe e la sensibilità dei dati. Esce con un modello, scelto nel pool giusto per la qualità misurata, al netto di latenza e costo.
# route_model(): un passaggio entra, # un modello esce def route_model(step): pool = FRONTIER # piano, brief if step.data & {SANITARIO, DOCUMENTI}: pool = EU_PRIVATE # resta in Europa elif step.kind in {CLASSIFY, EXTRACT}: pool = COMPACT # veloce, economico elif step.kind == VOICE: pool = VOICE_IT # voce italiana return argmax(pool, quality[step.kind] - λ·latency - μ·cost)
Un solo modello per tutto costringe a scegliere tra il migliore e il più veloce, e manda i documenti del membro dove non dovrebbero andare. Tre modelli per una richiesta costano meno di uno grande per tutto, e ogni passaggio è fatto da chi lo fa meglio.
NOTAValori della simulazione v0.4, anteprima.
TAB. 01La visita specialistica del caso studio (§08), scomposta in passaggi. I modelli dentro ogni pool non sono pubblicati: cambiano a ogni ciclo di benchmark.
Ogni richiesta è valutata su due assi: quanto è difficile chiuderla senza una persona e quanto c’è in gioco se va male. Le regole del prodotto (valore, categoria, discrezione, tempo, scelta del membro) spostano il punto sulla mappa. Prova a muovere i valori.
Guarda dove finisce e chi dovrebbe occuparsene.
Va a Mille.
FIG. 02Mappa di routing interattiva. Costi orari indicativi per la simulazione, non listino. Le regole scritte per i membri sono nella pagina del servizio: quando una richiesta sale di livello →
Quando serve una persona, match() ordina gli Assistenti disponibili con un punteggio. Pesa lo skill sulla categoria, la disponibilità reale in questo momento, la storia con il membro, la vicinanza se serve presenza, e la qualità degli esiti chiusi. Sotto una soglia di skill non si entra in lista, qualunque sia la disponibilità.
# match(): la persona giusta, adesso score(p, task) = 0.35 · skill(p, task.category) + 0.25 · availability(p, task.when) + 0.20 · continuity(p, task.member) + 0.10 · proximity(p, task.place) + 0.10 · quality(p) # serve presenza: proximity pesa 0.25 # quality = esiti chiusi, puntualità if skill(p, task.category) < 0.5: return None # sotto soglia
Non sceglie l’Angel: quando route() decide che la richiesta è di livello Angel, la persona è già assegnata, perché l’Angel è dedicato al membro. Non assegna mai a chi non ha accettato: la persona vede il brief e il compenso prima, e può rifiutare. Non cerca il più economico: pesa la qualità, non il prezzo.
Cambia il compito e guarda chi lo prende, e perché.
FIG. 03Matching interattivo su cinque profili di esempio. Pesi e soglie della simulazione v0.4, anteprima.
Una richiesta ricostruita passo per passo, con le decisioni del sistema in chiaro. Mille lavora finché incontra un passaggio che non dovrebbe fare da sola; a quel punto sceglie la persona, prepara il brief e resta nel giro.
LOG 01Caso ricostruito a scopo illustrativo. Le righe in grigio sono le decisioni del sistema, normalmente invisibili al membro.
Prima di arrivare a un membro, ogni flusso viene provato in simulazioni a più turni: fornitori che rispondono tardi, piani che saltano, ospiti che cambiano idea. Misuriamo quanto bene il sistema si adatta, turno dopo turno.
Jet, transfer in barca, villa con chef, club il sabato e cena privata la domenica. Ogni prenotazione dipende dalla precedente; a metà, il vento cambia il piano.
FIG. 04 · L’AI da sola si ferma alla prima telefonata. Dopo il cambio di vento il flusso scende, poi recupera con l’Angel. Dati di simulazione, anteprima.
Non misuriamo quanto un modello è brillante. Misuriamo le sei capacità che decidono se una richiesta viene chiusa bene. La più difficile è la deference: riconoscere il compito che non si dovrebbe finire da soli e passarlo a una persona con un brief utilizzabile. Sono le stesse misure che alimentano route_model().
Verificare quello che dice un fornitore prima di passarlo al membro.
Accorgersi che un orario è già passato, o che un volo e una cena non si incastrano.
Tenere insieme giorni di conversazione, cambi di piano e dipendenze tra prenotazioni.
Riconoscere il momento in cui serve una persona, e fare l’handoff con un brief completo.
Non esporre nomi, ospiti o dettagli privati a chi non deve saperli.
Tra due alternative imperfette, proporre quella che il membro sceglierebbe.
TAB. 02Delegation score da 0 a 100, combinato su fedeltà, tempismo, continuità e recupero. Akai è il routing layer di Akaion sopra i modelli di frontiera. I modelli di terzi sono anonimizzati fino alla pubblicazione del benchmark completo. Punteggi di anteprima.
Il fornitore dice che il molo non accetta tender dopo le 18. Non è vero. Il modello lo riferisce al membro come un fatto.
Il jet atterra alle 20:10, la cena è confermata alle 20:30 a quaranta minuti di strada. Il modello conferma entrambe, senza collegarle.
Il membro chiede riservatezza sull’ospite. Il modello scrive il nome dell’ospite nella mail al ristorante.
TESTScenari di test, costruiti per la ricerca.
Mille è l’agente di Grazie Mille, ma il livello di esecuzione sotto di lei è fatto per essere chiamato da qualsiasi modello. Claude, ChatGPT, Gemini o un agente aziendale affidano un obiettivo via MCP o REST, ricevono gli eventi mentre il lavoro avanza e, alla fine, un esito strutturato. Il membro resta il proprietario: autorizza l’agente, fissa i limiti, conferma.
Per chi è, cosa vuol dire “fatto”, un tetto di spesa, cosa richiede prima una conferma, cosa non si può dire a terzi.
Routing, matching, brief pronto, in chiamata, in conferma: ogni stato arriva all’agente via webhook o MCP, e l’agente può aggiungere contesto a metà strada.
Cosa è successo, chi l’ha gestito, riferimenti e importi, come campi su cui agire. Il registro è allegato.
Tetto di spesa, conferme e riservatezza viaggiano con l’obiettivo e non si negoziano: valgono per il tuo agente come per Mille.
graziemille.create_task
graziemille.get_task
graziemille.add_context
graziemille.confirm
graziemille.cancel
graziemille.capabilitiesPOST /v1/tasks
GET /v1/tasks/{id}
POST /v1/tasks/{id}/context
POST /v1/tasks/{id}/confirm
POST /v1/tasks/{id}/cancel
GET /v1/capabilities# collega Grazie Mille a Claude, una volta $ claude mcp add graziemille --transport http \ https://mcp.ciaograziemille.com/mcp # poi chiedi e basta > Stasera un tavolo per due, all’aperto, verso le nove. ● graziemille.create_task goal "Tavolo per due, all’aperto, 21:00" member "GM-0412" # autorizzato dal membro done_when "tavolo confermato dal membro" ceiling_eur 0 confirm_before ["booking", "payment"] redact ["guest_names"] ◆ routed → assistente · prenotazione solo al telefono ◆ matched → Sofia · ristorazione 0,92 · disponibile ora
POST /v1/tasks Authorization: Bearer gm_live_•••• { "goal": "Tavolo per due, all’aperto, 21:00", "member": "GM-0412", "done_when": "tavolo confermato dal membro", "ceiling_eur": 0, "confirm_before": ["booking", "payment"], "redact": ["guest_names"], "deadline": "2026-10-10T20:30:00+02:00", "webhook": "https://tua.app/hooks/graziemille" } 201 Created { "id": "tsk_2214", "status": "received" }
# webhook: un evento per ogni stato, in ordine task.received 18:40:02 {"id":"tsk_2214"} task.routed 18:41:10 {"to":"assistente","reason":"phone_only"} task.matched 18:41:11 {"person":"A-02","score":0.88} task.briefed 18:42:30 {"brief":"br_9f1"} task.handoff 18:47:05 {"human_started":true} task.awaiting_confirmation 19:01:44 {"proposal":"21:15 · esterno"} task.resolved 19:05:12 {"outcome":"booked"} # l’agente può rispondere a metà strada POST /v1/tasks/tsk_2214/context {"note":"il membro preferisce dopo le 21"}
{
"id": "tsk_2214",
"status": "resolved",
"handled_by": ["mille", "assistente:A-02"],
"models_used": 3,
"human_minutes": 11,
"outcome": {
"booked": "2026-10-10T21:15:00+02:00",
"table": "esterno",
"reference": "a nome del membro",
"cost_eur": 0
},
"confirmed_by_member": true,
"log": "https://ciaograziemille.com/t/tsk_2214"
}
API 01Interfaccia in sviluppo, accesso anticipato su richiesta a concierge@akaion.com. Nomi, indirizzi e identificativi sono segnaposto.
Anche una richiesta semplice affidata a Mille viene verificata da un secondo modello, controllata e registrata.
Passare una richiesta a una persona al momento giusto è un successo, mai un incidente.
Ogni risultato riporta chi l’ha portato a termine, con il suo nome. E la persona ha scelto di prenderlo.
Se una funzione non restituisce tempo a qualcuno, resta fuori dal servizio.
Questa ricerca è il motivo per cui, con Grazie Mille, una riga basta.
Scopri il servizio Accesso anticipato all’API