La ricerca web ereditata dal tuo agente non è sufficiente

Un agente che ha bisogno del mondo esterno

Un ingegnere di un'azienda di software sta creando un agente per mantenere aggiornata la visione del mercato dell'azienda. Monitora centinaia di migliaia di prospect e account cliente alla ricerca di segnali che indichino un'apertura al contatto: un nuovo round di finanziamento, un cambio di leadership, il lancio di un prodotto o un picco di assunzioni che indichi disponibilità di budget.

I record degli account si trovano già in Databricks, in tabelle Delta gestite da Unity Catalog e unite ai dati di utilizzo e di pipeline dell'azienda. Ma i segnali che muovono un account si trovano all'esterno dell'azienda, sul web. Il compito dell'agente è unire i due aspetti, continuamente, in un quadro coerente e aggiornato all'ultimo minuto di ogni account, in modo da poter indicare a un venditore quali contattare questa settimana.

Versione 1.0: un disordine gestibile

La prima versione non è un unico sistema. È la stessa logica di arricchimento, ricostruita da zero tre volte diverse, una per ogni strumento utilizzato dall'ingegnere. Il primo passaggio viene eseguito in Claude Code, dove le parti agentiche (decidere quali account necessitano di una nuova analisi, concatenare le ricerche, scrivere il riepilogo) costituiscono la maggior parte del lavoro. Quando un collega menziona che Codex gestisce un certo tipo di scripting batch più velocemente, l'ingegnere trasferisce il ciclo di arricchimento per fare una verifica. Una terza copia salta completamente l'harness e chiama un modello direttamente tramite API, per un job notturno leggero che richiede solo un singolo prompt e una risposta, senza bisogno di orchestrazione degli strumenti. Stesso lavoro, tre build, ognuna modellata dallo strumento più adatto in quel momento.

Ogni harness include i propri strumenti e la propria ricerca web e li collega a modo suo, costringendo l'ingegnere a creare la stessa logica di arricchimento tre volte, una per ogni formato di configurazione dell'harness. Ed è così che se ne va la giornata. Invece di migliorare il modo in cui gli account vengono arricchiti, l'ingegnere sta imparando come Claude Code vuole che vengano dichiarati i suoi strumenti, perché lo stesso server MCP si connette in modo diverso in Codex e cosa manca al percorso API non elaborato che gli altri due offrivano già pronto.

Gli strumenti non sono equivalenti, e quindi non lo sono nemmeno i risultati. La ricerca web integrata in un harness restituisce dati diversi rispetto a un altro. Una fonte raggiungibile in uno viene persa in un altro. Gli strumenti di ricerca web integrati per i LLM possono trovare informazioni di alto livello come i round di finanziamento e i cambi di leadership, ma trascurano dettagli granulari come le modifiche allo stack tecnologico. L'accesso alle informazioni online è proprio il motivo per cui questo agente esiste, ma la sua qualità ora dipende da una ricerca web che non riesce a far emergere in modo affidabile i dettagli chiave sul web.

E non c'è nulla al di sopra di questi tre sistemi. Nessun sistema di misurazione condiviso, quindi nessuno può vedere o limitare il costo di un ciclo su centinaia di migliaia di account. Nessun regolamento condiviso, quindi le fonti che un agente può leggere e il momento in cui è necessaria l'approvazione umana sono impostati in tre modi diversi o non lo sono affatto. Nessun registro condiviso, quindi quando un risultato è errato, non c'è modo di ricostruire ciò che l'agente ha letto, speso o deciso.

In un certo senso funziona, perché produce un risultato. Ed è esattamente per questo che non viene mai sistemato. Funziona abbastanza bene da essere mantenuto, ma non abbastanza da potersi fidare ciecamente.

Omnigent: una sola definizione, qualsiasi harness

Omnigent è il livello che frena questa frammentazione. Si posiziona al di sopra dei singoli harness, consentendo all'ingegnere di definire l'agente una sola volta: il modello su cui viene eseguito, gli strumenti a cui può accedere, le policy e i limiti entro cui opera. Le tre ricostruzioni si riducono a un'unica definizione e l'attenzione dell'ingegnere torna all'arricchimento degli account. Gli strumenti non sono più semplicemente quelli integrati in ogni harness, ma diventano dichiarazioni sull'agente, impostate una sola volta e sostituite liberamente. Eseguendo il processo su un modello ospitato su Databricks, le chiamate al modello vengono instradate attraverso le Foundation Model API, dove ogni chiamata viene registrata per costi, audit e governance in un unico punto, anziché essere dispersa in tre runtime diversi. E quando il modello o i fattori economici cambiano, l'ingegnere modifica una sola riga, scegliendo un nuovo modello o passando a uno più economico senza alcuna interruzione.

Questo risolve la maggior parte della frammentazione, ma lascia un elemento critico deciso per impostazione predefinita anziché per scelta progettuale. La ricerca web è una delle funzionalità principali integrate in ogni harness, e non ce ne sono due che includano la stessa. La stessa query fornisce un risultato tramite Claude Code e un altro tramite Codex. Omnigent offre la possibilità di definire una scelta coerente per ogni task, ma non prende la decisione al posto tuo. È necessario assegnare una funzionalità di ricerca partner. Con un partner come Nimble, puoi inserire nello slot un elemento che si adatta al task, offrendo a ogni harness sottostante la stessa lettura esperta.

Nimble: riempire lo slot di ricerca

La Search API di Nimble può basare le risposte su dati web freschi e in tempo reale tramite la ricerca live. Per i task di ricerca approfondita, i Web Search Agents di Nimble automatizzano la ricerca web e l'orchestrazione dell'estrazione per completare il task, analizzando molteplici fonti, incrociandole e restituendo una risposta completa di citazioni a supporto di ogni affermazione, un audit trail che un percorso generico non potrebbe mai produrre.

Mentre gli strumenti di ricerca web generici trattano ogni caso d'uso allo stesso modo, Nimble si specializza nel caso d'uso specifico dell'agente, apprende autonomamente i migliori metodi di recupero e adatta la ricerca web e il crawling per andare a fondo nel dominio e acquisire dati che gli strumenti di ricerca generici trascurano. Raggiunge i dati protetti da JavaScript, filtri e paginazione su cui un normale crawler si arrenderebbe. E poiché ricorda il modo migliore per recuperare i dati rilevanti, riutilizza i percorsi di recupero dei dati anziché riscoprire tutto da zero, riducendo i costi dei token. Indicato come provider nella configurazione, questo rappresenta il percorso più rapido per ottenere un contesto web più completo per i tuoi agenti.

Nei test di Nimble, l'aggiunta della ricerca web di Nimble ha aumentato l'accuratezza del benchmark LLM dal 46% al 71%, dimezzando al contempo i costi di ricerca web (costi di ricerca web di Claude rispetto a Nimble). I Web Search Agents possono essere indirizzati verso un dominio e mantenuti lì, in modo da ricordare quali fonti e quali percorsi di recupero hanno prodotto i dati corretti e riutilizzarli la volta successiva. Diventa più preciso quanto più a lungo lavora su un dominio, e il costo per riscoprire dove si trova un segnale diminuisce per gli account su cui viene eseguito più spesso.

Versione 2.0: creata una sola volta, su Databricks e Nimble

Tornando all'ingegnere, l'agente è ora sulla buona strada per diventare un insieme coerente, gestibile e affidabile. L'agente viene definito una sola volta in Omnigent, su un modello ospitato su Databricks, con i suoi strumenti, le sue policy e i suoi limiti in un'unica specifica. Le tre ricostruzioni sono un ricordo del passato. Così come la fatica del cablaggio; l'ingegnere è tornato a occuparsi dell'arricchimento, non di come ogni harness voglia che vengano dichiarati i suoi strumenti.

La ricerca web ora è un'unica decisione invece di tre. Specificare Nimble nel builtin web_search indirizza ogni harness sottostante alla stessa Nimble Search API per una ricerca web rapida ed efficiente:

Per gli account che necessitano di una risposta giustificabile piuttosto che di dati web grezzi, Omnigent può ricorrere ai Web Search Agents di Nimble, che automatizzano la ricerca web e l'estrazione per attività di ricerca, arricchimento o creazione di dataset.

La chiave proviene da un account Nimble, che puoi attivare gratuitamente.

Il controllo ora ha un'unica sede. Le chiamate al modello vengono instradate attraverso le Foundation Model API sotto governance, i costi sono visibili e limitati in un unico punto, e ciò che l'agente legge, spende e decide viene registrato in modo coerente su un'unica superficie di governance.

Le due metà del quadro finalmente si uniscono. I record interni in Databricks e i segnali esterni di Nimble, in un unico posto, gestiti e letti da un solo agente. La versione 1.0 era composta da tre harness e nessun punto di osservazione privilegiato. Questo è un unico agente, basato su ciò che l'azienda sa e su ciò che il web può dirle, in esecuzione dove si trovano già i dati. Coerente dove prima tendeva a deviare, approfondito dove prima era superficiale, e con una governance completa sul recupero del contesto web esterno.

Provalo oggi stesso

La configurazione richiede due passaggi.

Connetti Omnigent a Databricks. Databricks esegue il server Omnigent per te. Sulla tua macchina, installa la CLI con l'integrazione Databricks e registra la macchina come host:

Quindi accedi con l'identità del tuo workspace ed esegui il tuo primo agente su un modello ospitato su Databricks. Omnigent su Databricks è il punto di partenza; copre la configurazione gestita end-to-end e rimanda ai passaggi della CLI. Due prerequisiti da verificare prima: la Beta di Omnigent deve essere abilitata per il tuo workspace, e il workspace deve trovarsi in una regione che supporta Unity AI Gateway. Per altri metodi di installazione e requisiti, consulta la guida all'installazione completa.

I tuoi agenti vengono eseguiti sul server gestito, quindi le stesse sessioni ti seguono su ogni superficie:

• il terminale, dove hai installato
• l'app desktop, una finestra nativa con notifiche e un badge nel dock per gli agenti in attesa
• dispositivi mobili, app native iOS e Android, o la web UI in qualsiasi browser del telefono, inserendo l'URL del tuo workspace

Indirizza la ricerca su Nimble. Indica Nimble nel builtin web_search, la modifica di una sola riga menzionata in precedenza, e ogni agente ospitato su Databricks baserà le sue risposte su di esso. Per un lavoro giustificabile e verificabile, ricorri al pass di ricerca. La documentazione del connettore Nimble copre entrambi gli aspetti. Avrai bisogno di una chiave Nimble, avvia una prova gratuita per ottenerne una.

I dati interni sono già tuoi. Questo è ciò che serve per consentire ai tuoi agenti di ragionare sul resto del web, con la stessa piattaforma che gestisce entrambe le parti.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale