Freitagabend, Repo aufgeräumt, Agent-Session läuft. Ich tippe „schau bitte nur die Log-Zeilen an“, geh Kaffee holen – und komm zurück zu einem Diff, der drei Test-Fixtures umgeschrieben hat. Kein Prompt. Kein Dialog. Einfach passiert. Spoiler: Assisted Approvals hatten den Tool-Call als Low-Risk eingestuft. Automatisch freigegeben. Und ich hatte die Session-Historie schon weiterlaufen lassen, bevor mir klar war, dass der Auto-Approve der eigentliche Incident war – nicht der Agent.

Nerd-Alarm: Das ist kein Horror-Szenario aus einem Security-Talk. Das ist der Alltag, den GitHub mit Copilot für JetBrains 1.18.0 (Changelog vom 22.9.) gerade öffentlich in Public Preview rollt. Weniger Approval-Interruptions. Mehr Flow. Klingt nach dem, was man sich seit Monaten wünscht. Im Ernst: Es ist genau die Stelle, an der Komfort und Kontrolle sich die Hand reichen – und wo Sie merken, dass die Hand manchmal zu fest zupackt.

Die kurze Version vorweg, bevor wir in die Features abtauchen: Weniger Prompts heißt nicht automatisch, dass der Classifier sicherer geworden ist. Es heißt nur, dass er öfter „passt schon“ sagt. Und Rewind nach parallelen Edits ist keine einfache Undo-Taste – es ist Zeitreise durch Conversation und Dateisystem zugleich. Wir bei digital-magazin.de schauen uns deshalb die Vendor-Claims aus dem JetBrains-Changelog zu Copilot 1.18.0 an, legen daneben den OpenTelemetry-Eintrag vom selben Tag und fragen: Was davon macht Ihren Alltag leichter – und was macht Debugging teurer?

Was Copilot für JetBrains 1.18.0 laut GitHub mitbringt

Laut GitHub-Changelog vom 22.9. bringt Version 1.18.0 eine ganze Packung Agent-Features. Alles Vendor-Claims, keine eigenen Messungen von uns – das gehört vorneweg, bevor jemand die Zahlen in Präsentationen kippt.

AI-assisted tool approvals (Assisted Approvals): Public Preview für Copilot-Agent-Sessions. Low-Risk-Tool-Calls werden automatisch freigegeben, Higher-Risk bleibt Prompt.
Re-edit früherer User-Messages: Vor dem Absenden der Ersatz-Nachricht rewound Copilot Conversation und Datei-Änderungen.
Shared Skills und Org-Instructions: Organisation- und Enterprise-Skills plus org-verwaltete Custom Instructions in lokalen und Copilot-Agent-Sessions.
Codex-Agent Plan Mode: Plan reviewen, verfeinern, freigeben – bevor Implementation startet.
MCP-Kontrollen: Built-in GitHub MCP Server per Toggle (Default an), ohne manuell konfigurierte Server anzufassen; persistente Per-Tool-Controls in Agent-Sessions.
Side-by-Side-Chat-Panel-Switcher, Usage Tips, Welcome Screen, klareres /init-Tipp, Qualitätsschrauben, Gateway/Remote: Inline Chat versteckt; Deprecation-Hinweis für IDE 2025.1 → Upgrade auf 2026.1+.

Das ist die Einkaufsliste. Die spannende Frage ist nicht „was ist neu?“, sondern: Welches dieser Features verändert das Risiko-Profil Ihrer Session – und welches verändert nur den Ton der UI?

Falls Sie generell den Überblick zu GitHub Copilot brauchen: Hier geht’s speziell um die JetBrains-Plugin-Linie 1.18.0 und Agent-Sessions, nicht um Inline-Ghost-Text und auch nicht um das VS-Code-Universum. Randnotiz für alle, die beide IDEs fahren: In VS Code sieht der Flow anders aus – hier bleiben wir bei JetBrains.

Assisted Approvals: Weniger Interruptions, gleiche Verantwortung

GitHub schreibt sinngemäß: Low-Risk-Tool-Calls bekommen automatische Freigabe, Higher-Risk bleibt bei Ihnen. Weniger Approval-Interruptions für Low-Risk, Higher-Risk-Entscheidungen bleiben in Ihrer Hand. Vendor-Claim, klar gekennzeichnet.

Klingt einfach, ist es aber nicht. Denn „Low-Risk“ ist keine physikalische Eigenschaft eines Tools. Es ist eine Klassifikation. Und Klassifikationen irren. Ein Read auf package.json wirkt harmlos – bis der Agent daraus ableitet, dass er Dependencies „aufräumen“ darf und der nächste Call plötzlich Write ist. Ein List-Directory wirkt wie Stöbern – bis der Pfad in .env-Nähe landet und der Kontext für den nächsten Prompt giftig wird.

Meine persönliche Einschätzung: Assisted Approvals sind der Punkt, an dem Teams den Fehler machen, Komfort mit Sicherheit zu verwechseln. Der Prompt, den Sie früher gesehen haben, war nervig. Er war aber auch ein Audit-Event. Wenn er wegfällt, weil irgendetwas „Low-Risk“ sagt, brauchen Sie einen Ersatz-Audit – sonst debuggen Sie später Modell-Schuld, die die Approvals-Policy selbst gebaut hat.

Bastelprojekt-Gedanke: Stellen Sie sich vor, Ihr Pair-Programmer sagt „ich rühr nur die Logs an“ und schreibt heimlich drei Fixtures um, weil die Policy „Log-Tools“ als Low-Risk geführt hat. Wer ist schuld? Das Modell? Der Tool-Wrapper? Oder die Policy, die Low-Risk so breit definiert hat, dass Write-Nebenwirkungen drunterfallen?

https://digital-magazin.de/copilot/

Wenn Low-Risk falsch sitzt: Der Auto-Approve ist der Incident

These, klar als Redaktionsthese: Weniger Approval-Interruptions ≠ sicherer Classifier. Wenn Low-Risk falsch sitzt, ist der Auto-Approve der Incident – nicht der Tool-Call danach. Der Call ist nur die sichtbare Konsequenz.

Warum das so wehtut: In klassischen Agent-Sessions (siehe auch unsere ältere Spur zu Copilot Agent Mode und Next Edit) hatten Sie mindestens einen Moment, in dem Sie „Allow“ oder „Deny“ tippen mussten. Dieser Moment war langsam. Er war aber auch die Stelle, an der Sie den Intent nochmal gegenlesen konnten. Assisted Approvals verkürzen genau diesen Moment für die als Low-Risk markierten Calls.

Fail-Szenario, das ich mir (und Ihnen) wünsche, bevor es real wird:

Sie starten eine Agent-Session: „Lies die Test-Ausgabe und sag mir, warum der Build rot ist.“
Der Agent ruft ein Read-Tool auf die Log-Datei auf – Low-Risk, auto-approved.
Der Agent „hilft“ und will eine Fixture anpassen, weil er die Ursache „sieht“ – und irgendwo in der Tool-Kette sitzt ein Write, der ebenfalls als Low-Risk durchrutscht oder als Folge einer schon freigegebenen Kette läuft.
Sie kommen zurück, sehen grüne Tests – und merken erst beim Review, dass die Fixture jetzt das Bug-Verhalten maskiert statt zu reproduzieren.

Wer ist hier der Bösewicht? Das Modell, das zu hilfsbereit war? Oder die Policy, die „hilfsbereit schreiben“ unter Low-Risk mitlaufen ließ? Im Ernst: Ohne Trace, welches Tool als Low-Risk galt und warum, drehen Sie sich im Kreis. Sie schimpfen auf das Modell, obwohl die Approvals-Policy den Freifahrtschein ausgestellt hat.

Wir bei digital-magazin.de halten das für den zentralen Punkte-Abzug an Assisted Approvals – nicht weil das Feature schlecht wäre, sondern weil es ohne Observability-Gegenstück riskant skaliert. Dazu gleich OpenTelemetry.

Rewind nach Re-Edit: Zeitreise-Diff, kein Undo

Zweiter großer Claim im Changelog: Sie können eine frühere User-Message in einer Copilot-Agent-Session re-editieren. Bevor die Ersatz-Nachricht rausgeht, rewound Copilot sowohl die Conversation als auch Datei-Änderungen. Vendor-Claim.

Das klingt nach „Ups, falsch formuliert, nochmal von vorne“. Und für den linearen Fall – eine Message, ein Diff, kein Parallelchaos – ist das vermutlich genau so angenehm, wie es sich anhört. Aber: Agent-Sessions sind selten linear. Der Agent hat vielleicht parallel drei Dateien angefasst, während Sie noch an Message 2 rumdachten. Ein anderer Tab hat inzwischen manuell nachgezogen. Ein Testlauf hat Artefakte geschrieben, die nicht in der Conversation stehen.

Rewind heißt dann: Conversation zurückrollen und Datei-Änderungen zurückrollen. Das ist Zeitreise. Und Zeitreise hat bekannte Nebenwirkungen – besonders, wenn parallel jemand anderes (oder Sie selbst in einem anderen Fenster) denselben Workspace anfasst. Klingt nach Magie, fühlt sich an wie git reset --hard mit Chat-Gedächtnis. Nur dass Sie vorher vielleicht schon Teile des Diffs committed, gestaged oder manuell weitergebaut haben.

Rhetorische Frage, die ich mir beim Lesen des Changelogs gestellt habe: Was passiert mit Änderungen, die nach dem Rewind-Punkt von Ihnen manuell kamen, aber vor dem Re-Edit-Absenden? Sitzt der Rewind streng am Conversation-Cursor – oder nimmt er alles mit, was der Agent seitdem angefasst hat? Das Changelog sagt „rewinds both the conversation and file changes“. Es sagt nicht explizit, wie Konflikte mit manuellen Edits gelöst werden. Vendor-Claim + Unschärfe. Halten Sie das im Hinterkopf, bevor Sie Rewind als Sicherheitsnetz verkaufen.

Meine zweite persönliche Einschätzung: Rewind ist mächtig und gefährlich zugleich. Es ist genau das Feature, das ich in einer sauberen Session liebe – und in einer Session mit parallelen Edits fürchte. Wenn Sie Rewind nutzen, behandeln Sie es wie einen Checkpoint-Jump, nicht wie Strg+Z. Committen Sie vorher. Oder branch’en Sie. Bastelprojekt-Tipp: Vor dem ersten Re-Edit in einer heiklen Session einen lokalen Commit mit Message „pre-rewind-checkpoint“ setzen. Langweilig. Rettet Abende.

Codex-Agent Plan Mode: Erst Plan, dann Spaten

Der Codex-Agent unterstützt laut Changelog jetzt Plan Mode. Sie können den Plan reviewen, verfeinern oder freigeben, bevor Implementation startet. Vendor-Claim.

Das ist, ehrlich gesagt, die Stelle, an der Assisted Approvals und Plan Mode sich gegenseitig erklären. Plan Mode verschiebt Risiko nach vorne: Sie schauen sich den Plan an, bevor der Agent gräbt. Assisted Approvals verschieben Risiko in die Policy: Low-Risk läuft ohne Sie. Zusammen können sie sinnvoll sein – Plan genehmigt die Richtung, Approvals steuern die Einzelwerkzeuge. Getrennt können sie sich widersprechen: Ein freigegebener Plan, der Low-Risk-Writes in einem Umfang enthält, den Sie im Plan-Review nicht als Risiko gelesen haben.

Spoiler: Ein Plan, der „Refactor der Fixture-Schicht“ sagt, klingt abstrakt harmlos. Die konkreten Tool-Calls darunter können trotzdem die Reproduktionsbasis Ihres Bugs zerstören. Plan Mode ersetzt also nicht Approvals – er ersetzt die blinde Implementation. Approvals bleiben die Feinsteuerung, Assisted Approvals die Automatisierung der Feinsteuerung.

Für Teams, die Agent-Sessions schon länger fahren: Plan Mode ist der Moment, in dem Sie „darf der überhaupt?“ wieder als menschliche Entscheidung einziehen, bevor die Tool-Kette startet. Nutzen Sie das. Besonders, wenn Assisted Approvals parallel Low-Risk durchwinken.

MCP: Toggle für Built-in und persistente Per-Tool-Controls

Zwei MCP-Punkte im Changelog, beide relevant für die Approvals-Diskussion:

Neuer Setting: Built-in GitHub MCP Server an/aus, ohne manuell konfigurierte MCP-Server anzutasten. Default: an.
In Copilot-Agent-Sessions: persistente Per-Tool-Controls für MCP-Server. Einzelne Tools steuern, Built-in-Server separat.

Vendor-Claims. Warum uns das interessiert: Assisted Approvals klassifizieren Tool-Calls. MCP erweitert die Tool-Oberfläche massiv – plötzlich sind nicht nur IDE-interne Reads/Writes im Spiel, sondern externe Server mit eigenen Capabilities. Persistente Per-Tool-Controls heißen: Sie können einzelne MCP-Tools hart abklemmen oder erlauben, und das bleibt. Das ist die Stellschraube, die Assisted Approvals überhaupt erst teamfähig macht.

Die kurze Version: Wenn Low-Risk falsch sitzt, hilft es enorm, wenn Sie das betreffende Tool vorher schon auf „nie ohne Prompt“ oder „gar nicht“ gestellt haben. Per-Tool-Controls sind das manuelle Gegengewicht zur automatischen Freigabe. Nutzen Sie beides – nicht eines von beiden.

Nerd-Alarm für alle, die schon MCP-Server in JetBrains verdrahtet haben: Der Toggle für den Built-in GitHub MCP Server ist genau die Art Feature, die man erst vermisst, wenn man es nicht hatte. Früher: Built-in und Custom vermischt, Konfiguration anfassen, alles wackelt. Jetzt: Built-in aus, Custom bleibt. Klingt banal. Spart Support-Tickets.

Randvergleich, absichtlich kurz: Wer parallel mit Agent-Tools außerhalb von Copilot arbeitet – etwa mit Claude Code – kennt ähnliche Spannungen zwischen Tool-Freigabe und Flow. Die JetBrains-Variante ist hier spezifisch: Persistent per Tool, plus Assisted Approvals als Classifier-Schicht darüber.

Shared Skills und Org-Instructions: Policy wird Produkt

Local- und Copilot-Agent-Sessions unterstützen laut GitHub jetzt Organisation- und Enterprise-Skills sowie org-verwaltete Custom Instructions. Vendor-Claim.

Das verschiebt die Approvals-Diskussion von „was macht mein Plugin?“ zu „was schreibt meine Org mir vor?“. Shared Skills heißen: Dieselbe Skill-Definition landet bei vielen Entwicklerinnen und Entwicklern. Org-managed Custom Instructions heißen: Der System-Prompt-Charakter der Session wird zentral mitgesteuert.

Wir bei digital-magazin.de sehen darin den Punkt, an dem Assisted Approvals unternehmensweit gefährlich oder nützlich werden – je nachdem, ob die Org die Skills und Instructions mit denselben Leuten reviewt, die auch die Approvals-Policy verantworten. Wenn Skills „hilf aktiv beim Refactor“ sagen und Approvals „Refactor-Tools sind Low-Risk“ flüstern, haben Sie eine Feedbackschleife gebaut, die niemand einzeln abgenickt hat.

Praktischer Check für Admins:

Welche Skills gelten als „schreibend“?
Welche Tools stufen Assisted Approvals als Low-Risk ein – und wer dokumentiert das?
Stehen Org-Instructions und Per-Tool-MCP-Controls im selben Review-Zyklus?

Wenn die Antwort auf die dritte Frage „weiß nicht“ ist, haben Sie kein Tooling-Problem. Sie haben ein Ownership-Problem.

OpenTelemetry am selben Tag: Der Trace als Gegenmittel

Copilot: Mechanische Tastatur und leere Sticky Notes — Rewind und Diff-Metaphorik (Symbolbild)

Am 22.9. hat GitHub parallel einen zweiten Changelog-Eintrag veröffentlicht: OpenTelemetry in der GitHub-Copilot-App. Nebenkontext, aber für unsere These zentral.

Laut GitHub können Enterprises über managed Settings OpenTelemetry konfigurieren. Ziel: Agent-Sessions analysieren, unerwartetes Verhalten untersuchen, Monitoring zentral steuern. Konfiguration über die telemetry-Property in der Enterprise-managed-settings.json. Prompt- und Response-Inhalt ist standardmäßig ausgeschlossen – Content-Capture vorher prüfen. Vendor-Claims.

Warum das neben Assisted Approvals gehört: Ohne Trace, welches Tool als Low-Risk galt, debuggen Sie Modell-Schuld, die die Approvals-Policy selbst gebaut hat. OTel ist genau die Schicht, die „welches Tool, wann, mit welchem Status“ in Ihr bestehendes Monitoring schieben kann – statt dass Sie in der IDE-UI Scrollen und raten.

Im Ernst: Assisted Approvals ohne Observability sind Komfort mit Augenbinde. Assisted Approvals plus OTel-Export in Ihr zentrales System – das ist zumindest die Chance, nach einem Incident zu sehen, ob der Classifier „Low-Risk“ gesagt hat, bevor der Write lief. Die kurze Version der Redaktionsmeinung: Schalten Sie Approvals erst dann aggressiv auf Auto, wenn Sie den Trace danach lesen können.

Hinweis zur Privacy-Seite: Prompt/Response sind default excluded. Gut so. Aber „Agent activity data“ – Requests an Modelle, genutzte Tools, Session-Flow – das landet potenziell bei Ihnen. Klären Sie intern, wer diese Traces sehen darf, bevor die ersten Low-Risk-Incidents auftauchen und plötzlich alle den Trace wollen.

Qualität, UX-Kleinkram und der Deprecation-Hinweis

Der Changelog listet außerdem eine Reihe UX- und Qualitätsfixes, die ich nicht unterschlagen will, auch wenn sie weniger dramatisch sind als Approvals:

Side-by-Side-Chat-Panel-Switcher in der Session-Toolbar: Chat im Editor, Sessions im Tool-Window.
Browsable Usage Tips über dem Chat-Input, Shortcuts zu Commands, Customizations, Settings.
Vereinfachter Welcome Screen, Feedback-Link.
Built-in GitHub MCP Server in der Tool-Config gelabelt, Direktlink zu Settings.
Shortcuts für Agent-Instructions und Usage-based-Billing-Best-Practices wieder da.
/init-Tipp klarer, bei Customizations gruppiert.
Inline-Chat-Zuverlässigkeit: Edits behalten, wenn Requests enden; Thinking-Effort und Context-Window-Settings respektieren.
Codex-Session-Startup, Multi-Project-Window-Verhalten, Embedded Editors und Message-Re-Editing auf IntelliJ 2026.3 EAP.

Changed: Inline Chat und Einstiege sind in JetBrains Gateway und Remote-Development-Umgebungen versteckt. Deprecation: IDE 2025.1 bekommt Advance Notice Richtung 2026.1+. Support in diesem Release unverändert – aber der Hinweis hängt.

Bastelprojekt-Realität: Wer noch auf 2025.1 hängt, weil „läuft doch“, kriegt jetzt den sanften Schubs. Planen Sie das Upgrade, bevor Assisted Approvals und Plan Mode Features sind, die Sie brauchen, aber die IDE-Linie nicht mehr mitzieht.

Was Sie konkret tun sollten – ohne Panik, mit Checkliste

Kein Haken-setzen-und-weiter. Eine Arbeitsliste, die wir bei digital-magazin.de so angehen würden, wenn morgen 1.18.0 in der Org landet:

Assisted Approvals bewusst einschalten/testen – erst in einem Scratch-Repo, nicht im Monorepo mit Prod-Secrets in Neighbour-Ordnern.
Per-Tool-MCP-Controls durchgehen – schreibende Tools und alles, was Netz/Secrets berührt, nicht auf Blindvertrauen lassen.
Plan Mode für Codex default nutzen, wenn der Agent mehr als „lies und erklär“ machen soll.
Vor Re-Edit committen – Rewind ist Zeitreise, keine Undo-Taste.
OTel in managed-settings.json zumindest evaluieren, bevor Auto-Approve flächendeckend läuft.
Org-Skills und Custom Instructions mit denselben Leuten reviewen, die Approvals-Policy und MCP-Controls besitzen.
IDE-Linie checken – 2025.1 bekommt den Deprecation-Hinweis; Upgrade-Pfad nach 2026.1+ einplanen.

Und ja: Lesen Sie den Changelog selbst. Vendor-Claims ändern sich, Preview-Status ändert sich, und „Public Preview“ heißt ausdrücklich: Es kann noch wackeln.

Warum das für JetBrains-Alltag mehr ist als ein Plugin-Bump

Copilot in JetBrains war lange das „auch-da“-Plugin neben dem VS-Code-Schwergewicht. Mit Agent-Sessions, MCP, Shared Skills und jetzt Assisted Approvals plus Plan Mode wird aus dem Plugin eine Steuerzentrale für Agent-Verhalten in der IDE. Das ist kein Marketing-Satz – das ist die Konsequenz daraus, dass Low-Risk-Auto-Approve und Rewind Dateisystem und Conversation anfassen.

Wer früher „Copilot = Autocomplete“ dachte, muss umdenken. Wer schon Agent-Sessions fährt – und das tun inzwischen viele Teams, siehe auch unsere Spur zu Enterprise-Sandbox-Themen unter Copilot JetBrains Enterprise Sandbox und Keychain – merkt: Die Frage ist nicht mehr „schlägt der Code vor?“, sondern „welche Tools dürfen ohne mich laufen?“.

Das ist der Shift. Assisted Approvals sind der sichtbare Ausdruck dieses Shifts. Rewind ist der sichtbare Ausdruck davon, dass Sessions Zustand haben, den man zurückspulen will. OTel ist der Ausdruck davon, dass Enterprises diesen Zustand später nachvollziehen müssen.

Drei Fallen, die ich Ihnen ersparen will

Falle 1: „Weniger Prompts = sicherer.“ Nein. Weniger Prompts = weniger menschliche Checkpoints. Sicherheit hängt davon ab, ob Low-Risk korrekt sitzt und ob Sie danach noch sehen, was auto-approved wurde.

Falle 2: „Rewind rettet alles.“ Nein. Rewind rettet den Conversation-Zweig und die vom Agent getrackten Datei-Änderungen – laut Vendor-Claim. Parallel-Edits, Commits, externe Artefakte, andere Fenster: anderes Spiel. Behandeln Sie Rewind als Checkpoint-Jump.

Falle 3: „Skills und Approvals sind getrennte Themen.“ Nein. Org-Skills formen Verhalten. Approvals formen, welche Tools ohne Sie laufen. Zusammen formen sie die tatsächliche Angriffs- bzw. Fehlerfläche Ihrer Agent-Sessions. Ein Ownership-Review für beides.

Spoiler für Security-Teams: Assisted Approvals werden in Threat-Models auftauchen, sobald der erste Low-Risk-Write in einer Audit-Trail-Lücke landet. Seien Sie die Leute, die den Trace schon haben, bevor jemand fragt.

Was der Changelog nicht sagt – und warum das okay ist

Das Changelog sagt nicht, wie der Low-Risk-Classifier trainiert oder geregelt ist. Es sagt nicht, welche konkreten Tool-Typen default Low-Risk sind. Es sagt nicht, wie Rewind mit manuellen Parallel-Edits kollidiert. Es sagt nicht, welche Felder OTel genau exportiert, jenseits von „agent activity“ und dem Hinweis, dass Prompt/Response default excluded sind.

Das ist für ein Changelog normal. Es ist für Ihre Risikoabschätzung unangenehm. Deshalb markieren wir Claims als Vendor-Claims und lassen die Lücken stehen, statt sie mit Spekulation zuzukleistern. Wenn Sie interne Docs oder Support-Antworten zu „welche Tools sind Low-Risk?“ bekommen: Dokumentieren Sie die Antwort neben Ihrer MCP-Per-Tool-Liste. Das ist die einzige belastbare Quelle, die Sie haben, bis GitHub nachzieht.

Nerd-Alarm zum Schluss dieses Abschnitts: Feature-Changelogs sind Absichtserklärungen mit Versionsnummer. Operations-Runbooks entstehen erst, wenn jemand den ersten Incident überlebt hat. Schreiben Sie das Runbook, bevor der Incident kommt – mit den sieben Punkten von oben als Gerüst.

Agent-Sessions als neuer Normalzustand – und was 1.18.0 daran ändert

Vor einem Jahr war „der Agent schreibt Dateien um“ noch Demo-Material. Heute ist es Alltag in vielen Teams, die Copilot ernsthaft einsetzen. 1.18.0 ändert nicht, ob Agent-Sessions Dateien anfassen. Es ändert, wie oft Sie dazwischenstehen – und wie Sie zurückspulen, wenn die Richtung falsch war.

Assisted Approvals reduzieren die Reibung. Plan Mode erhöht die Reibung am Anfang bewusst. Rewind gibt Ihnen einen Notausgang. MCP-Per-Tool gibt Ihnen Feinjustierung. Shared Skills geben der Org eine Stimme in jeder Session. OTel gibt der Org Augen hinterher.

Zusammen ist das kein einzelnes Feature. Es ist ein Steuerungsset. Und Steuerungssets scheitern nicht an fehlenden Buttons – sie scheitern an fehlender Ownership. Wer besitzt Low-Risk-Definitionen? Wer besitzt Skills? Wer besitzt den Telemetry-Endpoint? Wenn die Antwort drei verschiedene Teams ohne gemeinsamen Review-Termin sind, haben Sie 1.18.0 installiert und trotzdem kein System.

Die kurze Version meiner Redaktionsmeinung: Installieren Sie 1.18.0. Nutzen Sie Plan Mode. Drehen Sie Assisted Approvals erst auf, wenn Per-Tool-Controls und ein Observability-Pfad stehen. Behandeln Sie Rewind wie Zeitreise. Und hören Sie auf, „weniger Interruptions“ mit „sicherer“ zu verwechseln – das ist der Satz, den ich auf Sticky Notes kleben würde, direkt neben den Monitor, auf dem die nächste Agent-Session läuft.

Freitagabend, Kaffee, Diff. Diesmal mit Prompt. Diesmal mit Trace. Und wenn Low-Risk trotzdem falsch lag: Dann wissen Sie wenigstens, wen Sie fragen müssen – die Policy, nicht nur das Modell.