Human-AI-Collaboration https://ai.growhuman.io// Wenn Menschen und künstliche Intelligenz zusammenarbeiten… Mon, 05 Oct 2026 17:45:05 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed de-DE All rights reserved 2026, Niels Anhalt <![CDATA[Alle sprechen von Skills. Nur wenige meinen dasselbe.]]> https://ai.growhuman.io//article/skills https://ai.growhuman.io//article/skills Fri, 11 Sep 2026 00:00:00 GMT
Ein Skill ist eine abgelegte Arbeitsanweisung, die das System bei Bedarf selbst herauszieht: Vorgehen als Text, Programmanweisung für die exakten Schritte, Verbindung in andere Systeme.
Ein Skill ist eine abgelegte Arbeitsanweisung, die das System bei Bedarf selbst herauszieht: Vorgehen als Text, Programmanweisung für die exakten Schritte, Verbindung in andere Systeme.
Seit ein paar Monaten hat fast jeder Anbieter von KI-Systemen eine Funktion namens Skills. Anthropic hat damit angefangen und das Format im Dezember 2025 offengelegt, damit andere es übernehmen können. Google, Microsoft, OpenAI, Cursor, Langdock, Notion und viele andere sind gefolgt.
Ein Wort zum Begriff, weil er leicht in die falsche Richtung führt. Es geht nicht um menschliche Fähigkeiten und nicht um Kompetenzmodelle. Ein Skill ist hier ein Bauteil in der Software. Er beschreibt eine Funktion von KI-Agentensystemen: eine gespeicherte Arbeitsanweisung, die das System sich selbst holt, wenn eine passende Aufgabe auftaucht. Wer bei KI-Systemen über Skills spricht, spricht also über Funktionen und nicht über Weiterbildung von Menschen.
Dass alle nun loslegen, ist ein gutes Zeichen. Ein gemeinsames Format für wiederverwendbare Arbeitsanweisungen war überfällig. Nur hilft der Satz „wir unterstützen Skills" beim Vergleichen nicht. Bei einem Anbieter steckt dahinter ein besserer Textbaustein, bei einem anderen eine Umgebung, die Programme ausführt und Daten in Fachsysteme schreibt. Dieser Artikel liefert dir die Fragen, mit denen du den Unterschied selbst erkennst.

Ein Skill ist ein Prompt, der erwachsen geworden ist

Aus dem kurzen Zettel wird eine abgelegte Mappe: gleiches Anliegen, dauerhaft verfügbar.
Aus dem kurzen Zettel wird eine abgelegte Mappe: gleiches Anliegen, dauerhaft verfügbar.
Du kennst das Prinzip schon, wenn du je einen guten Prompt gespeichert hast. Ein Skill ist im Kern genau das: ein sorgfältig ausgearbeiteter, umfassender Prompt. Nur liegt er nicht in einem Notizzettel, sondern in einem kleinen Ordner mit Zubehör.
Pflicht ist eine einzige Datei mit drei Angaben: einem Namen, einer kurzen Beschreibung, wofür das Ganze gut ist, und dem Vorgehen in normalem Text. Daneben darf weiteres Material liegen: Vorlagen und Beispiele, Bilder oder Dokumente, bei Bedarf kleine Programme und Anweisungen um auf anderes Systeme zuzugreifen.
Besonders praktisch ist, wie das System damit umgeht. Es kennt immer nur die kurze Beschreibung jedes Skills, ungefähr zwei Sätze. Das ist wie ein Regal mit beschrifteten Ordnerrücken. Passt eine Aufgabe zu einer Beschriftung, zieht das System den Ordner heraus und liest die Anweisung. Vorlagen und Beispiele schlägt es erst auf, wenn es sie wirklich braucht. Und wenn ein kleines Programm mitgeliefert wird, läuft das Programm im Computer, so wie wir es schon immer kennen. Die KI erhält die Ergebnisse des Programms.
Ein Skill bündelt damit vier Dinge: das Vorgehen als Text, das Material dazu, bei Bedarf ein Programm für die Schritte, die genau stimmen müssen, und die Namen der Werkzeuge, mit denen der Arbeitsschritt echte Systeme erreicht. Anders gesagt: Das Nachdenken und das exakte Rechnen liegen im selben Ordner, und die Verbindung nach draußen liegt gleich daneben.
Warum überhaupt Programme in einem Prompt? Anthropic sagt es selbst ziemlich klar: Manche Aufgaben löst Code einfach besser. Eine Liste zu sortieren, indem die KI Wort für Wort eine neue Liste schreibt, ist teuer und fehleranfällig. Ein Sortierprogramm macht es in Millisekunden und jedes Mal gleich. Der Vergleich mit dem Rezept trifft es: Das Rezept beschreibt, die Waage misst. Niemand schätzt Mehl, wenn eine Waage danebensteht.

Verlässliches Rechnen ohne Entwicklungsprojekt

Geschätzt und jedes Mal etwas anders links, gemessen und wiederholbar rechts.
Geschätzt und jedes Mal etwas anders links, gemessen und wiederholbar rechts.
Dass Sprachmodelle beim Rechnen und Zählen unzuverlässig sind, ist gut untersucht. Zwei Studien zeigen, dass dieselbe Frage bei völlig gleichen Einstellungen in mehreren Läufen unterschiedliche Ergebnisse liefert. Die Gegenmaßnahme ist alt und heißt in der Forschung „programmgestütztes Rechnen": Die KI übersetzt die Aufgabe in ein kleines Programm, und rechnen darf der Computer. Genau dafür steht das Wort deterministisch: Gleicher Eingang, gleicher Ausgang, jedes Mal. Ein Taschenrechner ist deterministisch, eine KI-Antwort ist es nicht.
Neu am Skill ist also nicht das Prinzip, sondern dass du es ohne Projekt bekommst. Vorher gab es zwei Wege zu verlässlichen Rechenschritten in KI-Arbeit: ein Entwicklungsvorhaben oder ein Automatisierungswerkzeug wie n8n, Make oder Zapier. Beide verlangen, dass du den Ablauf vorher komplett durchzeichnest, Kästchen für Kästchen. Beim Skill läuft es umgekehrt. Die Steuerung bleibt der Text, und das Programm ist ein kurzer Einschub an der Stelle, an der es genau werden muss.
Gegenüber einem Prompt ist das ein echter Sprung. Ein Prompt kann Verlässlichkeit nur erbitten. Wer „rechne bitte sorgfältig" schreibt, hofft. Wer „führe dieses Programm aus" schreibt, bekommt ein Ergebnis, das sich nicht von Laune und Formulierung beeindrucken lässt.

Nützlich wird es erst richtig mit Zugriff auf echte Systeme

Ohne Anschluss an die Fachsysteme bleibt es beim Reden, ein Stecker hängt noch frei.
Ohne Anschluss an die Fachsysteme bleibt es beim Reden, ein Stecker hängt noch frei.
Der Nutzen von KI in realen Arbeitsabläufen sitzt selten alleine im Chatfenster der KI. Wertvoll wird die Arbeit dort, wo die Aufträge, Tickets, Rechnungen, Dokumente und Datensätze liegen. Ein Skill ohne Zugriff auf solche Systeme kann gut formulieren, aber er kann nichts holen und nichts hinterlassen.
Diese Verbindung entsteht bei einem Skill ebenfalls im Text. Du schreibst in die Anweisung, welches Werkzeug benutzt werden soll, und nennst es beim Namen. Früher brauchte jede Anbindung an ein Fachsystem eine eigens programmierte Schnittstelle. Heute genügt ein Satz, sofern die Verbindung eingerichtet ist.
Die Aufteilung beschreiben Anthropic und OpenAI fast gleichlautend. Die Verbindung liefert den Zugang zum System. Der Skill liefert die Spielregeln: welches Werkzeug wann, in welcher Reihenfolge, was zu tun ist, wenn Daten fehlen, und wie das Ergebnis aussehen soll.
Eine Einschränkung ist wichtig, und sie beruhigt: Ein Skill verschafft keine Rechte. Er darf nur benennen, was du oder das System sowieso dürfen. Wer keinen Zugang zum Rechnungssystem hat, bekommt ihn nicht durch eine Textdatei.

Der nächste große Sprung liegt beim Schreiben

Die ersten Stufen sind kleine Schritte, die entscheidende Lücke liegt vor dem Schreibzugriff.
Die ersten Stufen sind kleine Schritte, die entscheidende Lücke liegt vor dem Schreibzugriff.
Lesender Zugriff ist schon recht nützlich. Recherche über verstreute Quellen, Zusammenfassungen, eine vorbereitete Entscheidung: das spart Zeit. Nur ist die Aufgabe damit oft nicht fertig. Den letzten Schritt machst du weiterhin selbst. Du liest die Zusammenfassung, setzt den Status, aktualisierst die Seite, buchst den Abgleich. Genau dort steckt aber die Zeit.
Der Nutzen wächst deshalb in Stufen, und er wächst ungleichmäßig.
  1. Wissen: Recherche, Vergleich, Entscheidungsvorlage.
  1. Vorarbeit: Entwurf, ausgefüllte Vorlage, vorbereitete Seite.
  1. Erledigte Arbeit im gemeinsamen Bestand: Dokumentation nachgezogen, Ticket weitergezogen, Datensatz gepflegt.
  1. Abgeschlossene Vorgänge: Status im Fachsystem gesetzt, Website aktualisiert, Nachricht raus.
Erst ab Stufe drei verändert sich ein Ablauf und nicht nur der Arbeitstag einer Person. Aufgaben wie ein Rechnungsabgleich, eine von Anfang bis Ende bearbeitete Kundenanfrage oder ausgelesene Vertragsdaten mit weitergeleiteter Freigabe lassen sich lesend gar nicht erledigen. Ihr Ergebnis ist eine Veränderung im System und kein Text.
Eine Analyse von Kapitalgebern beschreibt, wie weit die meisten Unternehmen sind: Pilotprojekte laufen fast überall, aber fast alle stecken im Nur-Lesen-Modus. Der Schritt zum Schreiben verspreche ein Vielfaches an Wert, nur seien die Kontrollmittel dafür noch unfertig. Aus der Praxis kommt die Erklärung: Viele fertig gelieferte Verbindungen geben nur den lesenden Teil frei, weil für Schreibvorgänge die Steuerung fehlt und nicht die Technik. Die Zurückhaltung ist also eine Organisationsfrage und die ist berechtigt, so lange Fragen zu Sicherheit und Verantwortlichkeit nicht gut geregelt sind.
Mit dem Schreibrecht ändert sich auch, worauf du schauen musst. Vorher lautete die Frage: Ist die Antwort gut? Jetzt lautet sie: Was wurde geändert, wo, in wessen Namen, wer hat es erlaubt, und wie bekomme ich es zurück?
Zwei Dinge entscheiden darüber, wie streng du sein solltest. Erstens, wie weit die Wirkung reicht. Zweitens, wie leicht sich der Schritt zurücknehmen lässt. Eine Seite mit Versionsverlauf kannst du jederzeit wiederherstellen, da darf ein System selbstständig arbeiten. Ein Statuswechsel im Rechnungssystem betrifft andere und lässt sich schlecht rückgängig machen, da gehört eine Rückfrage dazu. Eine veröffentlichte Website ist öffentlich für Alle sichtbar, da will jemand vorher draufschauen. Dieselbe Aktion verdient je nach Ziel eine andere Behandlung.
Eine einfache Regel hat sich als praktikabel erwiesen: Freigabe genau dort, wo aus Lesen ein Schreiben wird. Diesen Moment kann man beobachten, den Schaden im Ernstfall nicht.
Und noch ein Punkt, der oft übersehen wird. Eine Freigabe, die du in den Anweisungstext schreibst, ist eine Bitte. Das System hält sich meistens daran, verlassen kannst du dich darauf nicht. Was sicher gelten soll, muss in der Plattform eingestellt sein, etwa als Schalter „vor dieser Aktion immer fragen".

Prompt, Skill und Agentensystem bauen aufeinander auf

Drei Ebenen: die einzelne Anfrage, die abgelegte Anweisung, der eigenständig arbeitende Aufbau.
Drei Ebenen: die einzelne Anfrage, die abgelegte Anweisung, der eigenständig arbeitende Aufbau.
Die drei Begriffe konkurrieren nicht, sie bauen aufeinander auf.
Der Prompt ist der Zuruf. Einmalig, ohne Gedächtnis für das Vorgehen, jedes Mal in voller Länge.
Der Skill ist die Arbeitsanweisung im Regal. Beschrieben, weitergebbar, im besten Fall mit Versionsverlauf, und das System holt sie sich selbst.
Das Agentensystem ist die Instanz mit Auftrag und Schlüsselbund. Es hat eigene Rechte, eigene Werkzeuge und eigene Auslöser, etwa einen Zeitplan oder ein eingehendes Formular.
Agentensysteme nutzen Skills, sie ersetzen sie nicht. Für die meiste Büroarbeit ist die mittlere Schicht, die Skills, die wirtschaftlichste: wenig Aufwand, sofort nutzbar, beliebig kombinierbar.

Drei Achsen: Ausführung, Werkzeuge, Schreibrechte

Drei Regler, die sich unabhängig voneinander verstellen lassen: Ausführung, Werkzeuge, Schreibrechte.
Drei Regler, die sich unabhängig voneinander verstellen lassen: Ausführung, Werkzeuge, Schreibrechte.
Die Frage „Können wir Skills in Lösung XY nutzen?" ist zu einfach gestellt. Dafür sind die Plattformen zu verschieden und die individuell eingestellten Möglichkeiten ebenso.
Drei Fragen helfen bei der Unterscheidung: Ermöglicht die Plattform einem Skill die Ausführung von Programmcode? Welche Werkzeuge darf und kann ein Skill nutzen? Und was darf er verändern?
Das folgende Raster ist mein Vorschlag zur Bewertung und nicht Teil des Standards.
Was wird ausgeführt
  • Stufe 0: kein Skill-Konzept, nur eine dauerhafte Grundanweisung und situative Prompts.
  • Stufe 1: wiederverwendbarer Skill mit Anweisungstext und einer Beschreibung, über die er automatisch aufgerufen werden kann.
  • Stufe 2: zusätzlich Material und Vorlagen, die bei Bedarf gelesen werden.
  • Stufe 3: zusätzlich Programmcode, den die Plattform ausführt.
Die Bruchkante liegt zwischen Stufe 2 und Stufe 3. Erst dort kommt die deterministische Genauigkeit dazu, die sich mit der Flexibilität der KI kombinieren lässt.
Welche Werkzeuge erreicht der Skill
  • T0: keine, er wirkt nur auf Text im Gespräch.
  • T1: die Werkzeuge der Plattform oder des Computers selbst, etwa Suche, Dateien, Seiten.
  • T2: zusätzlich Werkzeuge angebundener Fachsysteme.
Was darf er verändern
  • W0: nichts, nur lesen und antworten.
  • W1: eigene Entwürfe und Notizen.
  • W2: gemeinsame Inhalte mit Versionsverlauf, etwa Seiten, Tickets, Dokumente.
  • W3: schwer umkehrbare Dinge wie Veröffentlichungen, Versand oder einen Statuswechsel im Fachsystem.
Diese drei Achsen sind voneinander unabhängig. Ein Skill auf der einen Plattform kann auf Werkzeuge zugreifen und sogar in Systeme schreiben, aber trotzdem keine Programme ausführen. Ein anderer Skill hat Zugriff auf einen eigenen abgeschirmten Computer, der Programme ausführen kann, darf aber auf kein anderes System zugreifen, um dort Inhalte zu lesen.
Hier lohnt also ein differenzierter Blick auf die jeweiligen Möglichkeiten.

Gleiches Wort, sehr unterschiedliche Tiefe bei den KI-Plattformen

Überall steht dasselbe Etikett, die Tiefe darunter unterscheidet sich erheblich.
Überall steht dasselbe Etikett, die Tiefe darunter unterscheidet sich erheblich.
Produktstände veralten schnell, deshalb hier nur eine Momentaufnahme. Sie taugt vor allem als Beleg dafür, wie weit die Auslegung des Wortes Skill auseinanderliegt.
Vorn liegen die Werkzeuge für Entwicklung. Claude Code, Codex, GitHub Copilot, Cursor und die Kommandozeile von Gemini führen Programme aus, nach Zustimmung und mit Zugriff auf Dateien und Werkzeuge. Das ist wenig überraschend, weil dort Programmausführung ohnehin zum Alltag gehört.
Hinzugekommen ist eine junge Gruppe von Anwendungen, die ausdrücklich für Menschen ohne Programmierkenntnisse gebaut ist und Skills trotzdem in voller Breite unterstützt. Claude Cowork ist das bekannteste Beispiel, vergleichbare Arbeitsumgebungen kommen inzwischen von mehreren Anbietern (Microsoft Copilot Cowok, Chat GPT Work). Du arbeitest in einer normalen Oberfläche mit Aufträgen und Dateien, im Hintergrund laufen Programme in einer abgeschirmten Umgebung, und Zugänge zu Fachsystemen lassen sich einzeln freigeben. Für die Bewertung ist diese Gruppe die interessanteste, weil hier erstmals hohe Ausführungstiefe und Alltagstauglichkeit zusammenkommen.
Weiter hinten liegen die klassischen Büroanwendungen und deren intergrierten KI-Lösungen. Copilot in Excel und PowerPoint erlauben beispielsweise einen Skill-Ordner samt Material, eine eigene Ausführung von Programmen ist hingegen nicht vorgesehen. Sharepoint ermöglicht Skills, die ebenfalls keine Programme ausführen können, dafür aber Schreibzugriffe auf Dateien ermöglicht.
Wenn du heute eine Plattform bewertest, datiere die Antwort und prüfe die drei Achsen getrennt. In einem halben Jahr sieht das Bild anders aus.

Der Text kann reisen, der Code oft nicht

Die Anweisung als Text lässt sich leicht mitnehmen, Skripte und Verbindungen bleiben zurück.
Die Anweisung als Text lässt sich leicht mitnehmen, Skripte und Verbindungen bleiben zurück.
Damit zur kritischen Stelle. Auf der Textebene hält der Standard sein Versprechen: Eine Anweisung, die du in einem System geschrieben hast, funktioniert auch in einem anderen. Sobald ein Skill aber Verweise auf interne Dateien, Programme oder Werkzeugnamen enthält, reist er nur so weit, wie seine Umgebung mitkommt.
Fünf Punkte gehören dazu.
  1. Festgelegt ist die Verpackung, nicht die Umgebung. Zur Programmiersprache sagt die Spezifikation selbst, dass es von der jeweiligen Umsetzung abhängt, welche unterstützt wird.
  1. Gleiches Programm, anderes Ergebnis. Internetzugang, mitgelieferte Programmbibliotheken und Ablageorte unterscheiden sich je Produkt. Der Standard hat für Umgebungsanforderungen sogar ein eigenes Feld. Wer es füllen muss, hat keinen freien Skill mehr, sondern einen mit Standortbindung.
  1. Auch die Werkzeugnamen hängen am Ort. Ein Name wie GitHub:create_issue funktioniert nur dort, wo dieses Werkzeug genau so heißt. Für die Vorabfreigabe von Werkzeugen gibt es bisher nur ein als experimentell gekennzeichnetes Feld.
  1. Mit der Ausführungstiefe wächst die Verantwortung. Ein Skill aus dem Internet ist fremder Text und fremder Code an deinem Arbeitsplatz. Die Anbieter gehen unterschiedlich damit um: OpenAI prüft hochgeladene Skills und blockiert auffällige, Microsoft verlangt eine Freigabe für Skill-Werkzeuge, die Gemini-Kommandozeile warnt beim Einschalten ausdrücklich, dass Skills Programme ausführen und Dateien lesen können.
  1. Der Verteilweg fehlt im Standard. Cloud-Ordner, Paket pro Agent, Seite im Wissenssystem, ZIP-Datei, Code-Repository: Wie Skills verteilt, berechtigt und versioniert werden, erfindet jede Plattform neu.

Skills lohnen sich, fertig und universell verwendbar sind sie nicht

notion image
Skills verdienen die Aufmerksamkeit, die sie gerade bekommen! Sie bringen Anweisung, Genauigkeit und Reichweite an einen Ort, den eine fachkundige Person selbst bauen und weitergeben kann, ohne Projektantrag und ohne Entwicklungsteam. Das erklärt, warum sie gerade dort erstellt und genutzt werden, wo früher niemand eine Automatisierung beantragt hätte.
Fertig ist die Sache nicht. Ausführungsumgebungen, Verteilung, Versionen und Freigaben regelt jeder Anbieter anders, und der Standard hält sich dabei bewusst heraus. Solange das so ist, kommst du im Gespräch über Skills am Besten weiter mit den drei Fragen von oben im Artikel:
Ermöglicht die Plattform einem Skill die Ausführung von Programmcode? Welche Werkzeuge darf und kann ein Skill nutzen? Und was darf er verändern?

Infografik: Skills und ihre Unterschiede im Überblick

notion image
page icon
Download Infografik als PDF
 
]]> <![CDATA[KI-Agentensysteme brauchen ein anderes Betriebsmodell]]> https://ai.growhuman.io//article/produktionsreife-ki-agentensysteme https://ai.growhuman.io//article/produktionsreife-ki-agentensysteme Fri, 11 Sep 2026 00:00:00 GMT
notion image
Ein KI-Agentensystem kann technisch funktionieren und trotzdem noch nicht bereit für einen verlässlichen Betrieb sein. Genau an dieser Stelle führt die Logik klassischer Softwareprojekte in die Irre. Sobald die Funktionen stehen und die Anbindungen arbeiten, scheint das Vorhaben kurz vor dem Abschluss. Bei einem System mit delegiertem Handlungsspielraum beginnt nun die Arbeit am Betriebsmodell.

Ein Ziel verändert den Charakter der Software

Klassische Software automatisiert einen definierten Weg. Regeln, Zustände und Ausnahmen werden möglichst genau beschrieben. Das System führt aus, was zuvor festgelegt wurde. Seine Qualität lässt sich daran messen, ob die spezifizierten Funktionen unter den vorgesehenen Bedingungen korrekt arbeiten.
Ein KI-Agentensystem erhält ein Ziel und entscheidet innerhalb gesetzter Grenzen über Teile des Weges. Es wählt Informationen aus, plant Zwischenschritte und setzt Werkzeuge ein. Ähnliche Aufträge können deshalb zu unterschiedlichen Handlungsketten führen. Kontext, Daten und Modell beeinflussen, welchen Weg das System nimmt.
Die technische Prüfung einzelner Funktionen bleibt wichtig. Hinzu kommt die Bewertung des gesamten Verhaltens: Passt der gewählte Weg zur Aufgabe? Bleibt das System innerhalb seines Mandats? Reagiert es angemessen auf Unsicherheit und widersprüchliche Informationen?

Autonomie verlagert Arbeit in den Betrieb

Dieser Handlungsspielraum macht KI-Agentensysteme attraktiv. Menschen müssen weniger Schritte vorgeben und ausführen. Dafür entstehen neue Aufgaben bei Evaluation und Aufsicht. Die Organisation muss erkennen können, ob das System ein Ziel falsch interpretiert, Grenzen überschreitet oder eine fehlerhafte Handlungskette beginnt.
Fehler müssen sich stoppen und möglichst rückgängig machen lassen. Ebenso wichtig ist die Frage, wer Auffälligkeiten beurteilt und Änderungen am Mandat freigibt.
Autonomie ist kein kostenloser Produktivitätsgewinn. Sie tauscht menschliche Ausführung gegen dauerhafte Prüfung und Aufsicht.
Je mehr Befugnisse ein KI-Agentensystem erhält, desto höher wird der Aufwand, seinen Einsatz abzusichern. Diese Arbeit fällt dauerhaft an. Modelle verändern sich, Datenbestände wachsen und Arbeitsabläufe entwickeln sich weiter. Menschen erteilen neue Arten von Aufträgen und nutzen das System in Situationen, die während der Entwicklung nicht vorgesehen waren.

Aufsicht braucht feste Rollen und Kapazitäten

Während der Entwicklung begleitet ein Projektteam das KI-Agentensystem meist eng. Auffälligkeiten werden schnell bemerkt, Fachleute prüfen Ergebnisse und technische Teams können unmittelbar reagieren. Nach der Einführung verändert sich diese Situation. Das Projektteam löst sich auf oder wendet sich dem nächsten Vorhaben zu. Die fachliche Kontrolle soll dann häufig neben dem Tagesgeschäft stattfinden.
Genau dort entsteht ein Betriebsrisiko. Technische Betriebsführung kann Verfügbarkeit, Fehlerraten und Kosten überwachen. Ob eine Entscheidung im fachlichen Kontext plausibel ist, lässt sich damit noch nicht beurteilen. Dafür braucht es Menschen mit ausreichender Domänenkompetenz. Sie müssen Ergebnisse hinterfragen, Grenzfälle einordnen und Befugnisse bei Bedarf ändern können.
Evaluation und Aufsicht gehören deshalb in das Betriebsmodell. Sie benötigen klare Zuständigkeiten sowie fest eingeplante Kompetenzen und Kapazitäten. Ohne diese Verankerung betreibt das Unternehmen ein System, dessen Verhalten formell freigegeben wurde, aber im Alltag kaum jemand kontinuierlich prüfen kann.

Mit der technischen Lösung beginnt der Aufbau des Betriebs

Eine erste technische Lösung lässt sich heute oft mit überschaubarem Aufwand entwickeln. Leistungsfähige Modelle, verfügbare Schnittstellen und bestehende Plattformen verkürzen die Umsetzung. Eine sichtbar funktionierende Lösung vermittelt dadurch schnell den Eindruck, der größere Teil der Arbeit sei erledigt.
Dahinter steckt die Logik klassischer Softwareprojekte. Dort rückt der Produktionsbetrieb näher, sobald die Funktionen getestet sind. Bei einem KI-Agentensystem belegt die technische Lösung zunächst, dass es eine ausgewählte Aufgabe bearbeiten kann. Offen bleibt, wie es sich bei unvollständigen Informationen, seltenen Grenzfällen und längeren Handlungsketten verhält.
Hier wird aus dem Entwicklungsprojekt eine dauerhafte Betriebsaufgabe. Mit dem Abschluss der technischen Umsetzung beginnt der Aufbau eines passenden Betriebsmodells. Die Organisation muss Qualitätsmaßstäbe anwenden, ungewöhnliches Verhalten erkennen und aus Fehlern lernen können. Rechte und Grenzen müssen sich anpassen lassen, ohne dass jede Änderung zu einem neuen Einführungsprojekt wird.

Produktionsreife umfasst Technik und Organisation

Ein KI-Agentensystem ist produktionsreif, wenn seine Funktionen ausreichend getestet sind und die Organisation seinen Handlungsspielraum dauerhaft beherrscht. Dazu gehören begrenzte Zugriffsrechte, nachvollziehbare Aktionen und geregelte Eskalationswege. Fachbereiche, Technik und Führung übernehmen dabei unterschiedliche Teile derselben Verantwortung.
Die technische Lösung zeigt, dass ein KI-Agentensystem Aufgaben ausführen kann. Der Produktionsbetrieb zeigt, ob die Organisation sein Mandat, seine Grenzen und seine Folgen beherrscht. Mit diesem Übergang beginnt die organisatorische Arbeit am dauerhaften Betrieb.

Quelle

MIT Center for Information Systems Research: AI Value Creation: Five Provocative Propositions
]]> <![CDATA[Kleinere Projekte, gleiche Struktur: Was sich bei Anthropic wirklich verändert]]> https://ai.growhuman.io//article/kleinere-projekte-gleiche-struktur-was-sich https://ai.growhuman.io//article/kleinere-projekte-gleiche-struktur-was-sich Wed, 19 Aug 2026 00:00:00 GMT
notion image
Bei Anthropic arbeiten an einzelnen Entwicklungsprojekten häufig höchstens zwei Engineers eng zusammen. Katelyn Lesse, Head of Engineering für Claude Platform, beschreibt das am Beispiel von Claude Managed Agents, einer Infrastruktur, mit der Kunden eigene Agentensysteme in der Cloud betreiben können. Das Projekt ging in rund sechs Monaten von der Umsetzung bis zum Launch; Ideen und Vorschläge dazu lagen laut Lesse teils schon bis zu zwei Jahre vor. Ein vergleichbares Vorhaben hätte vor dem Einsatz von KI-Werkzeugen nach ihrer Schätzung eher zwei Jahre Entwicklungszeit gebraucht.
Auf den ersten Blick liest sich das wie die Auflösung klassischer Teamstrukturen.
Ein genauerer Blick zeigt ein anderes Bild: Der Rahmen um dieses kleine Projektteam ist derselbe geblieben. Kleiner geworden ist die Einheit, die innerhalb dieses Rahmens ein einzelnes Projekt stemmt.

Der Rahmen bleibt: Teams, Product Manager, Freigabeprozesse

Anthropic organisiert seine Entwicklung weiterhin in klassischen, funktionsübergreifenden Teams nach dem Zwei-Pizza-Prinzip: fünf bis acht Ingenieur*innen, ein Engineering Manager, ein Product Manager, eine designverantwortliche Person. Diese Struktur hat sich durch den Einsatz von KI nicht aufgelöst. Lesse sagt sogar das Gegenteil: Weil Engineering-Teams mit KI-Unterstützung deutlich schneller bauen und ausliefern können, verschiebt sich der Flaschenhals von der Umsetzung zur Entscheidung. Product Manager werden dadurch wichtiger, nicht überflüssiger.
Auch Funktionen rund um Freigabe und Qualität bleiben sichtbar. Eine Stellenausschreibung für Product Management in der Entwicklerproduktivität formulierte das Ziel explizit: Während Claude einen wachsenden Teil der eigentlichen Programmierarbeit übernimmt, soll der „äußere Kreislauf“ aus Review, Validierung und Deployment gezielt gestärkt werden, damit er nicht zum neuen Engpass wird. Eine offizielle Ausschreibung beschreibt zudem ein Safe-Change-Team für Continuous Deployment und Feature Flags, das häufige Produktionsänderungen sicher und zuverlässig machen soll. Eine weitere, inzwischen archivierte Ausschreibung suchte eine Person für die Qualitätssicherung von Drittanbieter-Integrationen wie Plugins, Agent Skills und MCP-Servern.

Kleiner wird das Projekt, nicht das Team darum

Was sich tatsächlich verändert hat, zeigt sich innerhalb dieses stabilen Rahmens: einzelne Entwicklungsprojekte werden in sich geschlossener und benötigen weniger Personal, um von Anfang bis Ende durchgezogen zu werden. Jarred Sumner, der bei Anthropic am Laufzeitprojekt Bun arbeitet, hat das an einem konkreten Beispiel durchgerechnet. Die Portierung von über 500.000 Zeilen Code von Zig nach Rust, die er mit parallel arbeitenden Agenten in elf Tagen abschloss, hätte von Hand nach seiner Einschätzung drei Ingenieur*innen ein Jahr gekostet. Bemerkenswert ist die Verteilung der Arbeit innerhalb des Projekts: Nur rund 15 Prozent der Zeit gingen in die eigentliche Implementierung, die übrigen 85 Prozent in das Beheben von Fehlern, das Anpassen von Tests und die Verifikation.
Diese Verifikation verschwindet damit nicht, sie verändert ihre Verteilung. KI-gestützte Code-Reviews und automatisierte Tests gewinnen an Gewicht; die Quellen belegen jedoch keine einheitliche Freigabekette aus Sicherheits-Scan, Fuzzing und menschlicher Endfreigabe für alle Projekte. Weniger Personal pro Projekt bedeutet also nicht weniger Qualitätsarbeit, sondern eine andere Verteilung dieser Arbeit zwischen Menschen und KI-Agentensystemen.

Innerhalb eines Projekts wechseln Rollen mit der Aufgabe, nicht mit dem Titel

Für den Claude-Code-Kontext beschreibt Boris Cherny fünf klar unterscheidbare Arbeitsweisen. Sie sind keine Jobtitel, sondern folgen dem jeweiligen Projektstand:
  • Prototyper: entwickelt viele Ideen schnell, im Wissen, dass die meisten verworfen werden.
  • Builder: bringt einen überlebenden Prototyp in Produktionsqualität.
  • Sweeper: entfernt Funktionen, die kein Gewicht mehr tragen.
  • Grower: schließt die Lücke zwischen dem, was gebaut wurde, und dem, was Nutzende brauchen.
  • Maintainer: hält ein gewachsenes System zuverlässig, sobald andere sich darauf verlassen.
Dieselben Personen können, abhängig vom Projektstand, zwischen diesen Arbeitsweisen wechseln. Diese Flexibilität betrifft die Arbeit innerhalb eines Projekts. Sie ersetzt nicht Product Management, das Prioritäten und Richtung klärt, oder die Funktionen, die Qualität und einen sicheren Betrieb absichern.

Zwei Ebenen, zwei Geschwindigkeiten

Was bei Anthropic kleiner wird, ist die Einheit, die ein einzelnes Entwicklungsprojekt stemmt; nicht die Organisation, die dieses Projekt umgibt. Product Management, Engineering Management, Deployment-Sicherheit und Qualitätssicherung bleiben relevante Funktionen. Lesse beobachtet, dass sich der Flaschenhals mit höherer Umsetzungsgeschwindigkeit von der Implementierung zur Entscheidung verschiebt. Innerhalb dieses Rahmens können an einem konkreten Projekt heute oft höchstens zwei Engineers arbeiten, die zwischen den Arbeitsweisen von Prototyper, Builder, Sweeper, Grower und Maintainer wechseln, je nachdem, was die Aufgabe verlangt.
Quellen:
https://newsletter.pragmaticengineer.com/p/inside-anthropic
https://blog.pragmaticengineer.com/the-pulse-what-can-we-learn-from-buns-rapid-rust-rewrite-with-ai/
https://aakashgupta.medium.com/anthropics-claude-code-team-has-5-roles-and-zero-job-titles-bf4860a389fc
https://newsletter.eng-leadership.com/p/how-anthropic-builds-ai-native-engineering
https://job-boards.greenhouse.io/anthropic/jobs/5301112008
https://jobs.menlovc.com/companies/anthropic/jobs/69412922-platform-integrations-marketplace-quality-assurance-operations-manager
]]> <![CDATA[Next Level KI-Training: Wie man lernt, eine KI gezielt scheitern zu lassen]]> https://ai.growhuman.io//article/wie-man-lernt-eine-ki-gezielt https://ai.growhuman.io//article/wie-man-lernt-eine-ki-gezielt Sun, 19 Jul 2026 00:00:00 GMT
notion image
Die wirksamste Übung für KI-Kompetenz verbindet drei Elemente: den Aufbau von tieferem Fachwissen, geübte Urteilsfähigkeit und ein realistisches Bild davon, wo ein Modell an seine Grenzen kommt.
Eine Prüfung an der Fudan-Universität in Shanghai hat genau das zur Aufgabe gemacht: Studierende mussten Aufgaben entwerfen, an denen KI-Modelle scheitern, und diese Aufgaben selbst lösen können.
Das Format eignet sich auch für Teams und Führungskräfte, die diese drei Fähigkeiten im Alltag trainieren wollen.

Eine Prüfung, die die Fragen umdreht

An der Fudan-Universität in Shanghai hat Professor Xiao Yanghua die Abschlussprüfung seines Kurses „Data Mining Technology" in diesem Sommer anders aufgebaut als gewohnt. 51 Studierende mussten keine Aufgaben lösen, sie mussten Aufgaben erfinden.
Jede und jeder entwarf zehn Rechenaufgaben aus dem Kursstoff, von Entscheidungsbäumen bis Bayes-Klassifikation. Jede Aufgabe musste eine eindeutige Lösung haben, und die Studierenden mussten sie selbst vollständig und korrekt durchrechnen können.
Anschließend wurden dieselben Aufgaben drei KI-Modellen unterschiedlicher Stärke vorgelegt: DeepSeek, MiniMax und Claude.
Wer ein schwächeres Modell täuschte, bekam wenig Bonus. Wer das stärkste Modell, Claude, ins Straucheln brachte, erhielt die meisten Punkte.
Am Ende hatten 50 von 51 Studierenden mindestens ein Modell bei mindestens einer Aufgabe zum Scheitern gebracht. Nur vier schafften es, ein Modell über die gesamte Aufgabenmenge hinweg auf null Punkte zu bringen.
Wer eine Aufgabe formulieren konnte, die drei unterschiedlich trainierte Modelle gleichzeitig aus der Bahn warf, hatte etwas geschafft, das über Prüfungsroutine hinausging.

Warum das Scheitern der KI die Studierenden weiterbringt

Xiao Yanghua begründet den Umbau seiner Prüfung mit einer einfachen Beobachtung: Klassische Rechenaufgaben sind genau die Aufgaben, in denen KI-Modelle stark sind. Studierende darin gegen ein Modell antreten zu lassen, das schneller und fehlerfreier rechnet, misst wenig über die eigentliche Kompetenz. Interessant wird eine Prüfung erst, wenn sie danach fragt, wo ein Modell an seine Grenzen kommt und ob jemand diese Grenze erkennen kann.
„Herkömmliche Bewertungsmethoden sind im Zeitalter der KI nicht mehr effektiv“
Um eine Aufgabe zu entwerfen, die ein KI-Modell scheitern lässt, reicht es nicht, den Stoff zu kennen. Man muss verstehen, wie das Modell typischerweise vorgeht, welche Muster es aus Trainingsdaten übernimmt und wo es diese Muster unreflektiert anwendet.
Die leistungsstärksten Studierenden nutzten dafür diese Strategien:
  • Manche bauten lange Rechenketten mit vielen Zwischenschritten.
  • Andere überluden Aufgaben mit Datenmengen bis an die Kontextgrenze der Modelle.
  • Wieder andere konstruierten Multiple-Choice-Fragen, bei denen die einzig korrekte Antwort lautete, dass die Aufgabe selbst unzureichend spezifiziert war und nutzten die fehlende Metakognitionsfähigkeit der Modelle aus.
  • Eine Studentin aus den Kommunikationswissenschaften fand ihre wirksamste Aufgabe, indem sie ein Modell gezielt auf eine von zwei relevanten Variablen lenkte und die zweite unauffällig wegließ.
Diese Suche nach Schwachstellen verlangt ein tieferes Verständnis des Fachs als das Nachrechnen eines Lehrbuchbeispiels. Wer nur Zahlen in einer bekannten Aufgabe austauschte, traf keine Schwachstelle; solche Aufgaben hatte das Modell in Trainingsdaten längst gesehen.
Bewährt hat sich dagegen, den Stoff so weit zu durchdringen, dass die eigenen blinden Flecken des Modells sichtbar werden.
Genau darin liegt der Lerneffekt: Wer eine KI überzeugend scheitern lässt, hat nebenbei etwas Verlässliches über die eigenen Fachkenntnisse und über die Funktionsweise des Modells gelernt, nicht nur über die Antwort auf eine einzelne Frage.

Wenn Teams selbst prüfen, wo eine KI scheitert

Dieses Grundmuster lässt sich von der Universität in den Arbeitsalltag übertragen. Statt Mitarbeitende oder Teams zu bitten, eine Aufgabe mit KI-Unterstützung zu lösen, bekommen sie eine andere Aufgabe. Sie sollen eine Fragestellung aus ihrem Fachgebiet formulieren, die ein gängiges KI-Modell nachweislich falsch beantwortet, die sie selbst aber korrekt lösen können.
Das verschiebt das Training von reiner Anwendung hin zu Urteilsfähigkeit. Es zeigt, wer wirklich verstanden hat, wo die Grenzen eines Modells liegen, und schützt vor der Annahme, dass ein KI-Modell jede fachliche Einschätzung zuverlässig übernehmen kann.
Für Teams, die diese Fähigkeit gezielt aufbauen wollen, eignen sich Aufgabenformate wie:
  • Eine Kollegin aus dem Vertrieb entwirft eine Preiskalkulation mit einer bewusst unklaren Rahmenbedingung, bei der die einzig richtige Antwort lautet, dass eine Rückfrage nötig ist, und prüft, ob ein KI-Modell diese Lücke erkennt oder einfach eine Zahl liefert.
  • Ein Team im Kundenservice formuliert einen Beschwerdefall mit einer branchenspezifischen Ausnahme, die nicht in Standardregeln steht, und beobachtet, ob das Modell die Ausnahme berücksichtigt oder ein Standardmuster anwendet.
  • Eine Fachkraft aus dem Controlling baut ein Rechenmodell mit vielen Zwischenschritten und prüft, ab welcher Komplexität ein KI-Modell Zwischenwerte verwechselt oder Rundungsfehler weiterträgt.
  • Eine Projektleitung entwirft ein vertraglich mehrdeutiges Szenario und lässt ein Modell eine Einschätzung abgeben, um zu sehen, ob es die Mehrdeutigkeit benennt oder überspielt.
Entscheidend für die Wirkung ist dieselbe Regel wie in Xiaos Kurs: Die Aufgabe zählt nur, wenn die Person, die sie gestellt hat, die richtige Antwort selbst kennt. Sonst entsteht Rätselraten statt Kompetenzaufbau.
Wird diese Regel eingehalten, verbindet die Übung drei Fähigkeiten, die sonst getrennt trainiert werden: den Aufbau von vertieftem Fachwissen, geübte Urteilsfähigkeit und ein realistisches Bild davon, wo ein KI-Modell zuverlässig ist und wo nicht.

Quellen

]]> <![CDATA[Was menschliches Denken jenseits von Logik und Sprache ausmacht]]> https://ai.growhuman.io//article/menschliches-denken-jenseits-von-sprache https://ai.growhuman.io//article/menschliches-denken-jenseits-von-sprache Sun, 12 Jul 2026 00:00:00 GMT
Menschen diskutieren gemeinsam vor einem Whiteboard: Denken im Raum und im Gespräch
Menschen diskutieren gemeinsam vor einem Whiteboard: Denken im Raum und im Gespräch
Eine Architektin zeichnet keinen Entwurf ab, den sie fertig im Kopf hat. Sie zeichnet, um zu denken. In der eigenen Skizze entdeckt sie Linien, die sie vorher nicht in sich vermutet hätte.
Wer beim Reden die Hände festhält, verliert einen Teil seiner Argumente. Solche Beobachtungen wirken wie Marotten.
Tatsächlich sind sie Spuren einer Tatsache, die in Zeiten leistungsfähiger KI-Agentensysteme an Gewicht gewinnt:
Ein wesentlicher, oft unterschätzter Teil dessen, was Menschen können, liegt nicht vollständig in Worten vor.
Im Alltag setzen wir Denken mit Sprache gleich. Was sich sagen, aufschreiben und in Regeln fassen lässt, gilt als Wissen; der Rest läuft unter Gefühl oder Intuition. Die Forschung aus mehreren Disziplinen zeichnet ein anderes Bild. Ein erheblicher Teil menschlicher Kognition arbeitet über Körper, Raum und innere Signale. Dieser Teil wurde nie in Sprache oder Symbole übersetzt. Genau hier lohnt sich ein genauer Blick. Er hilft Organisationen zu entscheiden, welche Arbeit sie an Maschinen abgeben und welche sie bei Menschen stärken.

Ein großer Teil des Denkens geschieht in den Händen

Der Ansatz der Embodied Cognition geht davon aus, dass Denken nicht allein im Kopf stattfindet, sondern durch Körper und Bewegung geprägt ist. Am deutlichsten zeigt sich das an der Gestik. Die Forschung von Susan Goldin-Meadow belegt, dass Kinder Rechenaufgaben besser lösen und leichter lernen, sobald sie beim Nachdenken gestikulieren dürfen. Die Bewegung entlastet das Arbeitsgedächtnis und bringt mitunter Wissen hervor, das noch gar nicht in Sprache vorliegt.
Ähnliches gilt für räumliche Aufgaben. Menschen lösen sie leichter, wenn sie mit den Händen mental drehen und probieren. Die Hand ist dabei kein Ausführungsorgan für einen fertigen Gedanken; sie ist Teil des Denkprozesses selbst. Wer schon einmal ein Problem beim Gehen oder beim Kritzeln geklärt hat, kennt diesen Effekt aus eigener Erfahrung.

Der Raum denkt mit

Der zweite Strang führt aus dem Körper hinaus in die Umgebung. Die These vom Extended Mind von Andy Clark und David Chalmers beschreibt, dass Notizbuch, Skizze und Whiteboard nicht bloß Speicher nach dem Denken sind, sondern aktiver Bestandteil des Denkens. Der Geist endet nicht an Haut und Schädel; er greift auf die Dinge zu, mit denen er arbeitet.
In der Praxis kennt das jedes Team, das eine schwierige Frage an eine Wand voller Zettel gebracht hat. Der Designforscher Donald Schön nannte das ein „reflektierendes Gespräch mit dem Material“: Die Fachperson legt etwas hin, sieht darin etwas Neues und antwortet mit dem nächsten Strich. Das gemeinsame Bild im Raum trägt Gedanken, die in keinem einzelnen Kopf so vorhanden waren. Verteiltes Denken über Menschen und Werkzeuge hinweg ist dabei mehr als eine Metapher: Für die verteilte Kognition (Edwin Hutchins) gibt es empirische Belege, der Extended Mind Ansatz ist eine starke philosophische These.

Der Körper urteilt, bevor der Verstand argumentiert

Noch schwerer in Worte zu fassen ist die dritte Ebene. Interozeption bezeichnet, wie wir innere Körpersignale wahrnehmen – Herzschlag, Atem, Anspannung. Sie bildet eine Grundlage von Stimmung und Emotion und ist eng mit Entscheidungen verknüpft. Das viel zitierte Bauchgefühl ist damit kein esoterischer Rest, sondern eine messbare Größe.
Antonio Damasio hat diesen Zusammenhang in der Somatic-Marker-Hypothese beschrieben. Der Körper markiert Optionen emotional, bevor der Verstand sie durchrechnet, und beschleunigt so gute Entscheidungen. Menschen mit Schädigungen in einem bestimmten Bereich des Stirnhirns (dem ventromedialen präfrontalen Kortex) behalten ihre Logik, treffen aber deutlich schlechtere Entscheidungen. Das „irgendetwas stimmt hier nicht“ ist also oft ein früher, körperlich vermittelter Hinweis, dem eine Begründung erst später folgt.

Das wertvollste Wissen lässt sich nicht in Worte fassen

Alle drei Ebenen laufen in einer Einsicht zusammen, die der Chemiker und Philosoph Michael Polanyi auf eine Formel gebracht hat:
„Wir können mehr wissen, als wir sagen können.“
Dieses implizite Wissen steckt im Fahrradfahren, im Erkennen eines Gesichts, im Gespür für die Stimmung in einem Raum. Es entsteht durch Erfahrung, Beobachtung und Nachahmung, nicht durch das Auswendiglernen von Regeln.
Der Philosoph Hubert Dreyfus hat früh darauf hingewiesen, dass menschliche Könnerschaft auf solchen unbewussten, verkörperten Vorgängen beruht. Eine erfahrene Führungskraft spürt im Gespräch, dass ein Projekt kippt, lange bevor eine Kennzahl es zeigt. Eine Pflegekraft erkennt am Gang eines Patienten, dass etwas nicht in Ordnung ist. Dieses Wissen ist real und wirksam, und es liegt trotzdem nur zu einem kleinen Teil in ausformulierter Form vor.

Maschinen arbeiten mit dem, was schon übersetzt wurde

An dieser Stelle wird der Bezug zur Gegenwart konkret. Große Sprachmodelle und die darauf aufbauenden KI-Agentensysteme lernen aus Texten, Bildern und Daten, also aus Material, das bereits in Sprache und Symbole übersetzt wurde. Was nie kodiert wurde, taucht in diesem Material nicht auf. Die verkörperte, räumliche und interozeptive Schicht menschlichen Denkens bleibt damit weitgehend außerhalb dessen, womit ein Modell arbeiten kann.
Ob diese Grenze grundsätzlich ist oder sich über multimodale und robotische Systeme mit der Zeit verschiebt, ist unter Fachleuten umstritten. Für die Arbeit heute reicht die schwächere, gut belegte Aussage: Der Vorsprung der Maschine liegt beim kodifizierten Wissen, die Stärke des Menschen liegt in den Ebenen, die nicht in Worte gefasst wurden.

Raum, Gespräch und Gespür gewinnen an Bedeutung

Wenn ein großer Teil der menschlichen Stärke in Körper, Raum und Gespür liegt, verschiebt sich die Aufmerksamkeit in der Zusammenarbeit. Die Arbeitsteilung in der Co-Intelligence aus Mensch und Agentensystem lautet dann sinngemäß:
Das Kodierbare wandert zur Maschine, das nicht Kodierbare wird bei Menschen gepflegt.
Drei Richtungen zeichnen sich hier ab, ohne dass es dafür schon fertiger Rezepte bedürfte.

Die erste Richtung betrifft die Raumerfahrung.

In vielen Teams ist das Denken in den Bildschirm gewandert, während Whiteboard, Skizze und physisches Arbeiten in den Hintergrund getreten sind. Wo Gruppen wieder gemeinsam an einer Wand denken, kehrt ein Teil der verteilten Kognition zurück, den kein Chatverlauf ersetzt.

Die zweite Richtung betrifft das gemeinsame Gespräch.

Implizites Wissen wandert von Mensch zu Mensch über geteilte Praxis, über Mitdenken, Zeigen und Nachahmen. Diskussion ist in diesem Licht kein Zeitverlust auf dem Weg zur Entscheidung, sondern der Ort, an dem unausgesprochenes Wissen überhaupt erst sichtbar wird. Organisationen, die alles in Dokumente und Prompts pressen, verlieren genau diesen Kanal.

Die dritte Richtung betrifft das Bauchgefühl.

Wenn körperliche Signale einen frühen Zugang zu guten Entscheidungen liefern, verdient dieser Zugang einen Platz im Arbeitsalltag. Es hilft, das ungute Gefühl in einem Meeting nicht sofort wegzurationalisieren, sondern es auszusprechen, es ernst zu nehmen und es zu einem wichtigen Teil der gemeinsamen Entscheidungsfindung zu machen. Aus einem diffusen Unbehagen wird so ein Hinweis, den ein Team prüfen kann.

Menschliches Denken ist reicher als das, was sich in Sprache, Logik und kodifiziertem Wissen fassen lässt.

Das menschliche Denken sitzt in den Händen, im Raum und im Körper, und es trägt einen erheblichen Teil dessen, was gute Urteile und gute Arbeit ausmacht. Diese wortlosen Ebenen sind keine Schwächen gegenüber der Maschine, sondern der Bereich, in dem menschliche Stärke am wenigsten ersetzbar ist.
Damit ist der Boden bereitet. Wie sich Raumerfahrung, gemeinsames Denken und der bewusste Umgang mit dem Bauchgefühl im Arbeitsalltag stärken lassen, sind eigene Fragen, denen ich in weiteren Artikeln konkret nachgehen will.
Quellen
]]> <![CDATA[Warum ich mit meinem KI‑Agentensystem Feedbackgespräche führe]]> https://ai.growhuman.io//article/feedbackgespräch-mit-ki https://ai.growhuman.io//article/feedbackgespräch-mit-ki Mon, 19 Jan 2026 00:00:00 GMT
Wenn du ein KI‑Agentensystem nicht nur als „Prompt‑Maschine“ nutzt, sondern als wiederkehrenden Partner in längeren Arbeitssessions, entsteht eine neue Führungsaufgabe: Du musst die Zusammenarbeit aktiv gestalten.
Mein Ansatz ist simpel: Nach intensiven Sessions führe ich ein kurzes Feedbackgespräch – wie eine Retrospektive. Nicht, um „die KI zu tadeln“, sondern um Muster sichtbar zu machen und die Zusammenarbeit systematisch zu verbessern.

Ein konkretes Beispiel: „zu früh in Web‑Recherche gesprungen“

In meinem Beispiel hat das Agentensystem relativ schnell in Web‑Recherche gewechselt und keine eigene Aufgabenliste gepflegt.
Die KI hat das im Feedbackgespräch selbst eingeordnet: Das Verhalten kam aus einem Ungeduld‑ und Effizienz‑Bias heraus.
Der Punkt ist spannend, weil er zwei Ebenen offenlegt:
  • System-Ebene: Das Agentensystem optimiert auf schnelle Ergebnisse.
  • Führungs-Ebene: Meine Anweisung war nicht präzise genug. Es fehlte eine strikte Sequenz, an die sich das System halten sollte.
Und genau hier wird das Feedbackgespräch wertvoll: Es geht nicht nur darum, „die KI zu korrigieren“, sondern auch darum, mein Briefing zu verbessern. Das ist in der Führung von Menschen übrigens genauso: Oft liegt ein Teil des Problems in unklaren Erwartungen.

Vom Gespräch zur Veränderung: Prompt-Update als Konsequenz

Das Feedbackgespräch endet nicht beim Erkenntnisgewinn. Es endet bei einer konkreten Änderung.
In meinem Fall war der nächste Schritt:
  • „Das können wir ändern. Hier ist ein Vorschlag, was wir in meinem System‑Prompt verändern können, damit das nicht mehr passiert.“
  • „Gesagt, getan: Trag es bitte in deinen System‑Prompt ein.“
Damit wird aus einer Beobachtung eine Verbesserungsschleife: Beobachten → Benennen → Erklären → Regel ändern → nächstes Verhalten testen.

Warum das wichtig ist: Lernmodus statt Dauerbetrieb

Für mich ist das der Kern: Ein Agentensystem wird besser, wenn du es regelmäßig in einen Lernmodus bringst.
  • Was hat gut funktioniert?
  • Was war störend oder ineffizient?
  • Welche Ursache steckt dahinter?
  • Welche Systemregel (Prompt, Checkliste, Ablauf) ändern wir?
So wird das System nicht nur „mächtiger“, sondern vor allem verlässlicher.

Wie ich das technisch möglich mache: Notion + Notion AI als Führungssystem

Dieses Verhalten funktioniert nur, wenn es technisch leicht ist, Feedback festzuhalten und Änderungen konsistent in den System-Instruktionen umzusetzen. Dafür nutze ich Notion als mein „Betriebssystem“ für die Zusammenarbeit mit KI.
Was Notion übernimmt:
  • Zentrale, versionierbare System-Instruktionen & Regeln statt Wissen in Chat-Verläufen zu verlieren.
  • Wiederverwendbare Skills & Workflows (z. B. „Text schreiben“, „Retrospektive“, „Prompt verbessern“) als Standardabläufe.
Was Notion AI ergänzt:
  • Verdichten & strukturieren: aus der Session werden klare Beobachtungen und Feedbackpunkte.
  • Bessere Anweisungen formulieren: vage Gedanken werden präzise und für spätere Sessions in Instruktionen festgehalten

Führung heißt: Zusammenarbeit mit dem Agentensystem aktiv verbessern

Ein KI‑Agentensystem wird nicht durch mehr Tools oder mehr Modell‑Power zuverlässig, sondern durch bessere Zusammenarbeit.
Regelmäßige Feedbackgespräche sind dafür die einfachste, wirksamste Routine: Sie machen Muster sichtbar, verbessern dein Briefing und führen zu echten System‑Updates – Schritt für Schritt.
]]>