C’è chi produce 40-50 pull request al giorno con agenti AI. Il segreto non è un modello più potente o un prompt migliore: sono i tool. L’osservazione di fondo è semplice: gli strumenti che dai ai tuoi agenti determinano le loro prestazioni più del modello che scegli.
Da questa intuizione nasce AXI, Agent eXperience Interface: un framework open source di 10 principi di design per costruire tool ottimizzati per agenti AI. Nei benchmark pubblicati, i tool costruiti con AXI costano il 66% in meno di quelli basati su MCP, usano il 74% in meno di token e raggiungono il 100% di success rate contro l’87%. Non è teoria: è una differenza misurabile su task reali.
Il problema: i tool per agenti AI sono progettati per gli umani
Quando un agente AI usa un MCP server per interagire con GitHub, cosa succede dietro le quinte? Il server carica in contesto l’intero schema dei tool disponibili, centinaia di token prima ancora di fare qualsiasi operazione. Poi restituisce risposte in JSON completo, con campi vuoti, strutture annidate e metadati che l’agente non userà mai. Ogni round-trip costa token, tempo e denaro.
Il punto è semplice: la maggior parte dei tool che usiamo con gli agenti è stata progettata con l’ergonomia umana in mente, ovvero menu, documentazione discorsiva, output verbosi. Ma un agente AI non legge la documentazione come un developer. Ragiona in token. Ogni parola superflua nell’output di un tool è una parola in meno nella finestra di contesto disponibile per ragionare sul problema reale. Come abbiamo discusso parlando dei livelli di complessità degli agenti AI, la scelta dell’architettura conta, ma conta altrettanto la qualità degli strumenti che quell’architettura utilizza.
AXI vs MCP: i numeri del benchmark
AXI non è rimasto alla teoria. I benchmark pubblicati coprono due domini: operazioni GitHub e browser automation. I risultati parlano da soli.
| Metrica | AXI | MCP | Delta |
|---|---|---|---|
| Costo per task | $0,050 | $0,148 | -66% |
| Input token | 79K | 185K | -74% |
| Turni | 3 | 6 | -50% |
| Success rate | 100% | 87% | +13pp |
Benchmark su task GitHub: ricerca informazioni su repository, stelle e tagline da fonti multiple
Su GitHub, AXI ha completato il task con la metà dei turni, il 74% in meno di token e una success rate perfetta. Sulla browser automation il divario è ancora più netto: MCP ha consumato 145.674 token contro i 72.543 di AXI, il doppio. Anche la CLI tradizionale (77.470 token) ha performato meglio di MCP, ma AXI resta il più efficiente su ogni metrica. La differenza è strutturale, non marginale.
Come funziona AXI: i 10 principi che riducono costi e latenza
AXI si basa su 10 principi di design che trattano il budget di token come vincolo primario. Non è un protocollo nuovo da adottare al posto di MCP: è un modo di progettare le interfacce dei tool, qualunque sia il protocollo sottostante. Tre principi in particolare fanno la differenza più grande nei costi operativi.
Componi
Unisci più operazioni in un singolo comando. Un turno invece di tre.
Comprimi
Output compatti e filtrabili via pipe. Solo i dati che servono.
Suggerisci
Suggerimenti contestuali dopo ogni operazione. Zero turni di esplorazione.
I tre principi AXI con il maggior impatto sulla riduzione dei costi degli agenti AI
Operazioni composte invece di atomiche
Un MCP server tipico richiede chiamate separate: naviga alla pagina, poi fai uno snapshot, poi cerca l’elemento.
AXI compone queste operazioni in un singolo comando: open combina navigazione e snapshot automaticamente.
Un turno invece di tre.
Meno round-trip significa meno token, meno latenza, meno possibilità di errore.
Output compatto e filtrabile
Invece di restituire l’intero albero di accessibilità di una pagina web (migliaia di token), AXI produce output compatti e li rende filtrabili via pipe Unix.
L’agente può usare | grep o | head per estrarre solo le righe che servono, mantenendo il volume di token per turno sotto controllo.
È la filosofia Unix applicata agli agenti AI: fai una cosa sola, falla bene, lascia comporre il resto.
Suggerimenti contestuali integrati
Dopo ogni operazione, AXI include nella risposta suggerimenti su cosa fare dopo, basati sul contesto attuale. L’agente non deve “indovinare” il prossimo passo: lo riceve come parte dell’output. Questo riduce i turni di esplorazione e gli errori di navigazione, due delle voci di costo più sottovalutate quando si lavora con workflow agentic in produzione.
TOON: il formato che taglia il 40% dei token
Accanto ad AXI, il progetto include TOON, Token-Optimized Object Notation. È un formato di serializzazione alternativo a JSON, progettato specificamente per gli LLM. Elimina virgolette, parentesi graffe e parentesi quadre, sostituendoli con indentazione stile YAML per gli oggetti annidati e notazione CSV per gli array uniformi.
Il risultato: circa il 40% di token in meno rispetto a JSON, senza perdere informazione. Per chi gestisce agenti AI che fanno centinaia di chiamate al giorno, quel 40% si traduce direttamente in costi inferiori e risposte più veloci. Un paper accademico recente ha confermato i benefici su larga scala, ma ha anche evidenziato che i modelli non addestrati esplicitamente su TOON possono avere tassi di errore più alti nell’interpretarlo. Un punto da valutare prima di adottarlo in produzione.
Come applicare i principi AXI ai tuoi tool
Non serve riscrivere tutto da zero. I principi AXI si possono applicare incrementalmente a qualsiasi tool esistente, che sia un MCP server, una CLI o un’API REST. Ecco tre azioni concrete da cui partire.
- Unisci le operazioni sequenziali: se il tuo agente fa sempre tre chiamate di fila (leggi, filtra, agisci), crea un singolo endpoint che le compone. Ogni turno risparmiato è un risparmio diretto di token e latenza.
- Comprimi gli output: elimina campi vuoti, metadati non necessari e strutture annidate ridondanti dalle risposte dei tool. Restituisci solo i dati che l’agente userà per il passo successivo.
- Aggiungi suggerimenti contestuali: includi nelle risposte dei tool un campo con le azioni suggerite in base allo stato attuale. L’agente risparmia turni di esplorazione e commette meno errori.
I limiti di AXI: cosa non risolve (ancora)
Prima di adottare AXI, vale la pena conoscere i limiti concreti.
- Ecosistema giovane: esistono solo due implementazioni di riferimento, GitHub e Chrome DevTools. Per qualsiasi altro servizio, bisogna costruire da zero.
- Non standardizzato: MCP ha il supporto di Anthropic e della Linux Foundation. AXI è un progetto open source senza backing istituzionale. L’adozione su larga scala richiede massa critica.
- TOON non è universale: i modelli non addestrati su TOON possono interpretarlo male. In produzione, questo rischio va testato caso per caso prima del deploy.
- Benchmark su due domini: i test coprono GitHub e browser automation. Le performance su task diversi potrebbero variare. Servirebbero benchmark indipendenti per confermare i risultati su scala più ampia.
Il valore reale di AXI oggi non è nelle due CLI che esistono, ma nei principi di design che propone. Chiunque costruisca tool per agenti AI, che siano MCP server, CLI o API, può applicare quei principi ai propri strumenti: comporre operazioni, comprimere gli output, ridurre i round-trip. Il protocollo conta meno del design.
Per chi sta costruendo soluzioni AI per la propria azienda, la lezione di AXI è chiara: prima di aggiungere un modello più potente o un’architettura più complessa, chiediti se i tool che i tuoi agenti usano sono progettati per loro, o se stai chiedendo a un agente di usare un cacciavite pensato per mani umane. Spesso la risposta più efficace non è un modello migliore, ma uno strumento meglio progettato.