News · Google integriert HTML-Diagramme und Live-Reasoning in seinen Deep-Research-Agenten
Google integriert HTML-Diagramme und Live-Reasoning in seinen Deep-Research-Agenten
Der Research-Agent der Gemini API teilt sich künftig in eine schnelle, interaktive Stufe und eine asynchrone Max-Stufe auf. Für Frontend-Teams liegt die eigentliche Neuerung darin, was der Agent nun zurückliefert: eingebettete Diagramme, live mitlaufende Gedankenzusammenfassungen und einen überprüfbaren Plan.
Zwei Agenten, zwei Latenzbudgets, auf die man das Design ausrichten muss
Google hat seine Dezember-Preview in zwei Agenten aufgeteilt, die sich so unterschiedlich verhalten, dass eine Frontend-Entscheidung schon früh getroffen werden muss. Deep Research ist positioniert für „Research-Erlebnisse, die direkt in interaktive Nutzeroberflächen integriert sind, wo geringere Latenz gewünscht ist“, und ersetzt die bisherige Preview-Version durch das, was Google als geringere Latenz und Kosten bei höherer Qualität beschreibt. Deep Research Max hingegen „nutzt erweiterte Test-Time-Compute, um iterativ zu denken, zu suchen und zu verfeinern“ – Googles eigenes Beispiel dafür ist ein nächtlicher Cron-Job, der bis zum Morgen Due-Diligence-Berichte erstellt.
Diese Unterscheidung ist ein UI-Vertrag, keine reine Preisstufe. Eine synchrone Oberfläche, bei der ein Nutzer auf ein Ergebnis wartet, sollte auf den schnellen Agenten setzen; alles im Max-Maßstab gehört hinter einen asynchronen Job mit Benachrichtigung oder Berichts-Postfach. Für beide dieselbe Warte-UI zu bauen, würde die tatsächliche Laufzeit jeweils falsch darstellen.
Der Agent liefert jetzt darstellbare Diagramme, nicht nur Fließtext
Die konkreteste Änderung für alle, die die Empfängerseite bauen, ist, dass Deep Research „nicht mehr nur Text erstellt, sondern hochwertige Diagramme und Infografiken nativ inline mit HTML oder Nano Banana generiert“. Google beschreibt diese als „präsentationsreife“ visuelle Elemente, die dynamisch aus den zugrunde liegenden Daten erzeugt werden.
HTML-Output bedeutet, dass das Frontend jetzt für das Bereinigen und sichere Einbetten von modellgeneriertem Markup verantwortlich ist – und für die Handhabung von Bildausgaben (Nano Banana) neben Text im selben Berichts-Stream. Das ist eine andere Rendering-Pipeline als die Anzeige einer Markdown-Zusammenfassung. Teams brauchen ein Layout, das erzählenden Text, generierte Diagramme und Zitate miteinander verschränkt – und eine Richtlinie dafür, was zu tun ist, wenn das generierte HTML fehlerhaft oder unerwartet ausfällt.
Gestreamtes Reasoning und ein Review-Schritt verändern die Interaktionsschleife
Zwei Funktionen prägen das Moment-für-Moment-Erlebnis neu. Echtzeit-Streaming legt „die Zwischenschritte des Denkprozesses des Agenten mit live mitlaufenden Gedankenzusammenfassungen“ offen und liefert Text- und Bildausgaben, sobald sie entstehen. Kollaborative Planung erlaubt es Nutzern, „den vom Agenten erstellten Research-Plan zu prüfen, zu steuern und zu verfeinern, bevor die Ausführung beginnt“.
Zusammen ergeben diese Funktionen eine zweiphasige Oberfläche: eine Plan-Freigabephase, bevor die kostspielige Arbeit startet, gefolgt von einem Live-Fortschritts-Feed während der Ausführung. Bei langwierigen Recherchen ist genau diese Plan-Überprüfung der Hebel – sie ermöglicht es Nutzern, den Umfang umzulenken, bevor Rechenleistung verbraucht wird, statt einen fertigen Bericht zu verwerfen. Frontend-Arbeit bedeutet hier weniger eine Chat-Box als vielmehr ein editierbares Plan-Objekt plus einen dauerhaften Stream von Zwischenzuständen.
Was das für Teams bedeutet, die Research in eine Produktoberfläche einbinden
Die Datenreichweite des Agenten hängt jetzt von einer Konfiguration ab, die das Frontend ehrlich sichtbar machen muss. Deep Research kann „das Web, beliebige externe MCPs, Datei-Uploads und verbundene Dateispeicher – oder eine beliebige Teilmenge davon“ durchsuchen, einschließlich der Option, „den Webzugriff vollständig zu deaktivieren, um ausschließlich über eigene, benutzerdefinierte Daten zu suchen“. Da als MCP-Partner FactSet, S&P Global und PitchBook genannt werden, müssen Nutzer in regulierten Branchen sehen und kontrollieren können, welche Quellen eine Recherche berührt hat – und jeder Bericht wird als „vollständig belegtes“ Ergebnis ausgeliefert, das die Oberfläche als überprüfbare Links darstellen muss, nicht als Dekoration.
Die praktische Erkenntnis: Dieses Release verschiebt die Integrationsebene von „API aufrufen, Zusammenfassung anzeigen“ hin zu „einen Plan verwalten, Zwischenzustände streamen, gemischten HTML- und Bild-Output rendern und den Quellenumfang offenlegen“. Es ist ab heute als Public Preview auf den kostenpflichtigen Stufen der Gemini API über die Interactions API verfügbar – die Frontend-Muster für diese drei Phasen (Plan, Stream, belegter Bericht) sollten Teams also prototypisch erproben, bevor sie sich auf eine einzige Ansicht festlegen.
Find this story relevant to you?
Contact us to find a unique solution
Brauchen Sie einen KI-Engineering-Partner, der auch liefern kann?
Wir helfen Unternehmen dabei, KI in Produkte und Prozesse zu integrieren, wertvolle Workflows zu automatisieren und die zugrunde liegenden Softwaresysteme zu modernisieren.
Weiterführende Beiträge
Weitere Analysen rund um Produktbereitstellung, operative KI und die Systemarbeit, die dafür sorgt, dass der Einsatz in der Praxis Bestand hat.