La compatibilità Web per gli agenti sta passando da una funzionalità aggiuntiva a un requisito predefinito

Nel browser viene visualizzato un normale contenuto, ma spesso non può essere letto completamente quando viene passato al programma agente. Solo perché la pagina può essere aperta, non significa che la pagina possa davvero essere consumata; solo perché può essere visto dalle persone, non significa che possa essere letto, verificato e tracciato stabilmente dalle macchine.

Questa questione veniva considerata una questione secondaria, come “riempire la mappa del sito” o “aggiungere alcuni dati strutturati alla pagina dell’articolo”. Non è più un angolo. Una volta che un sito pubblico affronta i crawler AI, il recupero automatizzato e i flussi di lavoro basati su agenti, gli oggetti compatibili non sono più solo browser e motori di ricerca, ma anche un tipo di client che può dividere le pagine in base alla semantica, saltare in base ai collegamenti e continuare l’esecuzione in base allo stato. Se una pagina è amichevole solo per i lettori umani ma piena di trappole per tali clienti, inizierà ad apparire come un sito Web con compatibilità incompleta.

Solo perché la pagina può essere aperta non significa che la pagina possa essere letta.

Il primo problema di solito non è la qualità del contenuto, ma il modo in cui il contenuto viene prodotto.

Se una pagina incorpora il corpo del testo nel rendering lato client, nasconde i campi chiave nei pannelli a fisarmonica, trasforma l’impaginazione in un flusso a scorrimento senza URL espliciti e trasforma le tabelle in immagini, il programma agente può fare affidamento solo su congetture. Per gli esseri umani, un’ipotesi sbagliata può significare che viene mancato un paragrafo; per una macchina, un’ipotesi sbagliata può far sì che le azioni successive vadano fuori strada, e qualche passo in più in futuro continuerà semplicemente lungo la comprensione sbagliata.

Questo tipo di problema è particolarmente evidente nei siti di documenti e nei siti di contenuto. I lettori umani seguono il livello visivo e completano da soli il contesto; gli agenti no. Ciò che l’agente vede è il DOM, la gerarchia delle intestazioni, le relazioni dei collegamenti, i controlli dei moduli, i codici di stato e il testo scansionabile. Se il testo principale è slegato da questi segnali basilari, la pagina apparirà in uno stato scomodo: sembra moderna ma in realtà è instabile.

In passato, durante la migrazione di applicazioni a pagina singola, questo livello era spesso il primo a essere esposto. Viene visualizzata la prima schermata e l’interazione è possibile, ma la macchina cattura la shell e il testo reale non viene visualizzato fino al termine dello script. Insieme al caricamento lento, allo scorrimento infinito e a vari design “espandi e visualizza”, la pagina di contenuto diventerà una serie di eventi accidentali. Per gli utenti del browser si tratta solo di un leggero rallentamento; per gli agenti è una catena di voci inaffidabili.

Ciò che la macchina vuole è un’entrata stabile, non contenuti visivi.

Rendere il sito “pronto per l’agente” significa essenzialmente aggiungere un livello di compatibilità, piuttosto che aggiungere un nuovo trucco.

L’aspetto più prezioso di questo livello di compatibilità non è quello di far “sembrare che la pagina sia per le macchine”, ma di indicare chiaramente i fatti più elementari: di quale pagina si tratta, dove si trova il testo, qual è lo stato attuale, se può continuare a saltare e cosa dovrebbe essere restituito quando fallisce. Finché questi fatti rimarranno instabili, gli agenti metteranno ripetutamente alla prova i confini.

Le cose più importanti da affrontare per prime nei siti di contenuto sono solitamente queste:

• Il testo deve essere direttamente accessibile dall’HTML, senza fare affidamento su script per indovinarlo
• La gerarchia dei titoli dovrebbe essere stabile e non lasciare che lo stile visivo sostituisca la struttura semantica.
• L’impaginazione, il filtraggio e i risultati di ricerca devono avere URL condivisibili, anziché esistere solo nello stato front-end
• Immagini, tabelle e blocchi di codice devono avere testo alternativo leggibile o testo originale
• Le esportazioni di base di canonical, mappa del sito e feed dovrebbero essere pulite e non mescolate con una serie di parametri temporanei.

Potrebbero sembrare luoghi comuni, ma il loro significato ora è cambiato. In passato, questi venivano aggiunti per motivi di motori di ricerca e accessibilità; ora, questi vengono aggiunti per consentire all’agente di individuare stabilmente il contenuto, determinare la relazione tra le pagine e procedere al passaggio successivo senza richieste manuali. Puntano tutti alla stessa cosa: la pagina deve essere trattata come un input definito da un altro client, piuttosto che come un risultato visivo una tantum.

Questo è il motivo per cui “aggiungere un pulsante AI” non aiuta davvero. Il pulsante in sé non rende la pagina più consumabile. Nella migliore delle ipotesi, racchiude semplicemente un’azione in una nuova voce. Se il livello inferiore si basa ancora sul layout visivo e sullo stato temporaneo per mantenere la comprensione, il programma agente perderà comunque la presa durante l’aggiornamento, il salto, il rollback e le modifiche delle autorizzazioni.

L’interazione deve completare l’azione, non limitarsi a fermarsi alla richiesta

Se la pagina serve solo per visualizzare il contenuto, i problemi di compatibilità sono relativamente facili da gestire. Quando si arriva al livello di interazione e di operatività, il problema diventa ancora più difficile.

Ciò di cui un agente ha veramente bisogno non è “quasi sufficiente”, ma confini chiari dell’azione. Invia, conferma, revoca, scarica, iscriviti, salta ed esporta; queste azioni dovrebbero preferibilmente avere precondizioni chiare, ritorni di errori e risultati tracciabili. Finché le azioni sono mescolate con una serie di popup, istruzioni e conferme secondarie, la macchina rimarrà bloccata nello stesso posto ancora e ancora.

È qui che la differenza tra siti pubblici e sistemi interni inizia a diventare grande. I siti pubblici devono affrontare il problema della consumabilità, mentre i sistemi interni devono affrontare le autorizzazioni e il controllo dei rischi. Il primo è più adatto a stabilizzare la struttura dell’informazione e la semantica dell’azione, in modo che i clienti esterni possano evitare deviazioni; quest’ultimo non dovrebbe allentare i confini per essere “compatibile con gli Agenti”, soprattutto quando sono coinvolti fondi, pubblicazione, cancellazione e modifiche dei permessi. Dobbiamo ancora essere conservatori laddove dovremmo essere conservatori.

Non si tratta quindi di trasformare tutte le pagine web in interfacce macchina. Un approccio più realistico consiste nel trasformare le pagine originariamente destinate al consumo esterno in ingressi stabili, verificabili e riproducibili. Le pagine di articoli, le pagine di documentazione, le basi di conoscenza, i centri di assistenza, le API aperte e i risultati di ricerca pubblici sono i primi a essere interessati e i primi a vedere i vantaggi.

Questo livello di compatibilità ha confini chiari

Essere pronti per l’agente non è un obiettivo valido per tutti.

Il backend di una intranet completa, il sistema aziendale con un forte controllo delle autorizzazioni, la pagina delle attività del ciclo di vita breve e la stazione di contenuti per il consumo pubblico non sono allo stesso livello. Il primo si preoccupa maggiormente del controllo, mentre il secondo si preoccupa maggiormente della leggibilità, dell’indicizzabilità e della tracciabilità. Forzare questi due tipi di sistemi nello stesso insieme di standard che “rendono le macchine utilizzabili” alla fine non farà altro che aumentare i costi di gestione.

Ma è difficile continuare a far finta che nulla sia cambiato sul sito pubblico. I crawler AI leggeranno sempre più direttamente le pagine e i flussi di lavoro degli agenti si affideranno sempre più a contenuti strutturati e azioni stabili. Se un sito si attiene ancora all’idea “è sufficiente che le persone lo vedano”, prima o poi si verificheranno delle crepe nella distribuzione, nel recupero, nell’archiviazione e nell’integrazione automatizzata dei contenuti.

Quindi questa modifica è più simile a un aggiornamento di compatibilità. In passato, il front-end doveva considerare diversi browser, diversi schermi e diverse reti; ora deve anche considerare un tipo di client in grado di dividere le pagine da solo, seguire i collegamenti da solo e verificare lo stato da solo. Con questo livello di compatibilità aggiunto, il sito può davvero entrare in un nuovo requisito predefinito: non solo deve essere visualizzabile, ma anche essere consumato stabilmente.