Die Websuche, die Ihr Agent geerbt hat, ist nicht gut genug

Ein Agent, der die Außenwelt braucht

Ein Softwareentwickler baut einen Agenten, um die Marktübersicht des Unternehmens aktuell zu halten. Er überwacht einige hunderttausend potenzielle Kunden und Kundenkonten auf Signale, die auf eine Interaktionsbereitschaft hindeuten: eine neue Finanzierungsrunde, ein Führungswechsel, ein Produktlaunch oder eine Einstellungswelle, die auf ein freies Budget hinweist.

Die Kontodaten befinden sich bereits in Databricks, in Delta-Tabellen, die von Unity Catalog verwaltet und mit den eigenen Nutzungs- und Pipeline-Daten des Unternehmens verknüpft sind. Aber die Signale, die ein Konto in Bewegung bringen, liegen außerhalb des Unternehmens im Web. Die Aufgabe des Agenten ist es, beide Welten kontinuierlich zu einem konsistenten und topaktuellen Bild jedes Kontos zusammenzuführen, um dem Vertriebsteam zu zeigen, welche Konten diese Woche kontaktiert werden sollten.

Version 1.0: Ein brauchbares Chaos

Die erste Version ist kein einzelnes System. Es ist dieselbe Anreicherungslogik, die dreimal unabhängig voneinander von Grund auf neu erstellt wurde – jeweils in dem Tool, das dem Entwickler gerade zur Hand war. Der erste Durchlauf läuft in Claude Code, wo die agentischen Teile (die Entscheidung, welche Konten neu geprüft werden müssen, das Verketten von Suchen, das Schreiben der Zusammenfassung) den Großteil der Arbeit ausmachen. Als ein Kollege erwähnt, dass Codex eine bestimmte Art von Batch-Scripting schneller erledigt, portiert der Entwickler die Anreicherungsschleife dorthin, um es zu testen. Eine dritte Kopie umgeht das Harness komplett und ruft ein Modell direkt über die API auf – für einen leichtgewichtigen nächtlichen Job, der nur einen einzigen Prompt und eine Antwort benötigt, ganz ohne Tool-Orchestrierung. Dieselbe Aufgabe, drei Builds, jeweils geprägt von dem Tool, das in diesem Moment am besten passte.

Jedes Harness bündelt seine eigenen Tools sowie seine eigene Websuche und verknüpft sie auf seine eigene Weise. Der Entwickler baut also dieselbe Anreicherungslogik dreimal auf – einmal in jedem Konfigurationsformat des jeweiligen Harness. Und so vergeht der Tag. Anstatt die Anreicherung der Konten zu verbessern, lernt der Entwickler, wie Claude Code seine Tools deklariert haben möchte, warum sich derselbe MCP-Server in Codex anders verbindet und was dem rohen API-Pfad fehlt, was die anderen beiden kostenlos mitbrachten.

Die Tools sind nicht gleichwertig, und das gilt auch für die Ergebnisse. Die in einem Harness integrierte Websuche liefert andere Daten als die nächste. Eine Quelle, die in dem einen erreichbar ist, wird im anderen übersehen. Integrierte Websuch-Tools für LLMs können zwar allgemeine Informationen wie Finanzierungsrunden und Führungswechsel finden, übersehen aber granulare Details wie Änderungen im Tech-Stack. Der Zugriff auf Online-Informationen ist genau der Grund, warum dieser Agent existiert, aber seine Qualität hängt nun von einer Websuche ab, die wichtige Details im Web nicht zuverlässig finden kann.

Und es gibt keine übergeordnete Instanz für diese drei Systeme. Kein gemeinsames Messinstrument, sodass niemand sehen oder begrenzen kann, was ein Durchlauf für einige hunderttausend Konten kostet. Kein gemeinsames Regelwerk, sodass die Quellen, die ein Agent lesen darf, und der Zeitpunkt, an dem ein Mensch zustimmt, auf drei verschiedene Arten oder gar nicht festgelegt sind. Kein gemeinsames Protokoll, sodass bei einem fehlerhaften Ergebnis nirgends rekonstruiert werden kann, was der Agent gelesen, ausgegeben oder entschieden hat.

Es funktioniert halbwegs, da es ein Ergebnis liefert. Und genau das ist der Grund, warum es nie repariert wird. Es funktioniert gut genug, um es zu behalten, aber nicht gut genug, um ihm vollends zu vertrauen.

Omnigent: Eine Definition, beliebiges Harness

Omnigent ist die Ebene, die dem Wildwuchs Einhalt gebietet. Sie liegt über den einzelnen Harnesses, sodass der Entwickler den Agenten nur einmal definieren muss: das Modell, auf dem er läuft, die Tools, auf die er zugreifen kann, sowie die Richtlinien und Limits, innerhalb derer er agiert. Die drei separaten Builds verschmelzen zu einer einzigen Definition, und der Entwickler kann sich wieder voll auf die Konto-Anreicherung konzentrieren. Tools sind nicht mehr das, was jedes Harness standardmäßig mitbringt, sondern werden zu Deklarationen auf dem Agenten – einmal festgelegt und frei austauschbar. Bei der Ausführung auf einem von Databricks gehosteten Modell werden die Modellaufrufe über die Foundation Model APIs geleitet, wo jeder Aufruf für Kosten, Audit und Governance an einem zentralen Ort erfasst wird, anstatt über drei Runtimes verstreut zu sein. Und wenn sich das Modell oder die wirtschaftlichen Rahmenbedingungen ändern, passt der Entwickler einfach eine einzige Zeile an, wählt ein neues Modell oder wechselt ohne Unterbrechung zu einer günstigeren Variante.

Damit ist der Großteil des Wildwuchses beseitigt, aber eine entscheidende Sache bleibt standardmäßig statt gezielt geregelt. Die Websuche ist eine der Kernfunktionen, die jedes Harness mitbringt, und keine zwei bündeln dieselbe. Dieselbe Suchanfrage liefert über Claude Code ein anderes Ergebnis als über Codex. Omnigent bietet Ihnen die Möglichkeit, für jede Aufgabe eine konsistente Auswahl zu definieren, nimmt Ihnen diese Entscheidung jedoch nicht ab. Sie müssen eine Partner-Suchfunktion zuweisen. Mit einem Partner wie Nimble können Sie stattdessen eine Lösung integrieren, die sich an die jeweilige Aufgabe anpasst, und jedem darunter liegenden Harness dieselbe präzise Analyse bieten.

Nimble: Den Such-Slot füllen

Die Search-API von Nimble kann Antworten durch Live-Suche mit aktuellen Echtzeit-Webdaten untermauern. Für tiefgehende Rechercheaufgaben automatisieren die Web Search Agents von Nimble die Websuche und die Extraktions-Orchestrierung, um Ihre Aufgabe zu erfüllen. Sie nutzen zahlreiche Quellen, gleichen diese ab und liefern eine Antwort mit entsprechenden Quellenangaben für jede Behauptung – ein Audit-Trail, den der allgemeine Weg niemals erzeugen könnte.

Während allgemeine Websuch-Tools jeden Anwendungsfall gleich behandeln, spezialisiert sich Nimble auf den spezifischen Anwendungsfall des Agenten, lernt selbstständig die besten Abrufermethoden und passt Websuche und Crawling so an, dass sie tief in die Domain eindringen, um Daten zu erfassen, die generische Suchwerkzeuge übersehen. Nimble gelangt an Daten hinter JavaScript, Filtern und Paginierungen, bei denen ein gewöhnlicher Crawler aufgibt. Und weil es sich den besten Weg zum Abrufen der relevanten Daten merkt, verwendet es Datenabruf-Pfade wieder, anstatt alles von Grund auf neu zu suchen, was die Token-Kosten senkt. Wenn Nimble in der Konfiguration als Anbieter angegeben ist, ist dies der schnellste Weg zu einem vollständigeren Web-Kontext für Ihre Agenten.

In den Tests von Nimble steigerte das Hinzufügen der Websuche von Nimble die LLM-Benchmark-Genauigkeit von 46 Prozent auf 71 Prozent, während die Kosten für die Websuche halbiert wurden (Claude vs. Nimble Websuch-Kosten). Web Search Agents können auf eine Domain ausgerichtet und dort gehalten werden, sodass sie sich merken, welche Quellen und Abruf-Pfade die richtigen Daten geliefert haben, und diese beim nächsten Mal wiederverwenden. Je länger sie in einer Domain arbeiten, desto präziser werden sie, und die Kosten für das erneute Auffinden von Signalen sinken bei den am häufigsten geprüften Konten.

Version 2.0: Einmal gebaut, auf Databricks und Nimble

Zurück zu unserem Entwickler: Der Agent ist nun auf dem besten Weg, ein konsistentes, verwaltbares und vertrauenswürdiges Ganzes zu werden. Der Agent wird einmal in Omnigent auf einem von Databricks gehosteten Modell definiert, wobei seine Tools, Richtlinien und Limits in einer einzigen Spezifikation festgelegt sind. Die drei separaten Builds gehören der Vergangenheit an. Ebenso der Integrationsaufwand; der Entwickler konzentriert sich wieder auf die Anreicherung und nicht darauf, wie jedes Harness seine Tools deklariert haben möchte.

Die Websuche ist jetzt eine einzige Entscheidung statt drei. Die Angabe von Nimble im web_search-Builtin leitet jedes darunter liegende Harness an dieselbe Nimble Search-API für eine schnelle und effiziente Websuche weiter:

Für Konten, die eine fundierte Antwort anstelle von rohen Webdaten benötigen, kann Omnigent auf die Web Search Agents von Nimble zugreifen, die die Websuche und -extraktion für Recherche, Anreicherung oder den Aufbau von Datensätzen automatisieren.

Der Schlüssel stammt von einem Nimble-Konto, das Sie kostenlos erstellen können.

Die Kontrolle hat nun ein zentrales Zuhause. Modellaufrufe werden kontrolliert über die Foundation Model APIs geleitet, Kosten sind an einem Ort sichtbar und begrenzt, und was der Agent liest, ausgibt und entscheidet, wird konsistent über eine einzige Governance-Oberfläche erfasst.

Und die beiden Hälften des Bildes fügen sich endlich zusammen. Der interne Datensatz in Databricks und das externe Signal von Nimble an einem Ort, verwaltet und gelesen von einem einzigen Agenten. Version 1.0 bestand aus drei Harnesses und bot keine klare Perspektive. Dies ist ein einzelner Agent, der auf dem Wissen des Unternehmens und den Informationen aus dem Web basiert und dort läuft, wo sich die Daten bereits befinden. Konsistent, wo es früher Abweichungen gab, tiefgehend, wo es früher oberflächlich war, und mit vollständiger Governance über den Abruf externer Web-Kontexte.

Probieren Sie es heute aus

Die Einrichtung erfordert zwei Schritte.

Verbinden Sie Omnigent mit Databricks. Databricks führt den Omnigent-Server für Sie aus. Installieren Sie auf Ihrem eigenen Rechner die CLI mit der Databricks-Integration und registrieren Sie den Rechner als Host:

Melden Sie sich dann mit Ihrer Workspace-Identität an und führen Sie Ihren ersten Agenten auf einem von Databricks gehosteten Modell aus. Omnigent auf Databricks ist der ideale Ausgangspunkt; hier wird die verwaltete Einrichtung durchgängig beschrieben und die CLI-Schritte werden verlinkt. Zwei Voraussetzungen müssen vorab geprüft werden: Die Omnigent-Beta muss für Ihren Workspace aktiviert sein und der Workspace muss sich in einer Region befinden, die das Unity AI Gateway unterstützt. Weitere Installationsmethoden und Anforderungen finden Sie in der vollständigen Installationsreferenz.

Ihre Agenten laufen auf dem verwalteten Server, sodass dieselben Sitzungen Sie über alle Oberflächen hinweg begleiten:

• das Terminal, in dem Sie die Installation vorgenommen haben
• die Desktop-App, ein natives Fenster mit Benachrichtigungen und einem Dock-Symbol für Agenten, die auf Sie warten
• Mobilgeräte, native iOS- und Android-Apps oder die Web-UI in jedem Smartphone-Browser durch Eingabe Ihrer Workspace-URL

Richten Sie die Suche auf Nimble aus. Geben Sie Nimble im integrierten web_search-Tool an – die einzeilige Änderung von vorhin –, und jeder von Databricks gehostete Agent stützt seine Antworten darauf. Für nachvollziehbare, prüfbare Ergebnisse nutzen Sie den Research Pass. Die Dokumentation zum Nimble-Connector deckt beides ab. Sie benötigen einen Nimble-Schlüssel. Starten Sie eine kostenlose Testversion, um einen zu erhalten.

Die internen Daten gehören bereits Ihnen. Das ist alles, was nötig ist, damit Ihre Agenten logische Schlüsse über das restliche Web ziehen können, während dieselbe Plattform beide Hälften vereint.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag