I test dell'agente browser di Asana riducono i costi del modello di 76 volte con GPT-6.1 Sol
Asana afferma che il suo agente browser è diventato 76 volte meno costoso e cinque volte più veloce dopo che gli ingegneri hanno modificato il modo in cui conservava e memorizzava nella cache la cronologia di navigazione. I test dell'agente browser di Asana hanno utilizzato GPT-6 Astra in Codex per esaminare il sistema, condurre esperimenti e analizzare le tracce. GPT-6.1 Sol ha poi offerto il costo stimato del modello più basso nell'ambito del flusso di lavoro ottimizzato.
Il risultato principale sembra una vittoria del modello. La scoperta più importante riguarda l'architettura dell'agente. Asana ha modificato il momento in cui l'agente rimuoveva gli screenshot, ampliato il limite della cronologia e memorizzato nella cache il crescente registro dei passaggi precedenti. Questi cambiamenti hanno ridotto l'elaborazione ripetuta preservando le informazioni necessarie all'agente per completare il compito.
Questa distinzione conta per ogni azienda che valuta gli agenti browser. Un team può passare a un modello meno costoso e continuare a sprecare token a causa di una cattiva gestione del contesto. Può anche scegliere un modello più capace, conservare la cronologia corretta e ridurre i costi operativi complessivi. L'esperimento di Asana mette queste due strategie in competizione diretta.
Lo studio sull'agente browser di Asana ha cambiato più del solo modello
I maggiori miglioramenti di Asana sono derivati dalla riprogettazione del flusso di lavoro attorno al modello, non dalla semplice sostituzione di un modello con un altro.
L'azienda ha pubblicato i risultati l'8 ottobre 2026, seguiti da un case study di OpenAI il 9 ottobre. Il lavoro si è concentrato su un agente browser in StackAI, la piattaforma di automazione no-code acquisita da Asana all'inizio del 2026.
StackAI consente ai clienti di creare agenti che navigano siti web, raccolgono informazioni e compilano moduli nelle applicazioni aziendali. Questi flussi di lavoro assomigliano alla navigazione umana, ma l'agente sottostante invia ripetutamente a un modello istruzioni, strumenti, testo delle pagine, screenshot e azioni precedenti.
Questo contesto ripetuto crea uno schema costoso. Ogni nuovo passaggio include più cronologia del precedente. Se i contenuti precedenti continuano a cambiare, un provider non può riutilizzare in modo affidabile la relativa rappresentazione memorizzata nella cache.
L'agente originale di Asana memorizzava nella cache istruzioni fisse e definizioni degli strumenti. Non memorizzava efficacemente nella cache la crescente cronologia di navigazione. L'agente rimuoveva inoltre vecchi screenshot e tagliava frequentemente il testo, modificando le parti precedenti della richiesta.
Queste modifiche interrompevano il prefisso stabile, ovvero l'inizio invariato condiviso da richieste consecutive al modello. Una volta modificato quel prefisso, gran parte della cronologia di navigazione doveva essere elaborata di nuovo.
Frank Hidalgo, chief technology officer di StackAI presso Asana, ha incaricato GPT-6 Astra in Codex di ispezionare questo comportamento. Il modello ha mappato la codebase, esaminato come venivano assemblate le richieste e identificato le variabili da testare.
Asana afferma che lo studio risultante ha incluso 144 esecuzioni principali su quattro modelli frontier. Ha testato sei politiche di caching e gestione degli screenshot, due limiti di cronologia e tre esecuzioni per ciascuna condizione. L'azienda ha poi condotto un follow-up più piccolo.
Ogni configurazione ha ricevuto lo stesso incarico. L'agente browser doveva raccogliere sei campi per ciascuno di 32 libri da un catalogo dimostrativo pubblico. Ciò significava trovare 192 dati mantenendo abbastanza contesto da restituire una risposta finale corretta.
I modelli includevano GPT-6.1 Sol e tre alternative anonimizzate. Asana ha chiamato questi sistemi Modelli A, B e C. Il Modello B alimentava la configurazione di produzione originale, mentre il Modello C rappresentava un modello più recente dello stesso provider.
Asana non ha divulgato tali provider, limitando i confronti competitivi diretti. Tuttavia, ha dichiarato che il flusso di lavoro ottimizzato con GPT-6.1 Sol costava 76 volte meno della configurazione originale con il Modello B. Inoltre, veniva completato circa cinque volte più velocemente.
Da allora l'azienda ha rilasciato in StackAI le modifiche alla navigazione browser. Ciò trasforma l'esercizio da confronto di laboratorio a cambiamento in produzione, sebbene Asana non abbia pubblicato ampi dati sulle prestazioni a livello di cliente.
Perché il prompt caching è diventato il meccanismo decisivo
La variabile decisiva era se l'agente potesse mantenere invariata la maggior parte della cronologia accumulata tra una chiamata e l'altra.
Il prompt caching memorizza lo stato computazionale riutilizzabile associato a un prefisso di prompt invariato. Le richieste successive possono riutilizzare tale stato invece di elaborare lo stesso materiale dall'inizio.
La cache non conserva una risposta finale da riprodurre. Il modello continua a elaborare nuovo materiale e a generare una nuova risposta. Evita semplicemente di ripetere il lavoro per il contesto idoneo che resta identico.
La guida al prompt caching di OpenAI raccomanda di collocare istruzioni stabili e materiale di riferimento prima dei contenuti variabili. Consiglia inoltre alle applicazioni di aggiungere la cronologia della conversazione invece di riscrivere ripetutamente i turni precedenti.
Il design originale di Asana violava questo secondo principio durante le esecuzioni browser. Quasi a ogni passaggio, rimuoveva uno screenshot precedente e talvolta tagliava il testo meno recente. La richiesta successiva differiva quindi nel mezzo della propria cronologia.
Memorizzare nella cache solo il prompt di sistema fisso non poteva catturare la principale fonte di input ripetuto. L'agente browser accumulava testo delle pagine, screenshot, osservazioni e risultati degli strumenti mentre avanzava nel compito.
Asana ha testato una politica diversa chiamata batch pruning. Il pruning consiste nell'eliminare il contesto meno recente prima che la cronologia accumulata diventi troppo grande. Con la politica selezionata, l'agente conservava fino a 20 screenshot prima di ridurre l'insieme a quello più recente.
Questo approccio creava intervalli più lunghi di cronologia solo appendibile. L'agente poteva aggiungere nuove osservazioni alla fine senza modificare i contenuti precedenti a ogni passaggio. Di conseguenza, una parte maggiore di ciascuna richiesta restava idonea al riutilizzo.
Il flusso di lavoro ottimizzato ha anche aumentato il limite della cronologia testuale da 120.000 caratteri a 480.000 caratteri. Ciò ha dato all'agente più spazio per conservare i dati raccolti in precedenza invece di eliminarli.
Il limite maggiore ha avuto un effetto importante sul completamento. Con l'impostazione di cronologia più piccola, GPT-6.1 Sol ha prodotto una risposta in sole tre delle 18 esecuzioni. Con l'impostazione più ampia, ha risposto in tutte e 18 le esecuzioni, secondo Asana.
Asana afferma che tutte queste esecuzioni con cronologia più ampia hanno restituito la risposta corretta. Il risultato mette in discussione l'assunto secondo cui ridurre aggressivamente il contesto migliori sempre l'efficienza dell'agente.
Eliminare il contesto riduce la dimensione immediata di una richiesta. Tuttavia, può costringere un agente a rivisitare le pagine, ripetere le chiamate agli strumenti o proseguire senza prove raccolte in precedenza. Può anche interrompere il riutilizzo della cache quando l'eliminazione modifica il prefisso della richiesta.
La politica migliore dipende quindi dall'economia complessiva del compito. I team devono considerare l'elaborazione degli input, la navigazione ripetuta, i tassi di completamento, la qualità della risposta e il recupero dalle esecuzioni fallite.
Asana ha riferito che l'89 percento dell'input di GPT-6.1 Sol proveniva dalla cache nella configurazione ottimizzata. Tale rapporto spiega perché un modello più capace potesse diventare l'opzione testata meno costosa per il compito completo.
Questo è il meccanismo centrale alla base del risultato dell'agente browser di Asana. L'azienda non ha semplicemente chiesto a un modello di usare meno token. Ha riorganizzato il flusso di lavoro affinché i token ripetuti diventassero meno costosi da elaborare.
Più contesto ha aiutato l'agente a completare il compito in modo affidabile
L'esperimento suggerisce che la richiesta meno costosa non è sempre parte del flusso di lavoro completato meno costoso.
I costruttori di agenti spesso considerano il contesto una risorsa da minimizzare. Questa visione è sensata perché prompt lunghi aumentano l'elaborazione degli input e possono avvicinarsi al limite di contesto di un modello.
Gli agenti browser complicano il calcolo. Le loro osservazioni precedenti funzionano come memoria di lavoro. Rimuovere un indirizzo, un attributo di prodotto, un avviso o un risultato di navigazione può impedire all'agente di completare la risposta finale.
Il limite di cronologia minore ha prodotto risultati particolarmente deboli per alcuni modelli. Asana riferisce che il Modello C non ha restituito alcuna risposta nelle 18 esecuzioni in tale condizione. GPT-6.1 Sol ha restituito solo tre risposte.
Questi fallimenti non dimostravano che i modelli mancassero di capacità generali di navigazione. Il limite di cronologia maggiore ha cambiato il risultato. Entrambi i modelli hanno risposto a ogni esecuzione dopo aver ricevuto spazio sufficiente per conservare il record necessario.
Il risultato sostiene un principio ingegneristico più ampio. La politica del contesto deve adattarsi al modello e al compito. Un unico limite universale di token non produrrà un comportamento equivalente tra sistemi diversi.
I modelli possono consumare contesto a velocità diverse perché producono descrizioni, chiamate agli strumenti e tracce di ragionamento differenti. Un agente potrebbe raggiungere una soglia di pruning dopo un numero ridotto di azioni. Un altro potrebbe proseguire molto più a lungo.
Asana ha rilevato che modelli più recenti o più capaci non utilizzavano automaticamente il limite minore in modo più efficiente. Il Modello C ha iniziato a tagliare la cronologia molto prima del Modello A nel flusso di lavoro testato.
L'esperimento ha anche rilevato che il caching da solo era insufficiente. Con il limite di cronologia maggiore, il caching senza batch pruning costava più dell'assenza di caching su tre dei quattro modelli.
Questo risultato sembra contraddittorio finché non si considera la struttura della richiesta. Una cache offre valore limitato quando l'applicazione riscrive costantemente il materiale che desidera riutilizzare. Il sistema paga per elaborare una cronologia variabile senza ricevere abbastanza cache hit future.
La politica selezionata da Asana ha allineato tre decisioni. Ha memorizzato nella cache la cronologia, preservato una sequenza solo appendibile per periodi più lunghi e fornito un limite maggiore prima che il taglio diventasse necessario.
Un follow-up ha sollevato un'altra domanda. Asana ha testato configurazioni che conservavano ogni screenshot invece di eliminarli. Alcune hanno prodotto costi per chiamata inferiori rispetto alla politica selezionata in questo particolare compito.
L'azienda non ha considerato ciò una prova che il pruning dovesse scomparire. Flussi di lavoro più lunghi possono superare i limiti di contesto, mentre alcuni provider applicano costi maggiori per le operazioni di cache. Un agente che devia verso una navigazione non necessaria richiede inoltre confini rigorosi.
Asana raccomanda limiti per passaggi, token e costo totale dell'esecuzione. Questi limiti impediscono a un agente errato o confuso di espandere indefinitamente la propria cronologia. La compattazione, che sostituisce la cronologia meno recente con un riepilogo più breve, offre un'altra opzione.
La compattazione introduce il proprio compromesso. Riduce la dimensione del contesto ma modifica il prompt precedente, potenzialmente interrompendo il riutilizzo della cache. Un riepilogo può inoltre omettere un dettaglio che diventa importante in seguito.
Per questo motivo, i team necessitano di registri esterni al prompt attivo. Asana ha registrato richieste, tracce e risultati in Command, la sua piattaforma di software delivery. Gli ingegneri e altri agenti potevano quindi esaminare l'esperimento completo.
Un record durevole supporta inoltre una base di conoscenza ricercabile. L'agente attivo riceve solo il contesto necessario per il passaggio corrente, mentre i revisori mantengono accesso alla pista completa delle prove.
Questa separazione aiuta i team a distinguere la memoria del modello dalla memoria organizzativa. Il contesto di lavoro di un agente dovrebbe restare delimitato. Il record dell'esperimento dovrebbe restare sufficientemente dettagliato da riprodurre le decisioni e indagare sui fallimenti.
GPT-6 Astra ha trasformato il lavoro di valutazione in un compito per agenti
Asana ha utilizzato un modello per migliorare il sistema e un altro per eseguire il flusso di lavoro di produzione ottimizzato.
GPT-6 Astra ha lavorato all'interno di Codex come agente di ricerca e ingegneria. GPT-6.1 Sol è servito come uno dei modelli runtime dell'agente browser. Considerare questi ruoli separati evita un'interpretazione fuorviante dei risultati.
Hidalgo ha definito la direzione della ricerca e selezionato le modifiche proposte che valeva la pena testare. GPT-6 Astra ha ispezionato il codice, strumentato le richieste, condotto prove preliminari e identificato le variabili influenti.
Il codice esistente non era progettato per confronti controllati. Asana afferma che l’agente Codex ha ristrutturato il sistema affinché un frontend e un backend condivisi potessero supportare parallelamente diversi flussi di lavoro sperimentali.
GPT-6 Astra ha quindi avviato lo studio, analizzato i record di utilizzo e confrontato gli output. Sessioni di modello separate hanno esaminato parti del lavoro, mentre le persone hanno valutato le conclusioni e approvato le modifiche in produzione.
Asana stima che il progetto avrebbe richiesto uno o due mesi di lavoro manuale. Con il flusso di lavoro Codex, l’indagine ha richiesto circa una settimana.
Questa affermazione proviene dall’azienda e non da una valutazione indipendente. Inoltre, descrive un singolo progetto di ingegneria guidato da un dirigente tecnico che conosce bene il sistema. Altri team non dovrebbero presumere la stessa riduzione dei tempi.
Ciononostante, il flusso di lavoro illustra un cambiamento significativo nell’uso degli agenti di coding. L’agente non si è limitato a implementare una funzionalità a partire da una specifica completata. Ha contribuito a progettare e svolgere un’indagine empirica.
L’indagine ha prodotto tracce, risultati sperimentali, ticket e pull request. Questi artefatti sono passati attraverso Command prima che le modifiche raggiungessero StackAI in produzione.
Questo processo conta più dell’affermazione secondo cui un agente IA ha svolto la maggior parte del lavoro meccanico. Senza registrazioni stabili, i revisori non possono determinare con affidabilità quale configurazione sia stata eseguita, perché sia fallita o se un miglioramento dichiarato abbia resistito alle modifiche del codice.
Lo studio di Asana afferma che gli esseri umani hanno stabilito l’obiettivo e gli standard di valutazione. Hanno inoltre esaminato i risultati. L’agente di coding ha ampliato la quantità di sperimentazione che il team poteva svolgere tra queste decisioni.
Hidalgo ha descritto una routine in cui fissava un obiettivo prima di andare a dormire e rivedeva i risultati la mattina seguente. Questo schema asincrono trasforma il tempo di esecuzione dell’agente in una risorsa ingegneristica.
Ma sposta anche il collo di bottiglia. Quando gli esperimenti diventano facili da generare, gli esseri umani devono dedicare più tempo a selezionare domande valide, verificare le misurazioni e respingere conclusioni fuorvianti.
Il rischio è il rumore sperimentale automatizzato. Un agente può produrre molte esecuzioni senza generare prove solide. I test ripetuti restano vulnerabili alla progettazione del benchmark, alle variazioni nascoste dei task e agli errori di punteggio.
Asana ha ridotto parte di questo rischio usando un task fisso e una risposta di riferimento preparata indipendentemente. Ha inoltre registrato i contatori di utilizzo del provider invece di stimare il consumo di token dalla lunghezza del testo.
L’azienda ha eseguito solo tre ripetizioni per la maggior parte delle configurazioni. Asana afferma esplicitamente che lo studio rivela tendenze generali, non differenze affidabili di pochi punti percentuali.
Questa precisazione è importante. I confronti di 76x e 5x sono abbastanza ampi da giustificare attenzione, ma combinano cambiamenti architetturali e di modello. Non isolano un vantaggio universale di GPT-6.1 Sol.
I risultati interni di Asana mostrano che anche il Modello B è migliorato sostanzialmente dopo aver ricevuto il flusso di lavoro ottimizzato. L’architettura ha rappresentato una parte importante del guadagno prima che GPT-6.1 Sol riducesse ulteriormente i costi.
Cosa non dimostra l’affermazione del 76x
I risultati pubblicati costituiscono prove ingegneristiche convincenti, ma non sono un benchmark neutrale del mercato degli agenti browser.
Lo studio ha usato un task strutturato su un catalogo pubblico di libri. Ogni esecuzione seguiva lo stesso obiettivo e raccoglieva lo stesso insieme di campi. La navigazione aziendale reale spesso include autenticazione, layout mutevoli, istruzioni ambigue e recupero da finestre di dialogo impreviste.
Un flusso di lavoro che eccelle nell’estrazione ripetitiva potrebbe comportarsi diversamente negli acquisti, nel supporto, nella conformità o nelle operazioni interne. Questi task possono richiedere giudizio attraverso diversi sistemi, anziché una raccolta ripetuta da pagine simili.
Il test dell’agente browser di Asana ha inoltre confrontato GPT-6.1 Sol con tre modelli anonimizzati. I lettori non possono ispezionare le impostazioni specifiche dei provider né determinare come ciascuna alternativa si comporterebbe dopo un’ottimizzazione indipendente.
Asana afferma che i Modelli B, C e GPT-6.1 Sol avevano prezzi standard comparabili durante lo studio. Il Modello A era presentato come un’alternativa meno costosa. L’articolo pubblico non ne identifica i nomi.
Questo anonimato impedisce che il risultato diventi una classifica pulita dei modelli. Protegge inoltre lo studio dal trasformarsi in confronti tra fornitori non supportati da un numero sufficiente di prove.
Il titolo più importante confronta il flusso di lavoro GPT-6.1 Sol ottimizzato con la configurazione di produzione originale sul Modello B. Due variabili sono cambiate contemporaneamente: il modello e l’architettura dell’agente.
Un confronto più circoscritto ha rilevato una riduzione dei costi di quattro volte quando la nuova policy veniva applicata all’interno di GPT-6.1 Sol. La differenza rimanente derivava dal confronto tra quel sistema ottimizzato e la precedente baseline di produzione.
Questo non indebolisce il risultato. Cambia la conclusione. Lo studio supporta la combinazione di modelli capaci con un’architettura consapevole del contesto, non l’idea che un cambio di modello sia l’intera soluzione.
Il miglioramento di cinque volte nel tempo di esecuzione presenta qualificazioni analoghe. Alcune esecuzioni originali del Modello B hanno raggiunto un limite di passaggi prima del completamento. La loro durata misurata rappresenta quindi un limite inferiore per il task completo.
Anche la qualità di completamento richiede un’osservazione continua. Asana riferisce che tutte le esecuzioni nelle condizioni migliori hanno trovato i fatti richiesti e prodotto risposte corrette. Il materiale pubblico non include carichi di lavoro dei clienti né tassi di errore a lungo termine.
La replica indipendente resta limitata perché lo studio completo dipende dall’implementazione e dalle tracce di Asana. L’azienda ha condiviso i propri metodi e uno studio più completo, ma i team esterni hanno comunque bisogno delle proprie suite di task.
L’acquisizione di StackAI da parte dell’azienda crea inoltre un interesse commerciale nel risultato. Asana ha completato l’acquisizione di StackAI nel maggio 2026 per espandere i flussi di lavoro degli agenti tra sistemi diversi.
OpenAI ha un interesse simile nel mostrare come GPT-6 Astra e GPT-6.1 Sol supportino gli agenti aziendali. Entrambe le fonti primarie forniscono preziosi dettagli tecnici, ma nessuna delle due rappresenta una verifica indipendente del settore.
Anche le condizioni operative possono cambiare il risultato. La disponibilità della cache ha una durata limitata. Clienti concorrenti possono avere cronologie differenti e il contesto personalizzato può ridurre la quantità di materiale condiviso.
I requisiti di privacy possono limitare quali contenuti entrano nel contesto del modello. I team di sicurezza necessitano inoltre di controlli per screenshot, credenziali, record dei clienti e informazioni sensibili raccolte durante la navigazione.
Il caching non elimina questi obblighi. Modifica il comportamento computazionale e di fatturazione, non la necessità di una governance dei dati. I team hanno comunque bisogno di policy di conservazione, controlli di accesso, tracce di audit e gestione degli errori.
La conclusione corretta è quindi condizionale. Asana ha individuato un’ottimizzazione di alto valore per uno specifico agente browser e l’ha portata in produzione. Gli altri team dovrebbero considerare il meccanismo come un’ipotesi verificabile.
Il prossimo test è la performance nei flussi di lavoro reali dei clienti
I prossimi tre segnali mostreranno se il risultato di Asana diventerà un modello operativo riutilizzabile o resterà un solido caso di studio interno.
Il primo segnale è una copertura di valutazione più ampia. Asana afferma di stare sviluppando strumenti che consentano a clienti e team interni di confrontare costo, tempo di esecuzione e qualità delle risposte durante la configurazione degli agenti.
Queste valutazioni devono includere task che vadano oltre l’estrazione strutturata da cataloghi. Le suite di test utili dovrebbero comprendere siti web mutevoli, applicazioni autenticate, fallimenti parziali, lunghi percorsi di navigazione e istruzioni con punti di arresto ambigui.
Se la stessa policy della cronologia migliora questi flussi di lavoro, le argomentazioni a favore dell’ottimizzazione guidata dall’architettura diventano più forti. Se i guadagni si riducono, la configurazione scelta da Asana potrebbe essere strettamente legata all’estrazione ripetitiva.
Il secondo segnale è costituito dalle prove dell’adozione in produzione. Asana ha già distribuito le modifiche alla navigazione browser su StackAI, ma non ha pubblicato risultati aggregati dei clienti.
Il tasso di completamento dovrebbe contare più del costo per chiamata. Una richiesta meno costosa offre poco valore se i clienti devono rieseguire i job o riparare manualmente output incompleti.
I team dovrebbero anche monitorare la quota di input servita dalla cache, la durata mediana dei task, i fallimenti dovuti al limite di passaggi e i tassi di intervento umano. Queste misure rivelano se il design ottimizzato regge a un traffico di produzione variabile.
Il terzo segnale è la risposta dei provider di modelli e delle piattaforme di agenti concorrenti. Il prompt caching è diventato una funzionalità di prodotto, ma è l’architettura dell’applicazione a determinare se gli sviluppatori possano trarne vantaggio.
I provider possono competere attraverso una maggiore durata della cache, una diagnostica migliore, tariffe inferiori per gli input memorizzati nella cache e dati di utilizzo più chiari. I framework per agenti possono esporre policy della cronologia senza costringere ogni cliente a costruire strumentazione personalizzata.
OpenAI presenta GPT-6.1 Sol come un modello per lavoro agentico capace, con un costo operativo inferiore rispetto a GPT-6 Astra. Lo studio di Asana offre a questo posizionamento un esempio applicativo concreto.
Tuttavia, la pressione competitiva più forte ricade sui team che sviluppano software per agenti. I clienti si aspetteranno sempre più che le piattaforme ottimizzino automaticamente il costo totale dei task, anziché esporre soltanto un selettore di modelli.
Una piattaforma matura dovrebbe raccomandare limiti di contesto in base al comportamento osservato. Dovrebbe identificare le modifiche che interrompono la cache, confrontare le policy e avvisare quando la potatura induce l’agente a rivisitare pagine precedenti.
Dovrebbe inoltre conservare prove esterne sufficienti affinché gli esseri umani possano verificare il risultato. Un agente browser ha bisogno di una memoria di lavoro delimitata, mentre l’organizzazione necessita di un record operativo completo.
Asana prevede di incorporare test simili nel proprio sistema di valutazione. Sta inoltre usando GPT-6 Astra in Codex per navigare le funzionalità del prodotto, provare diversi input e segnalare bug ai revisori umani.
Questa estensione amplia la storia oltre un singolo agente browser. Asana sta verificando se gli agenti di ingegneria possano valutare continuamente altri agenti e funzionalità di prodotto.
L’opportunità è chiara. La sperimentazione automatizzata può valutare più configurazioni di quante un piccolo team di ingegneria potrebbe testare manualmente. Può inoltre abbreviare il percorso dall’analisi delle tracce alle modifiche di codice sottoposte a revisione.
Il vincolo è altrettanto chiaro. L’attenzione umana diventa la risorsa scarsa quando gli agenti possono generare continuamente esperimenti, risultati e patch. I team devono decidere quali risultati meritino fiducia ed esposizione in produzione.
Per gli sviluppatori, l’azione immediata è misurare task completi anziché chiamate isolate. Registrate i rapporti di cache hit, la qualità di completamento, il tempo di esecuzione, i tentativi ripetuti e il lavoro umano di riparazione in condizioni realistiche.
Per gli acquirenti aziendali, chiedete ai fornitori come i loro agenti gestiscono cronologie in crescita. Il nome di un modello da solo non rivela se il sistema circostante conservi il contesto utile o paghi ripetutamente per elaborarlo.
Per i knowledge worker, il cambiamento promette un’automazione browser più veloce e capace. Il suo valore dipenderà dalla capacità degli agenti di conservare i fatti necessari senza esporre dati sensibili o divagare attraverso passaggi non necessari.
Il risultato dell’agente browser di Asana sostiene in modo persuasivo che la progettazione del contesto debba ormai affiancare la selezione del modello in ogni valutazione degli agenti. La prossima domanda è se questa lezione valga nei flussi di lavoro complessi che i clienti desiderano davvero automatizzare.
