Mozilla AI fragt: Wer durchsucht das Web für Ihren Agenten?

Mozilla AI stellt mit Otari gebündelte Agentensuche infrage. Das Tool ermöglicht Teams, einen Suchdienst unabhängig von ihrem Modell zu wählen. Wer durchsucht das Web für Ihren Agenten? Der Beitrag vom 19. Oktober macht diese Frage konkret: Die Wahl eines KI-Modells bestimmt nicht zwangsläufig, wohin dessen Suchanfragen gehen.

Otari positioniert sich zwischen einem Agenten – einer Software, die Tools nutzt, um Aufgaben zu erledigen – und dem Modellanbieter. Mozilla AI zufolge kann es Suchanfragen dadurch umleiten und zugleich unterstützte Client-Schnittstellen erhalten. Die vorgeschlagene Änderung betrifft die Kontrolle über die Informationsbeschaffung, nicht die Frage, welches Modell die Antwort formuliert.

Die konkurrierenden Ansätze sind einfach: Man akzeptiert die mit einem Modelldienst gebündelte Suche oder verwaltet Suche als separate Abhängigkeit. Claude Code bietet einen nützlichen Vergleich, weil die integrierte Suche das Backend von Anthropic nutzt. Otari stellt diese Konstellation infrage, indem es das Routing der Suche zu einer eigenständigen Entscheidung macht – mit zusätzlicher Verantwortung für diejenige Partei, die sie trifft.

Wer durchsucht das Web für Ihren Agenten? Otari macht die Wahl explizit

In seiner Analyse zur Agentensuche beschreibt Mozilla AI drei Optionen: eine von Otari betriebene Suche, das Suchkonto eines Kunden oder einen selbstgehosteten Endpunkt. Das Unternehmen nennt Brave, Exa und Tavily als Dienste, die Kunden mit eigenen Zugangsdaten anbinden können.

Laut Mozilla AI können Kunden Claude, GPT oder Gemini beibehalten und zugleich den Dienst wechseln, der Suchanfragen verarbeitet. Suchzugangsdaten bleiben im Gateway – dem Vermittler, der Anfragen weiterleitet – statt den Agenten zu erreichen. Das Unternehmen beschreibt außerdem Workspace-Kontrollen und mit der Modellnutzung verknüpfte Suchprotokolle.

Die folgenreichste Änderung besteht darin, Suche zu einer Abhängigkeit zu machen, die Teams unabhängig vom Modell auswählen können.

Dieser Unterschied ist leicht zu übersehen, wenn eine Anwendung nur ein einziges Antwortfeld zeigt. Ein Nutzer stellt eine Frage, wartet und erhält eine Antwort mit Quellenangaben. Die Oberfläche kann Abruf und Schlussfolgerung wie einen einzigen Vorgang wirken lassen, auch wenn verschiedene Dienste sie ausführen.

Die Trennung dieser Vorgänge verändert, wie Käufer ein System bewerten. Eine Modellbewertung beantwortet, ob das Modell Anweisungen befolgt und effektiv schlussfolgert. Eine Suchbewertung fragt, ob das System geeignete Belege abruft, Anfragen akzeptabel verarbeitet und die betrieblichen Anforderungen der Organisation unterstützt.

Keine der beiden Bewertungen ersetzt die andere. Gute Schlussfolgerungen können kein Dokument wiederherstellen, das nie in die Belegmenge gelangt ist. Starker Abruf kann nicht jede unbelegte Schlussfolgerung verhindern. Die getrennte Betrachtung gibt Teams eine klarere Möglichkeit, Fehler zu untersuchen, ohne alles dem Modell zuzuschreiben.

Der Beitrag von Mozilla AI sollte außerdem zutreffend als Aussage über die Produktrichtung und dokumentierte Fähigkeiten gelesen werden. Sein Veröffentlichungsdatum belegt nicht, wann jede zugrunde liegende Funktion verfügbar wurde. Ebenso belegt die Ankündigung nicht, dass Kunden bereits bessere Antworten oder niedrigere Betriebskosten erzielt haben.

Die unmittelbare Nachricht ist daher enger gefasst als die Behauptung, die Agentensuche sei gelöst. Mozilla AI macht den Suchanbieter zu einem expliziten Teil der Kauf- und Architekturdebatte. Das schafft eine praktische Alternative dazu, den Retrieval-Dienst zu akzeptieren, der ein gewähltes Modell begleitet.

Für Teams, die mit gebündelter Suche bereits zufrieden sind, muss die Alternative ihren operativen Aufwand rechtfertigen. Für Teams, die durch eine nicht akzeptable Suchkonstellation blockiert werden, löst die Trennung dieser Abhängigkeit ein ganz anderes Problem. Sie brauchen eine Wahlmöglichkeit, die sie bewerten können, statt einer weiteren Modellrangliste.

Die Suchanfrage selbst verdient Prüfung

Eine Suchanfrage ist eine nach außen gerichtete Offenlegung, selbst wenn die gewünschte Antwort öffentliche Informationen betrifft.

Betrachten wir einen hypothetischen Coding-Assistenten, der einen Softwarefehler untersucht. Eine hilfreiche öffentliche Anfrage könnte eine Fehlermeldung und eine Bibliotheksversion beschreiben. Eine unnötig spezifische Anfrage könnte zusätzlich einen internen Servicenamen, eine Kundenkennung oder einen Namen eines unveröffentlichten Projekts enthalten.

Der Unterschied betrifft, was die Organisation verlässt – nicht, ob öffentliche Dokumentation sicher gelesen werden kann. Ein Assistent kann einen legitimen Grund zur Suche haben und dennoch eine unangemessene Anfrage formulieren. Die Wahl des Suchanbieters betrifft den Empfänger; die Prüfung der Anfragekonstruktion betrifft den Inhalt.

Diese Trennung ist für Engineering-Manager und Unternehmenskäufer wichtig. Die Genehmigung eines Modells beantwortet nicht jede Frage zu den daran angeschlossenen Tools. Jeder zusätzliche Dienst schafft eine operative Beziehung, die eine eigene Bewertung verdient – insbesondere wenn Anfragen aus privaten Arbeitskontexten stammen.

Die vernünftige Reaktion besteht darin, eine tatsächliche Aufgabe nachzuverfolgen. Welche Informationen gingen in den Prompt ein? Welcher Text wurde zur Suchanfrage? Welcher Dienst erhielt sie? Welche Ergebnisse kamen zurück, und welche davon beeinflussten die Antwort?

Diese Fragen machen eine Kaufdiskussion konkreter. Sie zeigen auch, wo eine Aussage an ihre Grenze stößt. Das Wissen um das Ziel schafft Transparenz über das Routing. Es belegt nicht, dass jede Anfrage notwendig, angemessen formuliert oder durch akzeptable Verarbeitungsbedingungen abgedeckt war.

Dasselbe gilt für Kundenrecherche. Stellen Sie sich einen Assistenten vor, der ein Briefing über einen potenziellen Kunden vorbereitet. Öffentliche Unternehmensinformationen gehören zum Rechercheprozess. Private Vertriebsnotizen, vorgeschlagene Vertragstexte und interne Bewertungen erfordern eine gesonderte Entscheidung, bevor sie in externen Anfragen erscheinen.

Dies sind illustrative Szenarien, keine dokumentierten Otari-Kundeneinsätze. Ihr Wert liegt darin zu zeigen, warum die Auswahl der Suche über Entwicklerpräferenzen hinaus wichtig ist. Eine scheinbar gewöhnliche Recherche kann eine Grenze überschreiten, die die endgültige Antwort nicht erkennen lässt.

Wissensarbeiter benötigen außerdem eine Unterscheidung zwischen öffentlicher Recherche und der Suche in eigenen Materialien. Eine persönliche Wissensbasis deckt einen Informationsbedarf ab, der sich von der Suche nach neuen öffentlichen Quellen unterscheidet. Ein effektiver Workflow sollte feststellen, welche Art von Belegen die Aufgabe erfordert, bevor entschieden wird, wo gesucht wird.

Für einen Produktmanager könnte das bedeuten, zunächst interne Forschung zu konsultieren, bevor aktuelle Informationen über Wettbewerber angefordert werden. Für einen Ingenieur könnte es bedeuten, private Designentscheidungen zu prüfen, bevor öffentliche Dokumentation nachgeschlagen wird. Es geht um zielgerichtete Informationsbeschaffung, statt jede Unsicherheit an das offene Web zu senden.

Das setzt die Personen unter Druck, die Agenteneinsätze genehmigen. Sie benötigen genügend Transparenz, um den Informationsweg einschließlich seiner Grenzen erklären zu können. Ein Produkt, das das Ziel der Suche offenlegt, kann diese Erklärung unterstützen, doch die Organisation muss weiterhin entscheiden, welche Informationen auf diesen Weg gehören.

Wer durchsucht das Web für Ihren Agenten? Für Käufer umfasst eine ausreichende Antwort den Betreiber, die relevante Vereinbarung und den Umfang der übermittelten Informationen. Allein ein bekanntes Modell zu nennen, lässt den Suchteil dieser Antwort unvollständig.

Gebündelte Suche bietet Komfort, getrennte Suche schafft Verantwortung

Das stärkste Argument für gebündelte Suche ist Komfort. Ein Entwickler erhält eine unterstützte Tool-Schnittstelle, ohne jeden Teil des Retrievals selbst zusammenzustellen. Eine Organisation kann diese Konstellation bevorzugen, wenn ihre Anforderungen mit dem Dienst und dem dokumentierten Verhalten des Anbieters übereinstimmen.

Das Web-Suchtool von Anthropic veranschaulicht den integrierten Ansatz. Claude entscheidet, wann gesucht wird, der Dienst führt die Suche aus, und die endgültige Antwort enthält Quellenangaben. Die Dokumentation beschreibt außerdem Domain-Kontrollen und verschiedene Tool-Versionen.

Diese Fähigkeiten sind wichtig, weil konfigurierbare Suche nicht einzigartig für ein unabhängiges Gateway ist. Kunden sollten zwischen Kontrollen über das Suchverhalten und der Kontrolle über den Suchanbieter unterscheiden. Ein Anbieter kann nützliche Einschränkungen bereitstellen und zugleich für den Betrieb des zugrunde liegenden Dienstes verantwortlich bleiben.

Die zentrale Entscheidung betrifft, wer die Retrieval-Entscheidungen und die zu ihrer Aufrechterhaltung erforderliche Arbeit übernimmt.

OtarIs Ansatz spricht Teams an, die diese Verantwortung übernehmen möchten. Doch Unabhängigkeit bringt Verpflichtungen mit sich, die gebündelte Dienste übernehmen oder vereinfachen. Jemand muss Zugangsdaten verwalten, das Dienstverhalten bewerten, Fehler untersuchen und eine funktionierende Beziehung zwischen dem Agenten und seinen Suchtools aufrechterhalten.

Ollama bietet einen weiteren nützlichen Vergleich. Die Dokumentation seiner gehosteten Websuche legt eine authentifizierte Anfrage an ollama.com/api/web_search fest. Die Antwort enthält Ergebnisse mit Seitentiteln, Adressen und Inhaltsausschnitten.

Dieses Beispiel belegt einen begrenzten, aber wichtigen Punkt: Die Nutzung eines lokalen Modells bedeutet nicht, dass dessen Websuchen lokal bleiben. Die dokumentierte Suchanfrage erreicht einen gehosteten Dienst. Kunden müssen Inferenz, Suche und Seitenabruf getrennt untersuchen, wenn sie bewerten, wo Verarbeitung stattfindet.

Dies ist kein Beleg dafür, dass gehostete Suche grundsätzlich ungeeignet ist. Ein gehosteter Dienst kann eine akzeptable Wahl sein, wenn seine Bedingungen, sein Verhalten und seine Zuverlässigkeit den Bedürfnissen der Organisation entsprechen. Der relevante Fehler besteht darin anzunehmen, dass eine Architekturentscheidung automatisch jede andere Komponente bestimmt.

Dieselbe Disziplin gilt für die Antwortqualität. Der Wechsel eines Suchdienstes verändert die Belege, die dem Modell zur Verfügung stehen. Eine Bewertung, die Modell und Suche gleichzeitig verändert, kann nur schwer erklären, welche Änderung das Ergebnis verbessert oder verschlechtert hat.

Die Trennung dieser Variablen ermöglicht aussagekräftigere Vergleiche. Teams können das Modell konstant halten, während sie den Retrieval-Prozess untersuchen, und anschließend die Belege konstant halten, während sie die Synthese untersuchen. Solche Bewertungen erfordern weiterhin sorgfältiges Design, vermeiden aber, die gesamte Anwendung als unteilbare Blackbox zu behandeln.

Eine Otari-Websuchevaluierung sollte daher mit den eigenen Aufgaben des Teams beginnen. Das Nachschlagen öffentlicher Dokumentation, aktuelle Unternehmensrecherche und spezialisierte technische Recherche können unterschiedliche Belege erfordern. Die allgemeine Behauptung, ein Suchdienst sei der beste, bräuchte Belege, die über diese einzelnen Arbeitslasten hinausgehen.

Die Ankündigung von Mozilla AI liefert keine unabhängige Vergleichsstudie, die einen solchen Sieger belegt. Die überzeugendere Lesart ist, dass Kunden die Abhängigkeit wählen und testen können sollten. Das ist ein Argument für Kontrolle und Bewertung, nicht für eine nachgewiesene Rangfolge von Suchmaschinen.

Der Druck liegt bei beiden Ansätzen. Anbieter gebündelter Dienste müssen ihre Suchvereinbarungen klar genug erklären, damit Käufer sie bewerten können. Unabhängige Infrastruktur muss zeigen, dass zusätzliche Kontrolle nutzbar bleibt, wenn sich Clients, Modelle und Tool-Schnittstellen ändern.

OtarIs Websuche hängt davon ab, die Erwartungen des Clients zu erfüllen

Ein konfigurierbarer Suchdienst hilft nur, wenn der Agent ihn korrekt nutzen kann. Anwendungen erwarten mehr als eine Liste von Links. Sie sind auf erkennbare Tool-Antworten, Fehlerverhalten und genügend Quellinformationen angewiesen, um die Aufgabe fortzusetzen.

Die Dokumentation zur Suchinterzeption von Otari beschreibt, wie bei aktivierter Interzeption unterstützte, nach Anbietern benannte Suchdeklarationen übernommen werden. Interzeption bedeutet, eine Anfrage zu bearbeiten, die andernfalls an das Tool des Anbieters gehen würde. Die Dokumentation unterscheidet dieses Verhalten von der Weiterleitung nativer Anbieteranfragen.

Es beschreibt außerdem Workspace-Beschränkungen, darunter das Deaktivieren der Suche, das Begrenzen von Ergebnissen und die Einschränkung von Domains. Die Dokumentation warnt, dass die gebündelte SearXNG-Einrichtung bei dauerhafter Nutzung rate-limitiert ist. Diese Warnung ist bei der Bewertung der Produktionsreife wichtiger als bei einer kurzen Demonstration.

Die Beibehaltung der Schnittstelle reduziert Integrationsaufwand, stellt jedoch kein identisches Verhalten sicher.

Ein Client kann eine Antwort akzeptieren und dennoch andere Nachweise erhalten. Er kann auch eine erfolgreiche Suche korrekt verarbeiten, aber auf einen nicht verfügbaren Dienst schlecht reagieren. Kompatibilität muss daher den Normalbetrieb ebenso abdecken wie die Fälle, die ihn unterbrechen.

Eine hypothetische Programmieraufgabe macht den Unterschied sichtbar. Ein Assistent sucht nach einem Migrationsleitfaden, liest das Ergebnis und schlägt eine Codeänderung vor. Eine sinnvolle Bewertung fragt, ob der abgerufene Leitfaden zur relevanten Softwareversion passt und die vorgeschlagene Änderung stützt.

Dieselbe Aufgabe sollte verständlich bleiben, wenn die Suche nichts zurückgibt. Ein Agent, der fehlende Nachweise klar meldet, verhält sich anders als einer, der eine Antwort improvisiert. Das Antwortformat des Gateways ist wichtig, ebenso wie die Interpretation eines Fehlers durch den Client.

Hier werden Vergleiche, die sich allein auf die Sprachgewandtheit von Antworten stützen, irreführend. Eine überzeugend formulierte Erklärung kann schwache Nachweise verdecken. Eine weniger elegante Antwort, die ihre Grenzen benennt, kann für eine folgenreiche technische Entscheidung nützlicher sein.

Otaris Suchkonfiguration dokumentiert benannte Suchinstanzen und eine Standardauswahl. Sie beschreibt außerdem anbieterspezifische Einstellungen und Anforderungen an Zugangsdaten. Diese Details zeigen, dass Suchunabhängigkeit eine Betriebskonfiguration ist und nicht bloß eine in einem Prompt geäußerte Präferenz.

Für Plattformteams wirft Konfiguration vertraute Wartungsfragen auf. Wer kann den Standard ändern? Wie erreicht eine Änderung verschiedene Workspaces? Welche Nachweise zeigen, dass eine Anfrage den vorgesehenen Dienst verwendet hat? Die Antworten bestimmen, ob Kontrolle die normale organisatorische Tätigkeit überdauert.

Eine Einstellung kann vorhanden sein, ohne zu einer wirksamen Richtlinie zu werden. Eine Bewertung muss feststellen, was unter der tatsächlichen Bereitstellungskonfiguration geschieht, einschließlich zulässiger Ausnahmen. Andernfalls besteht das Risiko, dass eine Demonstration auswählbarer Suche mit einer Zusicherung für jede Produktionsanfrage verwechselt wird.

Die Unterscheidung wird besonders wichtig, wenn eine Anwendung mehrere Wege zu externen Informationen hat. Ein Suchwerkzeug, ein Seitenabruf und ein Browser können unterschiedliche Pfade darstellen. Die Kontrolle eines Pfads stellt keine Kontrolle über alle anderen her.

Diese Beobachtung ist eine architektonische Überlegung, keine Feststellung, dass Otari einen bestimmten Umgehungsweg hat. Käufer sollten Nachweise zur Abdeckung verlangen, die zu ihren Clients und aktivierten Werkzeugen passen. Weite Aussagen wie „der gesamte Agentenverkehr“ erfordern umfassendere Überprüfung als eine erfolgreich abgefangene Suche.

Der Mechanismus ist vielversprechend, weil er eine Routingentscheidung außerhalb des Urteils des Modells platziert. Sein praktischer Wert hängt davon ab, ob die umgebende Anwendung diesen kontrollierten Weg konsequent nutzt. Die Bewertung muss die vollständige Aufgabe verfolgen, einschließlich der Momente, in denen der erwartete Weg scheitert.

Self-Hosting verändert Verantwortung, ohne Abhängigkeiten zu beseitigen

Den Suchvermittler selbst zu betreiben bedeutet nicht, einen unabhängigen Webindex zu betreiben.

Die Metasucharchitektur von SearXNG aggregiert Ergebnisse anderer Suchmaschinen. Dadurch wird die Bedeutung von Self-Hosting präzise: Eine Organisation kann den Aggregationsdienst betreiben und für Ergebnisse dennoch auf vorgeschaltete Suchmaschinen angewiesen sein.

Bei einer Otari-Bereitstellung mit SearXNG verhindert diese Unterscheidung eine überzogene Datenschutzbehauptung. Der Betreiber kontrolliert seine Instanz, doch die konfigurierten Upstream-Beziehungen der Instanz bleiben relevant. Eine vollständige Bewertung verfolgt die Abfrage über den ersten Server der Organisation hinaus.

Dies ist ein nützlicher skeptischer Test der umfassenderen Botschaft. Wenn Self-Hosting als vollständige Unabhängigkeit dargestellt wird, verkompliziert Metasuche dieses Versprechen. Wenn es als Kontrolle über eine klar definierte Komponente dargestellt wird, ist die Behauptung enger gefasst und leichter zu bewerten.

Dieselbe Disziplin sollte Kostenvergleiche bestimmen. Das Entfernen einer gebündelten Suchgebühr beseitigt nicht den Aufwand für den Betrieb des Abrufs. Infrastruktur, Wartung, Reaktion auf Vorfälle und die Aufmerksamkeit von Mitarbeitenden gehören in die Bewertung, selbst wenn sie nicht als Kosten pro Abfrage erscheinen.

Es gibt hier keine Grundlage, Self-Hosting pauschal als günstiger zu erklären. Der relevante Vergleich hängt von Arbeitslast, Serviceanforderungen und den bestehenden Fähigkeiten der Organisation ab. Ein Team, das bereits verwandte Infrastruktur betreibt, steht vor einer anderen Entscheidung als ein Team ohne diese Expertise.

Auch die Kontrolle von Zugangsdaten erfordert eine präzise Auslegung. Zugangsdaten vom Agenten fernzuhalten, reduziert einen Offenlegungspfad. Der Dienst, der diese Zugangsdaten verwaltet, bleibt ein sensibles System, das angemessene Administration und Zugriffskontrollen benötigt.

Suchprotokolle schaffen einen weiteren Zielkonflikt. Sie können helfen zu erklären, warum ein Agent eine Antwort erzeugt hat, aber sie können auch sensible Abfragetexte bewahren. Eine Organisation, die Rechenschaftsfähigkeit anstrebt, sollte entscheiden, wer diese Aufzeichnungen einsehen kann und wie lange sie nützlich bleiben.

Mehr Transparenz schafft daher eine eigene Governance-Aufgabe. Detaillierte Aufzeichnungen sind nicht automatisch in jedem Kontext besser. Das Ziel sind ausreichende Nachweise für Untersuchungen, mit Regeln zur Handhabung, die den in diesen Aufzeichnungen enthaltenen Informationen angemessen sind.

Auch Domainbeschränkungen haben einen begrenzten Wert. Sie können den Pool zulässiger Quellen einschränken. Sie stellen nicht sicher, dass jede Seite einer erlaubten Domain korrekt, aktuell oder für die jeweilige Aufgabe geeignet ist.

Auch die Wahl eines Suchanbieters löst nicht das Problem von Prompt Injection, also bösartigen Inhalten, die das Verhalten eines Assistenten umleiten sollen. Abgerufene Seiten bleiben externe Eingaben. Ein Agent muss sie als zu bewertende Nachweise behandeln, nicht als Anweisungen mit Autorität über seine Aufgabe.

Diese Einschränkungen entkräften nicht das Argument für unabhängige Suche. Sie definieren, was dieses Argument stützen kann. Die Auswahl einer Abhängigkeit gibt Organisationen einen Ort, an dem sie ihr Urteil ausüben können; sie garantiert nicht, dass dieses Urteil richtig sein wird.

Das glaubwürdige Ergebnis ist eine größere Rechenschaftspflicht für identifizierbare Entscheidungen. Ein Käufer kann fragen, warum ein Dienst ausgewählt wurde, welche Annahmen ihn stützen und was einen Wechsel auslösen würde. Diese Fragen bleiben wertvoll, selbst wenn die gewählte Antwort ein verwalteter Anbieter ist.

Eine Otari-Websuche-Bereitstellung sollte an diesen konkreten Verantwortlichkeiten gemessen werden. Die Ankündigung allein belegt weder eine überlegene Informationsbeschaffung noch universelle Kompatibilität oder ein vollständiges Datenschutzergebnis. Nachweise aus der tatsächlichen Umgebung eines Teams müssen diese Schlussfolgerungen tragen.

Kompatibilität, Vergleichsnachweise und Offenlegung durch Anbieter beobachten

Das nächste Berichtsfenster sollte sich auf beobachtbare Veränderungen konzentrieren, nicht auf Versprechen eines offeneren KI-Stacks. Bis Ende 2026 und Anfang 2027 betreffen die nützlichen Signale die Frage, ob unabhängige Suche einfacher zu betreiben und einfacher zu bewerten wird.

Die stärksten Nachweise werden verlässliche Kontrolle bei realen Aufgaben zeigen, einschließlich Fehlern und Änderungen.

Das erste Signal sind veröffentlichte Kompatibilitätsnachweise für die Clients und Werkzeugschnittstellen, die Teams tatsächlich nutzen. Ein sinnvoller Release würde getestetes Verhalten, unterstützte Versionen und bekannte Einschränkungen benennen. Reproduzierbare Beispiele würden die Aussage stärken, dass Kunden ihre Anwendungen beibehalten und zugleich die Suche ändern können.

Umgekehrt würden wiederholte client-spezifische Workarounds die praktische Behauptung der Unabhängigkeit schwächen. Ein theoretisch austauschbarer Dienst bietet begrenzte Freiheit, wenn jeder Austausch umfangreiche Reparaturen an der Anwendung erfordert. Die Kompatibilität muss verständlich bleiben, während sich die umgebende Software weiterentwickelt.

Das zweite Signal ist eine vergleichende Bewertung mit kontrollierter Arbeitslast. Modell und Aufgaben bleiben konstant; anschließend werden Relevanz, Aktualität, Antwortzeit, Fehler und der gesamte Betriebsaufwand untersucht. Das Ergebnis sollte benennen, wo jede Anordnung funktioniert, einschließlich der Fälle, in denen gebündelte Suche weiterhin vorzuziehen ist.

Eine überzeugende Bewertung würde ausreichend Details veröffentlichen, damit Leser ihre Grenzen verstehen können. Ergebnisse aus der Suche in Dokumentationen sollten nicht zu Behauptungen über jede Rechercheaufgabe werden. Nachweise selektiver Vorteile wären glaubwürdiger als eine unerklärte Erklärung allgemeiner Überlegenheit.

Das dritte Signal sind klarere Offenlegungen oder zusätzliche Anbieterauswahl durch gebündelte Anbieter. Explizitere Dokumentation würde Kunden helfen, bestehende Dienste zu bewerten, ohne einen weiteren Vermittler einzuführen. Eine vom Anbieter unterstützte Auswahl würde zudem prüfen, ob Kunden vor allem Unabhängigkeit oder schlicht klarere Kontrollen wünschen.

Eine solche Entwicklung würde das zugrunde liegende Argument von Mozilla AI stärken und zugleich Otaris Wettbewerbsposition verändern. Suche würde zu einer sichtbareren Beschaffungsentscheidung, selbst wenn Käufer diese Wahl andernorts treffen. Die bleibende Frage ist, wer die Entscheidung treffen und erklären kann.

Wer durchsucht das Web für Ihren Agenten? Die Antwort sollte mit der Entwicklung dieser Signale konkreter werden. Sie sollte einen tatsächlichen Informationspfad und die Nachweise für seine Nutzung benennen, statt sich auf Annahmen zu stützen, die aus dem Namen eines Modells abgeleitet werden.

Bevor Sie einen Agenten-Workflow ausweiten, überprüfen Sie eine repräsentative Aufgabe vom Prompt bis zur endgültigen Antwort. Identifizieren Sie die ausgehende Abfrage, ihren Empfänger, die zurückgegebenen Quellen und die Nachweise, die die Schlussfolgerung stützen. Fragen Sie dann, ob die Anordnung zur Sensibilität und zum Zweck der Arbeit passt. Behalten Sie gebündelte Suche bei, wenn ihr dokumentiertes Verhalten diese Anforderungen erfüllt. Bewerten Sie einen separaten Suchdienst, wenn Anbieterauswahl, Betriebskontrolle oder klarere Aufzeichnungen eine konkrete Anforderung erfüllen. Bei Aufgaben, die privates Wissen mit öffentlicher Recherche verbinden, prüfen Sie diese Grenze ausdrücklich, statt jede Abfrage gleich zu behandeln. Der nützliche nächste Schritt ist eine Entscheidung, die Ihr Team erklären kann: Welchen Suchdienst sollte dieser Agent verwenden, und welche Nachweise rechtfertigen diese Wahl?