Vom Chatbot zum Agent Harness: Wie sich mein KI-Arbeitsplatz entwickelt hat

Ich habe mit GPT-3.5 in einem Browserfenster angefangen. Heute nutze ich KI-Systeme, die Repositories durchsuchen, Dateien verändern, Tests starten, Besprechungsnotizen strukturieren, Angebote vorbereiten und aus lose formulierten Ideen konkrete Aufgaben machen.

Zwischen diesen beiden Arbeitsweisen liegen nur wenige Jahre. Der entscheidende Fortschritt war für mich aber nicht einfach der Wechsel von einem Sprachmodell zum nächsten. Der eigentliche Sprung kam, als aus dem Modell ein Agent Harness wurde.

Damit meine ich eine Arbeitsumgebung, die dem Modell Kontext gibt, Werkzeuge bereitstellt, Aktionen ausführen lässt und Ergebnisse wieder überprüfbar macht. Erst dadurch wurde KI für mich vom interessanten Chatfenster zu einem täglichen Produktionswerkzeug.

Ich habe inzwischen mit mehreren dieser Umgebungen gearbeitet: GitHub Copilot, Cursor, Claude Code und Codex. Manche nutze ich nicht mehr, andere täglich, wieder andere gezielt für besonders schwierige Aufgaben. Dadurch habe ich vor allem gelernt, was man selbst tun muss, damit diese Werkzeuge produktiv werden.

Ein Sprachmodell erzeugt zunächst Text. Es kann erklären, zusammenfassen, Ideen entwickeln und Code vorschlagen. Das ist nützlich, aber es kennt damit noch nicht automatisch mein Projekt, meine Arbeitsweise oder das gewünschte Ergebnis. Es kann auch nicht von selbst prüfen, ob ein Vorschlag tatsächlich funktioniert.

Ein Agent Harness baut die Arbeitsumgebung um das Modell herum. In meiner praktischen Definition gehören fünf Dinge dazu: Kontext aus Dateien, Dokumentationen, Regeln und Entscheidungen; Werkzeuge wie Repositories, Terminals, Browser und Schnittstellen; die Ausführung von Änderungen innerhalb klarer Grenzen; Rückkopplung über Tests, Fehlermeldungen, Diffs und Reviews; sowie Leitplanken für Berechtigungen und Freigaben.

Anthropic verwendet den Begriff inzwischen selbst und beschreibt Claude Code als Agent Harness für langfristige, mehrstufige Aufgaben. Für mich ist der Begriff hilfreich, weil er den Blick vom Modell auf das gesamte Arbeitssystem lenkt. Quelle: Anthropic zu Claude Fable 5

Mein Einstieg war GPT-3.5 auf der OpenAI-Website. Wie vermutlich bei vielen anderen war es zunächst ein Chat: Frage eingeben, Antwort lesen, nachfragen, Text kopieren.

Das war beeindruckend, aber die Verantwortung für den gesamten Arbeitsprozess lag bei mir. Ich musste den benötigten Kontext auswählen und in den Chat einfügen, Antworten in meine Werkzeuge übertragen und selbst prüfen, ob sie fachlich richtig und praktisch nutzbar waren.

Trotzdem war diese Phase wichtig. Ich lernte, Aufgaben so zu formulieren, dass ein Sprachmodell damit arbeiten kann. Ich lernte auch sehr schnell, dass eine überzeugend klingende Antwort noch kein belastbares Ergebnis ist. Der Chat war ein guter Gesprächspartner. Er war noch kein integrierter Mitarbeiter in einem Arbeitsprozess.

Der nächste Schritt war GitHub Copilot. Zum ersten Mal musste ich den Kontext nicht vollständig aus meiner Entwicklungsumgebung in ein separates Chatfenster übertragen. Die KI erschien dort, wo der Code bereits entstand.

Copilot half mir vor allem dabei, schneller zu entwickeln. Vorschläge wurden direkt im Editor sichtbar, wiederkehrender Code ließ sich schneller schreiben und einzelne Fragen konnten im unmittelbaren Projektkontext geklärt werden. GitHub beschreibt Copilot als Coding-Assistenten, der unter anderem Codevorschläge liefert, Fragen beantwortet und Änderungen vorbereiten kann. Quelle: GitHub Docs

Für mich war damals vor allem die Integration entscheidend. Das Modell selbst war nicht mehr der einzige Wert. Die Position im Arbeitsablauf wurde mindestens genauso wichtig. Aber die grundlegende Arbeitsteilung blieb bestehen: Copilot schlug vor, ich setzte um und kontrollierte jeden Schritt.

Vor rund anderthalb Jahren ließ ich mir Cursor empfehlen. Anfangs war ich skeptisch. Schließlich hatte ich bereits einen Editor und einen KI-Assistenten. Warum also noch ein weiteres Werkzeug?

Die Antwort wurde schnell sichtbar. Cursor behandelte die KI nicht nur als Ergänzung für einzelne Codezeilen. Der Agent konnte größere Zusammenhänge im Repository erfassen, mehrere Dateien verändern und ganze Features auf Basis einer Aufgabenbeschreibung umsetzen. Quelle: Cursor Docs

Damit änderte sich auch meine Rolle. Ich schrieb weniger jede einzelne Zeile selbst. Dafür musste ich Anforderungen klarer formulieren, die Architektur im Blick behalten und die erzeugten Änderungen systematischer prüfen. Agentische Softwareentwicklung bedeutete nicht, weniger zu denken. Sie verschob das Denken von der manuellen Eingabe stärker in Richtung Spezifikation, Steuerung und Review.

Claude Code war das erste dieser Werkzeuge, das ich konsequent in der Kommandozeile nutzte. Dieser Wechsel wirkte zunächst unspektakulär, war für meinen Arbeitsprozess aber der nächste große Sprung.

Im Terminal konnte der Agent nicht nur Code lesen und verändern. Er konnte Befehle ausführen, Tests starten, Fehlermeldungen auswerten und anschließend weiterarbeiten. Anthropic beschreibt die CLI genau in diesem Sinne: Dateien bearbeiten, Kommandos ausführen und ein Projekt aus der Kommandozeile verwalten. Quelle: Claude Code Docs

Damit entstand ein Rückkopplungskreis: Aufgabe verstehen, Projekt untersuchen, Änderung planen und umsetzen, Tests ausführen, Fehler analysieren und das Ergebnis für mein Review vorbereiten. Dieser Ablauf ist deutlich wertvoller als ein einzelner guter Codevorschlag, weil der Agent die Folgen seiner eigenen Arbeit beobachten kann.

Gleichzeitig wurde mir besonders klar, wie wichtig Berechtigungen und Leitplanken sind. Ein Agent mit Terminalzugriff kann produktiver arbeiten. Er kann aber auch schneller falsche Annahmen in reale Änderungen übersetzen. Deshalb gehören kontrollierter Zugriff, kleine Arbeitspakete, Tests und ein abschließendes Review für mich immer zusammen.

Heute nutze ich Codex sowohl in der Kommandozeile als auch in der Desktop-App. Für mein persönliches Nutzungsprofil bietet mir Codex ein überzeugendes Preis-Leistungs-Verhältnis. Ausschlaggebend ist aber nicht nur der Preis.

Entscheidend ist, dass ich die Umgebung an meine tatsächliche Arbeit anpassen kann. OpenAI dokumentiert für Codex unter anderem Regeln über `AGENTS.md`, Skills, Plugins, MCP-Anbindungen, Terminalarbeit und lokale oder cloudbasierte Arbeitsumgebungen. Quelle: OpenAI Developers

In meinem Setup ist Codex mit einem nach dem Karpathy-Muster aufgebauten LLM-Wiki verbunden. Es ist kein loses Notizarchiv, sondern ein gepflegter Wissenskontext: Arbeitsprinzipien, Entscheidungen, Projektstände, Rollen und wiederkehrende Abläufe sind so strukturiert, dass der Agent sie bei einer Aufgabe gezielt berücksichtigen kann.

Das ist nicht nur für Entwickler relevant. Geschäftsführung und Führungskräfte können nach demselben Prinzip ein persönliches oder unternehmensweites Arbeitsgedächtnis aufbauen. Entscheidungen bleiben nachvollziehbar, Besprechungen führen schneller zu konkreten nächsten Schritten und wiederkehrende Managementaufgaben beginnen nicht jedes Mal bei null. Voraussetzung sind gepflegte Inhalte, klare Zugriffsrechte und eine fachliche Prüfung der Ergebnisse.

Skills bilden anschließend wiederkehrende Abläufe ab. Connectoren bringen den Agenten an die Orte, an denen die eigentliche Arbeit liegt. Das Wiki liefert den dauerhaften Kontext, während Skills und Connectoren daraus konkrete, überprüfbare Arbeitsschritte machen.

Dadurch nutze ich Codex längst nicht mehr nur zum Programmieren. Es hilft mir auch, Besprechungsnotizen zu strukturieren, Angebote vorzubereiten, aus groben Ideen konkrete Arbeitspakete zu entwickeln, Projektstände zusammenzufassen und wiederkehrende Abläufe über Skills zu standardisieren.

Der entscheidende Punkt ist nicht, dass Codex jede dieser Aufgaben ohne Prüfung erledigt. Der Wert entsteht dadurch, dass der Agent den nötigen Kontext und die passenden Werkzeuge in einer gemeinsamen Arbeitsumgebung erreicht. Ich muss nicht für jede Aufgabe wieder bei null anfangen.

Ein produktiver KI-Stack braucht für mich keinen einzelnen Gewinner. Codex ist mein täglicher Begleiter. Für besonders schwierige Aufgaben und komplexe Zusammenhänge greife ich weiterhin gezielt zu Claude Code, inzwischen auch mit Claude Fable 5.

Anthropic positioniert Fable 5 als sein leistungsfähigstes allgemein verfügbares Modell für anspruchsvolle, langfristige Coding- und Wissensarbeit. Das ist eine Herstellerangabe, kein unabhängiger Vergleich. Sie passt aber zu meiner eigenen Rollenverteilung: Ich setze das Modell dort ein, wo die zusätzliche Denktiefe für mich den höheren Aufwand rechtfertigt. Quelle: Anthropic

Diese Spezialisierung ist für mich sinnvoller als der Versuch, jedes Problem mit demselben Werkzeug zu lösen. Manche Aufgaben brauchen Geschwindigkeit und eine enge Integration in den täglichen Ablauf. Andere brauchen besonders viel Kontext, lange Denkwege oder eine zweite unabhängige Prüfung.

1. Kontext schlägt den perfekten Einzelprompt. Wenn ein Agent Projektregeln, Architekturentscheidungen und vorhandene Dokumentation kennt, muss ich weniger erklären und korrigieren. Ein LLM-Wiki, klare Repository-Regeln und aktuelle Spezifikationen sind deshalb Teil der Produktivitätsinfrastruktur.

2. Werkzeugzugriff verändert die Qualität der Arbeit. Ein Modell, das nur antwortet, kann einen plausiblen Vorschlag liefern. Ein Agent, der Dateien lesen, Befehle ausführen und das Ergebnis prüfen kann, erhält Rückmeldung aus der Realität. Das macht ihn nicht automatisch richtig, aber Fehler werden beobachtbarer und Korrekturschleifen kürzer.

3. Gute Spezifikation wird wichtiger, nicht unwichtiger. Je autonomer ein Agent arbeitet, desto teurer wird eine unklare Aufgabe. Ich investiere deshalb mehr Zeit in Ziel, Grenzen, Akzeptanzkriterien und Prüfverfahren. Bei klaren Spezifikationen ist oft zweitrangig, welches geeignete Harness die Umsetzung übernimmt.

4. Ausführung und Validierung gehören zusammen. Beim Coding sind das Tests, statische Prüfungen, Diffs und Reviews. Bei Angeboten oder Besprechungsnotizen sind es Quellen, bekannte Fakten, Vorlagen und meine fachliche Freigabe. Der genaue Prüfmechanismus unterscheidet sich, das Prinzip bleibt gleich.

5. Produktive Nutzung ist eine Betriebsdisziplin. Welche Daten darf der Agent sehen? Welche Werkzeuge darf er bedienen? Wann muss er fragen? Welche Aktionen benötigen eine Freigabe? Wie wird ein Ergebnis geprüft? Welches Wissen bleibt dauerhaft verfügbar? Hier trennt sich eine beeindruckende Demo von einem belastbaren Arbeitsprozess.

GPT-3.5 auf der OpenAI-Website war mein Einstieg in die Arbeit mit Sprachmodellen. GitHub Copilot brachte die KI direkt in den Editor und beschleunigte die Codeerstellung. Cursor war die prägende Zwischenstufe zur agentischen Umsetzung größerer Features.

Claude Code nutze ich heute gezielt für anspruchsvolle Aufgaben, lange Arbeitsketten, Terminalausführung und Tests. Codex ist mein anpassbares Harness mit Wiki, Skills und Integrationen und damit mein täglicher Begleiter für Entwicklung, Wissen und Projektarbeit. Claude Fable 5 in Claude Code gibt mir zusätzliche Kapazität für besonders komplexe Zusammenhänge.

Diese Aufteilung ist kein allgemeingültiges Ranking. Sie beschreibt meinen heutigen Arbeitsprozess. Andere Aufgaben, Sicherheitsanforderungen oder Unternehmensumgebungen können zu einer anderen Auswahl führen.

Mein heutiger KI-Stack ist leistungsfähig, hat aber noch eine praktische Grenze: Ein wesentlicher Teil des Harnesses läuft auf meinem lokalen Computer. Damit hängt seine Verfügbarkeit davon ab, ob dieses Gerät eingeschaltet, erreichbar und passend eingerichtet ist.

Als nächsten Schritt möchte ich das Harness deshalb auf einen VPS verlagern. Der Agent soll dauerhaft laufen und ortsunabhängig erreichbar sein. Aufgaben könnten dann weiterlaufen, ohne dass mein Laptop die zentrale Ausführungsumgebung bleiben muss. Gleichzeitig würden Wissen, Skills und wiederkehrende Abläufe an einem kontrollierten Ort zusammenkommen.

Für diesen Schritt möchte ich zwei Open-Source-Projekte evaluieren: Hermes Agent und OpenClaw. Hermes Agent dokumentiert unter anderem einen Betrieb auf einem VPS, persistentes Gedächtnis, Skills, MCP-Integration, geplante Automationen und verschiedene Kommunikationskanäle. Quelle: Hermes Agent Documentation

OpenClaw verfolgt über eine Gateway-Architektur einen ähnlichen Always-on-Gedanken. Das Gateway kann als dauerhaft laufender Dienst auf einem Cloud-Server oder VPS betrieben werden und Modelle, Werkzeuge, Skills, Plugins und Kommunikationskanäle verbinden. Quelle: OpenClaw, Quelle: OpenClaw auf einem VPS

Ich habe mich noch nicht für eines der beiden Systeme entschieden. Im Test interessieren mich vor allem Zuverlässigkeit, Pflege und Sicherung von Kontext und Gedächtnis, Schnittstellen, Isolation, Identitäten, Secrets, Protokollierung, Updates, Backups und ausdrückliche Freigaben für kritische Aktionen.

Ein dauerhaft erreichbarer Agent mit Zugriff auf Werkzeuge und Schnittstellen ist produktiver als ein isolierter Chat. Er vergrößert aber auch die Angriffsfläche und den möglichen Schaden einer falschen Aktion. Das Ziel ist deshalb nicht maximale Autonomie, sondern ein ortsunabhängiger Arbeitsprozess, der verfügbar bleibt, ohne Kontrolle und Prüfbarkeit aufzugeben.

Mein heutiger KI-Arbeitsplatz ist bewusst zusammengestellt. Ich habe das LLM-Wiki, die Skills, die Integrationen und die Rollen der einzelnen Werkzeuge schrittweise an meine Arbeit angepasst. Microsoft Copilot verspricht einen anderen Weg: Das Harness entsteht nicht individuell aus verschiedenen Werkzeugen, sondern soll bereits innerhalb einer weit verbreiteten Arbeitsumgebung verfügbar sein.

Microsoft beschreibt Microsoft 365 Copilot als KI-Werkzeug, das in Anwendungen wie Word, Outlook und Teams arbeitet und dabei Inhalte aus dem Arbeitskontext verwenden kann, auf die der jeweilige Nutzer zugreifen darf. Agenten und Connectoren können Copilot zusätzlich mit Wissen, Werkzeugen und anderen Systemen verbinden. Quelle: Microsoft 365 Copilot Overview, Quelle: Microsoft 365 Copilot Erweiterbarkeit

Deshalb prüfe ich Copilot entlang derselben fünf Fragen: Findet er im Arbeitskontext die relevanten Informationen? Reduziert der Werkzeugzugriff die Reibung zwischen Frage und Ergebnis? Welche Aufgaben kann er verlässlich ausführen? Lassen sich Ergebnisse nachvollziehen und verbessern? Sind Berechtigungen, Datenquellen und Verantwortlichkeiten klar?

Ich starte diesen Test nicht bei der Frage, ob generative KI grundsätzlich nützlich sein kann. Ich kenne die Produktivität gut gebauter Agent Harnesses aus meiner täglichen Arbeit. Mich interessiert, ob Microsoft diese Qualität in eine standardisierte Unternehmensumgebung übersetzen kann und welche Voraussetzungen dafür erfüllt sein müssen.

Der Copilot-Test ist damit kein losgelöster Produkttest. Er ist die nächste Stufe derselben Untersuchung: Was braucht ein KI-Agent, damit er im echten Arbeitsalltag mehr ist als ein beeindruckender Chat? Mehr zum Produktaufbau steht in meinem Überblick Was ist Microsoft Copilot?

Unternehmen sollten beim Einstieg in agentische KI nicht nur fragen, welches Modell in einem Benchmark vorne liegt. Wichtiger ist, wie das gesamte Arbeitssystem gestaltet wird.

Ein produktiver Agent braucht eine klar abgegrenzte Aufgabe, verlässlichen Kontext, passende Zugriffsrechte, kontrollierbare Werkzeuge und eine fachliche Prüfung. Fehlt einer dieser Bausteine, bleibt entweder viel Potenzial ungenutzt oder die Automatisierung erzeugt neue Risiken.

Mein eigener Weg von GPT-3.5 über GitHub Copilot, Cursor und Claude Code bis Codex hat mir vor allem eines gezeigt: Erfahrung mit KI-Agenten bedeutet nicht, möglichst viele Tools ausprobiert zu haben. Sie zeigt sich darin, aus Modellen einen wiederholbaren, überprüfbaren und wirtschaftlich sinnvollen Arbeitsprozess zu bauen.

Wer prüfen möchte, wie sich ein solches LLM-Wiki und ein Agent Harness auf Führungs-, Projekt- oder Wissensarbeit übertragen lassen, kann im kostenlosen Potenzial-Check einen konkreten Arbeitsablauf gemeinsam mit mir einordnen.