Far lavorare un agente sul web può richiedere molte più risorse di quanto suggerisca un singolo comando scritto in linguaggio naturale. Per completare un’attività, il sistema deve infatti leggere l’interfaccia, capire quali elementi siano rilevanti, scegliere una sequenza di azioni e verificare di non aver perso il contesto lungo il percorso. In questo ciclo, ogni osservazione e ogni passaggio di ragionamento può tradursi in token elaborati. È su questo costo operativo che interviene OdoBot, l’architettura descritta in un nuovo preprint pubblicato su arXiv da Alexandru Ianta ed Eleni Stroulia.
La proposta parte da un’idea lineare: anziché affrontare ogni istruzione come un’esplorazione sostanzialmente nuova della pagina, un web agent può sfruttare ciò che ha già imparato sul funzionamento dell’applicazione. OdoBot costruisce un modello comportamentale dell’app a partire da dimostrazioni di esecuzioni andate a buon fine. Quel modello diventa un riferimento per svolgere compiti successivi con meno elaborazione legata all’interpretazione dell’interfaccia.
Non si tratta, almeno per quanto emerge dal lavoro, di un sistema pensato per qualunque sito o per una navigazione web indistinta. Il campo d’azione è quello dei web agent incaricati di compiti all’interno di applicazioni con una UI definita: software in cui le persone formulano richieste in linguaggio naturale e l’agente deve poi agire sugli elementi disponibili sullo schermo. La distinzione è importante, perché in questi ambienti una parte significativa della conoscenza utile riguarda le regole pratiche dell’applicazione: quali passaggi consentono di raggiungere un risultato, quali azioni sono ammesse e in quale ordine tendono a funzionare.
Dal riconoscimento della schermata alla conoscenza dei flussi
Gli agenti web convenzionali analizzano l’interfaccia e interagiscono con essa durante l’esecuzione del compito. È un approccio flessibile, ma può diventare oneroso se il sistema deve ricostruire ripetutamente il significato operativo delle schermate. La ricerca di Ianta e Stroulia prova ad affiancare a questa capacità di osservazione una memoria strutturata dei comportamenti già dimostrati con successo.
Il risultato atteso non è soltanto una scorciatoia nell’esecuzione di un singolo click. Un modello del comportamento dell’applicazione può aiutare l’agente a collegare una richiesta al percorso necessario per soddisfarla, evitando una parte del lavoro di interpretazione che altrimenti sarebbe ripetuto. La promessa di efficienza va quindi letta nel contesto corretto: meno token non perché il compito sia diventato magicamente più semplice, ma perché l’agente riutilizza informazioni derivate da esempi precedenti.
Questo approccio risponde a una tensione concreta nello sviluppo delle infrastrutture agentiche. Le capacità degli agenti stanno spingendo aziende e sviluppatori a sperimentarne l’uso in procedure operative, assistenza interna, gestione di piattaforme e attività ripetitive svolte attraverso browser. Tuttavia, quando l’agente deve mantenere una lunga sequenza di osservazioni e decisioni, il consumo di token incide direttamente sulla sostenibilità economica del servizio. Ridurre questa voce può determinare se un’automazione resta confinata a una demo oppure diventa utilizzabile su scala.
I risultati dichiarati su Canvas LMS
Gli autori hanno valutato OdoBot su 45 attività nel Canvas Learning Management System, piattaforma usata per la gestione di corsi e processi didattici. Nel confronto riportato nel preprint, OdoBot utilizza il 44% di token in meno rispetto ad Agent-E e l’80% in meno rispetto a WebVoyager, due agenti indicati dagli autori come riferimenti avanzati. Il lavoro segnala inoltre che OdoBot supera WebVoyager nel tasso di completamento dei task.
I numeri sono rilevanti soprattutto per l’ampiezza della differenza sul consumo dichiarata nel confronto con WebVoyager. Se confermata in altri contesti, una riduzione di questa portata renderebbe più interessante l’adozione di agenti in applicazioni dove molte richieste ricadono su flussi ricorrenti. Un learning management system è, da questo punto di vista, un banco di prova coerente: le operazioni si svolgono in un ambiente con procedure, ruoli e interfacce relativamente stabili, dunque adatto a verificare quanto una conoscenza del comportamento dell’app possa essere riutilizzata.
Al tempo stesso, il perimetro dell’esperimento definisce anche ciò che non si può ancora dedurre. I dati disponibili riguardano 45 task e una sola applicazione, Canvas LMS. Dal solo abstract non emergono elementi sufficienti per stabilire come l’architettura si comporti su servizi radicalmente diversi, interfacce che cambiano spesso o compiti mai incontrati durante la costruzione del modello. Non sarebbe corretto estendere automaticamente i risultati all’intero web, né interpretare il confronto come una certificazione generale della superiorità del sistema.
Efficienza e manutenzione restano legate
La stessa strategia che permette di risparmiare token apre una questione pratica: la qualità del modello comportamentale dipende dalle dimostrazioni disponibili e dalla stabilità dell’applicazione osservata. Un software web può modificare menu, percorsi e autorizzazioni; può introdurre nuove funzioni o cambiare il modo in cui presenta una stessa azione. In tali casi, la conoscenza ricavata dalle esecuzioni precedenti potrebbe dover essere aggiornata. Il preprint mette al centro la costruzione del modello da dimostrazioni riuscite, ma il materiale fornito non quantifica il costo iniziale di questa fase né quello necessario per mantenerlo allineato nel tempo.
È un aspetto decisivo per valutare il beneficio reale in produzione. Un agente che consuma meno token durante ogni task può essere vantaggioso, ma il bilancio complessivo dipende anche da quanto costa raccogliere esempi affidabili, costruire il modello e intervenire quando l’applicazione evolve. Il risparmio è più plausibile laddove i volumi siano ripetuti e le procedure abbastanza consolidate; è invece da verificare negli ambienti con cambiamenti frequenti o con richieste molto eterogenee.
Resta poi il tema dell’affidabilità. Un modello che comprime l’esplorazione non dovrebbe trasformarsi in un meccanismo rigido, incapace di riconoscere una situazione nuova o una schermata inattesa. Il lavoro riporta un miglioramento rispetto a WebVoyager nel tasso di successo dei compiti esaminati, ma non offre nel testo disponibile una base per confrontare tutti gli aspetti qualitativi dei sistemi o per misurarne la tenuta fuori dal dataset di prova. Serviranno repliche, test su applicazioni differenti e valutazioni che includano anche la manutenzione del modello nel ciclo di vita del prodotto.
OdoBot non è dunque una soluzione pronta da considerare come standard del settore, ma un’indicazione interessante sulla direzione che potrebbero prendere i web agent. Invece di affidarsi esclusivamente a modelli sempre più grandi e a finestre di contesto più estese, una parte dell’efficienza può arrivare dalla conoscenza specifica dell’ambiente in cui l’agente opera. Per le aziende che progettano automazioni browser-based, il messaggio del preprint è concreto: imparare i flussi di un’applicazione potrebbe ridurre il costo di esecuzione senza rinunciare, nei test presentati, alla capacità di completare i compiti.
Il lavoro, caricato su arXiv l’11 settembre 2026, è un preprint e non va quindi letto come una validazione definitiva attraverso peer review. La fase successiva sarà capire se i risultati ottenuti su Canvas LMS restano consistenti su piattaforme aziendali, servizi con interfacce dinamiche e scenari in cui gli agenti devono conciliare efficienza, adattamento e controllo degli errori. È su questa prova di generalizzazione che si misurerà la portata effettiva dell’architettura proposta.
