Agents: Was Handlungsfähigkeit für LLMs wirklich bedeutet – und was sich daraus für die Arbeitswelt ergibt

Der Begriff „Agent“ ist zum Sammelbegriff für fast alles geworden, was ein LLM tut, das über eine einzelne Antwort hinausgeht. Damit verliert er an Aussagekraft – ausgerechnet in einem Moment, in dem die tatsächliche Handlungsfähigkeit dieser Systeme einen qualitativen Sprung macht. Dieser Artikel versucht, den Begriff zu schärfen, die wesentlichen Unterschiede zwischen verschiedenen Systemarchitekturen herauszuarbeiten und zwei Konsequenzen für die Arbeitswelt zu beschreiben, die über das übliche „AI macht X schneller“ hinausgehen: die Notwendigkeit, Arbeit als Kontext zu denken, und die wachsende Bedeutung, die eigene Arbeit als System beschreiben zu können.

Was „Agent“ bedeutet – und was nicht

Agent leitet sich von agens ab – dem Handelnden. Aus dieser einfachen Begriffsdefinition ergibt sich das wesentliche Kriterium: Agency (Handlungsfähigkeit) beginnt dort, wo ein System eigenständig entscheidet, wie viele Schritte es zur Lösung einer Aufgabe unternimmt. Nicht die Qualität der Antwort macht den Unterschied, sondern wer den Ablauf steuert – der Code oder das Modell.

Ein Workflow ist eine vordefinierte Verkettung von LLM-Aufrufen: Der erste Aufruf verarbeitet den Input, sein Ergebnis fließt in den zweiten, und so weiter. Die Ergebnisse dieser einzelnen Aufrufe und damit auch des ganzen Workflows sind probabilistisch – kein Durchlauf liefert identischen Output –, aber die Struktur steht vorab fest. Typische Muster sind Prompt Chaining, Routing oder Parallelisierung. Hier liegt keine Agency vor. Das System tut, was ihm architektonisch vorgegeben wurde – nur eben mit variablen Inhalten.

Modelle mit Extended Thinking oder Chain-of-Thought bestimmen selbst, wie lange sie nachdenken. Sie steuern die Tiefe ihrer eigenen Verarbeitung. Das wirkt manchmal wie Agency, ist es aber nicht – denn es fehlt neues Feedback aus der Außenwelt zwischen den Denkschritten. Das Modell reorganisiert, was es bereits weiß. Es führt, salopp gesagt, ein Selbstgespräch. Das ist Deliberation, nicht Handlung.

Ein Agent im engeren Sinne operiert in einer offenen Schleife: Er führt eine Aktion aus, erhält ein Ergebnis aus der Umwelt zurück – ein Suchergebnis, eine API-Antwort, die Ausgabe einer Code-Ausführung –, und entscheidet auf dieser Basis über den nächsten Schritt. Jede Iteration liefert Information, die zuvor nicht verfügbar war. Erst diese Rückkopplung mit der Welt macht aus Deliberation echte Agency.

Innerhalb dessen, was tatsächlich als Agent gelten kann, gibt es eine weitere Unterscheidung, die aus Nutzersicht mindestens ebenso wichtig ist: Was verändert sich durch die Handlung? Ein LLM, das im Hintergrund Python ausführt, um eine Berechnung zu machen, hat technisch ein Tool benutzt – aber der Zustand der Arbeitsumgebung ist danach derselbe wie vorher. Das Modell hat lediglich eine Schwäche kompensiert, ähnlich wie ein Mensch zum Taschenrechner greift.

Etwas qualitativ anderes passiert, wenn ein System Dateien erzeugt, Code committet oder E-Mails versendet: Hier entstehen persistente Handlungsergebnisse, die nach dem Aufruf weiter existieren und für andere sichtbar sind. Die Kombination aus Autonomie und Wirkungsradius bestimmt das tatsächliche Risiko- und Nutzenprofil eines Systems.

Agentische Systeme in der Praxis

Die Systeme, die sowohl autonom als auch mit realen Seiteneffekten arbeiten, haben 2025 einen Entwicklungsschub erfahren. Claude Code, Anthropics Terminal-basierter Coding-Agent, ist dabei der wohl wirkungsmächtigste Vertreter: Er durchsucht eigenständig Repositories, liest und schreibt Dateien, führt Code aus und validiert Ergebnisse – in einer offenen Schleife, deren Länge sich aus der Aufgabe ergibt.

Claude Code hat eine bemerkenswerte Nutzerbasis aufgebaut, allerdings fast ausschließlich unter technischen Anwendern. Interessant war dabei ein Phänomen, das Anthropic intern als „Shadow Use“ beobachtete: Entwickler setzten das Tool zunehmend für Aufgaben jenseits des Programmierens ein – Recherche, Dokumentenerstellung, Dateiverwaltung, sogar Urlaubsplanung. Im Januar 2026 zog Anthropic die Konsequenz und veröffentlichte Cowork: dieselbe agentische Architektur – autonome Schleife, Dateizugriff, Multi-Step-Ausführung –, aber als grafische Oberfläche, die kein Terminal erfordert. Der Nutzer zeigt Cowork auf einen Ordner, beschreibt eine Aufgabe, und das System plant und führt die nötigen Schritte eigenständig aus.

Wie viel Kontrolle gibt man ab?

Was agentische LLM-Systeme von konventioneller Software unterscheidet, ist nicht nur, was sie tun – sondern wie sie dazu gebracht werden, es zu tun. Die zentrale Designentscheidung ist dabei nicht technisch, sondern konzeptionell: Wie viel Kontrolle über den Prozess behält der Mensch – und wie viel überlässt er dem System?

Am einen Ende steht maximale Kontrolle. Das Open-Source-Projekt Superpowers von Jesse Vincent besteht aus über 20 sog. Skills – Markdown-Dateien, die einem Agenten Schritt für Schritt beschreiben, wie er planen, testen, debuggen und Code reviewen soll. Diese Skills definieren nicht nur den Sollprozess, sondern antizipieren die spezifischen Ausweichmanöver, die ein LLM-Agent versuchen wird, um Schritte zu überspringen – und formulieren explizite Gegenmaßnahmen. Der Mensch gibt die Methodik vor; der Agent führt aus.

Am anderen Ende steht maximale Autonomie. OpenClaw, ein Open-Source-Projekt des österreichischen Entwicklers Peter Steinberger, verbindet einen Agenten mit Messaging-Diensten wie WhatsApp oder Slack, gibt ihm ein persistentes Gedächtnis und eigene Werkzeuge – und lässt ihn eigenständig auf eingehende Nachrichten reagieren, Aufgaben planen und ausführen. Der Agent läuft dauerhaft, entscheidet selbst, wann und wie er handelt; der Nutzer gibt die Kontrolle über den Prozess weitgehend ab. Dass OpenAI Steinberger im Februar 2026 akquirierte, zeigt, wie ernst die großen Anbieter diesen Ansatz nehmen.

Zwischen diesen Polen liegt ein Designraum — und was ihn von konventioneller Softwareentwicklung unterscheidet, ist das Medium: An beiden Enden des Spektrums wird das Verhalten des Agenten primär in natürlicher Sprache definiert. Ein Skill ist eine Markdown-Datei, kein Code. Ein agentisches System zu erweitern oder an die eigene Arbeit anzupassen, erfordert daher keine Programmierkenntnisse.

Was das für die Arbeitswelt bedeutet

Das Maß der Autonomie ist eine zentrale Designentscheidung — und im geschäftlichen Kontext eine, bei der mehr Kontrolle in der Regel die bessere Wahl ist. Aber für die allermeisten Anwender in Unternehmen stellt sich diese Frage Stand Februar 2026 noch gar nicht so konkret. Die Systeme, auf die sie Zugriff haben — Microsofts Copilot, Googles Workspace Studio —, operieren innerhalb einzelner Anwendungen: Ein Agent bearbeitet ein Word-Dokument in Word, erstellt eine Tabelle in Sheets, speichert einen Anhang in Drive. Sie können Artefakte erzeugen und vordefinierte Abläufe automatisieren, aber sie operieren nicht auf derselben Ebene wie Claude Code oder Cowork: als general-purpose Systeme, die der Nutzer selbst durch natürliche Sprache instruiert und erweitert.

Dass sich das ändern wird, ist absehbar — Microsoft und Google bewegen sich klar in Richtung agentischer Systeme. Aber die Frage, die sich schon jetzt stellen lässt, ist grundsätzlicher: Wenn Agenten nicht mehr nur innerhalb einzelner Apps operieren, sondern auf der Ebene der eigentlichen Arbeitsinhalte — was verändert sich dann?

1. Arbeit als Kontext denken

Die bestehende Bürowelt denkt stark in Formaten und Artefakttypen: PowerPoint-Präsentationen, PDFs, E-Mails, Chat-Verläufe, Protokolle, Tabellen. Jedes Format hat seine eigene Anwendung, seine eigene Logik, seine eigenen Beschränkungen. Für Menschen ist das handhabbar – wir navigieren intuitiv zwischen Outlook, Teams, Word und der Dateiablage.

Agentische Systeme verschieben den Schwerpunkt. Ein LLM versteht Text. Es kann aus Text Artefakte in beliebigen Formaten erzeugen, aber seine eigentliche Arbeitsgrundlage ist strukturierter, lesbarer Text – Kontext. Und das Erzeugen von Artefakten – eine E-Mail, eine Präsentation, ein Konzeptpapier, ein Proposal – ist mit einem agentischen System keine nennenswerte Arbeit mehr. Das Formatieren, Layouten, Zusammenstellen: erledigt. Was dagegen Arbeit bleibt – und an Bedeutung gewinnt –, ist das Inhaltliche: der Kontext.

Konsequent weitergedacht sollten Kontext und Output-Format also als getrennte Ebenen verstanden werden. Nicht die Präsentation ist das Arbeitsergebnis, sondern das Wissen, das in ihr steckt. Die Präsentation ist ein Ausgabeformat, das sich bei Bedarf aus dem Kontext generieren lässt – genauso gut als Memo, als Zusammenfassung für Stakeholder oder als Entscheidungsvorlage.

Der alte Seufzer „meetings that could have been an email“ bekommt dadurch nochmal eine neue Dimension. In einer konsequent kontextorientierten Arbeitsweise hätte das Meeting nicht nur eine E-Mail sein können, sondern ein strukturiertes Dokument, aus dem sich automatisiert ein Aufgabentracking, eine Zusammenfassung und ein Follow-up-Draft ableiten lassen. Die Voraussetzung ist nicht „mehr schreiben“, sondern: das Richtige als Kontext verfügbar machen – vollständig, kohärent, in einer Form, die sowohl für Menschen als auch für Agenten lesbar ist.

Tools wie Obsidian und Markdown als Arbeitsformat gewinnen in diesem Zusammenhang eine neue Relevanz – nicht als Nerd-Spielzeug, sondern als kontext-optimierte Grundlage für eine Arbeitsumgebung, in der menschliche und agentische Arbeit ineinandergreifen.

2. Arbeit als System denken

Die zweite Rückkopplung betrifft eine Kompetenz, die bisher vor allem Softwareentwicklern und Prozessberatern zugeschrieben wurde: die Fähigkeit, die eigene Arbeit zu abstrahieren und als System zu beschreiben.

Wer einen Skill für eine wiederkehrende Aufgabe schreibt, muss zunächst verstehen und artikulieren, wie diese Tätigkeit eigentlich funktioniert. Was sind die Schritte? Was sind die Qualitätskriterien? Wo liegen die typischen Fehlerquellen? Was muss in welcher Reihenfolge passieren, und was kann parallel laufen?

Das ist im Kern Systemdesign – nur dass das System nicht aus Code besteht, sondern aus sprachlichen Handlungsanweisungen. Und genau wie beim klassischen Systemdesign gilt: Der Wert liegt nicht nur in der Automatisierung selbst, sondern im Prozess der Abstraktion. Wer gezwungen ist, die eigene Arbeit so präzise zu beschreiben, dass ein Agent sie ausführen kann, versteht diese Arbeit anschließend besser.

Die Fähigkeit, die eigene Arbeit als kohärentes System zu beschreiben – als eine Reihe von Prozessen mit definierten Inputs, Outputs, Qualitätskriterien und Ausnahmebehandlungen –, wird von einer Spezialkompetenz zu einer Grundkompetenz. Nicht weil jeder zum Systemarchitekten werden muss, sondern weil die Werkzeuge, die diese Abstraktion umsetzen können, erstmals für jeden zugänglich sind.

Dabei ist es nicht einmal nötig, diese Abstraktion allein zu leisten. Dieselben Agenten, die einen Skill später ausführen, können beim Formulieren helfen – nicht indem sie die Arbeit beschreiben, die sie nicht kennen, sondern indem sie Lücken, Mehrdeutigkeiten und implizite Annahmen im Entwurf sichtbar machen. Der Wert liegt nicht in der Niederschrift, sondern in der Abstraktion: im Durchdenken der eigenen Arbeit bis zu dem Punkt, an dem sie sich als System beschreiben lässt.

Systemverständnis > Programmierkenntnis

„Arbeit als Kontext“ und „Arbeit als System“ sind nicht unabhängig voneinander. Zusammen beschreiben sie eine Verschiebung, die über die Softwareentwicklung hinausgeht und die Büroarbeit insgesamt betrifft: Wer die eigene Arbeit strukturiert als Kontext verfügbar macht und gleichzeitig lernt, Prozesse so zu beschreiben, dass Agenten sie ausführen können, verändert nicht ein Werkzeug, sondern die Arbeitsweise selbst.

Dass beides in derselben Sprache stattfindet – strukturierter Text, lesbar für Menschen und Maschinen –, ist dabei kein Zufall, sondern der Grund, warum diese Verschiebung jetzt passiert und nicht erst in zehn Jahren. Die Hürde liegt nicht mehr im Programmieren, sondern im Denken: im Verstehen der eigenen Arbeit als System, das sich beschreiben lässt. Und in der Unterscheidung, welche Arbeit sich sinnvoll automatisieren lässt – und welche nicht.