Kategorie: Erklärer

Ein Chief Financial Officer sitzt an einem Montagmorgen in seinem Büro und öffnet das Dashboard der IT-Ausgaben. Die Zahlen für das laufende Quartal zeigen eine Abweichung, die er nicht einordnen kann: Die Kosten für künstliche Intelligenz sind um 40 Prozent höher als geplant. Niemand hat ihn vor dieser Entwicklung gewarnt – keine Prognose, keine Risikoanalyse, kein Hinweis in den wöchentlichen Statusberichten.

Die Szene ist kein Einzelfall. Sie wiederholt sich in immer mehr Unternehmen. KI-Projekte entpuppen sich als Kostenfalle, die erst spät sichtbar wird. Ein neuer Report des Softwarehauses Mavvirk zeichnet ein deutliches Bild: Fast die Hälfte aller befragten Organisationen musste KI-bedingte Ausgaben-Überraschungen bereits im Vorstand diskutieren. Ein Viertel hat laufende oder geplante KI-Initiativen wegen unvorhergesehener Kosten gestoppt oder verschoben.

Die Zahlen des Mavvirk-Reports

Mavvirk, ein Anbieter für Kostenmanagement-Software, hat für seinen „State of AI Cost Governance Report 2026“ insgesamt 396 Unternehmen aus verschiedenen Branchen befragt. Zwei Drittel der Befragten geben an, dass unerwartete KI-Kosten mindestens eine Geschäftsentscheidung materiell beeinflusst haben. Ein Drittel musste einen Notfall-Stopp für neue Ausgaben verhängen, um die steigenden Rechnungen einzudämmen.

Besonders auffällig ist, dass die Kostenprobleme nicht allein aus den Preisen für KI-Modelle entstehen. Sundeep Goel, CEO von Mavvirk, sagt im Report: „KI verändert grundlegend, wie Infrastruktur verbraucht wird und wie sich Kosten ansammeln. Was früher planbare IT-Ausgaben waren, ist heute dynamisch, verteilt und schwer zuzuordnen.“ Ausgaben für KI verteilen sich über viele Einzelposten – von Developer-Tools über Datenplattformen bis hin zu autonomen Agenten, die quasi endlos Rechenleistung konsumieren. Viele Firmen haben keine Werkzeuge, um diese Ausgaben sauber zu erfassen.

Weil niemand die Gesamtkosten überblickt, kann auch niemand den Return on Investment (ROI) belastbar berechnen. Ray Rike, CEO von Benchmarkit, sagt im Report: „Alle reden über KI und ROI, aber ROI ist Mathematik. Man kann keine Rendite berechnen, wenn man die Kosten nicht kennt.“ Daran scheitern viele Projekte: Sie werden nicht zu Ende gedacht, weil niemand die langfristigen Kosten verantwortlich budgetiert hat.

Warum KI-Kosten schwer zu kontrollieren sind

Die Gründe für die Überraschungen liegen in der Fragmentierung der KI-Landschaft. Unternehmen nutzen eine Vielzahl von Diensten: einzelne LLM-Modelle, Datenpipelines, Vektordatenbanken, Inferenz-Server und immer häufiger auch agentische Workflows, die mehrere Schritte autonom abarbeiten. Jeder dieser Bausteine erzeugt eigene Kosten – und die Summe ist kaum im Voraus abzuschätzen.

Rita Sallam, Chief of Research für Daten und Analytik bei Gartner, weist auf einen Widerspruch hin: Während die reinen Modellpreise (etwa Kosten pro Token) sinken, steigen die Gesamtkosten pro Aufgabe. Der Grund: Agentische Systeme verlangen zunehmend komplexere Denkprozesse, die deutlich mehr Rechenschritte benötigen – und die Rechnung dafür wächst exponentiell. „Die Preisgestaltung verlagert sich auf nutzungsbasierte Modelle, was die Kosten für komplexe, autonome Workflows in die Höhe treibt und häufig die Einsparungen übersteigt, die sie eigentlich erzeugen sollten“, erklärt sie gegenüber CIO Dive.

Hinzu kommt, dass viele Entscheidungsträger erst spät von den hohen Ausgaben erfahren. Die Sichtbarkeit ist schlecht, weil die Kosten nicht einem einzelnen Projekt zugeordnet werden können, sondern über verschiedene Konten und Teams verstreut sind. Das erinnert an ein bekanntes Problem aus der Cloud-Ära: Auch dort überschritten Budgets oft die Planung, weil Speicher- und Transfergebühren nicht im Blick waren. Daten von Wasabi Technologies aus dem letzten Jahr zeigen, dass fast zwei Drittel der Unternehmen ihr Cloud-Speicherbudget überschritten – wegen unvorhergesehener Nutzung und Egress-Fees.

FinOps: Ein Ansatz aus der Cloud-Welt

Aus der Cloud-Welt gibt es einen etablierten Lösungsansatz: FinOps. Was ursprünglich entwickelt wurde, um Cloud-Kosten zu kontrollieren, wird zunehmend auch auf KI angewandt. FinOps steht für ein Bündel aus Prozessen, Tools und kulturellen Praktiken, die Finanzen, Technik und Business zusammenbringen, um Ausgaben transparent zu machen und zu optimieren. Der Grundgedanke ist simpel: Erst wer die Kosten versteht, kann sie steuern.

Mittlerweile reagieren auch die großen Cloud-Anbieter auf den Druck. Google Cloud, AWS und Microsoft haben in den vergangenen Monaten einige Speicher- und Transfergebühren reduziert, um Kunden zu entlasten. Das hilft, löst das Grundproblem aber nicht. Denn die KI-Kosten entstehen nicht nur in der Cloud-Infrastruktur, sondern auch in den Modellausgaben selbst, die sich nur schwer standardisieren lassen.

Rita Sallam vom Gartner fordert deshalb einen Perspektivwechsel: „Unternehmen sollten die KI-Kostenoptimierung als architektonische Anforderung betrachten, nicht als nachträgliche Finanzübung.“ Das bedeutet, schon bei der Entwicklung über Kostenaspekte nachzudenken – nicht erst, wenn die Rechnung kommt. Modellwahl, Pipelinedesign und Nutzungspolitik müssen frühzeitig auf Kosteneffizienz ausgelegt sein.

Gegenmaßnahmen: Modelle, Routen, Bildung

Sallam empfiehlt, einfache Anfragen zu preisgünstigeren Modellen zu routen, anstatt immer das teuerste Reasoning-Modell zu verwenden. „Man sollte keine Ferrari nehmen, wenn ein Kia auch reicht.“ Es geht nicht um Leistungsverzicht, sondern um wirtschaftlichen Einsatz. Ein kleines, domänenspezifisches Sprachmodell kann oft genauso gute Ergebnisse liefern wie ein großes, universelles Modell – zu einem Bruchteil der Kosten.

Darüber hinaus betont Sallam, wie wichtig es ist, die KI-Fähigkeiten der Mitarbeiter zu fördern. „Die Nutzer müssen die finanziellen Konsequenzen ihres KI-Einsatzes verstehen. Es bringt nichts, wenn sie das teuerste Reasoning-Modell nutzen, um das Wetter zu checken.“ Sie fordert verbindliche Schulungen zu „KI-Token-Finanzkompetenz“. Wenn die Belegschaft versteht, dass jede Anfrage reale Kosten erzeugt, stellt sich ein achtsameres Nutzungsverhalten ein.

Die Empfehlungen der Experten lassen sich zu einem Drei-Punkte-Plan zusammenfassen: Erstens, die Kostenarchitektur fest ins Design integrieren. Zweitens, ein Governance-Rahmenwerk schaffen, das technische und finanzielle Aspekte abdeckt. Drittens, die Mitarbeiter aktiv schulen und in die Verantwortung nehmen.

Was du jetzt in deinem Unternehmen tun kannst

Die Entwicklung betrifft nicht nur Großkonzerne – auch mittelständische Unternehmen, die gerade mit KI experimentieren, stehen vor den gleichen Herausforderungen. Wenn du in deinem Unternehmen für IT-Strategie oder Finanzen zuständig bist, gibt es konkrete Schritte, die du sofort einleiten kannst. Beginne damit, eine Inventur deiner KI-Systeme zu erstellen: Welche Modelle werden genutzt? Welche Workflows laufen auf welcher Infrastruktur? Wer hat Zugriff auf welche Ressourcen? Ohne diese Grundlagen bleibt jede Kostendiskussion Stückwerk.

Setze klare Budgetgrenzen und implementiere Monitoring-Tools, die dir Echtzeitdaten über die KI-Ausgaben liefern. Es gibt spezialisierte Lösungen, die Token-Verbrauch und Modellkosten transparent machen und Alarme bei Abweichungen auslösen. Scheue dich nicht davor, Projekte zu verlangsamen, wenn die Wirtschaftlichkeit nicht stimmt. Ein Viertel der Unternehmen hat bereits KI-Initiativen pausiert oder gestoppt – das ist keine Niederlage, sondern eine bewusste Entscheidung.

Am Ende braucht es eine kulturelle Veränderung. KI verursacht Kosten wie jede andere Technologie. Wer diese Realität akzeptiert, plant realistisch. Die Zahlen aus dem Mavvirk-Report zeigen: KI erfordert finanzielle Disziplin, sonst übersteigen die Ausgaben den Nutzen.

Quelle: ciodive.com

95 Sicherheitsberichte über 32 Produkte und Konfigurationen ergeben ein eindeutiges Bild: Jede getestete NAT-Implementierung ist verwundbar. Der unabhängige Forscher Malcolm Stagg präsentierte auf der Black Hat USA 2026 die Angriffsklasse NatJack. Sie manipuliert die Verbindungsverwaltung von Network Address Translation (NAT) direkt. Aktive Verbindungen lassen sich entführen, DNS-Antworten vergiften und Denial-of-Service auslösen. Klassische IP-Spoofing-Angriffe oder Zugriff auf den Broadcast-Domänen-Bereich sind nicht nötig.

Wenn du ein Netzwerk betreibst, solltest du genau hinschauen. NatJack funktioniert gegen Windows, Linux und macOS gleichermaßen – obwohl diese Systeme keinen gemeinsamen NAT-Codebase haben. Das deutet auf ein grundlegendes Designproblem hin, nicht auf einen einzelnen Programmierfehler.

Stell dir NAT wie eine Hausverwaltung vor, die alle Briefe für ein Mehrfamilienhaus an einer Adresse annimmt und dann an die Wohnungen weiterleitet. Die Hausverwaltung prüft nicht, ob ein Absender wirklich der ist, der er zu sein behauptet. Sie vertraut darauf, dass niemand böswillig handelt. Genau diese Vertrauenslücke macht NatJack aus.

Die Vertrauensannahme in NAT

NAT entstand in den frühen 1990er-Jahren als Übergangslösung gegen die IPv4-Adressknappheit. Mehrere Geräte teilen sich eine öffentliche IP-Adresse, intern verwenden sie private Adressen. Die Spezifikationen, die dieses Verhalten festlegten, gingen von einer friedlichen Umgebung aus. Stagg erklärt, dass diese Annahme tief in den RFCs verankert ist und bis heute fortbesteht.

Die Unter-Spezifikation erlaubt es der NAT, Verbindungen anhand von Quell- und Zieladressen sowie Ports zu verfolgen. Die dabei entstehende Tabelle, die Connection Tracking Table, ist das Herzstück von NAT. Sie hält fest, welches interne Gerät mit welchem externen Ziel kommuniziert und welche temporären Ports zugeordnet wurden. Wer die Kontrolle über diese Tabelle erlangt, kann praktisch jede Verbindung durch den NAT-Punkt umleiten.

Die Sicherheitslücke ist nicht neu. 2010 zeigte Samy Kamkar mit NAT Pinning, wie sich NAT-Verhalten manipulieren lässt. 2020 folgte NAT Slipstreaming, das das Application Level Gateway (ALG) ausnutzte. Diese Angriffe erforderten aber entweder eine Interaktion des Opfers oder den Einsatz von ALG-Diensten. NatJack umgeht diese Hürden: Es greift direkt auf die Connection Tracking Table zu, benötigt keine ALG-Unterstützung und genügt eine aktive Verbindung, die das Opfer bereits aufgebaut hat.

Layer-2-Isolationen wie VLAN-Segmentierung oder Switch-Port-Isolation bieten keinen Schutz. Die Angriffe finden auf Ebene 3 und 4 statt – in der Vermittlungs- und Transportschicht – und richten sich gegen die gemeinsame NAT-Infrastruktur. Selbst wenn du deine Netzwerksegmente strikt trennst, bleiben alle Geräte, die dieselbe NAT verwenden, verwundbar.

Vier Techniken, ein gemeinsamer Kern

NatJack umfasst vier verschiedene Angriffsvarianten, die alle auf derselben Schwachstelle beruhen: der fehlenden Überprüfung von Paketen, die die NAT-Tabelle verändern können. Stagg hat diese Techniken dokumentiert und veröffentlicht.

Die erste Technik ist die TCP-Verbindungsentführung. Der Angreifer sendet manipulierte Pakete, die eine laufende Verbindung in den Zustand „geschlossen“ versetzen. Dafür nutzt er den RFC-1337-Mechanismus namens TIME-WAIT Assassination. Der Zustand lässt sich mit wenigen Paketen erreichen, ohne auf ein normales Timeout zu warten. Anschließend ersetzt der Angreifer den Tabelleneintrag der Verbindung durch einen eigenen, sodass die Kommunikation über ihn umgeleitet wird. So kann er Daten abfangen oder sich in die Verbindung einschleusen.

Die zweite Technik ist die DNS-Antwort-Vergiftung. NatJack fängt UDP-DNS-Antworten ab, die durch die NAT laufen, und verändert sie. Das Opfer erhält gefälschte IP-Adressen für angefragte Domains, was zu Phishing oder Weiterleitungen auf Malware-Server führen kann. Der Angriff bleibt für den Nutzer unsichtbar: Die DNS-Antworten kommen ja von der NAT, der Browser ahnt nicht, dass sie manipuliert wurden.

Die dritte Technik ist ein Denial-of-Service-Angriff auf die NAT-Tabelle selbst. Der Angreifer sendet massenhaft Verbindungsanfragen oder Pakete mit gefälschten Adressen und füllt die Tabelle, bis keine neuen Verbindungen mehr aufgebaut werden können. Das betrifft nicht nur das einzelne Gerät, sondern alle Geräte hinter derselben NAT. Ein einziges bösartiges Gerät kann das gesamte Netzwerk lahmlegen.

Viertens gibt es die Verbindungs-Port-Identifikation. Der Angreifer findet heraus, welchen externen Port die NAT einem aktiven Datenstrom zugewiesen hat. Diese Information ist die Grundlage für die anderen drei Angriffe – ohne den korrekten Port lassen sich die Tabelleneinträge nicht gezielt manipulieren. Die Identifikation selbst ist nicht schädlich, dient aber als Aufklärungsphase.

Alle vier Techniken sind kombinierbar. Ein Angreifer kann zuerst den Port einer Verbindung ermitteln, dann die Verbindung beenden, den Tabelleneintrag übernehmen und anschließend gefälschte DNS-Antworten einschleusen. Das geht in Sekundenschnelle und erfordert keine besonderen Privilegien – lediglich die Möglichkeit, Pakete durch dieselbe NAT zu senden.

Herstellerreaktionen: Uneinheitlich und teils enttäuschend

Stagg meldete die Schwachstellen an dreizehn Hersteller. Die Antworten fielen sehr unterschiedlich aus. Das Linux-Kernel-Team wies den Bericht zunächst mit den Worten „total bogus“ zurück, wie Stagg in einem Interview berichtete. Er war überrascht und enttäuscht, doch später änderte sich die Lage: Auf Anfrage von Microsoft hin wurde der Fehler im Linux-Kernel behoben, um Azure Kubernetes Service zu unterstützen. Dafür erhielt die Schwachstelle die CVE-2026-63913.

Auch Microsoft selbst war betroffen: Die Windows-NAT-Implementierung für Hyper-V erhielt die CVE-2026-56181. Der Patch wurde im Rahmen eines regulären Sicherheitsupdates ausgeliefert. Andere Anbieter wie Cisco und Apple bewerteten die Ergebnisse jedoch nicht als Sicherheitslücken. Cisco verwies auf dokumentierte Mitigationsmaßnahmen für seine Produkte, Apple auf die Annahme, dass lokale Netzwerke feindlich sein können und End-to-End-Verschlüsselung wie TLS den Schaden begrenzt.

Stagg merkt an, dass Verschlüsselung tatsächlich hilft, aber sie kann nicht alles verhindern. Ein Angreifer, der eine Verbindung entführt, kann den verschlüsselten Datenstrom nicht lesen, aber er kann die Verbindung abrupt beenden oder blockieren. Das führt zu einem Denial-of-Service auf Anwendungsebene. Zudem sind nicht alle Protokolle standardmäßig verschlüsselt, und auch verschlüsselte Verbindungen können durch die Manipulation der NAT-Parameter unterbrochen werden.

Die unterschiedlichen Reaktionen zeigen, wie uneinheitlich die Branche mit Designfehlern umgeht. Einige Hersteller erkennen das Problem an und liefern Patches aus, andere sprechen von „Design-Limitationen“ und verweisen auf Best-Practice-Empfehlungen. Für dich als Netzwerkbetreiber bedeutet das: Du kannst dich nicht darauf verlassen, dass dein NAT-Gerät von Haus aus sicher ist. Du musst selbst aktiv werden.

Schutzmaßnahmen: Was Netzwerkbetreiber jetzt tun können

Auch ohne vollständige Patches gibt es mehrere konkrete Schritte, die das Risiko deutlich reduzieren. Stagg nennt in seinem Vortrag eine Reihe von Empfehlungen, die du direkt umsetzen kannst.

Überwache deine Netzwerk-Infrastruktur auf Auffälligkeiten. Dazu gehören eine vollständige oder fast volle NAT-Tabelle, ungewöhnliche Paketfluten über weite Portbereiche, die gleiche IP-Adresse an zwei physischen Standorten oder anomale SYN- und RST-Paketfolgen. Solche Anzeichen deuten darauf hin, dass ein Angreifer versucht, die Verbindungstabelle zu manipulieren.

Aktiviere den IP-Source-Guard an deinen Routern und Firewalls. Diese Schutzfunktion blockiert Pakete mit gefälschten Quelladressen, was viele NatJack-Varianten erschwert. Zusätzlich solltest du unvertrauenswürdige Geräte in separate Subnetze oder VLANs auslagern und die Verbindungsanzahl pro Client begrenzen – Stagg empfiehlt einen Wert von unter 10.000 gleichzeitig aktiven Verbindungen. Eine solche Begrenzung verhindert, dass ein einzelner Client die NAT-Tabelle überfluten kann.

Prüfe, ob dein NAT-Gerät sogenannte „Loose Connection Tracking“ oder „Port Preservation“ verwendet. Diese Modi erhöhen den Komfort für Anwendungen, schwächen aber auch die Sicherheit. Wenn möglich, deaktiviere sie und verwende striktes Adress- und Port-Mapping. Bei Containern solltest du den Netzwerkzugriff für unvertrauenswürdige Workloads einschränken: keine root-Rechte, keine Standard-Capabilities, und deaktiviere das Netzwerk für Container, die nicht zwingend erreichbar sein müssen.

In Cloud-Umgebungen gilt dieselbe Logik: Halte vertrauenswürdige und unvertrauenswürdige Workloads strikt getrennt, und nutze für Serverless-Funktionen dedizierte öffentliche IPs, anstatt sie über einen gemeinsamen NAT-Gateway laufen zu lassen. Stagg weist darauf hin, dass eine der Angriffsvarianten auch zwischen verschiedenen Subnetzen funktioniert, also eine Trennung auf Subnetzebene nicht ausreicht. Die Isolation muss auf NAT-Ebene erfolgen.

Die Lektion aus NatJack: Historische Annahmen neu bewerten

NatJack ist mehr als nur eine weitere Sicherheitslücke. Es zeigt, wie sehr sich die Bedrohungslandschaft verändert hat, während unsere Netzwerktechnik in den 1990er-Jahren stehen geblieben ist. Die Annahme, dass alle Geräte hinter einer NAT vertrauenswürdig sind, war vielleicht einmal vertretbar – in Zeiten, in denen Netzwerke aus wenigen Rechnern bestanden, die von derselben Administration kontrolliert wurden. Heute jedoch verbinden sich unzählige IoT-Geräte, Gastnotebooks, Smartphones und Cloud-Workloads über denselben NAT-Punkt. Jedes dieser Geräte könnte bereits kompromittiert sein oder böswillig agieren.

Die Tatsache, dass NatJack auf allen drei Betriebssystemfamilien funktioniert, ohne dass der Code geteilt wird, unterstreicht den systemischen Charakter des Problems. Es handelt sich nicht um einen einzelnen Fehler, sondern um ein grundlegendes Vertrauensmodell, das der heutigen Realität nicht mehr standhält. Sicherheitsarchitekten müssen sich daher von der Vorstellung verabschieden, dass eine NAT automatisch Schutz bietet. Sie ist eine Adressumsetzung, keine Firewall.

Für dich als Entscheider im Netzwerk bedeutet das: Du musst deine Sicherheitslösungen auf mehreren Ebenen implementieren. Verschleiere die interne Struktur nicht durch NAT allein, sondern setze zusätzlich auf robuste Firewall-Regeln, Intrusion-Detection-Systeme und eine konsequente Segmentierung. Und überprüfe regelmäßig die Designannahmen deiner Infrastruktur. Was vor zwanzig Jahren sicher war, kann heute ein Einfallstor sein.

Stagg fasst es treffend zusammen: Man dürfe sich nicht auf die historischen Designentscheidungen verlassen, sondern müsse die Bedrohungsmodelle von heute anwenden. NatJack ist ein Weckruf – und eine Chance, die Sicherheitsarchitektur endlich an die Realität anzupassen.

Quelle: networkworld.com

Warum bauen Coding-Agents Komponenten neu, die längst im Designsystem existieren? Fehlender Kontext. Genau hier setzt Code Connect an.

Arbeitest du als Entwickler mit KI-gestützten Coding-Agents, kennst du das Szenario: Der Agent bekommt ein Design aus Figma und liefert Code, der auf den ersten Blick stimmt. Aber schaut man genauer hin, hat er eine Button-Komponente selbst aus <div>s gebaut, obwohl es eine produktionsreife Button-Komponente im eigenen Design System gibt. Das Ergebnis sieht richtig aus, ist aber für deinen Codebase falsch. Der Agent hat nicht mutwillig Mist gebaut – ihm fehlte die Information, dass es diese Komponente bereits gibt.

Code Connect adressiert dieses Problem in Kombination mit dem Figma MCP Server. Statt nur einer generischen React-Darstellung des visuellen Designs erhält der Agent einen echten Code-Snippet direkt aus eurem Design System. Das spart Zeit, reduziert Token-Kosten und führt zu besserer Code-Qualität. Die Entwickler bei Figma haben das evaluiert – mit messbaren Ergebnissen.

Was Code Connect für Coding-Agents verändert

Figma’s MCP Server (Model Context Protocol) erlaubt Coding-Agents, strukturierte Kontextinformationen aus einem Design abzurufen. Das Kernwerkzeug get_design_context liefert dem Agenten eine Codebeschreibung in React – also eine visuell korrekte, aber generische Darstellung dessen, was auf dem Canvas zu sehen ist. Der Agent weiß damit, wie das UI aussieht, aber nicht, wie es in eurem Projekt aufgebaut ist.

Das führt zu drei typischen Verhaltensweisen: Der Agent erfindet eine neue Komponente von Grund auf, obwohl es eine passende im Design System gibt. Oder er wählt die falsche Komponente, weil er die Nomenklatur nicht kennt. Und selbst wenn er die richtige findet, macht er unnötige Arbeit – er durchsucht Ordner, rät bei Imports und verbrennt dabei Tokens. Code Connect eliminiert genau diese unnötige Arbeit.

Wenn Code Connect eingerichtet ist, ersetzt der Figma MCP Server Teile des generierten React-Codes durch produktionsnahe Snippets aus eurem Codebase. Der Agent bekommt dann nicht nur eine abstrakte Beschreibung eines Segmented Controls, sondern direkt den Import und den Aufruf der echten Komponente: <SegmentedControl value="design" options={"Design","Code"} />. Damit ist klar, welche Komponente, welche Props und welche Werte er verwenden soll – keine Ratespiele, kein Suchen, kein Neuerfinden.

Diese Kontextanreicherung wirkt wie ein Bauplan für einen Handwerker. Gibst du ihm nur ein Foto des gewünschten Möbelstücks, improvisiert er nach Augenmaß. Gibst du ihm eine technische Zeichnung mit exakten Maßen und Materialangaben, arbeitet er zielgerichtet und das Ergebnis passt genau. Code Connect ist die technische Zeichnung für deinen Coding-Agent.

Die Messung: Wie Figma die Vorteile evaluiert hat

Um den konkreten Nutzen zu beziffern, hat das Team von Figma ein Evaluierungs-Setup gebaut. Sie testeten dieselben Design-to-Code-Aufgaben einmal mit und einmal ohne Code Connect. Insgesamt 27 Testfälle wurden durchlaufen, jeweils mit zwei unterschiedlichen React-basierten Design-Systemen: Das „Simple Design System“ (SDS) – ein Beispiel-System mit fast vollständiger Code-Connect-Abdeckung – und die „Figma Pattern Library“ (FPL), ein realistisches internes System, das nur teilweise Code-Connectiert ist.

Die Qualität des generierten Codes wurde von LLM-Judges bewertet. Diese verglichen den Output mit Referenz-Snippets und bewerteten nach fünf Kriterien: Korrektheit, Code-Qualität, Wartbarkeit, Vollständigkeit und Best Practices. Die Noten lagen auf einer Likert-Skala von 1 bis 4, wobei 1 für völlig unbrauchbar und 4 für exzellent steht. Zusätzlich wurden die Token-Nutzung und die Dauer jedes Runs erfasst.

Die Ergebnisse sind eindeutig. Mit Code Connect verbessert sich die mittlere Code-Qualität um einen vollen Punkt – von 2 auf 3. Die Token-Nutzung sinkt im Median um 29,5 Prozent, die Bearbeitungszeit um 19,6 Prozent. Der Agent liefert besseren Code, braucht weniger Rechenleistung und ist schneller fertig. Die Effekte zeigten sich konsistent über alle Testfälle hinweg.

Warum die Abdeckung der entscheidende Faktor ist

Der Nutzen hängt davon ab, wie gut euer Design System mit Code Connect abgedeckt ist. Das Team von Figma beobachtete klare Unterschiede zwischen den beiden getesteten Systemen. Bei SDS, wo fast alle Komponenten Code-Connectiert sind, war der Anteil an Code-Connect-Snippets in den MCP-Antworten mit etwa 20 Prozent deutlich höher als bei FPL, wo nur rund 6 Prozent der Antworten echte Snippets enthielten.

Ein anschauliches Beispiel zeigt die Wirkung: Bei einer Aufgabe ohne Code Connect durchsuchte der Agent den node_modules-Ordner, machte breite Greps nach Icon-Namen und baute die Tab-Bar manuell mit CSS nach. Der Output sah optisch ähnlich aus, war aber nicht funktional – die Tabs waren hartkodiert und nicht interaktiv. Mit Code Connect griff der Agent direkt auf die echten Tabs- und Button-Komponenten zu, benötigte nur 77 Prozent der Zeit und 62 Prozent der Tokens, und der Code war sauber und korrekt.

Die Qualität des Ergebnisses skaliert mit der Sorgfalt, die ihr in eure Code-Connect-Abdeckung investiert. Je mehr Komponenten, Tokens und Varianten verknüpft sind, desto weniger Raum bleibt für Improvisation. Das ist keine Raketenwissenschaft, erfordert aber eine bewusste Pflege – genau wie ein gutes Design System selbst.

Coinbase: Ein Praxisbeispiel aus einem großen Unternehmen

Coinbase zeigt, wie Code Connect in der echten Welt wirkt. Das Coinbase Design Systems (CDS)-Team betreut die zentralen Design-Komponenten, Tokens und Infrastruktur für alle großen Consumer-Produkte. Als die Frontend Engineers auf agentengetriebene Entwicklung umstellten, investierten sie gezielt in Code Connect. Frontend Engineer Erich Kuerschner beschreibt den Unterschied: Ohne Code Connect erfand der Agent manchmal eigene Komponenten – etwa einen Stepper aus einfachen Progress-Bars. Mit Code Connect sieht der Agent die korrekte Darstellung als Code und erhält direkte Import-Pfade zu den echten CDS-Komponenten. Das Ergebnis: deutlich bessere Code-Qualität und eine spürbare Token-Ersparnis.

Das Beispiel von Coinbase zeigt, dass Code Connect kein Werkzeug nur für kleine Teams oder einfache Projekte ist. Gerade in großen Codebasen mit vielen Komponenten und strikten Design-Richtlinien schlägt der Nutzen voll durch. Der Agent erhält eine klare, maschinenlesbare Anweisung, welche Komponente zu verwenden ist – kein Raten, kein Abweichen vom Standard.

Auch wenn die Zahlen von Coinbase nicht im Detail veröffentlicht wurden, passt das Bild zu den Ergebnissen von Figma: Mehr Kontext führt zu weniger Fehlern, weniger Token-Verbrauch und schnelleren Durchläufen. Genau das sind die Hebel, die für produktive Teams zählen.

Was das konkret für dein Team bedeutet

Die Evaluierung von Figma bestätigt, was viele Entwickler intuitiv spüren: KI-Agenten brauchen Kontext, um wirklich gut zu sein. Ein Agent ist kein Orakel – er kann nur das nutzen, was er sieht. Bekommt er nur ein Bild des Designs, wird er so lange raten, bis etwas einigermaßen passt. Das kostet Zeit und Geld. Mit Code Connect gibst du ihm die Antworten, bevor er überhaupt anfängt zu suchen.

Für euer Team bedeutet das: Arbeitet ihr bereits mit dem Figma MCP Server, lohnt sich die Investition in Code Connect gleich doppelt. Ihr verbessert nicht nur die Qualität eurer Code-Generierung, sondern senkt gleichzeitig die Betriebskosten – weniger Tokens, weniger Rechenzeit, weniger Iterationen. Die Steigerung von einer ganzen Likert-Stufe mag abstrakt klingen, aber in der Praxis heißt sie: weniger kaputte Imports, weniger manuelle Nacharbeit, weniger Gespräche mit dem Agenten über seine Fantasie-Komponenten.

Die Einrichtung ist kein Hexenwerk. Code Connect folgt einer klaren Struktur: Komponenten in Figma werden mit Code-Snippets aus eurem Repository verknüpft. Je nach Umfang eures Design Systems kann das ein paar Stunden oder ein paar Tage dauern, aber die Amortisation beginnt mit dem ersten Agenten-Lauf, der keine eigene Button-Komponente mehr erfindet. Der Bericht von Figma liefert eine solide Grundlage für Entscheidungen zu eurem Agenten-Workflow.

Quelle: figma.com

„Keines dieser Tools erinnert sich an deine Kunden, deine Markenregeln oder die Entscheidung von letztem Dienstag.“ Dieser Satz stammt aus einem Praxisbericht von jemandem, der eine Agentic Experience Design Practice in einem großen Studio leitet. Er beschreibt die Realität der meisten Design-Teams: Drei oder vier KI-Tabs offen, keiner hat Kontext. Du tippst dieselben Hintergründe immer wieder neu und wunderst dich, warum der Workflow sich anfühlt wie ein Glücksspielautomat. Genau hier setzt Claude Cowork an, das Anthropic am 12. Januar 2026 als Research Preview für macOS startete und später auf Windows, Web und Mobile ausrollte.

Der Autor des Reports, im Original als „Working Field Guide“ bezeichnet, hat das Tool wochenlang im Studio getestet. Seine Kernaussage: Cowork ist kein Chatbot mit hübscherer Oberfläche. Es ist ein Agent, der deine Ordner öffnet, Quellen liest, Code ausführt, den Browser steuert und dir am Ende eine fertige Präsentation, Tabelle oder ein Dokument liefert – während du dich mit den eigentlichen Designfragen beschäftigst. Ob dieser Anspruch hält, was er verspricht, zeigen konkrete Prompts, Dateistrukturen und Sicherheitseinstellungen.

Der Unterschied zwischen Chat, Code und Cowork

Die mentale Landkarte für Cowork ist überraschend schlicht: Es gibt drei Oberflächen, aber dasselbe Sprachmodell. Der gewöhnliche Claude-Chat antwortet Zug um Zug und produziert Text, den du dann selbst in Aktionen übersetzt. Er kann nicht direkt auf deine Dateien zugreifen. Claude Code lebt im Terminal und der IDE: Es plant, verändert Code über ein Repository, führt Befehle aus, und du prüfst die Diffs. Es ist für Software-Auslieferung gebaut. Cowork schließlich sitzt im selben Zuhause wie der Chat, aber statt zu antworten, führt es aus.

Du beschreibst ein Ergebnis, und Cowork erstellt einen Plan, zerlegt die Arbeit in Teilaufgaben, führt diese in einer isolierten Umgebung aus, koordiniert parallele Arbeitsstränge und liefert Dateien, die du in der Vorschau prüfen und herunterladen kannst. Die Formel, die der Autor seinem Team mitgibt: Im Chat sagt dir Claude, wie du die Aufgabe machst. In Cowork macht Claude die Aufgabe. Dieser Unterschied ist das gesamte Produkt.

Diese Unterscheidung ist auch für dich als Designer relevant, weil sie den Arbeitsfluss fundamental verändert. Du wechselst vom Formulieren einer Anfrage zur Steuerung eines Prozesses. Du wirst vom Tippenden zum Dirigenten. Der Autor vergleicht das mit dem Schritt vom Interface-Design zum Agent-Design: Früher haben wir Bildschirme gestaltet, dann Erlebnisse, und jetzt gestalten wir Agenten.

Warum die Nutzungsdaten für Designer relevant sind

Die Zahlen sprechen für sich. Anthropic hat in einem Blogbeitrag 1,2 Millionen Sitzungen aus mehr als 600.000 Organisationen analysiert, gesammelt zwischen dem 11. und 31. Mai 2026. Die größte Kategorie war Geschäftsprozesse und Betrieb mit 33,4 Prozent. Inhaltserstellung und Copywriting landete auf Platz zwei mit 16,4 Prozent – also Entwürfe, Präsentationen, Posts und Vorschläge. Softwareentwicklung machte nur 8,7 Prozent aus, gefolgt von DevOps mit 7 Prozent, Forschung mit 6,4 Prozent und Datenanalyse mit 5,8 Prozent.

Anthropic nennt die dominante Nutzung „die Arbeit rund um die Arbeit“. Für ein Designteam ist das exakt die Steuer, die deine abrechenbaren Stunden auffrisst: die Decks, die Audits, die Synthese, die Übergabedokumente. Der Autor berichtet, dass genau diese Aufgaben in seinem Studio bisher oft übersprungen wurden, wenn der Zeitplan eng wurde. Mit Cowork werden sie jetzt ausgeführt, weil der Agent sie abnimmt.

Technisch läuft Cowork in der Beta standardmäßig remote. Die Agentenschleife und die Code-Ausführung passieren in einem isolierten, temporären Sandbox auf den Servern von Anthropic. Jede Sitzung bekommt ihre eigene Sandbox, die beim Start erstellt und beim Ende zerstört wird. Sitzungen und Dateien werden in deinem Claude-Konto gespeichert. So kannst du eine Aufgabe auf dem Laptop starten, sie vom Telefon aus beobachten und die Ergebnisse später abrufen, selbst wenn der Laptop zu ist. Geplante Aufgaben laufen sogar ganz ohne angeschlossenes Gerät. Für den Zugriff auf lokale Dateien nutzt Cowork die Claude-Desktop-App.

Die Einrichtung: Berechtigungsmodi und Anweisungen

Die technische Hürde ist niedrig. Du brauchst einen kostenpflichtigen Plan (Pro, Max, Team oder Enterprise), die Desktop-App für macOS oder Windows, und eine Internetverbindung während der Sitzung. Die Installation selbst ist ein Kinderspiel: Die App von claude.com/download holen, anmelden, und dann im Nachrichtenfeld statt „Chat“ die Option „Cowork“ wählen. Der schwerere Teil ist die Konfiguration, und die meisten Leute ignorieren sie – das ist ein Fehler.

Der Autor betont: Es gibt drei Berechtigungsmodi. „Manual“ (früher „Ask before acting“) bedeutet, dass Claude vor jeder Aktion stoppt und um Genehmigung bittet. Du prüfst jeden Schritt. Das ist der sicherste Modus, aber auch der langsamste. „Auto“ lässt Claude weiterarbeiten und jede Aktion selbst auf Sicherheit prüfen. Es blockiert Dinge wie Datenabfluss oder Prompt-Injection, fragt aber nicht nach. Dieser Modus verbraucht mehr Nutzungskontingent, weil die Prüfungen Rechenzeit kosten. „Skip“ schließlich fragt gar nicht erst – die gefährlichste Option, die du nur verwenden solltest, wenn du jedem File, Connector und App vollständig vertraust.

Die Empfehlung des Autors für sein Studio ist klar: Manual bei allem, was eine Nachricht als dich versendet, Geld berührt oder in ein Kundensystem schreibt. Auto bei interner Synthese und Entwürfen in einem abgegrenzten Ordner. Skip fast nie. Dazu kommen zwei Ebenen von Anweisungen: globale Instruktionen unter Einstellungen > Cowork, die für jede Sitzung gelten – dort beschreibst du, wer du bist und wie du schreibst. Und Ordner-Instruktionen, die projektbezogenen Kontext mit einem bestimmten lokalen Ordner verbinden.

Ein wichtiger Hinweis aus dem Bericht betrifft eine Klausel in den globalen Instruktionen: „Frag nach, wenn du etwas nicht weißt.“ Ohne diese explizite Anweisung neigt das Modell dazu, Lücken mit selbstbewusster Fiktion zu füllen. Der Autor nennt das den „Auslassventil-Effekt“ und bezeichnet ihn als nicht verhandelbar.

Drei konkrete Workflows, die den Unterschied zeigen

Der beste Einstieg ist nicht Dateiorganisation, sondern eine Aufgabe, die den Unterschied zwischen Chat und Agent beweist. Lege einen Ordner mit rohen Forschungsmaterialien auf den Desktop und schreibe in Cowork: „Analysiere alle Dateien in diesem Ordner. Identifiziere die wiederkehrenden Themen, zähle, wie oft jedes Thema in separaten Sitzungen auftaucht, und zitiere die wichtigsten Originalaussagen wörtlich. Erstelle FINDINGS.md im selben Ordner.“ Das ist der entscheidende Test: Chat würde dir eine Zusammenfassung geben, wenn du Text einfügst. Cowork liest jede Datei selbst, zählt über Sitzungen hinweg, behält die Zitate wörtlich bei und schreibt die Datei auf die Festplatte. Nach dem Lauf solltest du die Zitate gegen ein Transkript prüfen – diese Verifikation ist laut Autor Pflicht.

Der zweite Workflow koppelt Cowork mit der Claude-Erweiterung für Chrome. Der Browser navigiert und sammelt, Cowork kompiliert. Du beschreibst ein Thema, zum Beispiel die Preisstruktur eines Mitbewerbers, und Cowork öffnet die relevanten Seiten, extrahiert die Daten und führt sie in einer Tabelle zusammen. Eine Warnung: Cowork respektiert zwar deine Netzwerk-Ausgangsberechtigungen, aber diese gelten nicht für Web-Fetch, Websuche oder den Browser. Web-Fetch läuft serverseitig und ist auf Suchergebnisse und geteilte URLs beschränkt. Behandle alles, was der Browser berührt, als potenzielle Quelle von Prompt-Injection und wechsle die ersten Male in den Manual-Modus.

Der dritte Workflow ist die Interview-Synthese. Der Autor nutzt Cowork für die Auswertung von Nutzerinterviews. Die eingegebene Anweisung lautet zusammengefasst: „Synthetisiere alle Interviews in diesem Ordner. Gruppiere die Aussagen nach Themen. Zähle, wie oft jedes Thema vorkommt, mit direktem Zitat als Beleg. Markiere Aussagen mit niedriger Konfidenz und weise explizit auf widersprüchliche Belege hin. Exportiere als Excel-Datei mit mehreren Tabs, einem Tab pro Thema, mit einer Zusammenfassung und den genannten Risiken.“ Die ausgegebene Excel-Datei ist keine CSV mit Korrekturbedarf, sondern eine Tabelle mit funktionierenden Formeln und mehreren Registerkarten. Die Zeilen „niedrige Konfidenz markieren“ und „widersprüchliche Belege notieren“ sind die Schutzmechanismen gegen eine zu glatte Erzählung.

Diese drei Beispiele zeigen das Muster: Du ersetzt die mühsame manuelle Synthese durch einen Agenten, der systematisch arbeitet. Der Autor bezeichnet dies als „die Form des Agent-Designs: Du schreibst keine Prompts, du entwirfst eine dauerhafte Betriebsprozedur, die ein Agent ausführt und bei Bedarf eskaliert.“

Skills: Das Gedächtnis, das du nicht kanntest

Der heimliche Star von Cowork sind Skills. Prompts sind einmalige Anweisungen, Skills sind dauerhafte Anweisungen. Ein Skill ist ein Ordner mit einer SKILL.md-Datei, die YAML-Frontmatter (Name und Beschreibung) und Markdown-Instruktionen darunter enthält. Claude liest die Beschreibung, um zu entscheiden, wann der Skill automatisch geladen wird, oder du rufst ihn mit einem Slash-Befehl auf. Skills folgen dem offenen Agent-Skills-Standard und funktionieren sowohl in Cowork als auch in Claude Code.

Für Designer ist das die Hebelwirkung, die fast niemand ausnutzt. Wenn du zum Beispiel einen Skill „handoff-spec“ anlegst, der beschreibt, wie eine Übergabe-Spezifikation in deinem Hausformat auszusehen hat, dann produziert Claude auf Kommando eine vollständige Spezifikation, ohne neu eingewiesen zu werden. Der Autor gibt ein konkretes Beispiel: Der Skill enthält Platzhalter für „Design-Kontext“, „Nutzerfluss“, „Zustände“, „Barrierefreiheit“ und „offene Fragen“. Er enthält zwei wichtige Klauseln: Nicht zutreffende Zustände müssen begründet werden, und nicht verifizierbare Kontraste gehen in die offenen Fragen statt in eine falsche Erfolgsmeldung. Diese beiden Zeilen machen den Unterschied zwischen einer Spezifikation, der du vertraust, und einer, die du Zeile für Zeile nachprüfen musst.

Die Erstellung eines Skills ist einfacher als gedacht. Du kannst die SKILL.md von Hand schreiben oder Claude mit „/skill-creator“ ein Interview führen. In der macOS-App kannst du sogar eine Aktion aufzeichnen: Du führst eine Aufgabe auf dem Bildschirm aus, während du sie kommentierst, und Claude schlägt daraus einen Skill vor. Die Video- und Audiodaten werden nicht gespeichert, nur Screenshots bleiben in der Aufgabe. Weitere sinnvolle Skills aus der Praxis, die der Autor erwähnt: ein Marken- und Sprachleitfaden, der festhält, was die Marke ist, was sie nicht ist und warum; ein Kritik-Vorbereitungs-Skill, der dasselbe Design-Entscheidung für Peer, Produktmanager und VP unterschiedlich einrahmt; und ein Forschungsplan-Template-Skill.

Die beste Praxis bleibt: ein Skill sollte fokussiert sein, eine präzise Beschreibung haben und mindestens ein Beispiel enthalten. Der Autor warnt vor Overengineering: „Wenn die Instruktion länger ist als die Ausgabe, vereinfache.“ Anthropic pflegt auf GitHub Beispiel-Skills als Vorlagen.

Wo es schmerzt: Ehrliche Grenzen

So überzeugend die Workflows klingen, der Bericht verschweigt die Haken nicht. Sicherheit ist das offensichtliche Thema. Die Remote-Sandbox-Architektur bedeutet, dass deine Dateien auf Anthropic-Servern verarbeitet werden. Zwar ist die Sandbox isoliert und wird nach der Sitzung zerstört, aber du musst dir bewusst sein, was du dort ablegst. Vertrauliche Kundendaten, die unter NDA stehen, gehören nicht in eine Cowork-Sitzung ohne vorherige Freigabe durch die Rechtsabteilung.

Das zweite Risiko ist die fremde Umgebung. Der Autor erzählt von einem Test, bei dem Cowork Daten aus einer unzuverlässigen Quelle zu einem kohärenten Bericht verarbeitete und dabei fehlerhafte Zahlen übernahm. Er hätte die Ursprungsdaten gegenprüfen müssen. Das passiert, wenn du dem Agenten zu viel Vertrauen schenkst, ohne die „Frag nach“-Klausel zu verankern.

Der dritte Punkt ist die Nutzungsgrenze. Auto-Modus verbraucht doppelt so viele Credits, weil jede Aktion einer Sicherheitsprüfung unterliegt. Wenn du viele lange Synthese-Aufgaben hast, kann dein Kontingent schneller aufgebraucht sein als gedacht. Die geplanten Aufgaben laufen zwar unabhängig vom Gerät, aber sie zählen gegen dasselbe Budget.

Schließlich die Integration: Cowork funktioniert reibungslos mit Claude in Chrome, aber die Interaktion mit anderen Browser-Erweiterungen oder Desktop-Apps ist begrenzt. Der Zugriff auf lokale Dateien erfolgt über die Desktop-App, und du musst explizit Ordner freigeben. Das ist ein Sicherheitsgewinn, aber auch eine Reibung im Alltag.

Claude Cowork ist kein Wundermittel, sondern ein Werkzeug, das bestimmte monotone Wissensarbeit radikal beschleunigt. Die größte Verschiebung liegt nicht in der Technik, sondern in der Denkweise. Du steigst um vom Formulieren von Anfragen zum Gestalten von Prozessen. Der Autor fasst es so zusammen: „Wir haben gelernt, Interfaces zu gestalten, dann Erlebnisse, und jetzt gestalten wir Agenten.“ Für Designer bedeutet das: Die Fähigkeit, klare Ziele zu definieren, Kontext zu setzen und Ergebnisse zu verifizieren, wird wichtiger als das Tippen selbst. Cowork ist kein Ersatz für Urteilsvermögen – es ist ein Verstärker für die Arbeit, die du ohnehin tun wolltest.

Quelle: nervegna.substack.com

Viele denken, KI-Agenten arbeiten am liebsten isoliert in eigenen Interfaces, umgeben von Konsolenausgaben und Widgets. Doch das Gegenteil ist wahr: Ihre Wirkung entfalten sie dort, wo Entscheidungen fallen und Teams gemeinsam an Aufgaben wachsen. Das neue Channels SDK von CopilotKit schließt diese Lücke. Es bringt beliebige KI-Agenten in Slack, Microsoft Teams und andere Kollaborationsplattformen – mit nativer, interaktiver Oberfläche und vollständiger Kontrolle über Tools und Geschäftslogik.

Stell dir vor, du arbeitest in einem Team, das von Montag bis Freitag in Slack lebt. Plötzlich kann dich ein KI-Kollege aktiv unterstützen – er liest Kontext, ruft Tools auf, rendert Diagramme und fragt um Erlaubnis, bevor er kritische Aktionen ausführt. Das Channels SDK macht das möglich. Es ist ein Open-Source-Werkzeug, das die Kommunikationslücke zwischen modernen Agenten-Frameworks und den Plattformen schließt, auf denen täglich tausend Nachrichten ausgetauscht werden.

Warum native Integration mehr ist als nur ein Chatbot

Ein KI-Agent, der nur in einem eigenen Fenster läuft, ist wie ein exzellenter Berater, der niemals an Besprechungen teilnimmt. Er weiß alles, aber niemand fragt ihn. Das Channels SDK ändert das: Es verbindet Agenten mit Plattformen wie Slack, Microsoft Teams und Discord über den offenen AG-UI-Standard. Der Agent versteht Textnachrichten, Konversationskontext, Dateien, Streams und interaktive Elemente wie Buttons oder Dropdowns.

Der Clou: Ein einmal beschriebenes Element wird automatisch in das Block-Kit von Slack, Adaptive Cards von Teams und die spezifischen Komponenten anderer Plattformen übersetzt. Du bekommst keine generische Web-View, sondern ein Interface, das sich nahtlos in die gewohnte Arbeitsumgebung einfügt. Der Agent kann damit nicht nur antworten, sondern auch Entscheidungen visualisieren, Diagramme rendern oder einen Genehmigungsschritt einbauen – alles direkt im Chat.

Das SDK ist framework-agnostisch. Ob LangGraph, CrewAI, Mastra, Pydantic AI oder Googles ADK – jede AG-UI-kompatible Agenten-Factory lässt sich anschließen, ohne dass sich am Lebenszyklus des Channels etwas ändert. Für den schnellen Start liefert CopilotKit einen eingebauten Agenten mit. Die Freiheit der Wahl bleibt.

So einfach bringst du einen Agenten in Slack oder Teams

Der Weg zur Live-Schaltung ist kurz. Du brauchst Node.js 22+, eine CopilotKit Intelligence-Instanz (gehostet oder selbst gehostet) und einen langlaufenden Node-Prozess. Die Installation läuft über zwei npm-Pakete: @copilotkit/channels und @copilotkit/runtime. Letzteres enthält die Brücke zur Intelligenz-Schicht und zu deinem eigenen Agenten.

Der Code folgt einem klaren Muster: Du erstellst einen Channel, definierst eine Funktion, die deinen Agenten pro Thread instanziiert, und registrierst einen Listener, der eingehende Nachrichten verarbeitet. Deine Geschäftslogik bleibt vollständig bei dir – das SDK übernimmt nur die Translation zwischen Plattform-Events und AG-UI-Messages. Ein Beispiel aus der Dokumentation zeigt, wie der interne BuiltInAgent mit einem einzigen Aufruf eingebunden wird. Auch jede andere Factory passt problemlos.

Wer Zeit sparen will, nutzt npx copilotkit@latest channels setup. Das startet eine geführte Einrichtung, die deinen Coding-Agenten selbstständig durch die Konfiguration führt. API-Keys und Secrets bleiben in deiner .env-Datei. Wer es manuell macht, findet in der README eine detaillierte Schritt-für-Schritt-Anleitung mit allen nötigen Befehlen und einem lauffähigen Beispielskript. Nach zehn Minuten ist dein Agent in deinem Slack-Kanal aktiv.

Was hinter der Kulisse passiert – die Architektur im Schnelldurchlauf

Channels folgt einer simplen Grundlogik: Jeder Turn läuft nach demselben Schema ab. Eine Person schreibt eine Nachricht in Slack oder Teams. Diese wird an CopilotKit Intelligence übertragen, die den Event an deinen langlaufenden Channels-Prozess weiterleitet. Dort führt der eingebundene Agent über AG-UI Aktionen aus, ruft Tools auf und erzeugt eine Antwort. Die Intelligence übernimmt das Rendering als native Plattform-UI und schickt sie zurück in den Chat.

Die Trennung der Verantwortlichkeiten bleibt klar: Du betreibst deinen Agenten, deine Tools, deine Modell-Credentials und deine Business-Logik. CopilotKit Intelligence verwaltet die Plattform-Credentials, den Eingang, die Zustellung sowie Health-Checks und Reconnects. Das SDK steht unter MIT-Lizenz – du kannst es nach Belieben erweitern. Für Enterprise-Nutzer ist die Intelligenz-Schicht selbsthostbar.

Diese Architektur ist resilient. Wenn Plattformen ihre APIs ändern, sorgt die Intelligence-Schicht für die Anpassung – dein Code bleibt stabil. Du fokussierst dich auf das, was deinen Agenten ausmacht, anstatt dich um Platform-Quirks zu kümmern.

OpenTag als Referenz: Ein echter Agent im On-Call-Betrieb

CopilotKit verweist auf OpenTag, eine Open-Source-Anwendung für On-Call-Triage. Dieser Assistent nimmt Störungsmeldungen an, analysiert Logs, spricht mit Dateien und erstellt generative UI – alles direkt in Slack oder Microsoft Teams. Bevor er in Linear oder Notion schreibt, bittet er einen Menschen um Freigabe. Diese menschliche Kontrolle ist ein Kernfeature von Channels: Der Agent kann Aktionen ausführen, aber kritische Schritte pausieren und einen Button in den Chat schalten.

OpenTag ist als Lernvorlage konzipiert. Du kannst den kompletten Quellcode studieren – von der Python-LangGraph-Agentenüber AG-UI bis zum produktionsreifen Node-Laufzeitprozess. So siehst du, wie Datei-Uploads, generative UI und Genehmigungs-Workflows in der Praxis implementiert sind. Das ist kein Spielzeug-Example, sondern ein robustes Setup mit echten Fehlerprüfungen und sauberer Trennung zwischen Agent und Runtime.

Die Einstiegshürde ist niedrig. Du kannst deinen Coding-Agenten durch die Setup-Skills führen oder dich an den manuellen Schritten orientieren – beides wird durch die Dokumentation gut abgedeckt. Der schnellste Weg in die Praxis führt über npx copilotkit@latest channels setup, das dir den kompletten Zyklus von der Konfiguration bis zur Live-Schaltung abnimmt.

Warum das die Zukunft der KI-Assistenz verändert

Die Botschaft hinter Channels ist einfach: Agenten sollen nicht mehr in exotischen Interfaces leben, sondern dort, wo Menschen ohnehin arbeiten. Die Integration in Slack und Teams ist nicht nur Komfort – sie verändert die Dynamik. Ein Agent, der in jedem Channel mitlesen und auf Ansprache reagieren kann, wird zum echten Teammitglied. Er kann Kontext aus vergangenen Gesprächen ziehen, Vorgänge anstoßen und Rückfragen stellen, ohne dass jemand zwischen UI und Chat wechseln muss.

Genehmigungsschritte direkt im Chat sind ein entscheidender Baustein für Vertrauen. Nicht der Agent entscheidet allein, sondern er legt dir die Fakten vor und wartet auf deinen Klick. Das schafft eine Balance zwischen Automatisierung und Kontrolle – genau das, was Unternehmen für den produktiven Einsatz brauchen.

Das SDK ist offen. Jeder kann eigene Adapter für weitere Plattformen schreiben oder bestehende Agenten über AG-UI anbinden. Die Konkurrenz zwischen Frameworks spielt keine Rolle mehr – solange sie AG-UI sprechen, integrieren sie sich nahtlos. Das ist ein Standard, der die Fragmentierung der Agentenlandschaft überwinden hilft.

Was bleibt, ist die Frage nach dem Betrieb. CopilotKit Intelligence ist als Cloud-Dienst verfügbar, aber auch selbsthostbar. Damit ist die Lösung für streng regulierte Umgebungen geeignet. Die Kombination aus offenem SDK, klarer API und flexibler Hosting-Option sichert dem Projekt einen festen Platz in der KI-Infrastruktur von morgen.

Quelle: github.com