Workflow oder KI-Agent? Die Entscheidungsmatrix für Schweizer KMU

Ob das «AI Agent»-Projekt auf Ihrem Tisch trägt oder in zwei Jahren abgeschrieben wird, entscheidet sich meist an einer Frage, die in keiner Offerte steht: Ist dieser Prozess ein Workflow oder ein Agent? Gartner prognostiziert seit Mitte 2025, dass über 40 Prozent aller Agentic-AI-Projekte bis Ende 2027 eingestellt werden, wegen steigender Kosten, unklaren Geschäftswerts oder ungenügender Risikokontrolle. Dieselbe Analyse schätzt, dass von den Tausenden Anbietern mit «Agentic AI» im Prospekt nur rund 130 echte Agenten liefern. Für den Rest gibt es einen Namen, der im deutschsprachigen Raum noch kaum angekommen ist: Agent Washing, das Umetikettieren von Chatbots, RPA-Flows und Assistenten zu «Agenten».

Meine Antwort auf beide Fehlermodi ist dieselbe Maxime: so deterministisch wie möglich, so agentisch wie nötig. Ich vertrete sie nicht, weil sie vorsichtig klingt, sondern weil ich zweimal in diese Richtung umgekehrt bin. Einmal, nachdem ein autonomer Agent in meinem eigenen Produkt 13 Minuten lang dieselbe tote URL gescrapt hatte. Und einmal, als parallel laufende Agenten einander stillschweigend 19 Quellen überschrieben.

Dieser Artikel macht aus der Maxime ein Arbeitsinstrument. Er trennt dafür drei Entscheidungen, die in Anbietergesprächen fast immer zu einer einzigen verschmolzen werden: erstens das Architekturmuster pro Prozessschritt (Workflow, Agent oder Hybrid), zweitens das Werkzeug (Power Automate, Copilot Studio oder ein Pro-Code-Agent auf Microsoft Foundry), drittens den Governance-Rahmen (Identität, Freigaben, Audit, Obergrenzen). Wer die drei Entscheidungen sauber trennt, hat am Ende eine Matrix für jeden Prozess, eine Werkzeug-Treppe mit vier Aufstiegsfragen und eine Checkliste für das nächste Anbietergespräch.

Workflow oder Agent: Was ist der Unterschied?

Ein Workflow folgt einem vordefinierten Ablauf: Der Code bestimmt, welche Schritte in welcher Reihenfolge laufen, auch wenn einzelne Schritte ein Sprachmodell nutzen. Ein Agent entscheidet selbst, welche Werkzeuge er wann einsetzt, um ein Ziel zu erreichen. Die Faustregel: Wer den Entscheidungsbaum im Voraus aufzeichnen kann, baut einen Workflow, denn der ist genauer, günstiger und besser prüfbar.

Die Unterscheidung stammt aus Anthropics «Building Effective AI Agents», dem Referenztext dieser Debatte: Workflows orchestrieren Sprachmodelle über vordefinierte Code-Pfade, Agenten steuern Prozess und Werkzeugeinsatz selbst. Die Empfehlung dahinter überliest die Einkaufsseite des Markts systematisch. Anthropic rät, die einfachste tragfähige Lösung zu suchen, Komplexität nur bei nachweisbarem Nutzen zu erhöhen, und hält fest: «Workflows offer predictability and consistency for well-defined tasks.» Vorgezeichnet heisst dabei nicht KI-frei. Ein Workflow darf an einzelnen Stellen ein Sprachmodell aufrufen, etwa um ein Dokument zu klassifizieren; er bleibt ein Workflow, solange der Code die Reihenfolge bestimmt. Und zwischen den beiden Polen liegt die in der Praxis häufigste Form: der Hybrid, ein deterministischer Ablauf, der an einzelnen, bewusst gewählten Stellen einem eng begrenzten Agenten eine Entscheidung überlässt.

Bemerkenswert ist, dass Microsoft die Notbremse gleich selbst eingebaut hat. Die Dokumentation zum Microsoft Agent Framework empfiehlt Workflows genau dann, wenn eine «guaranteed execution order» nötig ist, die ein einzelner Agent «can't reliably provide»: bei Seiteneffekten wie Zahlungen oder E-Mails, die nicht beliebig wiederholt werden dürfen, und bei Abläufen, die nach einem Unterbruch am Checkpoint weiterlaufen müssen. Der Hersteller der Agenten-Werkzeuge rät also, zuerst das einfachste Muster zu versuchen.

Ein Agent ist folglich nicht die reifere Form eines Workflows. In meinem Architektur-Framework ist «mehr Autonomie wird mit höherer Reife verwechselt» als der klassische Fehler benannt. Wer zuerst die Produktnamen sortieren muss, findet die Landkarte in Microsofts Agenten-Stack entwirrt; für diesen Artikel reichen die zwei Begriffe und eine Vorschau: Zwischen den Polen liefert Microsoft fünf Abstufungen, dazu gleich mehr.

13 Minuten Leerlauf, 19 verlorene Quellen: zwei Lehrstücke aus der eigenen Produktion

Der Trace, der mich zum ersten Mal hat umkehren lassen, ist 777 Sekunden lang. Ein autonomer Web-Agent in meinem Recherche-Produkt AmpliQ sollte Quellen einsammeln und blieb an einer Seite hängen, die nichts mehr lieferte. Er scrapte dieselbe tote URL vier Mal hintereinander, verbrannte bei jedem Versuch den vollen 30-Sekunden-Timeout und meldete nach 13 Minuten ein mageres Ergebnis. Kein Absturz, keine Fehlermeldung. Der Agent tat exakt das, wofür Agenten gebaut sind: Er entschied selbst über den nächsten Schritt. Er entschied nur vier Mal gleich falsch. Die Korrektur war unspektakulär und vollständig deterministisch: ein Circuit Breaker, ein Scrape-Budget pro Knoten, eine Blacklist für gescheiterte URLs und die Regel «never repeat known-failed actions».

Das zweite Lehrstück war leiser. Zwei Agenten registrierten parallel Quellen im selben Zustandsobjekt: Beide lasen ein leeres Register, beide schrieben ihr volles zurück, der letzte gewann. 19 Quellen des ersten verschwanden ohne Warnung, und aufgefallen ist es erst, als Zitate im fertigen Dokument ins Leere liefen. (Wie Agenten belegbar antworten, statt still zu erfinden, ist ein eigenes Kapitel.) Die Lösung war wieder unglamourös: sequenzielle Registrierung und Merge-sichere Zustandsfunktionen statt naiver Parallelität.

Konsequenzen zog ich an zwei Stellen, beide in Richtung Determinismus. Als das starre Wellen-Modell der Recherche einem echten Abhängigkeitsgraphen weichen musste, wäre es naheliegend gewesen, die ganze Orchestrierung einem frei planenden ReAct-Agenten zu übergeben. Ich habe es bewusst nicht getan: Der Planner erzeugt einen validierten Graphen, und der Executor hält Prüfschritte, Schreibzugriffe und Routing deterministisch — mehr Ausdruckskraft und mehr Autonomie sind zwei verschiedene Achsen, und man kann die erste kaufen, ohne die zweite mitzubezahlen. Später kehrte auch der Schreibpfad um: Eine autonome, LLM-gesteuerte Retrieval-Schleife wurde durch eine kompilierte deterministische Engine ersetzt, mit genau einem gedeckelten LLM-Fallback von 25 Sekunden für die eine Entscheidung, die Code nicht treffen kann.

Zur Ehrlichkeit gehört der Massstab: Das sind Einzeltraces und Architekturentscheide aus einem einzigen Produkt, kein Benchmark. Aber beide Ausfälle teilen eine Eigenschaft, die sie für Entscheidungsträger relevant macht. Ohne Tracing wären sie unsichtbar geblieben: kein Fehler im Log, nur stiller Mehrverbrauch und ein stilles Loch im Ergebnis. Es sind Autonomie- und Parallelitätsrisiken dieser leisen Sorte, gegen die die Maxime absichert.

Drei Entscheidungen, nicht eine

Bevor die Matrix kommt, eine Klarstellung, die mehr Projekte rettet als jedes Framework: «Workflow oder Agent?» ist nicht eine Entscheidung, sondern drei, und sie werden in Offerten fast immer zu einer einzigen Plattformfrage verschmolzen.

Entscheidung 1 — das Architekturmuster. Workflow, Agent oder Hybrid, und zwar pro Prozessschritt, nicht pro Projekt. Das ist eine Frage der Prozessnatur: Lässt sich der Entscheidungsbaum vorzeichnen oder nicht?

Entscheidung 2 — das Werkzeug und die Laufzeit. Power Automate, Copilot Studio, ein Agent auf Microsoft Foundry oder eine eigene Anwendung. Das ist eine Frage von Kanal, Integrationstiefe, Betriebsmodell und Infrastrukturkontrolle, und sie kommt nach Entscheidung 1.

Entscheidung 3 — der Governance-Rahmen. Identität, Freigaben, Datenhaltung, Audit, Abnahmekriterien und Kostenobergrenzen. Dieser Rahmen gilt unabhängig davon, wie die ersten beiden Entscheidungen ausfallen, und er gehört in den Vertrag, nicht in den Anhang.

Getrennt heisst dabei nicht unabhängig. Die Antworten aus Entscheidung 1 sind die Eingaben für Entscheidung 2, und die Anforderungen aus Entscheidung 3 — Identität, Datenhaltung, Audit-Tiefe — werden früh erhoben, weil sie mitbestimmen, welches Werkzeug überhaupt in Frage kommt; festgeschrieben werden sie zuletzt, weil sie für jedes Werkzeug gelten. Die Trennung verhindert also nicht den Informationsfluss zwischen den Entscheidungen, sondern das Überspringen einer davon.

Wer die drei vermischt, bekommt die typischen Fehlentscheide: Ein Werkzeug wird gewählt, weil es moderner wirkt (Entscheidung 2 ersetzt Entscheidung 1), oder ein «autonomer Agent» wird ohne Obergrenzen abgenommen (Entscheidung 3 fällt aus). Der Rest dieses Artikels arbeitet die drei Entscheidungen der Reihe nach ab. Die Leitlinie über allen dreien: Die Maxime gilt pro Aufgabe, nicht pro Produkt.

Entscheidung 1 — Die Entscheidungsmatrix: Prozessvariabilität × Schadenspotenzial

Sortieren lässt sich jeder Prozess mit zwei Achsen. Erstens Prozessvariabilität: Ist der Ablauf fix, verzweigt, mehrdeutig oder offen? Zweitens Schadenspotenzial: Liest der Prozess nur, wirkt er intern und reversibel, wirkt er nach aussen, oder ist die Wirkung irreversibel oder reguliert? Mein Architektur-Framework fasst die erste Achse als sechsstufige Skala und benennt den typischen Fehler gleich mit: «Ein Agent wird eingesetzt, weil es moderner wirkt, obwohl ein expliziter Workflow zuverlässiger, günstiger und besser prüfbar wäre.»

Microsoft hat für diese Skala inzwischen den Regler gebaut. Das Agent Framework liefert fünf Orchestrierungsmuster: Sequential, Concurrent, Group Chat, Handoff und Magentic, von der festen Pipeline bis zum Manager-Agenten, der Spezialisten dynamisch koordiniert. Der springende Punkt: Das ist eine Wahl pro Prozessschritt, nicht pro Plattform. Ein Ablauf darf neun deterministische Knoten und einen agentischen enthalten. Was die fünf Muster im Einzelnen leisten, folgt am Ende dieses Abschnitts.

So sieht die Matrix angewendet aus. Die ersten drei Zeilen sind Einordnungsbeispiele, die letzten zwei die realen Platzierungen aus meinem eigenen Produkt:

Meine Betriebsregel dahinter stammt direkt aus der Produktionsdokumentation. Gebundene Agenten übernehmen Query-Generierung, Quellenauswahl und adaptives Retrieval, also die Aufgaben, deren Entscheidungsbaum sich wirklich nicht vorzeichnen lässt. Deterministisch bleiben Validierungs-Gates, Schreibzugriffe, Scheduler, Schleifenabbrüche und Routing. Die dokumentierte Begründung ist unromantisch: vorhersehbares Verhalten, sichere Seiteneffekte, tiefere Latenz, volle Prüfbarkeit, tiefere Kosten.

Die Matrix ist der erste Schnitt, nicht die ganze Architekturentscheidung. Bevor Sie daraus eine Werkzeug- oder Plattformwahl ableiten, gehören sechs Zusatzfragen auf den Tisch. Welche Daten sieht der Prozess: öffentliche, interne, Personendaten, Mandats- oder Finanzdaten? Welche Aktionen darf er auslösen: nur lesen, Entwürfe erstellen, reversibel schreiben, extern und irreversibel wirken? Kann das Ergebnis geprüft werden, bevor es wirkt, durch einen Menschen oder durch Code? In wessen Namen greift der Prozess zu: als Benutzer, als eigene Agentenidentität, als Service-Konto? Wer betreibt Monitoring, Kostenkontrolle und Fehlerbehandlung nach dem Go-live? Und wo arbeitet der Benutzer tatsächlich: in Teams, in Microsoft 365, in einer Fachapplikation oder in einem Hintergrundprozess ganz ohne Oberfläche? Die ersten vier Fragen verschieben Prozesse in der Matrix nach oben in die deterministische Zone; die letzten zwei bereiten Entscheidung 2 und 3 vor.

Konkret könnte die Aufteilung in einem 50-Personen-Treuhandbüro so aussehen: Die Rechnungsfreigabe läuft als deterministischer Workflow mit Freigabe-Gate, die Posteingangs-Triage als Workflow mit einem einzigen gebundenen Klassifikationsschritt, und nur die offene Mandatsrecherche bekommt einen Agenten, mit Budget. Kein Umbau der Firma; drei richtig dosierte Kontrollformen.

Die fünf Orchestrierungsmuster im Detail

Die fünf Muster sind kein Featurekatalog, sondern derselbe Regler in fünf Stellungen: Von Sequential bis Magentic wandert die Kontrolle über den nächsten Schritt schrittweise vom Code zum Modell. Die ersten beiden Muster sind Workflows im Sinne dieses Artikels — die Route steht im Code —, die letzten beiden sind agentisch, und Group Chat liegt dazwischen: Die Agenten reden frei, aber ein Chat-Manager vergibt das Wort.

Gelesen mit der Matrix von oben heisst das: Sequential und Concurrent gehören in die blaue Workflow-Zone, Handoff und Magentic verdienen sich nur die offene, risikoarme Ecke, und Group Chat braucht einen Manager mit klarem Abbruchkriterium. Magentic — Microsofts Produktname für das Manager-Muster aus dem Forschungsprojekt Magentic-One — ist ausdrücklich für Aufgaben gebaut, deren Lösungsweg sich nicht vorzeichnen lässt; es ist damit die maximale Reglerstellung, nicht die Standardeinstellung. Die gute Nachricht für Entscheidung 3: Alle fünf Muster unterstützen menschliche Freigaben und Checkpoints, bei Magentic inklusive der Möglichkeit, den Plan des Managers vor der Ausführung von einem Menschen prüfen zu lassen.

Eine Einordnung noch, weil sie in Anbietergesprächen gerade für Verwirrung sorgt: Microsoft Foundry bot dieselben Muster zeitweise auch als visuellen Workflow-Designer im Portal an. Dieser Weg wird per 1. Dezember 2026 eingestellt; die Orchestrierung wandert vollständig ins Agent Framework, als Code oder deklaratives YAML, ausgeführt als Hosted Agent. Wer Ihnen heute eine Lösung auf dem visuellen Foundry-Designer offeriert, verkauft Ihnen also eine Migration gleich mit — und für rein visuelle Prozessautomatisierung verweist Microsoft selbst auf Logic Apps und die Power-Platform-Schiene, die Rohrleitung aus Entscheidung 2.

Wann der Agent die richtige Antwort ist

Damit dieser Text nicht als Anti-Agenten-Pamphlet endet, das Gegenstück: In meinem Produkt laufen beide Enden des Spektrums, auf demselben Orchestrator. Die Suche ist ein echter ReAct-Agent mit zwei bis fünf adaptiven Schritten: denken, handeln, beobachten, und am Ende ein protokollierter Abbruchgrund, der festhält, ob das Ziel erreicht, das Schrittbudget erschöpft oder ein Fehler aufgetreten ist. Das Schreiben läuft als deterministische Engine. Diese Aufteilung war eine bewusste Designentscheidung, kein Zufall zweier Teams: Suche verträgt Exploration und variable Latenz, Schreiben braucht stabile Zitate und eine gedeckelte Antwortzeit. Die Maxime gilt pro Aufgabe, nicht pro Produkt.

Die Suche blieb dabei ganz bewusst agentisch, auch als der Schreibpfad deterministisch wurde. Eine Ad-hoc-Recherche ist genau der Fall, in dem sich der Entscheidungsbaum nicht vorzeichnen lässt: Was die zweite Suchrunde fragen soll, weiss man erst, wenn die erste geantwortet hat. Suchanfragen aus Zwischenergebnissen ableiten, Quellen gewichten, das Retrieval an der letzten Runde ausrichten; hier verdient der Agent seinen Platz. Wo Retrieval in Produktion trägt, ist es fast immer diese Sorte gebundener Agentik.

Gebunden ist das Stichwort. Auch mein «freier» Suchagent arbeitet im Käfig: maximal fünf Schritte, ein striktes Ausgabeschema, eine Neuheitsschwelle gegen Wiederholungen, und im Systemprompt der Satz «work with what you have», der das Nachfordern von Daten schlicht verbietet.

Die nützlichste Einsicht aus dem eigenen Bau kam zum Schluss: Determinismus ist eine Eigenschaft des Plans, nicht der Laufzeit. Mein Workflow-Editor lässt den Planner einen Ablauf vorschlagen, ein Mensch redigiert ihn, die Validierung friert ihn ein, und ausgeführt wird der eingefrorene Graph auf demselben Agenten-Orchestrator wie die freie Recherche. Derselbe Motor fährt einmal frei und einmal auf Schienen. Sie kaufen also kein Workflow-Produkt und kein Agenten-Produkt. Sie entscheiden pro Prozessschritt, wem die Entscheidung gehört.

Entscheidung 2 — Copilot Studio, Power Automate oder eigener Agent: Welches Werkzeug für welchen Prozess?

Power Automate ist kein Agent, sondern die deterministische Rohrleitung: Es führt fixe, wiederholbare Abläufe aus und wird von Copilot Studio als Unterbau mitgenutzt. Darüber ist die Werkzeugwahl kein Zweikampf «Copilot Studio gegen Eigenbau», sondern eine Treppe mit mehreren Stufen: Copilot Studio (Low-Code, konversationell, nah an Microsoft 365), darüber Prompt Agents auf Microsoft Foundry (konfiguriert statt programmiert, vollständig verwaltet), darüber Hosted Agents mit eigenem Code auf dem Agent Framework oder einem anderen SDK in der verwalteten Foundry-Laufzeit, und zuoberst die vollständig eigene Azure-Anwendung. Der Kipppunkt zwischen den Stufen liegt bei der benötigten Infrastruktur- und Orchestrierungskontrolle — Datenresidenz, Netzwerkisolation, Audit-Tiefe, eigene Oberfläche, eigene Ablauflogik —, nicht bei der Featureliste.

Zuerst aber die Reihenfolge: erst der Prozessentscheid aus der Matrix, dann das Werkzeug. Wer sie einhält, hat die halbe Werkzeugfrage schon beantwortet. Für die andere Hälfte lohnt der Blick auf eine reale Praktikerfrage bei Microsoft Q&A: wann und warum Foundry, wenn beide doch ähnlich funktionieren. Microsofts offizielles Flussdiagramm hilft dabei wenig; Anands Blog attestiert ihm, dass Teams schon an der ersten Verzweigung stecken bleiben, weil Datengrenzen, Governance und Kanalfragen selten auf eine Seite passen.

Der häufigste Denkfehler ist das Dreiecksrennen. Power Automate tritt in seriösen Vergleichen gar nicht als dritte Agenten-Plattform an: Agent flows sind deterministische Abläufe, die sich in Copilot Studio bauen und von Agenten als Werkzeug aufrufen lassen; bestehende Power-Automate-Flows lassen sich dorthin konvertieren. Rohrleitung eben, und als solche wertvoll.

Damit wird aus dem Baum eine Aufstiegsregel: Steigen Sie die Treppe von unten hoch, und bleiben Sie auf der ersten Stufe stehen, deren Frage Sie mit Ja beantworten.

1. 1Ist der Ablauf fix und wiederholbar, ganz ohne Konversation? Dann Power Automate, die Rohrleitung selbst, allenfalls ganz ohne KI.
2. 2Findet der Prozess als Konversation in Teams oder Microsoft 365 statt, und reichen Standard-Oberfläche und Power-Platform-Governance? Dann Copilot Studio.
3. 3Braucht es Infrastrukturkontrolle — Datenresidenz, Netzwerkisolation, Audit-Tiefe —, aber keine eigene Ablauflogik? Dann ein Prompt Agent auf Microsoft Foundry: konfiguriert statt programmiert, vollständig verwaltet.
4. 4Braucht es eigene Orchestrierung, eigene Logik oder eine eigene Oberfläche? Dann ein Hosted Agent mit dem Agent Framework in der verwalteten Foundry-Laufzeit — und erst wenn auch die zu eng wird, die vollständig eigene Azure-Anwendung.

Der Aufstieg ab der dritten Frage ist der Kipppunkt, aber er ist eine Schwelle, kein Schalter. Was Foundry dokumentiert liefert, ist Infrastrukturkontrolle: Customer-Managed Keys, private Netzwerke, eigene Ressourcen und regionale Endpunkte mit Datenhaltung in der gewählten Region, etwa Switzerland North. Zwei Präzisierungen gehören dazu, bevor daraus ein Beschaffungsargument wird. Erstens variiert die Verfügbarkeit von Modellen und Werkzeugen je Region; wer Schweizer Datenhaltung zusagt, muss jede Modell-Werkzeug-Kombination einzeln gegen die Regionen-Doku prüfen, nicht die Plattform pauschal. Zweitens heisst mehr Infrastrukturkontrolle nicht automatisch mehr Compliance: Ob ein Prozess revisionsfähig ist, entscheiden Mandantenkonfiguration, Datenklassifizierung, Konnektoren, Identität, Logging und Betriebsmodell — der Governance-Rahmen aus Entscheidung 3, und der lässt sich auch über Copilot Studio plus Power-Platform-Governance sauber aufsetzen, wenn Datenart und Aktionsradius es zulassen. Wo aber eine harte Anforderung wie CMK oder Netzwerkisolation tatsächlich in den Anforderungen steht, gehört der Pro-Code-Pfad von Tag eins ins Budget statt als spätere Migration ins Risiko. Was Datenresidenz und Regionen konkret bedeuten und wie ein Agent im Kundentenant betrieben wird, sind die passenden Vertiefungen; für Kanzleien und Treuhänder gibt es die Branchenversion dieser Entscheidung.

Unterhalb des Kipppunkts endet Copilot Studio trotzdem irgendwo: Community-Threads dokumentieren Grenzen bei Connector-Authentifizierung, dazu kommen Feature-Verzögerungen gegenüber dem Pro-Code-Stack und enge Spielräume bei eigener Benutzeroberfläche. Zu den Kosten nur der Mechanismus, denn Preise altern schneller als Artikel: Copilot Studio rechnet über Copilot Credits ab, der Eigenbau über Azure-Verbrauch (bei Hosted Agents inklusive Container-Compute), und zu beiden kommen Implementierung und Betrieb dazu. Zwei Fragen entlarven jede schöngerechnete Offerte: Wer bezahlt die Credits nach Jahr eins? Und was passiert, wenn wir aus Copilot Studio herauswachsen? Für die Rechnung in Franken: Was kosten Microsoft AI Agents wirklich?

Entscheidung 3 — Der Governance-Rahmen: Identität, Freigaben, Injection, Abnahme

Die dritte Entscheidung wird am häufigsten übersprungen, weil sie sich nach Papierkram anfühlt. Sie ist das Gegenteil: Der Governance-Rahmen ist der Teil, der einen KI-Prozess in der Schweiz revisionsfähig macht, und er gilt für jedes Werkzeug aus Entscheidung 2 gleichermassen.

Der Kern ist die Prüfbarkeit. Checkpoints, menschliche Freigaben und eine deterministische Ausführungsreihenfolge sind das, was ein Verwaltungsrat oder eine Revisionsstelle nachvollziehen kann; die Workflows des Agent Framework bringen Checkpointing und Freigabe-Mechanismen dafür mit. So betreibe ich es selbst: In meinem Stack wartet jeder Knoten, der ein Artefakt schreibt, auf eine menschliche Freigabe, und ein Checkpointer in der Datenbank hält den Zustand, damit der Lauf nach der Freigabe exakt dort weitergeht. Sobald Zahlungen, Mandatsdaten oder Kundenkommunikation im Spiel sind, gehört das in den Vertrag, nicht in den Anhang. Die Tiefe dazu liefern Approval-Gates, Governance-Hooks und Audit-Trails und, für regulierte Branchen, das Compliance-Playbook zu revDSG und FINMA.

Zwei Fragen definieren das Schadenspotenzial präziser als jedes Featureblatt. Erstens die Identität: In wessen Namen greift der Agent auf jedes einzelne Werkzeug zu — im Kontext des Benutzers, mit einer eigenen Agentenidentität, über ein Service-Konto? Die Berechtigungen dieser Identität sind das reale Schadenspotenzial des Prozesses, nicht das, was die Offerte als «Use Case» beschreibt. Zweitens die Aktionsklassen: Welche Aktionen sind nur lesend, welche erzeugen Entwürfe, welche schreiben reversibel, welche wirken extern oder irreversibel? Erst wenn jedes Werkzeug einer Klasse zugeordnet ist, lässt sich sagen, wo eine Freigabe zwingend ist und wo ein Trace genügt.

Dazu kommt ein Risiko, das in KMU-Gesprächen fast nie vorkommt und in jeder Sicherheitsbetrachtung vorkommen müsste: Prompt Injection. In dem Moment, in dem ein Agent Lieferanten-PDFs, Kunden-E-Mails, SharePoint-Dokumente oder Webseiten liest, können feindliche Anweisungen in seinen Kontext gelangen — und ein Agent, der Werkzeuge selbst wählt, kann sie ausführen. Die Gegenmittel sind dieselben wie oben: Aktionsklassen, Freigaben vor Wirkung, und so viel Determinismus wie möglich, denn ein Workflow, dessen Reihenfolge der Code bestimmt, bietet einer eingeschleusten Anweisung schlicht weniger Angriffsfläche als ein frei planender Agent mit denselben Werkzeugen.

Und schliesslich die Abnahme. «Funktioniert gut» ist kein Kriterium; verlangen Sie Zahlen, bevor etwas produktiv geht: Trefferquote und Fehlklassifikationsrate für eine Triage, Zitatabdeckung für eine Recherche, Eskalationsrate an Menschen, Kosten pro erfolgreich abgeschlossenem Fall, Latenz-Perzentile statt Durchschnittswerte, und der manuelle Korrekturaufwand pro Woche. Wer misst, kann kündigen und nachsteuern; wer nicht misst, verlängert im Blindflug. Wie Sie einen Piloten bewusst auf Falsifikation auslegen, damit er solche Zahlen liefern muss, statt sie zu versprechen, ist der Schritt danach.

Autonomie ist eine Zahl: Fünf Fragen an jeden Anbieter

In meinem Produkt ist Autonomie nirgends ein Adjektiv, sondern überall eine Konstante: maximal fünf Schritte pro Agentenlauf, Rekursionslimit 100, zwei Replan-Versuche, 900 Sekunden Timeout pro Knoten, 25 Sekunden für den einen LLM-Fallback im Schreibpfad. Das ist keine Pedanterie. Erst diese Zahlen machen aus «Was, wenn der Agent durchdreht?» eine berechenbare Obergrenze für Latenz und Kosten. Und sie sind verhandelbar, ohne ihr Wesen zu verlieren: Das Rekursionslimit habe ich von 25 auf 100 angehoben, damit grosse Abläufe durchlaufen. Eine justierte Grenze, keine entfernte.

Daraus folgt der Satz für Ihr nächstes Anbietergespräch: Wenn Ihr Anbieter die Obergrenzen seines Agenten nicht aufschreiben kann, kontrolliert er die Autonomie nicht. Er hofft.

Fünf Fragen genügen für den Anfang:

1. 1Was ist die maximale Schrittzahl pro Lauf?
2. 2Welche Timeouts gelten pro Schritt und pro Lauf?
3. 3Welches Token- oder Kostenbudget deckelt einen einzelnen Lauf?
4. 4Wie oft wird bei Fehlern wiederholt, und was passiert danach?
5. 5Wo ist das alles dokumentiert?

Und sechs weitere gehören in den Vertrag, weil sie den Governance-Rahmen aus Entscheidung 3 einfordern:

6. 6Mit welcher Identität greift der Agent auf jedes Werkzeug zu?
7. 7Welche Aktionen sind read-only, welche Entwürfe, welche extern oder irreversibel?
8. 8Wo werden Prompts, Tool-Aufrufe, Zwischenzustände und Artefakte gespeichert, und wie lange?
9. 9Wie wird Prompt Injection erkannt oder begrenzt, wenn der Agent fremde Inhalte liest?
10. 10Welche messbaren Abnahmekriterien gelten vor dem Go-live?
11. 11Wer bezahlt und überwacht den Verbrauch nach dem Piloten?

«Das regelt der Agent selbst» ist keine Antwort, sondern ein Warnsignal: Es beschreibt ziemlich genau das Profil der Projekte, aus denen sich Gartners 40-Prozent-Prognose speist. Der zweite Warnhinweis ist noch einfacher: Wenn ein Agent gewählt wurde, weil er moderner wirkt, war er schon im Entwurf der falsche. Weitere Warnsignale jenseits der Autonomie sammelt Fünf Fragen, die ein fragiles KI-Angebot entlarven.

Liegt bei Ihnen bereits eine Offerte, in der diese Zahlen fehlen, können Sie sie mit den elf Fragen selbst zurückweisen oder unabhängig prüfen lassen; genau das leistet ein Angebots-Review von PowerLeap, bevor Budget gebunden wird.

Fazit: Die Reihenfolge entscheidet

«So deterministisch wie möglich, so agentisch wie nötig» ist am Ende eine Reihenfolge: erst pro Prozessschritt entscheiden, ob Workflow oder Agent, dann erst das Werkzeug wählen, von Copilot Studio über Power Automate bis zum Pro-Code-Agenten auf Microsoft Foundry, und in jedem Fall den Governance-Rahmen aufsetzen und die Autonomie als Zahl festschreiben. Wer die Reihenfolge umdreht, bezahlt doppelt: in Tokens und in Kontrollverlust.

Beide Fehlermodi erkennen Sie jetzt: umetikettierte Workflows, die als «Agenten» verkauft werden, und echte Agenten, die nie hätten gebaut werden dürfen. Ich betreibe Agenten dort, wo sie ihren Platz verdienen, gebunden und gedeckelt in einer deterministischen Hülle; alles andere in meinem Stack ist mit Absicht langweilig. Welcher Use Case überhaupt welche Architektur verdient, ist der Entscheid davor. Für den nächsten Schritt brauchen Sie kein Budget: Nehmen Sie einen Ihrer Prozesse, setzen Sie ihn in die Matrix, und stellen Sie dem nächsten Anbieter die fünf Fragen.

FAQ: Workflow, Agent und die Microsoft-Werkzeuge

Was ist der Unterschied zwischen Copilot Studio und Power Automate?

Copilot Studio baut konversationelle Agenten, die Sprache verstehen und in Microsoft 365 und Teams auftreten. Power Automate führt deterministische Abläufe mit fix definierten Schritten aus. In der Praxis ergänzen sie sich: Copilot Studio spricht, Power Automate arbeitet, verbunden über Agent flows. Abgerechnet werden Agent flows über die Copilot-Studio-Kapazität, nicht über Power-Automate-Lizenzen.

Kann Copilot Studio Power Automate Flows aufrufen?

Ja, genau dafür sind Agent flows gebaut: Ein Copilot-Studio-Agent ruft zur Laufzeit einen deterministischen Flow als Werkzeug auf, um Daten zu holen oder Aktionen auszuführen; bestehende Power-Automate-Flows lassen sich in Agent flows umwandeln. Power Automate übernimmt damit die Rolle der deterministischen Rohrleitung unter einem konversationellen Agenten.

Wann braucht ein KMU einen eigenen AI Agent statt Copilot Studio?

Sobald Anforderungen auftauchen, die Copilot Studio nicht abdeckt: Datenhaltung in einer bestimmten Region (etwa Switzerland North), Netzwerkisolation und Customer-Managed Keys, tiefe Audit-Anforderungen, eine eigene Benutzeroberfläche oder eine eigene Ablauflogik. Dann führt der Weg zu Microsoft Foundry — als verwalteter Prompt Agent, wenn Konfiguration reicht, oder als Hosted Agent mit eigenem Code —, und dieser Pfad gehört von Anfang an ins Budget, nicht als spätere Migration. Wichtig: Der eigene Agent bringt mehr Infrastrukturkontrolle, nicht automatisch mehr Compliance; Freigaben, Identität und Audit müssen auf jedem Pfad aufgesetzt werden.