Agenten – die virtuellen Mitarbeiter

KI-Agenten brauchen Führung: klare Aufträge, begrenzte Befugnisse und geprüfte Releases. Wie Unternehmen virtuelle Mitarbeiter produktiv einsetzen.

Von Christian Fehrlin

Montagmorgen. Eine Teamleiterin öffnet die Übersicht ihrer Abteilung. Über Nacht hat ein Agent Liefertermine abgeglichen, ein zweiter Rückfragen vorbereitet, ein dritter offene Belege sortiert. Vieles ist fertig. Drei Vorgänge warten auf eine Entscheidung. Bei einem vierten steht: «Auftrag gestoppt. Berechtigung reicht nicht aus.»

Das klingt unspektakulär. Genau darin liegt der Fortschritt. Die Arbeit ist sichtbar, die Grenzen sind sichtbar, die Verantwortung ist sichtbar. Die Teamleiterin muss keine zwanzig Chatverläufe durchsuchen, um zu verstehen, was geschehen ist.

Diese Szene ist ein bewusst fiktives Zielbild. Sie zeigt, worum es bei der nächsten Stufe der Automatisierung geht: Unternehmen erhalten zusätzliche Ausführungskapazität. Damit entsteht eine Führungsaufgabe. Wer Agenten als virtuelle Mitarbeiter einsetzen will, muss ihnen einen Platz in der Organisation geben.

Meine These lautet: Der Wert eines Agenten entsteht aus einem guten Auftrag, überprüfbarer Arbeit und klarer Verantwortung. Die Qualität des Modells ist dafür eine Voraussetzung. Den Rest muss die Organisation gestalten.

Der virtuelle Mitarbeiter hat keinen gesunden Menschenverstand auf Abruf

Die Mitarbeiter-Metapher ist nützlich, weil sie die richtigen Fragen auslöst. Welche Aufgabe hat der Agent? Wem berichtet er? Was darf er entscheiden? Wann muss er nachfragen? Sie wird gefährlich, sobald wir daraus menschliches Urteilsvermögen, Loyalität oder Verantwortungsfähigkeit ableiten.

Ein Agent ist ein Softwaresystem. Ein Sprachmodell kann innerhalb einer vorgegebenen Umgebung Schritte auswählen, Werkzeuge aufrufen und auf Ergebnisse reagieren. Ein klassischer Workflow folgt stärker einem vorab festgelegten Ablauf. Diese begriffliche Unterscheidung beschreibt Anthropic in «Building effective agents». Für einen stabilen, vollständig beschreibbaren Prozess kann ein Workflow weiterhin die bessere Wahl sein.

Ein Agent kann einen plausiblen nächsten Schritt wählen und trotzdem einen wichtigen Zusammenhang übersehen. Er besitzt keine Verantwortung für den wirtschaftlichen Schaden einer falschen Zusage. Diese Verantwortung verbleibt bei den Menschen, die seinen Einsatz beschliessen, seine Befugnisse festlegen und seinen Betrieb führen.

Deshalb würde ich einen Agenten nicht mit «Kümmere dich um den Einkauf» starten lassen. Das ist keine brauchbare Delegation. Es ist eine offene Flanke mit einer freundlich formulierten Arbeitsanweisung.

Geben Sie dem Agenten eine Aufgabe, die einen Abschluss hat

Bleiben wir bei einem fiktiven mittelgrossen Unternehmen. Eine Mitarbeiterin prüft täglich, welche Lieferungen für offene Kundenaufträge gefährdet sind. Dafür verbindet sie Bestellungen, bestätigte Termine und Rückmeldungen der Lieferanten. Ein Agent soll einen Teil dieser Vorbereitung übernehmen.

Ein brauchbarer Auftrag könnte lauten: «Prüfe bis acht Uhr alle offenen Bestellpositionen mit Liefertermin in den nächsten sieben Tagen. Vergleiche den bestätigten Termin mit der letzten freigegebenen Lieferantenmeldung. Erstelle bei Abweichungen einen Klärungsfall mit Quelle, betroffenen Aufträgen und Handlungsvorschlag. Verändere keine Termine und versende keine Nachricht.»

Dieser Auftrag definiert Gegenstand, Zeitraum, Quellen, Ergebnis und Grenze. Vor allem beschreibt er, wann die Aufgabe beendet ist: Die relevanten Positionen wurden geprüft, Abweichungen nachvollziehbar dokumentiert, unprüfbare Positionen ausdrücklich ausgewiesen. Ein leerer Bericht darf nicht automatisch «keine Probleme» bedeuten. Vielleicht war die Schnittstelle nicht erreichbar.

Für den ersten Agenten würde ich ein kurzes Mandat verlangen, das Fachbereich und IT gemeinsam verstehen:

Das Mandat gehört in die technische Umsetzung. Schreibrechte werden tatsächlich entzogen, Kosten begrenzt und erlaubte Werkzeuge eingeschränkt. Ein Verbot im Prompt allein ersetzt diese Kontrollen nicht.

Ein Agent braucht einen Vorgesetzten mit Zeit im Kalender

Ein «Owner» in einer Tabelle reicht nicht. Jemand muss schlechte Ergebnisse anschauen, offene Ausnahmen entscheiden und den Auftrag weiterentwickeln. Diese Arbeit braucht Kapazität. Sonst bleibt die Verantwortung auf dem Papier, während sich im Alltag die unerledigten Fälle sammeln.

Im Beispiel führt die Disposition den Agenten fachlich: Welche Abweichung ist relevant? Welche Rückfrage wäre hilfreich? Die technische Betriebsverantwortung liegt bei einem Team, das Zugriffe, Ausfälle und Versionen beherrscht. Die Freigabe einer grösseren Handlungskompetenz erfolgt durch die dafür verantwortliche Führungsperson. Das können in einem kleinen Unternehmen wenige Menschen mit mehreren Rollen sein. Die Entscheidungen müssen trotzdem auseinanderzuhalten sein.

Auch die Mitarbeitenden brauchen Klarheit. Wer übernimmt einen eskalierten Fall? Welche Vorarbeit darf als geprüft gelten? Wie wird eine falsche Empfehlung gemeldet? Ein Agent, der Arbeit abgibt, ohne Empfänger und Rückweg zu kennen, erzeugt eine neue Warteschlange.

Die wöchentliche Führungsfrage lautet deshalb: Wo hat dieser Agent Arbeit tatsächlich abgeschlossen, wo hat er sie nur weitergereicht, und wo hat er zusätzliche Arbeit verursacht? Die Antwort ist aufschlussreicher als die Zahl seiner Nachrichten.

Der Wildwuchs beginnt mit einer guten Absicht

Die Disposition ist zufrieden. Der Vertrieb kopiert den Agenten, ergänzt eine andere Terminregel und erlaubt Antwortentwürfe. Ein drittes Team verbindet seine Kopie mit einem Postfach. Wenige Wochen später tragen drei Systeme fast denselben Namen, verwenden unterschiedliche Wissensstände und handeln nach verschiedenen Regeln.

Niemand hat diesen Zustand geplant. Jeder wollte eine kleine Verbesserung. Genau deshalb braucht die Organisation einen einfachen Weg vom Experiment zum verantworteten Betrieb.

Ein zentral auffindbares Agentenregister sollte zeigen: Zweck, fachlich verantwortliche Person, technische Betreuung, aktuelle Version, Datenquellen, Werkzeuge, Befugnisse, Kostenstelle, Nutzerkreis und Abschaltdatum beziehungsweise nächsten Überprüfungstermin. Ebenso wichtig ist der Status: Experiment, Test, begrenzter Pilot, produktiver Betrieb oder stillgelegt. Ein Experiment darf nicht unbemerkt zum geschäftskritischen Dienst werden.

Das ist anschlussfähig an das NIST AI RMF Playbook, Funktion Govern: Es behandelt unter anderem Inventare von KI-Systemen, Zuständigkeiten und Änderungsmanagement. Unser konkretes Agentenregister ist ein Gestaltungsvorschlag, keine Behauptung, dass NIST genau dieses Formular verlangt.

Der produktive Standard sollte leicht benutzbar sein: vorbereitete Zugriffe, nachvollziehbare Protokolle und ein überschaubarer Freigabeweg. Wenn der offizielle Weg jede kleine Verbesserung monatelang blockiert, werden Teams wieder eigene Abkürzungen suchen.

Warum ein geänderter Prompt ein Release sein kann

Beim Lieferagenten wird ein Satz ergänzt: «Behandle lange ausbleibende Antworten als dringlich.» Es wurde keine klassische Programmfunktion geändert. Trotzdem kann der Agent nun mehr Fälle eskalieren, andere Prioritäten setzen oder bei später erweiterten Rechten andere Nachrichten vorbereiten.

Eine veränderte Arbeitsanweisung ist daher potenziell eine Verhaltensänderung. Dasselbe gilt für ein neues Modell, eine zusätzliche Datenquelle, eine andere Werkzeugbeschreibung oder eine geänderte Berechtigung. Die produktive Fassung besteht aus dem Zusammenspiel dieser Teile.

Ein Release sollte deshalb festhalten, welche Kombination geprüft und freigegeben wurde: Code, Modellkonfiguration, Anweisungen, Werkzeugverträge, Berechtigungen und Regeln für die verwendeten Wissensquellen. Dynamische Geschäftsdaten bleiben dynamisch; ihre Herkunft und ihr Zeitpunkt müssen für die jeweilige Entscheidung nachvollziehbar sein. Nicht jede neue Bestellung erfordert ein Release. Eine neue Regel für die Interpretation von Bestellungen sehr wohl.

Der Aufwand richtet sich nach der möglichen Wirkung. Eine rein redaktionelle Korrektur kann einen kurzen Prüfweg haben. Neue Schreibrechte, externe Kommunikation oder finanzielle Befugnisse verlangen eine deutlich stärkere Prüfung. Diese Einteilung ist eine betriebliche Entscheidung, keine universelle Risikoklasse.

Von der guten Demo zur freigegebenen Arbeitskraft

Für unseren Lieferagenten würde ich sechs Schritte vorsehen. Sie sollen den Weg in den Betrieb berechenbar machen und lassen sich bei kleinen Änderungen schlank halten.

Erstens: Die Änderung begründen. Welches Problem wird gelöst? Welche Fälle sollen danach besser laufen? Ein Release ohne erwartete Verbesserung ist schwer sinnvoll zu bewerten.

Zweitens: An bekannten Fällen prüfen. Verwenden Sie geeignete, bereinigte Testdaten mit normalen Fällen, widersprüchlichen Meldungen, fehlenden Berechtigungen und ausgefallenen Schnittstellen. Legen Sie vorher fest, welches Ergebnis akzeptabel ist. Ein schön geschriebener Bericht genügt nicht, wenn er die falsche Bestellung betrifft.

Drittens: Das Verhalten bei Grenzen prüfen. Was geschieht nach einem Zeitlimit? Erkennt der Agent eine bereits bearbeitete Position? Kann eine Lieferantenmeldung ihn dazu bringen, fremde Anweisungen zu befolgen? Was passiert, wenn nach einem Werkzeugaufruf unklar bleibt, ob eine Änderung ausgeführt wurde? Ein erneuter Aufruf darf nicht unkontrolliert eine zweite Aktion auslösen.

Viertens: Ohne reale Wirkung mitlaufen lassen. Wo der Prozess es erlaubt, vergleicht das Team Vorschläge der neuen Version mit der bisherigen Bearbeitung. Externe Aktionen bleiben deaktiviert. Dieser Schattenbetrieb zeigt, ob die Testfälle den Alltag ausreichend abbilden.

Fünftens: Begrenzt freigeben. Starten Sie mit einem definierten Nutzerkreis, Falltyp oder Volumen. Der Verantwortliche bestätigt Version, Grenzen und Abbruchkriterien. Erst danach wächst der Handlungsspielraum.

Sechstens: Beobachten und entscheiden. Vergleichen Sie Ergebnisqualität, Eingriffe, Wartezeit und Kosten mit der Ausgangslage. Bei einer Verletzung wichtiger Grenzen wird gestoppt oder zurückgeschaltet. Eine Rollback-Entscheidung darf nicht erst in der Störung erfunden werden.

Solche Tests werden häufig als Evals bezeichnet. Anthropics Beitrag zur Evaluation von Agenten betont wiederholte Versuche und die Unterscheidung zwischen Ablaufprotokoll und tatsächlichem Ergebnis. Für unser Beispiel heisst das: Geprüft wird auch, ob der richtige Klärungsfall entstanden ist. Die Aussage des Agenten allein ist kein Erfolgsnachweis.

Die Notbremse muss auch die laufende Arbeit erreichen

Ein Agent lässt sich technisch stoppen. Damit sind seine bisherigen Handlungen noch nicht rückgängig gemacht. Eine versendete Nachricht bleibt beim Empfänger. Eine geänderte Bestellung kann bereits Folgeprozesse ausgelöst haben. Ein Rollback der Software repariert diese Geschäftsvorfälle nicht automatisch.

Der Betriebsplan muss deshalb zwischen drei Dingen unterscheiden: neue Aufträge stoppen, laufende Arbeit kontrolliert anhalten und bereits verursachte Änderungen fachlich klären. Für offene Vorgänge braucht es eine Liste mit letzter bestätigter Aktion, zuständiger Person und nächstem Schritt. Wiederanlauf bedeutet, diese Zustände zu prüfen, statt alle Aufträge nochmals von vorne auszuführen.

Auch Vertreterregelungen gehören dazu. Wenn die verantwortliche Person abwesend ist, darf der Agent keine unbegrenzte Sammlung dringlicher Fälle produzieren. Entweder übernimmt eine benannte Vertretung oder die erlaubte Betriebsweise wird reduziert.

Das NIST Playbook, Funktion Manage behandelt Überwachung nach der Einführung, Vorfälle, Wiederherstellung und Stilllegung. Die praktische Konsequenz ist einfach: Zum produktiven Agenten gehört ein Betriebsmodell, das auch den schlechten Dienstag abdeckt.

Befördern Sie einen Agenten anhand seiner Ergebnisse

In der ersten Stufe sammelt unser Agent Informationen. Später darf er interne Klärungsfälle anlegen. Vielleicht wird er nach weiteren Prüfungen standardisierte Rückfragen versenden dürfen. Jede Erweiterung ist eine neue Entscheidung über Befugnisse. Sie folgt aus belastbaren Ergebnissen innerhalb eines klaren Fallbereichs.

Ein einziges gutes Gesamtergebnis genügt dafür nicht. Prüfen Sie, welche Fälle gelingen, welche scheitern und wie schwer die Fehler wiegen. Eine seltene falsche verbindliche Zusage kann wichtiger sein als viele korrekt sortierte Belege. Fehlende Daten und begründete Eskalationen dürfen nicht pauschal als schlechte Leistung bestraft werden. Sonst optimieren Sie das System darauf, Unsicherheit zu überspielen.

Die Kennzahlen sollten sich ergänzen: Anteil korrekt abgeschlossener Fälle, menschliche Bearbeitungszeit inklusive Nacharbeit, Dauer bis zum Ergebnis, vermeidbare Eskalationen, Verletzungen von Befugnisgrenzen und Kosten pro akzeptiertem Ergebnis. Dazu gehört die Frage, ob Nutzer dem System noch vertrauen und Fehler tatsächlich melden.

Die technische Grundlage haben wir im Beitrag zur agentischen Infrastruktur beschrieben. Führung macht aus diesen Möglichkeiten einen verantworteten Arbeitsablauf.

Virtuelle Mitarbeiter haben ebenfalls Führungskosten

Die Lizenz ist selten die vollständige Rechnung. Hinzu kommen Integration, laufende Prüfung, Anpassungen, Betrieb und die Bearbeitung von Ausnahmen. Wer diesen Aufwand ausblendet, rechnet sich eine Belegschaft zusammen, die auf dem Papier günstiger ist als im Alltag.

Ein ausdrücklich hypothetisches Monatsbeispiel: 1’200 Vorgänge benötigen bisher je acht Minuten menschliche Arbeit, also 160 Stunden. Mit Agent bleiben im Mittel drei Minuten pro Vorgang, einschliesslich Prüfung und fallbezogener Nacharbeit: 60 Stunden. Weitere 20 Stunden fallen für Betreuung, Tests und Pflege an. Die verbleibende Entlastung beträgt 80 Stunden.

Bei angenommenen CHF 90 pro Stunde entspricht das CHF 7’200 bewerteter Kapazität. Werden CHF 2’400 monatliche technische Zusatzkosten angesetzt, bleiben rechnerisch CHF 4’800 vor einmaligen Einführungskosten. Das ist keine gemessene Kundeneinsparung und keine automatische Zahlungseinsparung. Es setzt vergleichbares Volumen und vergleichbare Qualität voraus.

Verdoppelt sich die fallbezogene menschliche Bearbeitung auf sechs Minuten, sinkt die Entlastung nach Betreuung auf 20 Stunden. Deren Kapazitätswert von CHF 1’800 liegt unter den angenommenen technischen Zusatzkosten. Gerade deshalb gehören Führung und Nacharbeit in den Business Case. Die Leitung muss zudem entscheiden, wofür gewonnene Kapazität eingesetzt wird: weniger Rückstände, bessere Betreuung oder zusätzliches Volumen.

Die Organisation wird zur Auftraggeberin ihrer Software

Das interessante Zukunftsbild ist ein Unternehmen, in dem Menschen Arbeit nicht mehr mühsam durch jede Anwendung tragen müssen. Sie formulieren ein Ziel, geben den nötigen Kontext und delegieren passende Schritte. Agenten arbeiten innerhalb dieser Grenzen, machen Fortschritt sichtbar und bringen Entscheidungen dorthin zurück, wo sie verantwortet werden können.

Damit verändert sich auch Führung. Gute Aufgabenbeschreibung, klares Feedback und saubere Übergaben werden zu Fähigkeiten, die unmittelbar auf die Leistung der Software wirken. Fachwissen wird nicht überflüssig. Es wird gebraucht, um zu erkennen, ob das Ergebnis überhaupt das richtige Problem löst.

Beginnen Sie mit einem Agenten und einem wichtigen Vorgang. Schreiben Sie sein Mandat. Benennen Sie Führung und Vertretung. Prüfen Sie eine Version an echten Anforderungen. Entscheiden Sie über eine begrenzte Freigabe und reservieren Sie Zeit für die Auswertung. Erst wenn dieser Kreislauf funktioniert, lohnt sich die Vervielfachung.

Die entscheidende Frage für die nächste Geschäftsleitungssitzung lautet: Wenn morgen zehn Agenten für uns arbeiten – wer gibt ihnen gute Aufträge, wer prüft ihre Leistung und wer darf ihre Befugnisse verändern?

Wer darauf eine klare Antwort hat, kann zusätzliche Kapazität verantwortungsvoll nutzen. Wer sie offenlässt, automatisiert auch die Unklarheiten seiner Organisation.

Möchten Sie den ersten Agenten mit einem belastbaren Führungs- und Release-Modell aufsetzen? Wir entwickeln mit Ihnen Auftrag, Befugnisse, Prüfverfahren und Betriebsverantwortung.

Einordnung: Dieser Beitrag formuliert einen Managementansatz. Die Unternehmensszene, das Mandat und sämtliche Rechenwerte sind illustrative Beispiele, keine Beschreibung eines Kundenbetriebs. Quellen geprüft am 12. November 2026.