Wenn ich über KI-Agenten spreche, meine ich nicht einfach einen etwas besseren Chatbot. Ich meine eine neue Architekturklasse: Software, die ein Ziel bekommt, Zwischenschritte plant, Werkzeuge nutzt, Informationen aus Systemen holt, Ergebnisse prüft und an den richtigen Stellen wieder einen Menschen einbindet.
Der Begriff wird im Moment sehr breit verwendet. Manchmal wird schon ein normaler Chatbot als Agent bezeichnet, nur weil ein großes Sprachmodell dahintersteht. Das greift aus meiner Sicht zu kurz. Ein Agent entsteht erst dort, wo ein Modell nicht nur antwortet, sondern in einer kontrollierten Umgebung handeln darf.
Vom Chatbot zum Agenten
Ein klassischer Chatbot reagiert auf eine Eingabe. Er kann gut formulieren, zusammenfassen, erklären oder Fragen beantworten. Das ist nützlich, bleibt aber meist innerhalb der Konversation. Der Nutzer stellt eine Frage, der Bot antwortet. Danach beginnt der nächste Schritt wieder beim Menschen.
Ein KI-Agent arbeitet anders. Er bekommt ein Ziel und zerlegt dieses Ziel in Schritte. Er kann Werkzeuge aufrufen, Dateien durchsuchen, APIs verwenden, Code ausführen, Ergebnisse vergleichen, Rückfragen stellen und seine nächsten Aktionen anpassen. Bei anspruchsvollen Aufgaben ist genau diese Schleife entscheidend: wahrnehmen, planen, handeln, prüfen, korrigieren.
Was einen KI-Agenten ausmacht
Für mich besteht ein KI-Agent aus fünf Bausteinen. Erstens braucht er ein Ziel oder eine Aufgabe. Zweitens braucht er Kontext: Daten, Dokumente, Systemzustand, Regeln und Rollen. Drittens braucht er Werkzeuge, sonst bleibt er beim Text stehen. Viertens braucht er Gedächtnis oder zumindest nachvollziehbaren Zustand über mehrere Schritte. Und fünftens braucht er Leitplanken: Berechtigungen, Protokollierung, Qualitätskontrolle und Freigaben.
Das ist auch der Punkt, an dem Architektur wichtiger wird als Demo-Charme. Ein Agent, der Zugriff auf Unternehmensdaten, Kundensysteme oder Quellcode bekommt, darf nicht einfach frei improvisieren. Er braucht Identitäten, Rollen, Audit-Trails, sichere Tool-Aufrufe, Fehlerbehandlung und klare Grenzen.
Ein abstraktes Beispiel mit Microsoft, OpenAI und Devin
Ein realistisches Beispiel könnte ein interner Agent für technische Änderungsanforderungen sein. Ein Fachbereich beschreibt in Microsoft Teams oder Microsoft 365 Copilot eine gewünschte Änderung: etwa einen neuen Report, eine Anpassung an einer Schnittstelle oder eine kleine Erweiterung in einer internen Anwendung.
Auf der Microsoft-Seite würde ich den Agenten nah an den vorhandenen Arbeitskontext setzen: Microsoft 365 Copilot oder Copilot Studio als Einstiegspunkt, Entra ID für Identität und Berechtigungen, SharePoint oder andere Microsoft-365-Inhalte als Wissensbasis und Power Platform oder eigene APIs für Aktionen. Microsoft beschreibt dafür unter anderem Agent Builder, deklarative Agenten und Copilot-Studio-Agenten als Wege, Agenten mit Wissen, Aktionen und Unternehmenskontext auszustatten.
OpenAI würde ich in diesem Bild als Modell- und Orchestrierungsschicht verstehen. Die Responses API und die Agents SDKs sind darauf ausgelegt, Modellaufrufe mit Werkzeugen, Zuständen, Handoffs, Guardrails und Tracing zu verbinden. Dort liegt der Teil, der aus einer Anfrage einen planbaren Ablauf macht: Informationen beschaffen, strukturierte Zwischenergebnisse erzeugen, Tools aufrufen, Rückfragen formulieren und Entscheidungen nachvollziehbar machen.
Cognition Devin wäre in diesem Szenario kein allgemeiner Chatbot, sondern ein spezialisierter Engineering-Agent. Wenn aus der Anforderung tatsächlich Codearbeit entsteht, kann ein Agent wie Devin eine Aufgabe planen, im Codebestand arbeiten, Tests ausführen, Änderungen vorbereiten und einen Pull Request liefern. Der Mensch bleibt dabei nicht außen vor: Architekturentscheidung, Review, Freigabe und Verantwortung bleiben beim Team.
Der eigentliche Nutzen liegt im Zusammenspiel
Der interessante Teil ist nicht, ob ein einzelnes Modell eine beeindruckende Antwort erzeugt. Interessant wird es, wenn mehrere Fähigkeiten sauber zusammenspielen: Microsoft bringt den Arbeitskontext und die Unternehmensintegration, OpenAI liefert Modell- und Agentenbausteine, Devin übernimmt spezialisierte Softwareaufgaben, und die Architektur sorgt dafür, dass daraus ein belastbarer Prozess wird.
Ein solcher Agent könnte eine Anfrage aufnehmen, die betroffenen Systeme identifizieren, vorhandene Dokumentation lesen, Akzeptanzkriterien vorschlagen, Risiken markieren, einen technischen Lösungsweg entwerfen, eine Umsetzung vorbereiten und anschließend Review-Schritte anstoßen. Nicht alles davon muss vollautomatisch passieren. Im Gegenteil: Die wichtigsten Agenten werden wahrscheinlich dort stark sein, wo Automatisierung und menschliche Entscheidung sauber ineinandergreifen.
Vom Ziel zum überprüften Ergebnis: ein Beispiel
Angenommen, ein interner Agent soll eine technische Änderungsanfrage vorbereiten. Das folgende Beispiel ist ein Architekturentwurf, kein Bericht über ein Kundenprojekt. Das gewünschte Ergebnis ist ein prüfbarer Umsetzungsvorschlag; eine produktive Änderung gehört nicht zum Auftrag.
- Auftrag eingrenzen: Welche Anwendung ist betroffen? Welches Verhalten soll sich ändern? Fehlen diese Angaben, stellt der Agent eine Rückfrage.
- Kontext lesen: Er sucht die betroffene Schnittstelle, Architekturentscheidungen und vorhandene Tests. Quellen und Annahmen bleiben erkennbar.
- Werkzeuge nutzen: Lesender Zugriff auf Repository und Tickets genügt zunächst. Ein Schreibrecht oder Produktionszugang ergibt sich nicht aus dem Auftrag.
- Ergebnis prüfen: Der Vorschlag nennt betroffene Komponenten, Akzeptanzkriterien, offene Fragen und Risiken. Ein Mensch entscheidet über die Umsetzung.
Wann genügt ein fester Workflow?
Wenn alle Schritte bereits feststehen, etwa bei einer bekannten Datenprüfung mit anschließendem Bericht, ist ein deterministischer Workflow oft einfacher zu testen. Ein Agent wird interessant, wenn erst Zwischenergebnisse bestimmen, welche Quelle oder welches Werkzeug als Nächstes gebraucht wird. Anthropic unterscheidet entsprechend zwischen vorgegebenen Workflows und modellgesteuerten Agenten.
Der technische Kern ist eine begrenzte Agentenschleife. Wie Werkzeuge angeschlossen werden können, erklärt der Beitrag zum Model Context Protocol.
Warum ich das wichtig finde
KI-Agenten sind für mich keine Magie und kein Ersatz für Architektur. Sie erhöhen vielmehr den Bedarf an Architektur. Je mehr ein System handeln darf, desto klarer müssen Rollen, Datenflüsse, Grenzen, Verantwortlichkeiten und Qualitätskriterien sein.
Ein normaler Chatbot kann schon viel helfen. Ein gut gebauter KI-Agent kann aber Arbeitsprozesse verändern: nicht, weil er alles allein macht, sondern weil er Routine, Recherche, Vorbereitung, technische Ausführung und Dokumentation so verbindet, dass Menschen bessere Entscheidungen schneller treffen können.
Genau deshalb beschäftige ich mich mit diesem Thema: KI-Agenten sind dort spannend, wo Cloud-Architektur, Softwareentwicklung, Unternehmensdaten und pragmatische Automatisierung zusammenkommen. Nicht als Selbstzweck, sondern als Baustein für digitale Lösungen mit Wirkung.
Weiterführende Quellen
- Anthropic: Building effective agents – Workflows und Agenten unterscheiden
- Microsoft Learn: Agent Builder in Microsoft 365 Copilot zur Erstellung deklarativer Agenten in Microsoft 365.
- Microsoft Learn: Declarative agents for Microsoft 365 Copilot zu Anweisungen, Aktionen und Wissen als Agentenbausteinen.
- Microsoft Learn: Copilot Studio overview zu Agenten, Themen, generativen Antworten und Veröffentlichung.
- OpenAI: Agents SDK für codebasierte Agenten mit Tools, Orchestrierung, Handoffs und Zustand.
- OpenAI: Responses API als agentische API-Oberfläche mit Tool-Nutzung und zustandsnahen Abläufen.
- Cognition: Introducing Devin als Beispiel für einen spezialisierten Software-Engineering-Agenten.
- Cognition: Devin is Getting a Windows PC zur Weiterentwicklung von Devin als Cloud-Agent für Build-, Test- und Codeaufgaben.