Was ist ein AI Agent? Überall hört man, dass man sie braucht und dass AI-Agents die Zukunft sind. Doch woraus besteht ein AI-Agent und wie entscheidest du, ob dein Unternehmen einen braucht? Wir haben in den letzten Monaten viele Gespräche geführt, in denen Agents einfach für einen Chatbot mit besserem Prompt stand. Schade, denn das ist es nicht. Der Unterschied ist technisch klein und organisatorisch riesig. In unserer dreiteiligen Blogserie gehen wir auf AI-Agents genauer ein. Nach diesem ersten Teil weisst du, welche Bausteine ein Agent hat, welche vier Muster der Zusammenarbeit es gibt und mit welchem ersten Anwendungsfall du anfangen kannst.
Ein AI-Agent ist eine Software, die ein Ziel bekommt und den Weg dorthin selbst festlegt. Sie zerlegt die Aufgabe, ruft Werkzeuge auf, sieht sich das Ergebnis an und korrigiert sich, wenn etwas nicht passt. Erst wenn das Ziel erreicht ist oder sie nicht weiterkommt, meldet sie sich zurück. Der Unterschied zu allem, was wir vorher hatten, steckt in einem Wort: Loop. Ein Chatbot antwortet einmal. Ein Agent arbeitet, prüft sich und arbeitet weiter. Deshalb kann er eine Aufgabe erledigen und nicht nur eine Frage beantworten.
Die Stufen können wir folgt beschrieben werden
Stufe 1 Chatbot: Agent kennt nur, was im Modell steckt und was du hineinschreibst. Nützlich zum Formulieren, blind für dein Unternehmen.
Stufe Assistent: Er sieht deine E-Mails, Dateien und Termine. Er formuliert, fasst zusammen, schlägt vor. Ausführen musst du selbst.
Stufe Agent: Er darf handeln. Er liest ein Ticket, sucht im Dokumentenspeicher, legt eine Antwort an, aktualisiert das System.
Stufe Agenten-Team: Mehrere Agenten arbeiten zusammen. Einer recherchiert, einer schreibt, einer prüft. Sie geben sich Zwischenergebnisse und eskalieren an dich, wenn etwas unklar ist.
Hinweis: Die meisten Unternehmen sind heute auf Stufe 2 und glauben, sie wären auf Stufe 3. Wenn ein Mensch jedes Ergebnis abschreibt oder per Copy-Paste ins nächste System trägt, ist das Stufe 2.
Wenn wir Agenten bauen, sind es immer die gleichen sechs Bausteine. Das ist unabhängig davon, ob du Copilot Studio, Microsoft Foundry oder eine eigene Plattform nutzt.
Am besten sieht man den Unterschied an einem echten Ablauf. Nehmen wir ein Support-Ticket: «Outlook startet nach dem Update nicht mehr, ich komme an keine E-Mails.» So arbeitet ein Agent das ab:
Verstehen: Er liest das Ticket, erkennt den Gerätenamen und den Nutzer und stellt fest, dass Informationen fehlen: Welches Update? Welche Outlook-Version?
Planen: Er legt eine Reihenfolge fest: Gerät im Endpoint-Management nachsehen, Update-Historie prüfen, in der Wissensdatenbank nach bekannten Fällen suchen.
Werkzeuge aufrufen: Er fragt das Gerät ab, holt die installierten Updates und sucht parallel in den Dokumenten nach demselben Fehlerbild.
Prüfen: Die Suche liefert drei Treffer, zwei passen nicht zur Version. Also verwirft er sie – das ist der Teil, den ein reiner Chatbot nicht kann.
Handeln oder eskalieren: Passt ein bekannter Fall, schreibt er die Lösung ins Ticket und setzt es auf «warten auf Rückmeldung». Passt keiner, eskaliert er mit einer Zusammenfassung dessen, was er schon geprüft hat.
Der Wert liegt in Schritt 4 und 5. Ein Assistent hätte in Schritt 3 aufgehört und dir drei Links gezeigt. Ein Agent bewertet und entscheidet, ob er weiterarbeiten kann. Und in Schritt 5 steckt die wichtigste Design-Entscheidung: Was darf er selbst tun, und wo geht die Aufgabe an einen Menschen?
Hinweis: Achte darauf, dass ein Agent bei der Eskalation immer mitgibt, was er bereits geprüft hat. Sonst fängt der Mensch von vorne an und die Zeitersparnis ist weg. Das ist eine Formulierungsfrage im Auftrag, keine Frage des Modells.
Werkzeuge geben einem Agenten Zugriff. Aber Zugriff ist nicht Können. Ein Agent mit Zugriff auf Word weiss nicht, wie ein Angebot bei euch aussieht. Genau diese Lücke füllen Skills. Und sie sind die am meisten unterschätzte Neuerung des letzten Jahres. Ein Skill ist erst mal unspektakulär: ein Ordner mit einer Datei namens SKILL.md. Darin steht in normaler Sprache, wie eine bestimmte Aufgabe erledigt wird. Daneben liegen optional Skripte, Vorlagen und Referenzdokumente. Anthropic hat das Konzept im Oktober 2025 eingeführt und im Dezember 2025 als offenen Standard veröffentlicht. Inzwischen unterstützen laut dem offiziellen Verzeichnis rund vierzig Produkte dasselbe Format – unter anderem OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI und VS Code. Ein Skill, den du einmal schreibst, funktioniert also in mehreren Werkzeugen.
Der eigentliche Clou ist, wie sie geladen werden.
Entdecken: Beim Start liest der Agent nur Name und Beschreibung jedes Skills. Das kostet ungefähr 80 Token pro Skill.
Aktivieren: Passt der Skill zur Aufgabe, liest er die vollständige SKILL.md. Erst hier wird es teuer.
Ausführen: Er folgt der Anleitung und nutzt die mitgelieferten Skripte und Vorlagen.
Der Effekt ist enorm: Ein Agent kann Dutzende Skills kennen und dabei weniger Kontext verbrauchen als ein einziger vollständig geladener Skill. Das löst ein Problem, das vorher kaum lösbar war, nämlich einem Agenten viel unternehmensspezifisches Wissen mitzugeben, ohne seinen Kontext zu überladen. Für Unternehmen ist der praktische Wert noch grösser als der technische. Ein Skill ist die erste Artefaktform, in der du Prozesswissen so aufschreiben kannst, dass sowohl Menschen als auch Agenten es benutzen. Er liegt in der Versionsverwaltung, er lässt sich reviewen, er hat einen Besitzer. Wenn du heute ein Agentenprojekt startest, frag dich früh: Welche fünf Skills brauchen wir, und wer im Fachbereich schreibt sie?
Hinweis: Schreibe Skills wie eine gute Arbeitsanweisung für einen neuen Kollegen. Wann greift sie, welche Schritte in welcher Reihenfolge, was ist verboten. Die Beschreibung im Kopf der Datei ist das Wichtigste. Daran entscheidet der Agent überhaupt, ob er den Skill liest.
«Werkzeuge» ist ein Sammelbegriff, und die Unterschiede darin sind entscheidend. Ein Agent kann auf vier verschiedene Arten handeln, und in einem guten Aufbau kombiniert er sie.
Hier bewusst deutlich, weil es viel Enttäuschung erspart:
Ein AI-Agent ist kein Ersatz für einen sauberen Prozess. Wenn dein Prozess kaputt ist, automatisierst du das Chaos.
Ein AI-Agent ist die falsche Wahl für Aufgaben mit festen Regeln. Eine Freigabe nach vier festen Kriterien gehört in eine Automatisierung, nicht in ein Sprachmodell.
Ein AI-Agent ist kein Ersatz für gute Daten. Er kann nur finden, was auffindbar und berechtigt zugänglich ist.
Ein AI-Agent ist kein Personalabbauprogramm. Die Fälle, die funktionieren, geben Zeit zurück – sie ersetzen keine Rollen.
Bis hierhin war es Technik. Jetzt der Teil, der die Entscheidung trägt. Microsoft hat für den Work Trend Index 2026 rund 20.000 Wissensarbeiter in zehn Ländern befragt und dazu anonymisierte Nutzungssignale aus Microsoft 365 ausgewertet. Drei Zahlen sind wirklich relevant:
15-fach so stark ist die Zahl aktiver Agenten im Jahresvergleich gewachsen – in grossen Unternehmen sogar 18-fach.
46% so viele Führungskräfte sagen, ihre Organisation nutze AI-Agenten, um ganze Arbeitsabläufe oder Geschäftsprozesse zu automatisieren.
71% so viele Mitarbeitende in sogenannten Frontier Firms sagen, ihr Unternehmen sei erfolgreich gegenüber 37% im globalen Durchschnitt.
Die Zahl, die uns am meisten überzeugt hat, ist eine andere: Laut dem Bericht erklären organisatorische Faktoren rund 67% der Wirkung von KI, individuelle nur etwa 32%. Vereinfacht gesagt: Es entscheidet nicht, wie geschickt einzelne Leute prompten. Es entscheidet, ob das Unternehmen Arbeit umbaut. Und gleichzeitig sagen nur 26% der Führungskräfte, ihre Organisation habe eine klar ausgerichtete KI-Strategie. Da liegt der Vorsprung, den man gerade holen kann.
Hinweis: Der Begriff Frontier Firm kommt aus dem Work Trend Index. Gemeint ist ein Unternehmen, das Intelligenz auf Abruf einkauft, in Mensch-Agenten-Teams arbeitet und eine neue Rolle etabliert: den Agent Boss – einen Menschen, der Agenten baut, beauftragt und führt.
Der Bericht 2026 beschreibt vier Muster, wie Menschen und Agenten zusammenarbeiten.
Der Sprung von Editor zu Director ist der eigentliche Schritt. Er ist keine Technikfrage, sondern eine Vertrauens- und Governance-Frage: Du übergibst eine ganze Aufgabe, nicht mehr einen Entwurf. Dafür brauchst du Protokolle, Rechte und einen definierten Eskalationsweg, sonst wird aus Delegation Kontrollverlust.
Drei Kriterien: Passiert es oft? Sind die Daten an einem Ort, auf den ich berechtigt zugreifen kann? Und ist ein Fehler bemerkbar und korrigierbar, bevor er wehtut? Wenn eine Antwort Nein ist, ist es kein guter erster Fall.
«Spart Zeit» überlebt keine Budgetrunde. Deshalb vor dem Bauen rechnen und zwar bewusst konservativ. Beispiel Ticket-Triage in einem Service Desk mit 60 Tickets am Tag: Heute braucht das Vorsortieren und Anreichern eines Tickets rund vier Minuten. Das sind vier Stunden pro Tag. Der Agent bearbeitet realistisch 60% der Tickets vollständig vor, bei 15% liegt er falsch und ein Mensch korrigiert. Netto bleiben rund zwei Stunden pro Tag – nicht vier. Die Korrekturen kosten Zeit und sollten eingerechnet werden. Dagegen stehen Modell- und Plattformkosten sowie einmalig der Aufbau. Wenn sich das in unter sechs Monaten nicht trägt, ist es der falsche erste Fall. Diese Rechnung ist nicht schön, aber sie ist verteidigbar. Und sie führt fast immer dazu, dass man den Anwendungsfall enger schneidet. Was gut ist, weil enge Agenten besser funktionieren.
Inventar: Welche Agenten laufen schon in deinem Tenant? Die Antwort ist fast immer «mehr als gedacht». Denk daran: Ohne Registry keine Governance.
Identität: Bekommt jeder Agent eine eigene Identität mit eigenem Rechte-Set? Wenn nein, ändere das, bevor du produktiv gehst.
Datenklassen: Welche Daten darf ein Agent sehen, welche nie? Das ist eine Entscheidung des Fachbereichs, nicht der IT.
Messung: Woran erkennst du in acht Wochen, dass es funktioniert hat? Wenn du das jetzt nicht sagen kannst, wirst du es später auch nicht können.
Mit dem spannendsten Fall statt dem nützlichsten anfangen. Der spannendste Fall ist meist der, bei dem alles fehlt: Daten, Rechte, Prozess.
Ohne Rückweg bauen. Jede Aktion braucht einen Weg zurück – ein Ticket wieder öffnen, eine E-Mail als Entwurf, statt gesendet. Ohne Rückweg wird aus jedem Fehler ein Vorfall.
Auf einer unaufgeräumten Wissensbasis starten. Wenn zwei Dokumente sich widersprechen, widerspricht sich auch der Agent. Und du suchst den Fehler im Modell, obwohl er im Ordner liegt.
Kein Budgetlimit setzen. Agenten laufen im Hintergrund, und Verbrauchsmodelle merken sich nicht, dass du sparen wolltest.
Ein AI-Agent ist kein besserer Chatbot, sondern ein Akteur mit Auftrag, Werkzeugen und Identität. Ob dein Unternehmen einen braucht, entscheidet nicht die Technik, sondern die Frage, ob es wiederkehrende Arbeit gibt, deren Daten erreichbar sind und bei dem du Fehler früh siehst. Wenn ja, fang mit genau einem solchen Fall an, gib dem Agenten eine eigene Identität und miss das Ergebnis.
Ein Chatbot antwortet einmal auf eine Frage. Ein Agent bekommt ein Ziel, plant den Weg selbst, ruft Werkzeuge auf, prüft das Ergebnis und arbeitet weiter, bis die Aufgabe erledigt ist oder er nicht weiterkommt. Der Unterschied ist dieser Prüf- und Korrekturschritt.
Vier Dinge:
ein Inventar darüber, welche Agenten überhaupt laufen,
eine eigene Identität mit eigenen Rechten pro Agent,
eine Entscheidung des Fachbereichs, welche Daten ein Agent sehen darf,
und einen Messpunkt, an dem du nach acht Wochen erkennst, ob es funktioniert hat.
Mit einem, der oft vorkommt, dessen Daten an einem erreichbaren Ort liegen und bei dem ein Fehler bemerkbar und korrigierbar ist. In der Praxis sind das meistens Ticket-Triage, das Vorbereiten von Angeboten oder Recherche und Zusammenfassung.
Die Frage ist weniger die Lizenz als der Verbrauch: Ein Agent, der stündlich im Hintergrund läuft, kostet deutlich mehr als einer, der auf Klick arbeitet. Rechne konservativ mit Korrekturaufwand und setze ein Budgetlimit für deine Gesamtkosten (nicht jedoch für Tokens pro Session), bevor der erste Agent produktiv geht.