AWS hat Web Answer als allgemein verfügbares, verwaltetes Tool für Amazon Bedrock AgentCore veröffentlicht. Es richtet sich an ein bekanntes Problem bei der Entwicklung von Agents: Eine Anwendung benötigt aktuelle Informationen aus dem öffentlichen Web, aber das Team möchte nicht die komplette Such- und Antwortpipeline selbst entwickeln und warten.

Redaktionelle Szene: Eine Person prüft die Webrecherche eines KI-Agenten und verknüpfte Quellenangaben auf einem Laptop.

Der neue Dienst nimmt eine Frage in natürlicher Sprache entgegen und gibt eine zusammengefasste Antwort mit Quellenangaben zurück. Er plant Suchvorgänge, führt mehrere davon parallel aus, liest relevante Seiten, prüft, ob die Belege ausreichen, und erstellt eine Antwort, in der Aussagen den jeweiligen Quell-URLs zugeordnet werden. Ein Agent erreicht den Dienst über ein AgentCore Gateway unter Verwendung des Model Context Protocol (MCP).

Das reduziert den Entwicklungsaufwand spürbar. Es ist jedoch nicht dasselbe wie eine Übertragung der Verantwortung. Teams müssen weiterhin festlegen, welche Domänen ein Agent konsultieren darf, wie Quellenangaben angezeigt werden, wann ein Mensch eine Antwort prüfen muss und ob der Dienst für die Daten und das Latenzprofil eines bestimmten Workflows geeignet ist.

Was AWS tatsächlich veröffentlicht hat

Web Answer ist ein verwalteter Connector, der an ein Amazon Bedrock AgentCore Gateway angebunden ist. Das Gateway authentifiziert den Aufrufer und ruft den AWS-eigenen Connector mit seiner eigenen Servicerolle auf. Ein angebundener Agent entdeckt das Tool über den üblichen MCP-Ablauf zur Auflistung von Tools und ruft es als eine Fähigkeit unter mehreren auf.

Der Unterschied zu einem herkömmlichen Such-Endpunkt ist wichtig. Ein Such-Tool liefert normalerweise nach Rang sortierte URLs, Titel, Ausschnitte und Metadaten. Die Anwendung muss anschließend Seiten abrufen, relevante Passagen bestimmen, ein Modell mit deren Zusammenfassung beauftragen und die Beziehung zwischen jeder Aussage und ihrem Beleg erhalten. Web Answer übernimmt diese Abruf- und Zusammenfassungsschleife für die Anwendung und gibt eine fertige Antwort mit Quellenangaben zurück.

AWS zufolge führt das Tool für jede Frage neue Suchvorgänge durch und erhält das aktuelle Datum, damit es zeitabhängige Anfragen verarbeiten kann. Außerdem lassen sich Vorgaben für ein- oder ausgeschlossene Domänen, Veröffentlichungszeiträume und die Lokalisierung nach Land übergeben. Administratoren können am Gateway-Ziel Grenzen festlegen. Ein einzelner Agent-Aufruf darf diese Grenzen weiter einengen, aber nicht ausweiten.

Die erste Version ist in US East (N. Virginia), also us-east-1, verfügbar. AWS beschreibt den Dienst als pro Tool-Aufruf abgerechnet; im Leitfaden für die ersten Schritte wird ein Preis von 10 US-Dollar pro 1.000 Web-Answer-Aufrufen genannt. Das ist nur ein Teil der Betriebskosten: Auch das Gateway, das Modell für den umgebenden Agent, nachgelagerte Tools, Protokollierung und Prüfaufwand müssen im Budget berücksichtigt werden.

Welches praktische Problem dadurch entfällt

Ein Agent für aktuelle Informationen enthält oft mehr technische Infrastruktur, als seine Nutzer jemals sehen. Eine typische Implementierung muss mehrere getrennte Fragen beantworten.

  • Welchen Suchanbieter soll sie verwenden?
  • Wie soll sie Folgeanfragen formulieren, wenn die ersten Ergebnisse unvollständig sind?
  • Wie soll sie Seiten abrufen, ohne dauerhaft einen unsicheren oder fehleranfälligen Browser-Stack betreiben zu müssen?
  • Wie soll sie Navigation, Werbung und irrelevante Seiteninhalte entfernen?
  • Wie soll sie widersprüchliche Veröffentlichungsdaten und Aussagen vergleichen?
  • Wie soll sie Quellenangaben an die exakten Aussagen der Antwort anhängen?
  • Was soll geschehen, wenn die Belege zu schwach sind, um eine Schlussfolgerung zu stützen?

Jede Entscheidung wird zu Anwendungscode, und jeder Teil dieses Codes wird Teil der Zuverlässigkeitsfläche. Ein Suchergebnis kann veraltet sein. Ein Seitenparser kann ausfallen. Ein Prompt für die Zusammenfassung kann die Zuordnung zu den Quellen verlieren. Ein Formatierer für Quellenangaben kann eine gültige URL neben einer Aussage platzieren, die von der Seite tatsächlich gar nicht gestützt wird.

Web Answer bündelt einen großen Teil dieser Schleife als verwaltete Fähigkeit. Für ein Team, das einen Support-Assistenten, eine Recherchehilfe, ein Tool zur Compliance-Vorsortierung oder einen internen Frage-Antwort-Agent entwickelt, kann das den ersten brauchbaren Prototyp deutlich kleiner machen. Außerdem entsteht eine zentrale Stelle, an der sich Einschränkungen für Domänen auf Gateway-Ebene durchsetzen lassen, statt sich ausschließlich auf Anweisungen zu verlassen, die in einem Agent-Prompt verborgen sind.

Dieser Vorteil ist am größten, wenn der Agent eine fertige Antwort auf eine eng gefasste Faktenfrage benötigt. Er fällt geringer aus, wenn die Anwendung Rohdokumente, ein eigenes Ranking, ein eigenes Extraktionsmodell, ein privates Korpus oder präzise Kontrolle über jeden einzelnen Zwischenschritt des Abrufs benötigt.

AWS positioniert Web Answer neben Web Search auf AgentCore, doch beide bedienen unterschiedliche Designentscheidungen.

Web Search liefert der Anwendung oder ihrem Modell Suchmaterial zur weiteren Verarbeitung. Entwickler behalten die Kontrolle über Ranking, Filterung, Abruf, Synthese und das Format der endgültigen Antwort. Das passt besser, wenn ein Workflow mehrere mögliche Dokumente prüfen, ein proprietäres Bewertungsverfahren anwenden, strukturierte Felder extrahieren oder Web-Ergebnisse vor dem Schreiben mit internen Datensätzen kombinieren muss.

Web Answer liefert die fertige Antwort. Das Tool ist für eine Teilaufgabe innerhalb eines größeren Agenten gedacht, bei der Entwickler aktuelle Informationen mit Quellenangaben benötigen, ohne eine weitere Abrufpipeline selbst betreiben zu wollen. Ein Agent könnte Web Search für eine offene Rechercheaufgabe und Web Answer für eine begrenzte Frage einsetzen, etwa: „Was hat sich diese Woche an den Leitlinien dieser Aufsichtsbehörde geändert, und welche offiziellen Seiten belegen die einzelnen Änderungen?“

Die Entscheidung ist daher eine architektonische Frage und nicht bloß die Wahl zwischen zwei Namen. Web Answer reduziert den Wartungsaufwand, kostet dafür aber einen Teil der Kontrolle. Web Search lässt mehr Arbeit in der Anwendung, macht dafür mehr vom Prozess der Beweissammlung sichtbar.

Ein sinnvoller erster Test besteht darin zu klären, ob der nachgelagerte Agent Quellen oder eine Antwort benötigt. Muss er selbst Dokumente vergleichen, sollte ein abruforientiertes Tool gewählt werden. Braucht er eine kurze, zitierte Faktenantwort und ist das Team mit einer verwalteten Synthese einverstanden, passt Web Answer direkter.

Zitate verbessern die Nachvollziehbarkeit, nicht die Wahrheit

Ein Zitat belegt die Nachvollziehbarkeit. Es garantiert nicht, dass die Antwort korrekt ist.

Web Answer kann Aussagen mit Quell-URLs verknüpfen, doch ein Agent muss weiterhin interpretieren, was diese Quellen aussagen. Eine Seite kann offiziell, aber veraltet sein. Ein Anbieter kann die Funktionen eines Produkts zutreffend beschreiben und zugleich eine für den Käufer wichtige Einschränkung auslassen. Zwei renommierte Quellen können unterschiedliche Versionen einer Richtlinie beschreiben. Ein Suchsystem kann eine Zusammenfassung aus zweiter Hand finden, bevor es die ursprüngliche Ankündigung findet.

Bei folgenreichen Workflows sollte die Anwendung Zitate als zu prüfende Objekte behandeln, nicht als dekorative Links, die nach der Generierung angehängt werden. Mindestens sollten Teams testen, ob:

  • jede wesentliche Aussage ein Zitat besitzt;
  • die zitierte Passage die Aussage tatsächlich stützt und nicht nur das Thema erwähnt;
  • Veröffentlichungsdaten sichtbar sind, wenn der Zeitpunkt für die Antwort relevant ist;
  • widersprüchliche Quellen angezeigt und nicht stillschweigend zusammengeführt werden;
  • das System angibt, wenn es nicht genügend Belege gefunden hat;
  • Nutzer die Quelle öffnen können, ohne den Kontext der Aussage zu verlieren;
  • Zitate nachgelagerten Transformationen wie Zusammenfassung, Übersetzung oder Export erhalten bleiben.

Das ist besonders wichtig, wenn ein Agent Web Answer als Zwischenschritt verwendet. Erhält der Agent eine zitierte Antwort und formuliert sie anschließend als E-Mail, Ticket oder Empfehlung um, können die ursprünglichen Belege verschwinden. Der Workflow sollte Zitate zusammen mit dem Text weiterreichen, statt sie in einem internen Tool-Protokoll zurückzulassen.

Dasselbe Prinzip gilt für automatisierte Entscheidungen. Eine zitierte Antwort kann einem Prüfer helfen zu verstehen, warum ein Agent zu einem Ergebnis gelangt ist. Sie sollte jedoch nicht allein deshalb zu einer automatischen Genehmigung führen, weil die Antwort Links enthält.

Domain-Kontrollen sind wertvoller als ein cleverer Prompt

AWS stellt Domain-Positiv- und -Negativlisten sowie Filter für Veröffentlichungsdaten als Kontrollen des Tools bereit. Der Gateway-Administrator kann eine äußere Grenze festlegen, innerhalb derer der Agent arbeitet.

Das ist eine beständigere Kontrolle, als einem Agenten zu sagen: „Bevorzuge offizielle Quellen.“ Prompt-Text kann ignoriert, durch eine lange Aufgabe abgeschwächt oder von einer späteren Anweisung übersteuert werden. Eine Domain-Richtlinie auf Gateway-Ebene kann verhindern, dass das Tool Quellen konsultiert, die die Organisation für einen bestimmten Workflow nicht freigegeben hat.

Eine sinnvolle Richtlinie kann je nach Aufgabe unterschiedlich aussehen. Ein Agent für Software-Support lässt sich auf die Dokumentation des Anbieters, dessen Statusseite und Release Notes beschränken. Ein Agent zur Beobachtung regulatorischer Entwicklungen kann Behörden, Normungsorganisationen und eine kontrollierte Auswahl von Fachpublikationen einbeziehen. Ein Agent für Marktrecherche braucht möglicherweise ein breiteres Quellenspektrum; seine Ausgabe sollte dann jedoch als Recherche und nicht als maßgebliche Tatsache gekennzeichnet werden.

Die Domain-Liste sollte nicht als dauerhafte Positivliste verstanden werden, die jedes Qualitätsproblem löst. Auch freigegebene Domains können Fehler veröffentlichen, URLs ändern, Seiten aktualisieren, ohne ältere Versionen zu erhalten, oder Marketingaussagen enthalten. Eine Domain-Richtlinie grenzt den Beleg-Pool ein; sie ersetzt nicht die Bewertung der Quellen.

Auch Filter nach Veröffentlichungsdatum müssen sorgfältig interpretiert werden. Eine aktuelle Seite ist nicht automatisch maßgeblicher als eine ältere. Bei Produktdokumentation kann die neueste Version die richtige sein. Bei Gesetzen, Standards oder historischen Berichten kann eine ältere Quelle weiterhin relevant sein, während ein neuerer Kommentar sie falsch wiedergibt. Welche zeitliche Abgrenzung sinnvoll ist, hängt von der jeweiligen Frage ab.

Datenschutz und Netzwerkgrenzen müssen tatsächlich geprüft werden

AWS zufolge verwendet Web Answer einen von Amazon betriebenen Webindex und Wissensgraphen; Abfragen und Ergebnisse bleiben innerhalb der AWS-Umgebung. Der Dienst wird über AgentCore Gateway bereitgestellt. Für das Gateway kommt IAM-Authentifizierung zum Einsatz, während eine AWS-Servicerolle den verwalteten Connector aufruft. AWS beschreibt den Dienst außerdem als ohne Datenabfluss nach außen.

Diese Angaben beschreiben die Dienstgrenze, sind aber keine pauschale Erlaubnis, beliebige sensible Inhalte in jede Abfrage zu übergeben. Ein Team muss weiterhin festlegen, welche Informationen der Agent in die Frage aufnehmen darf. Ein Kundenname, eine interne Incident-Nummer, ein unveröffentlichtes Produktdetail oder eine rechtliche Angelegenheit kann aus einer scheinbar gewöhnlichen Websuche ein Ereignis der Datenverarbeitung machen.

Am sichersten ist es, den privaten Kontext nach Möglichkeit von der öffentlichen Frage zu trennen. Der Agent kann interne Systeme nutzen, um das allgemeine Problem zu bestimmen, und Web Answer anschließend eine reduzierte Frage stellen, die keine unnötigen personenbezogenen oder vertraulichen Informationen enthält. Ist ein Detail unverzichtbar, sollte das Team bestätigen, dass vertragliche, regulatorische und aufbewahrungsbezogene Anforderungen die Übermittlung an den Dienst zulassen.

Auch die Gateway-Authentifizierung verdient einen eigenen Test. Ein Gateway kann den Zugriff auf den Connector schützen. Damit ist jedoch nicht automatisch festgelegt, dass jeder Agent, Nutzer oder Workflow jede beliebige Frage stellen darf. Die Berechtigungen sollten an Aufgabe und Datenklassifizierung gekoppelt sein. Ein Kundensupport-Agent und ein interner Agent für juristische Recherchen können zwar dieselbe Infrastrukturschicht nutzen, benötigen aber möglicherweise unterschiedliche Domain-Grenzen, Protokollierungsregeln und menschliche Freigaben.

Kosten werden leicht unterschätzt

Beim angekündigten Preis von 10 US-Dollar je 1.000 Tool-Aufrufen wirkt Web Answer gemessen an einer einzelnen Antwort günstig. Im Produktivbetrieb bleibt es selten bei einer einzigen Antwort.

Ein Agent kann das Tool mehrfach aufrufen, weil er Rückfragen stellt, eine fehlgeschlagene Anfrage wiederholt oder eine umfassende Aufgabe in kleinere Suchen aufteilt. Ein Assistent für Endnutzer kann in vielen Sitzungen ähnliche Fragen erneut stellen. Ein Hintergrundmonitor kann nach einem Zeitplan laufen, obwohl keine wesentliche Änderung eingetreten ist. Zusätzlich kann das umgebende Modell Tokens verbrauchen, um das Ergebnis zu interpretieren, Widersprüche aufzulösen oder die Antwort neu zu formulieren.

Eine bessere Kostenschätzung beginnt beim Workflow-Volumen, nicht beim Einzelpreis:

monatliche Kosten für Web Answers
= erwartete Tool-Aufrufe pro Aufgabe
× Aufgaben pro Monat
× Preis pro Aufruf

Diese Rechnung sollte um Modellinferenz, Gateway, Speicherung, Observability und Prüfung ergänzt werden. Wenn eine Aufgabe normalerweise drei Web-Answer-Aufrufe benötigt, sich aber mit einer einzigen sorgfältig formulierten Frage beantworten lässt, beeinflussen Prompt- und Workflow-Design direkt die Rechnung. Löst eine fehlerhafte Antwort wiederholte Versuche aus, werden Zuverlässigkeitsprobleme zugleich zu Kostenproblemen.

Teams sollten messen, welcher Anteil der Aufrufe eine Antwort liefert, die ein Prüfer als brauchbar einstuft, wie viele Zitate korrigiert werden müssen, wie hoch die mediane und die maximale Latenz sind und wie oft Agenten das Tool unnötigerweise aufrufen. Ein günstiger Aufruf, der eine unbrauchbare Antwort erzeugt, ist auf Workflow-Ebene nicht günstig.

Der Einrichtungsaufwand ist geringer, aber nicht null

Die Anleitung von AWS setzt ein AWS-Konto mit Zugriff auf AgentCore Gateway voraus, ein Gateway in us-east-1 mit eingehender IAM-Authentifizierung, Berechtigungen für die aufrufende Identität, eine Servicerolle mit der Befugnis, Web Answer aufzurufen, sowie eine unterstützte Agent-Umgebung. Das Beispiel verwendet Python 3.10 oder höher und MCP-kompatible Komponenten.

Die Einrichtung ist einfacher, als einen vollständigen Webrecherche-Dienst zu entwickeln, bleibt aber eine Infrastrukturänderung. Das Team muss ein Gateway erstellen oder auswählen, Berechtigungen konfigurieren, das verwaltete Ziel hinzufügen, die administrativen Domain-Grenzen festlegen und testen, wie der umgebende Agent mit dem Ergebnis umgeht.

Die regionale Einschränkung könnte das größte praktische Hindernis sein. Laut der Dokumentation zum Start ist Web Answer in US East (N. Virginia) verfügbar; weitere Regionen sollen später hinzukommen. Unternehmen mit Anforderungen an die Datenresidenz, regionaler Isolation oder Workloads in anderen Regionen können den Dienst möglicherweise nicht als primären Weg einsetzen. Selbst wenn der Agent in einer anderen Region läuft, müssen die Verfügbarkeit des Connectors und die Auswirkungen des Datenflusses geprüft werden.

Der Dienst schafft außerdem eine Abhängigkeit von AWS’ verwaltetem Such- und Antwortverhalten. Für Teams, die weniger Retrieval-Infrastruktur betreiben möchten, kann das ein sinnvoller Tausch sein. Zum Risiko wird es, wenn die Anwendung stabile, reproduzierbare Rankings oder vollständige Kontrolle über Modellversionierung und Auswahl der Belege verlangt.

Ein sinnvoller Evaluationsplan

Web Answer sollte mit den Fragen bewertet werden, die der Agent tatsächlich erhält – nicht mit einer Sammlung beeindruckender Demos.

Beginnen Sie mit einem kleinen Testsatz aus Aufgaben zu aktuellen Informationen. Nehmen Sie Fragen mit einer klaren Primärquelle auf, Fragen, bei denen mehrere Quellen widersprechen, Fragen mit einem Stichtag für das Veröffentlichungsdatum, Fragen, deren Antwort „nicht genügend Belege“ lautet, sowie Fragen mit Begriffen, die leicht miteinander verwechselt werden. Ergänzen Sie einige adversariale Fälle, in denen eine hoch gerankte Seite für das Thema maßgeblich ist, die verlangte Aussage aber nicht stützt.

Halten Sie für jede Antwort die Antwort selbst, die Zitate, die Quelldaten, die Latenz und fest, ob ein Prüfer die Belege akzeptiert. Testen Sie denselben Ablauf mit Web Search oder einer bestehenden Retrieval-Pipeline, sofern das Team bereits eine solche einsetzt. Der Vergleich sollte mehr als die Antwortqualität umfassen. Messen Sie den Entwicklungsaufwand, den Wartungsaufwand, die Kontrolle über Quellen, Fehlermuster und den erforderlichen Prüfaufwand.

Testen Sie anschließend den Agenten rund um das Tool. Stellt er Web Answer eine präzise Frage oder übergibt er dem Connector die gesamte Nutzeranfrage? Behält er die Zitate beim Verfassen der finalen Nachricht bei? Erkennt er, wann er aufhören sollte? Wiederholt er die Anfrage endlos? Kann ein Nutzer sehen, welche Quelle eine bestimmte Empfehlung stützt? Bleibt eine Domain-Einschränkung wirksam, wenn der Agent eine Anfrage umformuliert?

Bei Abläufen mit hoher Tragweite sollte vor einer Änderung eines Kundendatensatzes, dem Versand einer rechtlichen Auslegung, der Anpassung einer Sicherheitskontrolle oder dem Auslösen einer irreversiblen Aktion eine menschliche Freigabe eingebaut werden. Web Answer kann die für einen Prüfer verfügbaren Belege verbessern; es macht einen Prüfer nicht überflüssig.

Wer es ausprobieren sollte

Web Answer eignet sich für Teams, die AgentCore Gateway bereits nutzen, aktuelle Informationen aus dem öffentlichen Web benötigen und eine zitierte Antwort als begrenzten Schritt innerhalb eines größeren Agenten einsetzen möchten. Besonders interessant ist der Dienst für Support, Produktdokumentation, Richtlinienüberwachung und interne Recherche – also für Abläufe, bei denen der Aufbau von Retrieval, Synthese und Zitierlogik sonst vom eigentlichen Anwendungskern ablenken würde.

Weniger überzeugend ist er für Teams, die einen privaten Suchindex, eine eigene Dokumentrangfolge, rohe Seiteninhalte, deterministische Extraktion oder den Betrieb in einer Region benötigen, in der der Connector nicht verfügbar ist. Auch wenn die Organisation keine verwaltete Synthese akzeptieren kann oder jede Retrieval-Entscheidung auf einer niedrigeren Ebene als der finalen Antwort prüfen muss, kann Web Answer die falsche Wahl sein.

Die praktische Entscheidung lautet nicht, ob Web Answer eine überzeugende Antwort erzeugen kann. Das kann der Dienst. Entscheidend ist, ob die eingesparte Entwicklungsarbeit den Kontrollverlust aufwiegt und ob der Ablauf rund um das Tool genügend Belegverarbeitung vorsieht, damit dieser Tausch sicher ist.

AWS hat es einfacher gemacht, Webrecherche an einen Agenten anzubinden. Die nächste technische Aufgabe besteht darin, die Grenze dieser Recherche ausdrücklich festzulegen: freigegebene Quellen, minimierte Anfragen, sichtbare Zitate, messbare Kosten, regionale Einschränkungen und eine klare Regel dafür, wann ein Mensch übernehmen muss.