A busca na web que seu agente herdou não é boa o suficiente

Um agente que precisa do mundo exterior

Um engenheiro em uma empresa de software está criando um agente para manter a visão de mercado da empresa atualizada. Ele monitora centenas de milhares de clientes em potencial e contas de clientes em busca de sinais de que uma conta está aberta para engajamento: uma nova rodada de financiamento, uma mudança de liderança, o lançamento de um produto ou um aumento nas contratações que indique orçamento disponível.

Os registros de contas já estão no Databricks, em tabelas Delta governadas pelo Unity Catalog e integradas aos dados de uso e pipeline da própria empresa. Mas os sinais que movimentam uma conta estão fora da empresa, na web. O trabalho do agente é combinar os dois, continuamente, em uma visão única, coerente e atualizada de cada conta, para que ele possa indicar a um vendedor para quais contas ligar nesta semana.

Versão 1.0: uma bagunça funcional

A primeira versão não é um sistema único. É a mesma lógica de enriquecimento, reconstruída do zero três vezes distintas, uma em cada ferramenta que o engenheiro utilizou. A primeira etapa é executada no Claude Code, onde as partes de agente (decidir quais contas precisam de uma nova análise, encadear buscas, escrever o resumo) representam a maior parte do trabalho. Quando um colega menciona que o Codex lida com um certo tipo de script em lote de forma mais rápida, o engenheiro porta o loop de enriquecimento para testar. Uma terceira cópia ignora totalmente a estrutura de suporte (harness) e chama um modelo diretamente pela API, para uma tarefa noturna leve que precisa apenas de um único prompt e uma resposta, sem necessidade de orquestração de ferramentas. O mesmo trabalho, três versões, cada uma moldada pela ferramenta que melhor se adaptava àquele momento.

Cada harness agrupa suas próprias ferramentas e sua própria busca na web e as conecta de sua própria maneira, de modo que o engenheiro cria a mesma lógica de enriquecimento três vezes, uma no formato de configuração de cada harness. É aí que o dia vai embora. Em vez de melhorar a forma como as contas são enriquecidas, o engenheiro está aprendendo como o Claude Code quer que suas ferramentas sejam declaradas, por que o mesmo servidor MCP se conecta de forma diferente no Codex e o que falta no caminho bruto da API que os outros dois ofereciam nativamente.

As ferramentas não são equivalentes e, portanto, os resultados também não são. A busca na web integrada em um harness retorna dados diferentes do outro. Uma fonte acessível em um é perdida no outro. Ferramentas integradas de busca na web para LLMs podem encontrar informações de alto nível, como rodadas de financiamento e mudanças de liderança, mas perdem detalhes granulares, como mudanças na pilha de tecnologia (tech stack). O acesso a informações online é a razão de ser deste agente, mas sua qualidade agora depende de uma busca na web que não consegue trazer detalhes importantes de forma confiável.

E não há nada acima dos três. Nenhum medidor compartilhado, de modo que ninguém consegue ver ou limitar o custo de um ciclo em centenas de milhares de contas. Nenhuma regra compartilhada, de modo que as fontes que um agente pode ler e o momento em que um humano dá a aprovação são definidos de três maneiras diferentes ou simplesmente não são definidos. Nenhum registro compartilhado, de modo que, quando um resultado está errado, não há onde reconstruir o que o agente leu, gastou ou decidiu.

Funciona mais ou menos, no sentido de que gera um resultado. E é exatamente por isso que nunca é corrigido. Funciona bem o suficiente para ser mantido, mas não o suficiente para que se confie totalmente nele.

Omnigent: uma definição, qualquer harness

O Omnigent é a camada que controla essa dispersão. Ele fica acima dos harnesses individuais, permitindo que o engenheiro defina o agente uma única vez, bem como o modelo no qual ele é executado, as ferramentas que ele pode acessar e as políticas e limites sob os quais ele opera. As três reconstruções se reduzem a uma única definição, e a atenção do engenheiro volta para o enriquecimento de contas. As ferramentas deixam de ser o que quer que viesse integrado em cada harness e passam a ser declarações no agente, definidas uma vez e trocadas livremente. Sendo executadas em um modelo hospedado no Databricks, as chamadas de modelo são roteadas por meio das Foundation Model APIs, onde cada chamada é registrada para fins de custo, auditoria e governança em um único lugar, em vez de ficarem espalhadas por três ambientes de execução (runtimes). E quando o modelo ou os custos mudam, o engenheiro altera uma única linha, escolhendo um novo modelo ou migrando para um mais barato sem interrupções.

Isso elimina a maior parte da dispersão, mas deixa um aspecto crítico decidido por padrão (default) em vez de por planejamento. A busca na web é uma das principais capacidades que cada harness traz integrada, e não há dois que tragam a mesma. A mesma consulta gera um resultado no Claude Code e outro no Codex. O Omnigent oferece a capacidade de definir uma escolha consistente para cada tarefa, mas não toma a decisão por você. Você precisa atribuir uma capacidade de busca parceira. Com um parceiro como o Nimble, você pode colocar no espaço disponível algo que se adapte à tarefa e dar a cada harness subjacente a mesma leitura especializada.

Nimble: preenchendo o espaço de busca

A Search API do Nimble pode embasar respostas em dados da web recentes e em tempo real por meio de busca ao vivo. Para tarefas de pesquisa profunda, os Web Search Agents do Nimble automatizam a busca na web e a orquestração de extração para realizar sua tarefa, trabalhando com várias fontes, cruzando dados e retornando uma resposta com as citações para embasar cada afirmação — uma trilha de auditoria que o caminho geral nunca conseguiria produzir.

Enquanto as ferramentas gerais de busca na web tratam todos os casos de uso da mesma forma, o Nimble se especializa no caso de uso específico do agente, aprende sozinho os melhores métodos de recuperação e adapta a busca e o rastreamento (crawling) na web para se aprofundar no domínio e capturar dados que as ferramentas de busca genéricas perdem. Ele alcança os dados por trás de JavaScript, filtros e paginação que um rastreador (crawler) comum abandonaria. E como ele se lembra da melhor maneira de recuperar os dados relevantes, ele reutiliza os caminhos de recuperação de dados em vez de redescobrir tudo do zero, reduzindo os custos de tokens. Definido como o provedor na configuração (config), este é o caminho mais rápido para um contexto web mais completo para seus agentes.

Nos testes do Nimble, a adição da busca na web do Nimble aumentou a precisão do benchmark de LLM de 46% para 71%, enquanto cortou os custos de busca na web pela metade (custos de busca na web do Claude vs. Nimble). Os Web Search Agents podem ser direcionados a um domínio e mantidos lá, de modo que ele se lembra de quais fontes e caminhos de recuperação produziram os dados corretos e os reutiliza na próxima vez. Ele se torna mais preciso quanto mais tempo trabalha em um domínio, e o custo de redescobrir onde um sinal está localizado cai nas contas em que ele é mais executado.

Versão 2.0: criada uma vez, no Databricks e no Nimble

Voltando ao engenheiro, o agente agora está no caminho para se tornar um conjunto coerente, gerenciável e confiável. O agente é definido uma única vez no Omnigent, em um modelo hospedado no Databricks, com suas ferramentas, políticas e limites em uma única especificação (spec). As três reconstruções desapareceram. O mesmo vale para o esforço de integração (plumbing tax); o engenheiro voltou a focar no enriquecimento, e não em como cada harness quer que suas ferramentas sejam declaradas.

A busca na web agora é uma única decisão em vez de três. Definir o Nimble no recurso integrado web_search direciona cada harness subjacente para a mesma Nimble Search API para uma busca na web rápida e eficiente:

Para as contas que precisam de uma resposta justificável em vez de dados brutos da web, o Omnigent pode recorrer aos Web Search Agents do Nimble, que automatizam a busca e a extração na web para pesquisa, enriquecimento ou criação de conjuntos de dados (datasets).

A chave vem de uma conta do Nimble, que você pode começar gratuitamente.

O controle agora tem um único lar. As chamadas de modelo são roteadas pelas Foundation Model APIs sob governança, o custo é visível e limitado em um só lugar, e o que o agente lê, gasta e decide é registrado de forma consistente em uma única interface de governança.

E as duas metades do cenário finalmente se unem. O registro interno no Databricks e o sinal externo do Nimble, em um só lugar, governados e lidos por um único agente. A Versão 1.0 consistia em três harnesses e nenhum ponto de vista unificado. Este é um único agente, baseado no que a empresa sabe e no que a web pode lhe dizer, sendo executado onde os dados já estão. Consistente onde antes oscilava, profundo onde antes era superficial, e com governança total sobre a recuperação de contexto web externo.

Experimente hoje mesmo

A configuração exige apenas duas etapas.

Conecte o Omnigent ao Databricks. O Databricks executa o servidor Omnigent para você. Em sua própria máquina, instale a CLI com a integração do Databricks e registre a máquina como um host:

Em seguida, faça login com a identidade do seu workspace e execute seu primeiro agente em um modelo hospedado no Databricks. Omnigent no Databricks é o ponto de partida; ele aborda a configuração gerenciada de ponta a ponta e traz os links para as etapas da CLI. Dois pré-requisitos a serem verificados primeiro: o Omnigent Beta deve estar habilitado para o seu workspace, e o workspace deve estar em uma região que ofereça suporte ao Unity AI Gateway. Para outros métodos de instalação e requisitos, consulte a referência de instalação completa.

Seus agentes são executados no servidor gerenciado, de modo que as mesmas sessões acompanham você em todas as interfaces:

• o terminal, onde você instalou
• o aplicativo de desktop, uma janela nativa com notificações e um selo no dock para agentes esperando por você
• dispositivos móveis, aplicativos nativos de iOS e Android, ou a UI web em qualquer navegador de celular, inserindo a URL do seu workspace

Direcione a busca para o Nimble. Nomeie o Nimble no recurso integrado web_search, a alteração de uma única linha mencionada anteriormente, e cada agente hospedado no Databricks fundamenta suas respostas nele. Para um trabalho defensável e auditável, recorra ao passe de pesquisa. A documentação do conector do Nimble aborda ambos. Você precisará de uma chave do Nimble, inicie um teste gratuito para obter uma.

O registro interno já é seu. Isso é o que é necessário para permitir que seus agentes raciocinem sobre o restante da web, com a mesma plataforma contendo ambas as partes.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original