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
