Kategorie: KI-News

„Ein Browser sollte kein Einbahnkanal sein.“ So fasst Anthony Enzor-DeMeo, CEO von Mozilla, die Haltung seines Unternehmens zusammen. Mistral, französischer Anbieter offener KI-Modelle, liefert ab sofort die Modelle für Firefox Smart Window, den KI-Assistenten im Browser. Er läuft derzeit als Beta.

Was in der Ankündigung steht, lässt sich nachlesen. Es geht nicht um ein weiteres Feature in einem weiteren Browser, sondern darum, wer bestimmt, welche KI du benutzt – und wem dabei welche Daten gehören. Beide Firmen nennen sich Verfechter von Open Source und stellen die Zusammenarbeit in diese Tradition: zwei Anbieter, die verhindern wollen, dass KI im Web zur Einbahnstraße wird.

Das Web ist im Kern ein Marktplatz mit vielen Ständen. Auf einem wachsenden Teil davon stand bisher derselbe Verkäufer und bot freundlich, aber bestimmt nur seine eigene Ware an. Mozilla und Mistral stellen die Frage: Bleibt der Browser ein Ort, an dem verschiedene Anbieter konkurrieren – oder wird er zum Fließband zu einem einzigen KI-Anbieter?

Was Firefox Smart Window im Alltag macht

Die Ankündigung nennt drei Aufgaben für den Assistenten: komplexe Suchanfragen verständlich aufbereiten, Inhalte wiederfinden, die man versehentlich weggeklickt hat, und Informationen aus den geöffneten Tabs zusammenführen. Wer zwölf Tabs offen hat und irgendwo dazwischen eine wichtige Zahl gelesen hat, kennt das. Statt jeden Tab einzeln durchzugehen, fragt man den Browser, und Smart Window sucht die Antwort im aktuellen Kontext zusammen.

Wichtiger als die Funktion ist ihr Ort. Der Assistent sitzt nicht in einem separaten Chatfenster, sondern im Werkzeug, das man ohnehin den ganzen Tag benutzt. Das senkt die Hemmschwelle, erhöht aber die Verantwortung. Was im Browser passiert, ist selten harmlos: Kontostände, Arzttermine, interne Dokumente, private Nachrichten. Deshalb steht der Datenschutz in der Ankündigung weit vorn.

Frankreich und Nordamerika zuerst, Deutschland später

Laut Ankündigung entwickelt Mistral Smart Window zuerst für Nutzer in Frankreich und Nordamerika. Großbritannien und Deutschland sollen im Laufe des Jahres folgen. Die Reihenfolge hat Gründe: Frankreich ist Mistrals Heimatmarkt, Nordamerika der größte Browsermarkt. Dass Deutschland später dran ist, dürfte an der Sprachqualität und den regulatorischen Bedingungen liegen.

Für deutschsprachige Nutzer heißt das: Die Technik wird erst dann sinnvoll eingesetzt, wenn die Modelle mit der Sprache umgehen können. Der Zeitplan zeigt außerdem, dass kein global einheitliches Produkt ausgerollt wird, sondern ein schrittweises. Regionale Anpassung ist Voraussetzung dafür, dass so ein Assistent brauchbar ist, nicht Marketingzusatz.

Datenschutz von Anfang an

Die Ankündigung nennt zwei Zusagen. Gespräche werden standardmäßig nicht auf Mozillas Servern gespeichert. Partner wie Mistral verpflichten sich zur Zero Data Retention, bewahren die verarbeiteten Daten also nicht auf. Das ist mehr, als viele vergleichbare Dienste zusagen, und ein bewusster Kontrast zur üblichen Praxis, Chats zur Produktverbesserung mitzulesen.

Solche Zusagen sollte man trotzdem nüchtern lesen. Es sind Vereinbarungen zwischen Unternehmen, von außen nur begrenzt überprüfbar. Der Browser ist derzeit der Ort, an dem Datenschutz am ehesten verhandelbar ist, weil dort ein Anbieter mit langer Datenschutztradition am Ruder sitzt. Für eine App auf dem Smartphone oder eine Website mit eingebautem Chatbot gilt das nicht automatisch.

Im Alltag heißt das: Suchanfragen nach Produkten oder Reisezielen landen nicht als Trainingsmaterial. Welche Informationen du einem Assistenten gibst, entscheidest weiterhin du. Kein Modell und keine Zusage nimmt dir das ab.

Sprachmodelle für Dialekte und Regionen

Mistral trainiert und justiert seine Systeme nach eigenen Angaben auf regionale Sprachen, Dialekte und kulturellen Kontext. Was so ein Sprachmodell überhaupt ist: eine Maschine, die abschätzt, welches Wort als nächstes wahrscheinlich folgt – trainiert auf sehr viel Text. Was dabei herauskommt, hängt davon ab, welche Sprache und welche Welt in diesem Text vorkam.

Feinabstimmung heißt, das Grundmodell mit zusätzlichen Beispielen auf ein Verhalten oder eine Sprache zu justieren. Ein Modell, das überwiegend englische Texte gesehen hat, versteht deutsche Höflichkeitsformen, Dialekte oder regionale Begriffe oft nur oberflächlich. Es antwortet korrekt, aber nicht passend – wie jemand, der die Sprache aus dem Lehrbuch kennt, aber nie dort gelebt hat.

KI ist nicht einfach eine Schaltfläche, die man einschaltet. Wie gut sie funktioniert, hängt davon ab, ob sie Sprache, Kultur und Kontext ihres Gegenübers kennt. Hier setzt die Partnerschaft an: der Unterschied zwischen einem importierten Werkzeug und einem, das vor Ort entwickelt wurde.

Offene Technik braucht offene Verteilung

Der erste der vier genannten Gründe lautet: Offene Technologie braucht offene Wege, um Menschen zu erreichen. Mistral veröffentlicht seit dem ersten Release Modelle mit offenen Gewichten, Mozilla kämpft seit über zwei Jahrzehnten für ein offenes Web. Ein Punkt geht in der KI-Debatte oft unter: Ein Modell, das kaum jemand erreicht, verändert nichts, egal wie offen seine Lizenz ist.

Verteilung ist deshalb eine Machtfrage. Kommt KI nur über die Produkte von zwei oder drei Konzernen zu den Nutzern, entscheiden diese Konzerne, welche Modelle es in den Alltag schaffen. Ein Browser ist dann keine neutrale Software, sondern eine Vertriebsstraße mit viel Verkehr. Mozilla öffnet sie für mehrere Anbieter, statt sie selbst zu betreiben.

Als viertes Argument nennt Mistral die souveräne KI – Systeme, die nicht vollständig von ausländischer Infrastruktur und ausländischen Regeln abhängen. Ein politisches Ziel mit praktischem Kern: Wer kontrolliert, welche Daten wohin fließen, kontrolliert auch, welche Antworten möglich sind.

Was das konkret bedeutet – und was nicht

Die Partnerschaft macht den Browser zu einem Ort, an dem mehrere KI-Anbieter um dieselbe Aufmerksamkeit konkurrieren. Viel Lärm ist darum nicht zu machen. Es ist eine Weichenstellung: Wenn Nutzer den Anbieter wechseln können, ohne den Browser zu wechseln, entsteht Druck, der sonst fehlt.

Sie bedeutet nicht, dass KI im Browser dadurch vertrauenswürdig wird. Zusagen zur Datenaufbewahrung sind wichtig, bleiben aber Zusagen. Wie gut der Assistent Deutsch kann, lässt sich erst messen, wenn er hierzulande verfügbar ist. Bis dahin ist der deutsche Markt ein Versprechen mit Zeitplan.

Für Einsteiger ist das trotzdem erfreulich: KI kommt dorthin, wo man ohnehin arbeitet, und der Einstieg wird leichter. Man muss kein neues Programm lernen, um zu sehen, was ein Sprachmodell leistet. Man benutzt weiter seinen Browser, nur mit einem zusätzlichen Gesprächspartner, der die offenen Tabs kennt.

Der Satz vom Anfang taugt als Prüfstein. Ob ein Browser ein Einbahnkanal ist, entscheidet sich nicht an der Ankündigung, sondern daran, ob man den Anbieter dahinter austauschen kann. Daran wird sich zeigen, ob aus der Partnerschaft mehr wird als ein Beta-Feature.

Quelle: mistral.ai

Wer bisher wollte, dass ein Sprachmodell die Lampen schaltet oder die Aufnahmen der Türklingel zusammenfasst, baute sich den Weg dorthin selbst – durch Schnittstellen, Tokens und halb dokumentierte Bibliotheken. Seit dieser Woche gibt es einen offiziellen: Google hat eine frühe Fassung eines MCP-Servers für sein Smart-Home-Ökosystem freigegeben. Was dabei entsteht, ist weder eine App noch ein Skript, sondern eine Verbindung zwischen einem KI-Agenten und dem eigenen Zuhause.

Wie TechCrunch berichtet, dürfen KI-Agenten damit auf Geräte und Ereignisverlauf zugreifen – kontrolliert über Berechtigungen und ohne eigene Programmierung. Angekündigt wurde die Freigabe am Mittwoch, dem 16. September 2026.

Was der MCP-Server von Google Home macht

MCP steht für Model Context Protocol, einen offenen Standard, der beschreibt, wie ein KI-Modell mit externen Werkzeugen und Datenquellen spricht. Man kann sich das wie eine einheitliche Steckdose vorstellen. Früher hatte jedes Gerät seinen eigenen Stecker, jedes Haus seine eigene Dose, und für jede Kombination brauchte es einen neuen Adapter. Mit MCP gibt es eine Form, in die viele Geräte und viele Agenten passen.

Der Agent muss also nicht jedes einzelne Gerät kennen, sondern nur den Standard. Wer heute einen Agenten wie Claude, ChatGPT, Hermes, OpenClaw oder Googles Antigravity nutzt und dieser Standard unterstützt, kann dieselbe Verbindung verwenden. Der Server auf der anderen Seite übersetzt zwischen der Sprache des Modells und der Welt der Geräte.

Google setzt MCP nicht zum ersten Mal ein. In Google Cloud, den Datenplattformen, den Entwicklerwerkzeugen und in Workspace gehört der Standard längst zum Alltag. Neu ist der Adressat: Mit Google Home richtet sich die Unterstützung zum ersten Mal direkt an Menschen, die zu Hause mit KI-Agenten experimentieren, nicht an Entwicklerteams in Unternehmen. Damit stellt sich nicht mehr die Frage, ob es technisch geht, sondern wer das bedienen soll.

Einrichtung: Cloud-Projekt, Token, Agent

Bequem ist der Einstieg nicht, und Google tut auch nicht so. Wer die Verbindung nutzen will, legt zunächst ein Google-Cloud-Projekt an und richtet es für Home MCP ein. Danach gibt man die Konfigurationsdaten des MCP-Servers an den Agenten der Wahl weiter und bittet ihn, die Verbindung herzustellen.

Der Agent übernimmt den Rest und fragt im nächsten Schritt nach einer Anmeldung. Erst wenn der Nutzer sich angemeldet und die Berechtigungen erteilt hat, darf der Agent auf Geräte und Ereignisverläufe zugreifen. Wer das einmal durchlaufen hat, kennt das Muster von jeder App, die Zugriff auf ein Konto erbittet — nur dass hier ein Modell die Rolle der App übernimmt.

Eine ausführliche Anleitung will Google im Google Home Developer Center bereitstellen. Zusätzlich sammelt das Unternehmen während der frühen Phase Rückmeldungen in der Smart Home for Developers Community. Wer so etwas zuerst ausprobiert, stößt auf die Ecken und Kanten, die in keiner Dokumentation stehen.

Welche Geräte sich anbinden lassen

Der Zugriff gilt grundsätzlich für alles, was im Google-Home-Ökosystem hängt. Dazu gehören Nest-Türklingeln und Thermostate ebenso wie Geräte mit dem Siegel „Works with Google Home“ oder Anbindung über Matter — Glühbirnen, Steckdosen, Sensoren. Der Kreis ist größer, als man auf den ersten Blick vermuten würde.

Matter spielt dabei eine stille, aber wichtige Rolle. Der Standard sorgt dafür, dass Geräte verschiedener Hersteller überhaupt in einer gemeinsamen Sprache erreichbar sind. Ohne diese Basis wäre die Idee eines universellen Agenten nicht mehr als ein Versprechen.

Interessanter als das reine Schalten ist ohnehin der zweite Teil: der Zugriff auf den Ereignisverlauf. Ein Agent kann Zusammenfassungen der Kameraaufnahmen liefern, Aktivitäten im Haus beobachten und aus den Daten eigene Übersichten bauen. Statt zwanzig einzelne Befehle zu tippen — Licht an, Thermostat runter, Kamera prüfen — beschreibt man in natürlicher Sprache, was man wissen will.

Damit ändert sich auch die Sprachsteuerung selbst. Sie ist nicht mehr eine Sammlung fester Befehle, sondern ein Gespräch, in dem ein Agent Zusammenhänge herstellt. Aus „Mach das Licht aus“ wird „Ist heute Nacht jemand am Gartentor gewesen, und lief die Heizung durch?“. Das klingt nach einem kleinen Unterschied, verändert aber, wie man mit seinem Zuhause spricht.

Nur mit Google Home Premium Advanced

Die frühe Fassung ist nicht für alle gedacht. Die Freigabe startet in den USA und läuft über die kommenden Wochen aus, ausschließlich für Abonnenten von Google Home Premium Advanced. Das ist die teurere Stufe für rund 20 Dollar im Monat.

In dieser Stufe stecken Funktionen, die zur Idee passen: eine längere ereignisbasierte Video-Historie, beschreibende Benachrichtigungen, detaillierte Warnungen, eine Suche im Videoverlauf und tägliche Zusammenfassungen. Ein Agent, der den Haushalt zusammenfasst, braucht diese Daten, um etwas Sinnvolles sagen zu können. Ohne Verlauf gibt es nichts zu berichten.

Ob und wann der MCP-Server auch für günstigere Stufen oder andere Länder kommt, wollte Google nicht sagen. Dass eine frühere Fassung der Meldung noch korrigiert werden musste — der Start war Mittwoch, nicht Dienstag — zeigt, wie frisch die Sache ist.

Was Agenten im Haushalt leisten können

Praktisch sieht das so aus, dass man morgens fragt, ob in der Nacht alles ruhig war, und eine Antwort bekommt, die Klingel, Bewegungsmelder und Heizung zusammenführt. Man lässt sich eine Übersicht bauen, die genau die Werte zeigt, die einen interessieren, statt der Kacheln, die eine Hersteller-App vorgibt. Man bittet den Agenten, eine Regel zu formulieren, und sieht zu, wie er sie umsetzt.

Die Grenzen sind schnell erreicht. Ein Agent ist keine Automatisierung, die im Hintergrund dauerhaft zuverlässig läuft, sondern eine Schicht darüber, die auf Zuruf arbeitet. Er braucht Berechtigungen, eine Verbindung und ein Modell, das versteht, was gemeint ist. Wer einem Agenten Zugriff auf den Ereignisverlauf gibt, gibt ihm Zugriff auf ziemlich persönliche Daten — wer das Token hat, hat diesen Blick ins Haus.

Dazu kommt, dass die Sprachsteuerung selbst nicht neu ist. Neu ist die Rolle des Systems: vom Ausführenden zum Mitdenkenden. Ein Assistent, der einen Befehl erkennt, und ein Agent, der einen Zusammenhang herstellt, sind zwei verschiedene Dinge. Zwischen diesen beiden Dingen liegt der Sprung, den Google hier vorbereitet.

Google hat eine Steckdose installiert und einen ersten Kreis von Nutzern eingeladen, etwas einzustecken. Ob daraus ein Standard fürs ganze Zuhause wird oder eine Spielwiese für Technikbegeisterte, entscheidet sich an den Details: Preis, Verfügbarkeit, Datenschutz und daran, wie viel Kontrolle man abgeben will. Wer sein Smart Home bisher über feste Befehle steuert, bekommt hier den ersten ernsthaften Vorschlag, wie ein Agent den Alltag übernehmen könnte — nicht als Ersatz für die Geräte, sondern als Schicht darüber, die versteht, was man vorhat.

Quelle: techcrunch.com

Am 15. September 2026 hat Google mehrere Drittanbieter-Connectors für Gemini in Google Workspace freigeschaltet. Wer Gemini for Google Workspace nutzt, kann aus dem Gemini-Panel heraus direkt mit Asana, Atlassian Rovo, HubSpot, Intuit Mailchimp, Intuit QuickBooks, Monday und Salesforce arbeiten, ohne das jeweilige System in einem weiteren Tab zu öffnen oder Dateien hin und her zu schieben. Klingt nach einem weiteren Punkt auf der Feature-Liste. Entscheidend ist etwas anderes: Die meisten Gemini-Projekte scheitern nicht am Modell, sondern daran, dass die Daten in einem anderen System liegen als das Werkzeug, mit dem man sie abfragt.

Warum MCP wie ein einheitlicher Schlüssel funktioniert

Wer schon einmal Daten zwischen zwei Fachanwendungen übertragen hat, kennt das Muster: Jedes System hat sein eigenes Schloss, seinen eigenen Schlüssel und seine eigene Vorstellung davon, was ein Datensatz ist. Der Ausweg war lange der Export. Man lud eine CSV-Datei herunter, klebte sie in ein Sheet und arbeitete mit einer Kopie, die beim nächsten Öffnen schon veraltet war. Nicht der Export kostet, sondern die Kopie. Ab diesem Moment gibt es zwei Wahrheiten im Unternehmen.

Das Model Context Protocol, kurz MCP, setzt woanders an. Es beschreibt standardisiert, wie ein Sprachmodell Werkzeuge und Datenquellen anspricht: welche Abfragen möglich sind, welche Parameter erwartet werden, welche Antwortstruktur zurückkommt. Statt für jede Anwendung eine eigene Anbindung zu bauen, gibt es einen gemeinsamen Schlüsselbart, der in viele Schlösser passt. Gemini öffnet damit die Tür zum jeweiligen System, ohne dass die Daten es verlassen müssen. Für Anwender heißt das: Die Antwort kommt aus der Quelle, nicht aus einem Zwischenspeicher.

Wichtig sind die Berechtigungen. Ein Connector ist kein Generalschlüssel für alle Räume. Er ist eine Verbindung, die man ein- und ausschalten kann und die nur zeigt, wozu der Nutzer ohnehin Zugang hätte. Hier kommt die Admin-Konsole ins Spiel.

Was die sieben Connectors zusammenführen

Die Auswahl ist kein Zufall. Sie deckt die vier Bereiche ab, in denen Arbeitsalltag stattfindet: Projektarbeit, Vertrieb und Marketing, Finanzen, Wissensmanagement. Asana und Monday liefern Aufgaben, Projektstände und Zuständigkeiten. Atlassian Rovo bringt Jira und Confluence mit, wo technische Teams Tickets und Dokumentation pflegen. Salesforce und HubSpot steuern die Kundensicht bei, von Kontakten über Opportunities bis zu laufenden Deals.

Intuit QuickBooks trägt die Finanzperspektive bei: Rechnungen, Ausgaben, Buchhaltungsstände. Intuit Mailchimp ergänzt Kampagnendaten und Zielgruppen aus dem Marketing. Zusammen ergibt das eine Landkarte, wo vorher sieben einzelne Karten lagen.

Ein Beispiel zeigt den Unterschied deutlicher als jede Feature-Beschreibung. Eine Umsatzübersicht soll in einem Sheet entstehen. Bisher: Salesforce öffnen, Report bauen, exportieren, einfügen, Formatierung reparieren — und im Meeting feststellen, dass die Zahlen sich längst geändert haben. Mit einem aktiven Connector lässt sich die Frage direkt dort stellen, wo die Tabelle entsteht. Die Antwort kommt aus Salesforce, der Kontext bleibt in Docs, Sheets oder Chat. Der Nutzen liegt weniger in gesparten Klicks als darin, dass niemand mehr eine veraltete Kopie weiterreicht.

Wie Admins die Connectors steuern

Für Administratoren ist ein anderer Satz in Googles Ankündigung entscheidend: Die Funktion ist standardmäßig aktiv. Wer nichts tut, hat sie an. Das ist bequem, verschiebt aber die Verantwortung in die Konfiguration.

Gesteuert wird das in der Admin-Konsole unter Apps, Google Workspace, Gemini for Workspace, Third-Party Connectors. Dort lässt sich festlegen, welche Connectors für die Organisation verfügbar sind, und es lassen sich Zugriffsrichtlinien pflegen. Die Ebenen sind Domain, organisatorische Einheit (OU) oder Gruppe. Das bildet unterschiedliche Realitäten ab: Die Buchhaltung braucht QuickBooks, vertriebsnahe Rollen brauchen Salesforce und HubSpot, das Produktteam Asana und Rovo. Eine pauschale Freigabe für die ganze Domain wäre technisch einfach und organisatorisch falsch.

Wer konfiguriert, sollte außerdem klären, welche Systeme als Datenquelle gelten und wer für deren Inhalte verantwortlich ist. Ein Connector macht eine schlecht gepflegte Datenquelle nicht besser, nur schneller sichtbar. Die Dokumentation in Google Workspace Admin Help beschreibt die Verwaltung im Detail. Lesenswert vor der Freigabe, nicht danach. Die Standardeinstellung ist ein Angebot, keine Empfehlung.

Was Endnutzer im Gemini Side Panel sehen

Für Anwender ist von der Konfiguration nichts zu sehen. Sie sehen das Gemini-Panel, das sie kennen, erweitert um die Systeme, die ihr Admin freigegeben hat. Der Zugriff läuft über das Side Panel in Docs, Sheets und Slides sowie über Google Chat. In Sheets lässt sich Gemini nach Werten fragen, die aus einem angebundenen System stammen, während die Tabelle geöffnet bleibt.

In Chat entsteht eine Variante, die für viele Teams praxisnäher ist als jedes Dokument. Eine Frage im Kanal, eine Antwort aus dem verbundenen System — alle sehen denselben Stand. Die Information wandert nicht mehr zum Werkzeug; das Werkzeug holt sie dort, wo sie liegt.

Die Erwartungen sollten trotzdem realistisch bleiben. Ein Connector ist eine Schnittstelle, kein vollständiges Datenmodell. Nicht jede Frage, die sich in Salesforce stellen lässt, lässt sich aus dem Gemini-Panel beantworten. Die Anbindung deckt definierte Abfragen ab, nicht die komplette Oberfläche des Fremdsystems. Wer Reports mit komplexer Logik, Berechtigungskaskaden oder Custom-Objekten braucht, arbeitet weiter im Fachsystem. Der Gewinn liegt bei den häufigen, einfachen Fragen, die bisher jedes Mal einen Kontextwechsel erforderten.

Rollout, Editions und der 15. September 2026

Die Funktion ist ab sofort verfügbar, für Rapid-Release- und Scheduled-Release-Domains. Der Unterschied ist bekannt: Rapid-Release-Domains bekommen Neuerungen zuerst und können sie meist nicht aufschieben, Scheduled-Release-Domains nach einer Vorlaufzeit. Diesmal entfällt die Wartezeit, die Standardaktivierung greift in beiden Umgebungen zum selben Zeitpunkt.

Verfügbar ist die Funktion in mehreren Editionsgruppen. Im Business-Bereich: Business, Standard und Plus. Im Enterprise-Bereich: Enterprise, Standard und Plus. Dazu Enterprise Essentials Plus sowie die Education-Editionen Google AI Pro for Education, Teaching and Learning und Endpoint Education. Auf der Consumer-Seite sind Google AI Pro und Ultra dabei. Die Funktion bleibt also nicht auf große Vertriebsorganisationen beschränkt, sondern erreicht auch Bildungseinrichtungen und kleinere Unternehmen — sofern die jeweilige Edition Gemini for Google Workspace enthält.

Für Teams, die Gemini bisher nur für Textarbeit in Docs genutzt haben, wächst die Einsatzbreite. Für Teams, die Gemini gar nicht nutzen, ändert sich vor allem eine Einstellung in der Admin-Konsole, von der sie womöglich nichts wussten.

Was das im Alltag bedeutet

Die technische Anbindung ist der einfache Teil. Der schwierige Teil beginnt danach, und er ist organisatorisch. Sobald Gemini auf sieben externe Systeme zugreifen kann, ist die Frage nach Datenqualität und Berechtigungspflege nicht mehr nur Sache der Fachabteilungen. Sie berührt auch, welche Auskunft ein Sprachassistent im Zweifel gibt und wie nachvollziehbar das bleibt.

Sinnvoll ist ein Vorgehen in drei Schritten. Erstens: eine bewusste Entscheidung pro Connector statt stiller Übernahme der Standardeinstellung. Zweitens: eine Zuordnung, welche Rollen welchen Zugang brauchen, abgebildet über Gruppen oder organisatorische Einheiten. Drittens: eine kurze Prüfung der Datenquellen, die angebunden werden. Ein Connector verstärkt bestehende Unordnung, statt sie zu beheben.

Der Fortschritt liegt nicht darin, dass Gemini mehr Systeme kennt. Er liegt darin, dass der Wechsel zwischen Werkzeugen seine Selbstverständlichkeit verliert. Wer zehnmal am Tag zwischen Tabellen und CRM springt, hält das für Arbeit. Es ist Kontextwechsel, und der verschwindet gerade leise, ohne dass jemand eine neue Oberfläche lernen muss.

Quelle: workspaceupdates.googleblog.com

Ein Zieldatum verschiebt sich, und im selben Moment fällt dreierlei an: Das Launch-Dokument braucht eine neue Fassung, ein Issue will angelegt sein, das Team erwartet eine Erklärung für den neuen Termin. Linear bündelt diese Kette seit dem Changelog-Eintrag vom 14. September in Loops – wiederkehrenden Agent-Workflows, die auf Ereignisse im Workspace reagieren statt auf einen manuellen Anstoß. Beschrieben wird damit ein Problem, das viele Entwicklungsteams kennen: Nicht die Änderung kostet Zeit, sondern das Nachziehen. Dort gehen Übergaben verloren.

Die brauchbarste Analogie für Loops ist ein Protokollführer, der den Besprechungsraum nie verlässt. Er notiert nicht, weil er gerade Lust hat, sondern weil er einen Auftrag hat: festhalten, was sich ändert, die Notiz an die richtigen Leute verteilen, dafür sorgen, dass das Dokument zum Stand der Dinge passt. Bei Loops kommt der Anspruch hinzu, den nächsten Schritt gleich mitzuerledigen. Darin steckt auch die wichtigste Einschränkung: Ein Protokollführer ohne klare Regeln schreibt alles auf, und am Ende liest niemand mehr mit.

Was ein Loop technisch ist: wiederkehrende Agent-Workflows für Teams

Der Begriff klingt größer, als er ist. Ein Loop ist zunächst ein Ablauf, der an einen definierten Auslöser gebunden ist und danach eine Kette von Schritten ausführt: Issues anlegen, Projekte und Initiativen aktualisieren, Dokumente bearbeiten, Nachrichten formulieren. Der Unterschied zur klassischen Automatisierung mit starren Wenn-dann-Regeln liegt in der Bauart als Agent-Workflow. Ein Loop zieht Kontext aus dem Workspace und aus angebundenen Werkzeugen und formuliert daraus selbst, statt nur ein vorbereitetes Template zu füllen.

Damit verschiebt sich der Charakter der Automatisierung. Klassische Regeln kannten die Vergangenheit: Wenn sich Feld X ändert, setze Feld Y. Ein Agent-Workflow arbeitet stärker mit Bedeutung. Er weiß, dass ein verschobenes Zieldatum nicht nur ein Datum betrifft, sondern einen Launch-Plan, eine Meilensteinliste und die Erwartung von Menschen, die nicht im selben Slack-Kanal sitzen. Loops für Produktmanagement in Linear setzen dort an: nicht am einzelnen Feld, sondern an der Koordination, die daran hängt.

Die Frage ist deshalb selten, ob ein Loop etwas kann, sondern wann er es tut. Ein Protokollführer, der bei jeder Kleinigkeit aufsteht und eine Runde durchs Büro dreht, wird schnell ignoriert. In der Praxis heißt das: Die Qualität eines Loops hängt weniger an seiner Fähigkeit als an seinem Auslöser. Wer hier zu grob ansetzt, erzeugt Rauschen in den Kanälen, die für wichtige Information reserviert sind.

Neue Auslöser: Projektänderungen automatisch dokumentieren

Linear hat die Auslöser deutlich erweitert. Loops reagieren jetzt auf mehr Aktivität im Workspace, ausdrücklich genannt werden Änderungen an Initiativen, Projekten und Zyklen. Vorher waren die Anknüpfungspunkte enger gefasst; nun greifen die Abläufe auch dort, wo produktstrategische Planung stattfindet. Für Teams, die ihre Roadmap in Initiativen und Projekten abbilden, ist das der relevante Teil des Updates.

Konkret nennen die Release Notes bei Projekten und Initiativen Änderungen am Status, an der Verantwortlichkeit, an Zieldaten, an Meilensteinen, an der Mitgliedschaft und an Labels. Hinzu kommen neue Updates und Kommentare an diesen Objekten. Ein Loop lässt sich damit etwa an den Moment hängen, in dem ein Projekt den Besitzer wechselt, oder an den Moment, in dem ein Meilenstein verschoben wird. Projektänderungen lassen sich so automatisch dokumentieren, ohne für jeden Sonderfall eine Regel zu bauen.

Auch Zyklen sind jetzt Auslöser: Sie können erstellt, gestartet oder abgeschlossen werden. Auf der Ebene der Issues reagieren Loops auf Änderungen an Status, Priorität, zugewiesener Person, Zyklus, Projekt oder Labels. Zusammen ergibt das ein recht feinmaschiges Netz über den gesamten Arbeitsbereich. Man kann das als Feature-Liste lesen – oder als Anlass, die eigene Prozesshygiene zu überdenken.

Der zweite Blick lohnt sich, weil viele dieser Ereignisse im Alltag unbemerkt bleiben. Ein Label, das sich ändert, ist selten ein Grund für eine Nachricht. Ein Projekt, das die Verantwortung wechselt, dagegen sehr wohl. Die Arbeit besteht darin, aus der langen Liste der Auslöser die zwei oder drei herauszusuchen, die bei einem selbst wirklich Folgen haben. Alles andere erzeugt Aktivität ohne Wirkung.

Linear-Dokumente bearbeiten und Slack-Updates automatisch posten

Neu ist auch, was ein Loop nach dem Auslöser tut. Bisher konnten Loops Issues anlegen sowie Projekte und Initiativen aktualisieren. Jetzt kommen zwei Fähigkeiten hinzu, die einen großen Teil der Nacharbeit abdecken. Zum einen können Loops Linear-Dokumente bearbeiten. Wenn sich Umfang oder Zeitplan ändern, lässt sich das Dokument, in dem der Plan steht, direkt nachziehen, statt als Notiz daneben zu liegen.

Zum anderen formulieren Loops Slack-Nachrichten und posten sie. Sie nutzen dabei Kontext aus Linear und aus angebundenen Werkzeugen, sodass die Nachricht nicht nur ein Datenfeld weitergibt, sondern einordnet, was passiert ist und was als Nächstes zu tun ist. Slack-Updates automatisch posten heißt hier also nicht, dass ein Bot stumpf ein Datum ausgibt. Es heißt, dass ein kurzer, auf die Zielgruppe zugeschnittener Text entsteht.

Das Standardbeispiel im Changelog ist das, was in vielen Teams regelmäßig schiefgeht: Ein Projekt ändert sein Zieldatum. Der Loop aktualisiert den Launch-Plan und schreibt eine Slack-Nachricht, die erklärt, was sich geändert hat, warum, und wer etwas tun muss. Wer diese drei Punkte schon einmal nach einem hektischen Planungsmeeting per Hand zusammensuchen musste, weiß, wo die Zeit hingeht.

Die Grenze liegt in der Formulierung. Ein Agent, der eine Nachricht verfasst, trifft einen Ton. Der kann zur Kultur passen oder danebenliegen. Wer Loops produktiv einsetzt, sollte deshalb nicht bei der ersten Ausgabe aufhören, sondern die Ergebnisse kurz gegenlesen und die Auslöser so zuschneiden, dass nur relevante Änderungen eine Nachricht auslösen. Ein Protokollführer braucht Rückmeldung, sonst schreibt er ins Leere.

Jeder Lauf bleibt ein Gespräch mit dem Linear Agent

Ein weiterer Punkt ist die Nachvollziehbarkeit. Jeder Loop-Lauf startet eine Unterhaltung mit dem Linear Agent. Ist der Lauf beendet, lässt sich diese Unterhaltung weiterführen wie jede andere Agent-Session. Das klingt nach einem Detail, ist praktisch aber der Unterschied zwischen einer Blackbox und einem Werkzeug. Man kann prüfen, was der Agent getan hat, zusätzlichen Kontext nachliefern und steuern, was als Nächstes passiert.

Für Teams mit Review-Pflichten ist das relevant. Eine Änderung an einem Dokument oder ein Post in einem breit gelesenen Kanal lässt sich nach dem Lauf ansehen, kommentieren und korrigieren, statt unbemerkt stehen zu bleiben. Die Agent-Session wird damit zum Übergabepunkt zwischen Automatik und menschlicher Entscheidung. Dort gehört sie hin.

Die Einführungskosten bleiben zunächst gedeckelt. Linear hat die einführenden Loops-Credits bis zum 31. Dezember verlängert, damit Teams die Abläufe länger an eigenen Prozessen testen können. Details dazu stehen in der Dokumentation.

Callouts, Diffs und die vielen kleinen Korrekturen

Abseits der Loops enthält der Changelog eine Reihe kleinerer Änderungen, die keine große Überschrift brauchen, im Alltag aber auffallen. Dazu gehören Callout-Komponenten für Issue- und Projektbeschreibungen sowie für Dokumente. Farbe, Icon oder Emoji lassen sich frei wählen, und in Pull-Request-Beschreibungen übersetzt Linear den Callout in den nächstliegenden GitHub-Typ, damit die Hervorhebung erhalten bleibt. Ausgelöst wird das Ganze über den Befehl /callout.

Im Diff-Bereich hat Linear mehrere Reibungspunkte bearbeitet. Vorschläge für Issues lösen seltener falsche Treffer aus, es gibt eine Aktion zum Kopieren von Dateinamen im Dateibaum, eine Hover-Erklärung am Pull-Request-Status, die bei einem Blocked-Badge benennt, was den Merge blockiert, und einen Knopf zum Verwerfen einzelner Diff-Vorschläge. Zusätzlich tauchen verwandte Diffs nun in der Seitenleiste eines Pull Requests auf, und eingeklappte Codeblöcke lassen sich mit Shift plus Pfeiltaste nach oben oder unten gezielt aufklappen.

Weitere Korrekturen verteilen sich über die Bereiche Import, iOS, Issues, MCP, Settings und Slack. Der Import aus GitHub behält den Archivstatus bei, auf iOS zeigt die Bestätigung einer Issue-Delegation nicht mehr interne Nutzerdaten statt des Agent-Namens, und beim Kopieren von Issues fehlen keine verschachtelten Sub-Issues mehr. Datadog-MCP-Verbindungen laufen jetzt über die unterstützten v1-Endpunkte, SCIM-verwaltete Teammitglieder tragen nicht länger ein falsches Non-SCIM-Label, und Slack hat einen doppelten Linkback beseitigt.

Ergänzend gibt es kleinere Verbesserungen an mehreren Stellen: Issues aus Formularvorlagen behalten Status und Labels der Spalte, unter der sie erstellt wurden, der Editor erlaubt Kommentare auf Links samt Thread-Ansicht, neue Label-Filter stehen standardmäßig auf „include any of“, wenn alle gewählten Labels zur selben Gruppe gehören, und Projekte lassen sich über den synchronisierten Jira-Epic-Schlüssel finden. Für Webhooks kündigt Linear neue ausgehende IP-Adressen an, die in den Wochen nach dem 14. September 2026 aktiv werden, außerdem wurden Team-Updates für Asks-E-Mail-Adressen korrigiert.

Was das für Teams und Projektmanagement-Software konkret bedeutet

Betrachtet man das Update als Ganzes, verschiebt sich der Anspruch von Projektmanagement-Software. Die Anwendung war lange das Archiv: Hier steht, was beschlossen wurde. Mit Agent-Workflows wird sie zum Auslöser und Verteiler. Das System bemerkt Änderungen, zieht die Dokumentation nach und informiert die Beteiligten. Produktmanagement-Automatisierung wandert damit von der Aufgabenebene auf die Koordinationsebene, und dort sitzt der Aufwand.

Das entbindet niemanden von Verantwortung. Ein Loop kennt keine Politik, keine unausgesprochenen Absprachen und keine Ausnahme, die nur zwei Personen im Kopf haben. Er braucht klare Auslöser, eine benannte Verantwortung und einen Review-Punkt für alles, was nach außen geht. Wer diese drei Dinge nicht klärt, bekommt schnell viele gut formulierte Nachrichten, die niemand bestellt hat.

Für Teams, die bereits in Linear arbeiten, ist die Empfehlung unspektakulär: einen wiederkehrenden Schmerz auswählen, etwa das Nachziehen des Launch-Plans bei Terminänderungen, dafür einen einzigen Loop bauen und zwei Wochen beobachten, was passiert. Erst wenn die Ausgabe verlässlich ist, kommen weitere Auslöser dazu. Der Protokollführer wird nicht dadurch besser, dass er in jedem Raum gleichzeitig sitzt, sondern dadurch, dass er im richtigen Raum sitzt und dort gründlich arbeitet.

Quelle: linear.app

37 Fähigkeiten bringt das Plugin mit, das Anthropic laut eigenem Blogbeitrag gemeinsam mit Salesforce in einer Beta veröffentlicht hat. Die Zahl steht für den Kern der Ankündigung. Kein weiteres Chat-Fenster, sondern ein Werkzeugkasten für Accounts, Opportunities und Pipeline. Salesforce in Claude heißt das Plugin. Wer es nutzt, arbeitet weiter mit den Daten aus Salesforce – nur an anderer Stelle, mit anderen Mitteln und unter denselben Berechtigungen.

Im Vertrieb ist der Gegner selten der Wettbewerb. Es ist die Zeit zwischen zwei Kundengesprächen: Notizen sortieren, den Stand eines Geschäfts prüfen, herausfinden, was das Account-Team diese Woche besprochen hat, Termine vorbereiten, Updates nachtragen. Man kann sich das wie eine Werkbank vor einem Aktenschrank vorstellen. Die Ordnung bleibt im Schrank, gearbeitet wird davor, und was entsteht, wandert zurück in die Schublade. Diese Bewegung beschreibt, was das Plugin tut – und wo seine Grenzen liegen.

Zwei Connectoren und 37 Skills: der technische Aufbau

Das Plugin nutzt zwei Connectoren. Der Salesforce-Connector lässt Claude Daten lesen und auf sie reagieren: die Historie eines Accounts zusammenfassen, Opportunities aktualisieren, Anrufe protokollieren, Folgeaufgaben anlegen. Der Slack-Connector deckt die Deal-Channels und die Threads der Account-Teams ab, in beide Richtungen – die Skills lesen darin und schreiben hinein. Eingerichtet werden beide einmalig von einem Administrator, der die Salesforce-Instanz für die Organisation freigibt und festlegt, welche Gruppen das Plugin bekommen.

Für einzelne Nutzer ist der Einstieg schmal. Sie melden sich mit ihren Salesforce-Zugangsdaten an und arbeiten los. Beim ersten Einsatz prüft ein Setup-Skill, welche Werkzeuge und Connectoren vorhanden sind, und erstellt ein Claude-Artifact, das auf Rolle und Kundenbestand zugeschnitten ist. Der Salesforce-MCP lässt sich direkt über den Marktplatz installieren; Zugang für Administratoren läuft über AgentExchange, ein Einrichtungsleitfaden beschreibt die Freischaltung für die eigene Organisation. Unspektakuläre Infrastruktur, aber sie entscheidet, ob ein Rollout Wochen oder einen Nachmittag dauert.

Der Morgenbrief und der Freitagsabschluss

Der Arbeitstag beginnt mit einem Brief, den Claude zusammenstellt. Meetings des Tages, Deals mit nahem Abschlussdatum, gefährdete Opportunities, ungelesene Threads, die eine Antwort brauchen. Einmal geplant, läuft der Brief im Hintergrund und ist überall abrufbar, auch unterwegs in der Claude-App. Aus dem Brief heraus lassen sich Änderungen anstoßen: Abschlussdatum verschieben, Phase wechseln, Folgeaufgabe anlegen. Claude führt sie dann in Salesforce aus.

Am Freitag schließt derselbe Mechanismus die Woche ab und entwirft ein Update für die Führungskraft. Das wirkt wie eine Randnotiz, ist aber der Punkt, an dem sich der Nutzen zeigt. Der größte Teil des administrativen Aufwands kommt nicht von schwierigen Entscheidungen, sondern von den vielen kleinen Einträgen, die niemand gern macht. Ein CRM zu pflegen kostet Zeit, täglich. Verschwindet diese Routine in einem wiederkehrenden Ablauf, bleibt mehr Raum für die Gespräche, um die es geht.

Gesprächsvorbereitung, Deal-Review und der gemeinsame Abschlussplan

Vor einem Termin lässt sich Claude bitten, das nächste Gespräch vorzubereiten. Es zieht zusammen, was in Salesforce, Slack und E-Mail liegt: offene Opportunities und ihr Stand, was das Account-Team diese Woche besprochen hat, unbeantwortete Threads, offene Fragen aus früheren Calls. Findet es in diesen Threads Ansprechpartner, die noch nicht in Salesforce stehen, legt es sie als Kontakte am Account an. Die Vorbereitung endet also nicht beim Lesen, sondern verändert den Datensatz.

Für ein einzelnes Geschäft gibt es den genaueren Blick. Auf eine Opportunity gerichtet, bewertet Claude den Deal gegen die Methodik des Teams, berücksichtigt Lücken in der Qualifizierung, Stakeholder, die noch nicht getroffen wurden, und Faktoren, die das Abschlussdatum gefährden. Auf Nachfrage entwirft es die Nutzenargumentation und einen terminierten, gemeinsamen Abschlussplan, füllt die Qualifizierungsfelder und trägt fehlende Stakeholder als Kontaktrollen nach. Gespeichert wird das erst, nachdem der Vertriebsmitarbeiter zugestimmt hat. Der Ablauf schlägt vor, er führt nicht aus.

Nachbereitung, Pipeline-Dashboard und Forecast aus einer Ansicht

Nach jedem Telefonat übersetzt Claude das Transkript oder die Notizen in eine Folge-E-Mail, eine Zusammenfassung für den Deal-Channel in Slack und Entwürfe für die Opportunity selbst: nächste Schritte, Phase, Abschlussdatum. Auch hier gilt das Muster Vorschlag, Prüfung, Freigabe. Der Nutzen liegt weniger in einem einzelnen Schritt als in ihrer Verkettung. Die Nachbereitung hört auf, ein eigenes Projekt zu sein.

Für die Übersicht lässt sich eine Pipeline-Ansicht anfordern. Claude baut daraus ein interaktives Dashboard: Deckung nach Phase, Deals, die am ehesten rutschen, samt Begründung, und Drill-down bis zum einzelnen Account. Aus dem Dashboard heraus lassen sich Abschlussdaten und Phasen ändern, die Anpassung landet im Salesforce-Datensatz. Dashboards lassen sich mit der Führungsebene oder dem Team teilen, und Claude entwirft den Forecast in dem Format, das die Leitung erwartet. Führungskräfte öffnen dieselben Ansichten über ihr Team hinweg.

Salesforce bleibt das führende System

Ein CRM wird nicht nützlich, indem man es ersetzt, sondern indem man es ernst nimmt. Salesforce bleibt deshalb das führende System; Claude liest nur, was die Berechtigungen des angemeldeten Nutzers zulassen. Standardmäßig bittet Claude um Zustimmung, bevor ein vorgeschlagener Eintrag geschrieben wird. Auf den Tarifen Team und Enterprise werden die Daten standardmäßig nicht zum Training der Modelle verwendet. Der Administrator schaltet den Zugang einmal für die Organisation frei und entscheidet, welche Gruppen das Plugin nutzen dürfen.

Diese Reihenfolge ist der Knackpunkt jeder Salesforce-CRM-Integration. Ohne sie entsteht ein zweiter Datenbestand, der schnell veraltet und Vertrauen kostet. Der Ansatz dreht die Logik um: Nicht der Vertrieb passt sich einem neuen Werkzeug an, sondern das Werkzeug arbeitet in dem Bestand, der ohnehin gepflegt wird. Deshalb werden Lesezugriff, Schreibzugriff und Freigabeschritt getrennt behandelt und nicht in einem einzigen Automatismus aufgelöst.

Was GitLab, Siemens und Legora berichten – und was die Beta nicht löst

Anthropic nennt drei Kunden, die das Plugin ausgerollt haben: GitLab, Siemens und Legora. 7.000 Vertriebsmitarbeiter von Salesforce nutzen es laut Ankündigung in ihrer Arbeit. Der Finanzvorstand von Legora, David Eckstein, beschreibt den Effekt so: Seine Vertriebsmitarbeiter machen aus Live-Daten in Sekunden statt Stunden Gesprächsunterlagen, und jeder neue Mitarbeiter startet mit dem vollständigen Bild der betreuten Kanzleien. Alexa Vignone, President und Chief Revenue Officer bei Salesforce, hebt hervor, dass der Pipeline-Review am Morgen bereits erledigt und die Kontohistorie vorhanden sei – und die gewonnene Zeit direkt in Kundengespräche fließe.

Salesforce in Claude ist derzeit als Beta auf allen bezahlten Claude-Tarifen verfügbar, der Salesforce-MCP über den Marktplatz installierbar. Was das konkret bedeutet: Der Werkzeugkasten steht bereit, die Einrichtung liegt bei der Administration, und die Ergebnisqualität hängt daran, wie gepflegt der zugrunde liegende Datenbestand ist. Ein Plugin dieser Art verstärkt, was da ist. Es erfindet keine sauberen Opportunities, es beschleunigt die Arbeit an denen, die jemand sorgfältig angelegt hat. Für Vertriebsteams ist deshalb weniger interessant, ob Claude Salesforce bedienen kann, sondern wie viel der eigenen Routine sich überhaupt in Regeln und wiederkehrende Abläufe fassen lässt. Dort zeigt sich, ob aus 37 Skills im Alltag etwas wird.

Quelle: claude.com