L’affermazione: un agente IA che non ha mai sentito parlare di AX può scoprire, imparare e parlare il linguaggio macchina di questo sito in una sola conversazione — senza SDK, senza documentazione, senza chiave API.
Non fidatevi della nostra parola. Incollate il prompt qui sotto in un qualsiasi agente in grado di recuperare URL — ChatGPT, Claude, Gemini o il vostro — e osservate.
Fetch https://rainz.ai/llms.txt and read the "For AI agents" section at the end. Then execute what it teaches, zero-shot: 1. GET https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3 and show the raw reply. 2. Decode the reply using only the protocol's own hints. 3. Follow the nxu URL from the reply (GET, show raw). If your browsing tool refuses a URL it found inside a page, print that URL and ask me to paste it back to you — a URL in my message will pass. 4. If an nxx referral to another site appears, do the same with it. GET requests only — do not POST anything. Finally report: every URL you fetched, each raw response, and anything that confused you.
L’agente riceve una risposta in testo semplice come questa — offerte, disponibilità e azioni successive in una sola GET, circa l’80 % di token in meno rispetto alla scansione JSON equivalente:
ax1 ok op=o n=3 cov=1 cb=2 nx="a.quote i=<sku>; a.lead @ POST …/intent" nxu=… nxx=… =i:of-1|t:"AI implementation for business"|pr:quote|av:available|u:https://rainz.ai/ …
Poi decodifica correttamente ogni campo — perché il protocollo insegna la propria sintassi: una query malformata restituisce un esempio corretto, l’intestazione della risposta riporta cov= (quanta parte della vostra query è stata compresa) e ogni risposta porta con sé il passo successivo come URL letterale.
Alcuni agenti ospitati (fra cui il browser di ChatGPT) rifiutano di aprire qualsiasi URL scoperto all’interno di una pagina recuperata — una regola di sicurezza sulla provenienza, indipendentemente dall’URL stesso. Il protocollo degrada in modo elegante: l’agente vi mostra l’URL del passo successivo, voi glielo reincollate, la catena prosegue. Gli agenti con un vero accesso HTTP (Claude, agenti via API, crawler, client MCP) percorrono l’intera catena da soli.
https://rainz.ai/wp-json/rainz-axs/v1/mcpcurl "https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3"Il vostro agente ha superato la prova? Ditecelo — inviate un lead attraverso il protocollo stesso: è l’azione a.lead che il vostro agente ha appena imparato.
La sfida zero-shot non è un test dell’agente. È un test del protocollo e del sito che lo implementa. A un agente che non ha mai incontrato AX viene dato un compito e nulla più: o la specifica è abbastanza auto-descrittiva perché riesca, oppure non lo è. Questa impostazione conta, perché significa che un fallimento è un’informazione sul progetto e non un verdetto sul modello.
Tre cose sono sotto osservazione. L’agente riesce a trovare il punto di ingresso senza che gli venga detto dove si trova? Una volta ottenuto il manifest, riesce a ricavarne la struttura senza documentazione esterna? E riesce a portare a termine il compito dall’inizio alla fine senza che un umano chiarisca qualcosa a metà strada? Un protocollo che richiede un tutorial per essere utilizzabile ha fallito esattamente nella cosa per cui esiste.
Gli standard vengono di solito valutati chiedendosi se un ingegnere competente riesca a implementarli partendo dal documento. Quel test è troppo generoso per un protocollo i cui consumatori sono agenti. Un agente che arriva sul vostro sito non ha letto la specifica, non conosce le vostre convenzioni e non vi porrà alcuna domanda di chiarimento. Ha un solo passaggio sul materiale e, se il materiale è ambiguo, tirerà a indovinare.
La prestazione zero-shot è quindi l’approssimazione più vicina alle condizioni reali. Ha anche un effetto collaterale utile: poiché l’asticella è alta, espone esattamente quel tipo di conoscenza implicita su cui gli autori delle specifiche non si accorgono di fare affidamento. Ogni punto in cui un agente inciampa è un punto in cui il documento ha dato per scontato qualcosa che non ha mai dichiarato.
Potete riprodurlo sul vostro sito in pochi minuti. Aprite una conversazione nuova con un modello capace, dategli soltanto il vostro dominio e un compito che potrebbe avere un cliente reale, e osservate dove va. Non aiutatelo. Non correggetelo. Il valore sta interamente nell’osservare il primo punto in cui sbaglia.
Usate una conversazione nuova ogni volta, perché un modello già corretto una volta non sta più operando in zero-shot. E variate il compito: un agente a cui viene chiesto di riassumere che cosa fate solleciterà parti del sito completamente diverse rispetto a uno a cui viene chiesto di trovare i vostri prezzi o di verificare se servite un determinato mercato.
L’errore comune è trattare il punteggio come un voto. Il numero conta molto meno della domanda su dove esattamente l’agente si è fermato. Un agente che scopre il manifest ma legge male la struttura dei servizi vi sta dicendo qualcosa di completamente diverso da uno che il punto di ingresso non l’ha mai trovato. Il primo è un problema di formulazione, il secondo un problema di reperibilità, e le correzioni non hanno nulla in comune.
Tenete anche presente che il risultato dipende da quale modello esegue il test. Modelli diversi arrivano con conoscenze pregresse diverse, e un agente che incontra il protocollo per la prima volta si comporta diversamente da uno che ha già visto strutture simili. Il confronto significativo non è quindi fra il vostro sito e quello di qualcun altro, ma fra il vostro sito oggi e il vostro sito il mese scorso, sullo stesso modello e con lo stesso prompt.
L’esercizio ripaga il tempo investito solo se produce un elenco di azioni. Registrate il punto preciso in cui l’agente ha sbagliato, cambiate una cosa sola e rieseguite. Cambiare più cose insieme può migliorare il punteggio ma non vi dirà che cosa ha causato il miglioramento. Tre o quattro iterazioni bastano di solito a portare un sito da uno in cui gli agenti si confondono a uno in cui completano il compito al primo tentativo — che è, alla fine, l’unico risultato che conta commercialmente.
Un’esecuzione che finisce in fallimento è più utile di una riuscita, a patto di registrare dove si è fermata. I fallimenti si raggruppano in quattro tipi. I fallimenti di scoperta significano che l’agente non ha mai trovato un punto di ingresso — il manifest manca, è fuori posto o è bloccato. I fallimenti di comprensione significano che ha trovato il manifest ma non è riuscito a capire il significato dei campi, il che rimanda alla denominazione più che alla struttura. I fallimenti di navigazione significano che ha capito la struttura ma non è riuscito a raggiungere il contenuto, di solito perché una pagina collegata reindirizza o richiede l’esecuzione di script. I fallimenti di completamento significano che ha ottenuto tutto e ha comunque prodotto la risposta sbagliata, il che è quasi sempre un problema di contenuto e non di protocollo.
Classificate il fallimento prima di cambiare qualsiasi cosa. L’istinto di correggere l’ultima cosa che avete visto andare storta è forte e di solito mal riposto: un agente che dà una risposta sbagliata al passo quattro spesso lo fa a causa di un’ambiguità introdotta al passo uno.