Alle Notizen
24. Mai 202612 Min. Lesedauercopilot-studioworkflowsai-agentsmicrosoft-365engineeringorchestration

Copilot Studio Workflows ist das Rückgrat, das LLM-Agents brauchten

Die meisten Agents, die 2025 ausgeliefert wurden, sind ein LLM im Kostüm. Eine Schleife, eine Tool-Liste, ein Prompt, der "Du bist hilfsbereit" sagt, und ein Gebet, dass der nächste Token gut ist. Was in jedem ernsthaften Production-Deployment, das ich gesehen habe, fehlte, ist die langweilige Schicht darunter: ein Graph, der sich merkt, wo er war, der erneut versucht, wenn das LLM blinzelt, und der jeden Zustandsübergang an einen Auditor offenlegt. Diese Schicht ist soeben in Power Platform gelandet.

Kernpunkte

  • Copilot Studio Workflows ist kein neues Automatisierungstool. Es ist Microsofts Eingeständnis, dass reine konversationale Agents zu nicht-deterministisch sind, um unbeaufsichtigt in einen Geschäftsprozess verdrahtet zu werden.
  • Fünf Vendors liefern jetzt dieselbe Form: Temporal, LangGraph, AWS Step Functions plus Bedrock AgentCore, Azure Durable Task for AI Agents und nun Copilot Studio Workflows. Das deterministische Rückgrat um das LLM ist die Konsens-Architektur, kein Pattern mehr.
  • Das Rückgrat ist zugleich die Audit-Fläche. Jeder Knotenübergang wird geloggt; ein reiner LLM-Agent, der Tool-Calls ausfächert, nicht. Das Governance-Argument ist unabhängig vom Reliability-Argument.
  • Die These verliert bei emergentem Reasoning, bei Low-Code-Versionskontrolle-Hygiene und an der Skalengrenze, an der deterministische Graphen zum Sarg werden.
  • Wenn Sie 2026 Agents entwerfen und das Design keinen benannten Harness hat, bauen Sie die unausgelieferte 2024er-Version des bereits eingestellten Prototyps eines anderen.

Der Launch der neu gestalteten Canvas für Copilot Studio Workflows ist das interessanteste Governance-Ereignis der Power-Platform-2026-Welle-1, und fast niemand liest es so. Die Berichterstattung, die ich gesehen habe, behandelt es als weitere Low-Code-Automation-Fläche: Knoten ziehen, Connector verbinden, dem Diagramm beim Ausfächern zusehen. Das verfehlt die tragende Behauptung, die Microsoft unter den Pixeln macht. Die neue Canvas behandelt LLM-Aufrufe und Connector-Aufrufe als Peer-Primitive und platziert beide in einem Graphen, den die Platform besitzt, auditiert und fortsetzt. Das ist der gesamte Schritt. Der visuelle Designer ist eine Tarngeschichte für eine architektonische Festlegung.

Das ist nicht nur ein neuer Editor. Das ist Microsoft, das schriftlich den Leuten Recht gibt, die zwei Jahre lang argumentiert haben, dass konversationale Agents alleine keinen Kontakt mit einem realen Geschäftsprozess überleben. Den Harness, den Sie in Temporal oder LangGraph von Hand bauten, weil Sie mussten, liefert Microsoft jetzt in derselben Fläche aus, in der Ihr Finance-Team Spesen-Automatisierung baut. Dieselbe Lektion, bezahlt in Copilot-Credits statt Python. War das deterministische Rückgrat um ein LLM 2024 ein umstrittenes Pattern, ist die Fünf-Vendor-Konvergenz 2026 sein Konsensmoment.

Das Pattern, das Microsoft soeben ausgeliefert hat

In Microsofts eigener Rahmung im Copilot-Blog vom April 2026 sind Workflows "schrittweise Automatisierungsprozesse, die Aktionen oder Aufgaben deterministisch und zuverlässig abschließen". Lesen Sie diesen Satz, wie ein Ingenieur ein Postmortem liest. Das Wort "deterministisch" leistet die Arbeit. Es ist die Platform, die so klar zugibt, wie Microsoft je etwas zugibt, dass der konversationale Agent allein es nicht ist. Derselbe Blog positioniert Agents-in-Workflows als die Antwort auf die Unzuverlässigkeit autonomer Agents. Die Lösung ist kein besseres Modell. Die Lösung ist ein Harness.

Die neu gestaltete Canvas, jetzt in Public Preview laut Microsoft Learn, legt einen Peer-Satz von Knotentypen offen, den ich Microsoft bisher nicht auf derselben Fläche habe platzieren sehen: einen Prompt-Knoten (ein einzelner LLM-Aufruf), einen Classify-Knoten (LLM-geroutete Verzweigung mit Few-Shot-Beispielen), einen Agent-Knoten (ein vollständiger Copilot-Studio-Agent als Sub-Schritt), einen M365-Copilot-Knoten (Graph-gegroundete Generierung), einen Request-for-Information-Knoten (durables Human-in-the-Loop) sowie die traditionellen Connector-, Loop-, Variable- und Condition-Blöcke. Der Community-Tutorial-Kanal zur Public Preview (vollständiger Walkthrough auf YouTube) zeigt die praktische Konsequenz: Ein einziger Graph kann ein Shared Mailbox nach Sentiment routen, Erstattungen an einen policy-gegroundeten Agent delegieren, für einen benannten Genehmiger pausieren und beim Ja des Menschen zu einem Connector durchfallen. Keiner dieser Schritte kümmert sich darum, was die anderen sind. Der Graph ist der Vertrag.

Zwei strukturelle Details zählen. Erstens, das Human-Review-Primitiv ist durable: Der Flow pausiert, mailt den Genehmiger und setzt bei strukturierter Antwort fort. Das war früher eine custom Service-Bus-Nachricht und ein Queue-Trigger. Jetzt ist es ein Knoten. Zweitens bedeutet das Agent-als-Knoten-Primitiv, dass ein in einem Workflow eingebetteter Agent nur ein weiterer Schritt ist, mit Inputs, Outputs und einer resumebaren Grenze. Der Graph delegiert Reasoning an einer vorgeschriebenen Stelle an den Agent und nimmt die Kontrolle danach wieder auf. Der Agent ist nicht mehr der Orchestrator. Er ist ein Mieter.

Warum LLM-only-Agents abdriften

Wenn Sie einen LLM-only-Agent in Produktion gebracht und ab Woche zwei beim freien Fall zugesehen haben, kennen Sie den Fehlermodus schon. Das Modell ist konstruktionsbedingt stochastisch. Temperatur null rettet Sie nicht (die ausführliche Version habe ich in einem früheren Beitrag argumentiert): Sampling-Determinismus gibt Ihnen keinen Zustands-Determinismus, und sobald Sie eine Tool-Schleife um den Aufruf legen, haben Sie eine unbegrenzte Zustandsmaschine ohne Backing-Store eingeführt. Der Agent vergisst, wo er war. Der Retry startet von vorn. Der Auditor fragt, was passiert ist, und Sie überreichen ihm ein Chat-Log.

Das deterministische Rückgrat-Pattern löst das mit einem einzigen Schritt: Der Orchestrator wird zu deterministischem Code, das LLM wird zu einer Aktivität, und die Platform checkpointet jeden Zustandsübergang. Temporals eigene KI-Seite argumentiert, dass das nötig ist, weil naive Implementierungen bei transienten LLM-Fehlern allen Fortschritt verlieren und von vorn beginnen müssen. LangGraph modelliert dieselbe Form als State Graph aus Knoten und Kanten mit persistentem geteilten Zustand und bedingtem Routing. Der Graph ist durable. Das LLM ist es nicht. Diese Asymmetrie ist die gesamte Architektur.

💡 Die Lösung für nicht-deterministisches LLM-Verhalten ist kein besseres Modell. Es ist ein deterministischer Graph, der das LLM als einen Knoten in einer resumebaren Zustandsmaschine behandelt, mit Checkpoints zu beiden Seiten und einem Audit-Trail durch die Mitte.

Der Fall für das Rückgrat wird schärfer, wenn Sie Governance hinzunehmen. Ein LLM-only-Agent, der Tool-Calls ausfächert, ist auf keine Weise auditierbar, die ein Enterprise-Compliance-Team akzeptieren würde; das Trace ist ein Token-Strom, der Zustand ist im Prompt, und der nächste Lauf wird nicht dieselbe Form produzieren. Ein Workflow mit dem LLM als einem Knoten ist auditierbar, weil der Graph das Artefakt ist: Jeder Übergang hat einen Zeitstempel, jeder Input hat einen Elternteil, jeder Retry hat eine Ursache. Die Drittpartei-Zusammenfassung auf Help Net Security nennt Copilot Studio "ein KI-Agent-Control-Center", und die Rahmung stimmt aus dem falschen Grund. Das Rückgrat ist das Control Center. Die Governance-UI ist nur die Leseansicht.

Das deterministische Rückgrat, beim Namen genannt

Wenn man das Pattern bei einem Vendor sieht, kann man es bei den anderen nicht mehr übersehen. Dass das dieselbe Architektur unter unterschiedlichen SKUs ist, ist die tragende Beobachtung dieses gesamten Stücks.

# Das Deterministisches-Rückgrat-Pattern, schematisch
spine: # Eigentum der Platform, deterministisch, gecheckpointed
  nodes:
    - id: classify_email
      kind: llm_call            # der einzige nicht-deterministische Schritt in diesem Slice
      retry: { max: 3, backoff: exponential }
      checkpoint_after: true
    - id: route_on_label
      kind: deterministic_branch
      branches: { billing: bill_path, technical: tech_path, sales: sales_path }
    - id: bill_path.draft_reply
      kind: agent_invocation    # Sub-Graph, intern noch nicht-deterministisch
      returns: { draft: string, requires_approval: bool, refund_amount: number }
    - id: bill_path.gate
      kind: human_review        # durable, kann tagelang schlafen
      cond: requires_approval == true
    - id: bill_path.send
      kind: connector_call      # deterministisch, idempotent, mit Nebenwirkung
trace: every_node_transition_to_event_store
resume: from_last_checkpoint_on_worker_crash

Die Form ist an fünf Stellen dieselbe. Temporal: Workflow-Code ist das Rückgrat, Aktivitäten sind die LLM- und Tool-Aufrufe, jeder Zustandsübergang lebt in der Event-History; Temporal misst grob 10 bis 50 Millisekunden Overhead pro Activity-Dispatch für diese Persistenz, was gegenüber LLM-Aufrufen von 1 bis 30 Sekunden vernachlässigbar ist. LangGraph: Knoten und Kanten, persistenter geteilter Zustand, Durable Execution, die bei Fehlern fortsetzt; LangChains eigene Produktseite rahmt es als das Agent-Orchestrierungs-Framework für zuverlässige KI-Agents. AWS: Step Functions für das regelbasierte Rückgrat, Bedrock AgentCore für den KI-nativen Zweig, in Kombination gemäß der AWS Prescriptive Guidance empfohlen. Azure: Durable Task for AI Agents auf der Azure-Functions-Runtime, mit derselben Taxonomie deterministisch-vs-agent-directed, die Microsoft selbst im Agentic-Application-Patterns-Doc formalisiert hat.

Der Microsoft-Tech-Community-Bericht zum Bauen durabler und deterministischer Multi-Agent-Orchestrierungen ist im Kern derselbe Essay wie dieser, geschrieben von Microsoft-Ingenieuren über Microsofts Code-first-Stack. Das Pattern kam zuerst aus der Durable-Execution-Community mit Temporal, traf zweitens AWS und LangChain, drittens Azure im Code und trifft viertens Power Platform im Low-Code. Damit stehen fünf Vendors auf derselben Architektur. Es gibt keinen offensichtlichen nächsten Schritt am Horizont. Das ist der Konsens.

| Vendor | Rückgrat | LLM-Knoten-Primitiv | Durables Resume | Audit-Fläche | |---|---|---|---|---| | Temporal | Workflow-Code | Activity | Event-History | Pro Activity | | LangGraph | State Graph | Knoten | Checkpointer | Pro Zustandsübergang | | AWS Step Functions plus Bedrock | State Machine | Task oder Agent-Invocation | Execution-History | Pro State | | Azure Durable Task | Orchestrator-Funktion | Activity oder Agent | Checkpoint Store | Pro Yield | | Copilot Studio Workflows | Visueller Graph | Prompt, Classify, Agent, M365 Node | Platform-managed | Pro Knoten, im MAC |

Der visuelle Designer ist eine harte Interface-Entscheidung mit echten Kosten (mehr dazu unten), aber die Architektur darunter ist dieselbe Architektur, die ich in den letzten achtzehn Monaten dreimal im Code gebaut habe. Die Copilot-Studio-Variante tauscht Flexibilität gegen Governance: Sie bekommen weniger Notausgänge, einen managed Event Store, das Microsoft-365-Admin-Surface kostenlos und das Connector-Ökosystem von Power Platform als Nebeneffekt. Das Community-Vergleichsstück stuft Agent Flows und Power-Automate-Cloud-Flows auf rund 98 Prozent Capability-Überlappung ein, wobei die Divergenz auf den KI-nativen Knotensatz und die Copilot-Credit-Lizenzierung konzentriert ist. Diese zwei Prozent sind der ganze Punkt.

Aus demselben Bericht stammt ein konsequenter Migrations-Vorbehalt: Die Konvertierung von Cloud Flow zu Agent Flow ist einseitig. Wenn Sie sich auf das Rückgrat festlegen, legen Sie sich darauf fest. Die Rückwärts-Migration wird nicht unterstützt, was ich als Microsoft-Signal lese, dass die Durable-Task-Fläche das strategische Ziel ist und der reine Connector-Cloud-Flow der Legacy-Pfad. Der Release-Plan für 2026 Welle 1 listet Workflows, KI-Aktionen und Governance als die Schlagzeilen-Investitionen in dieser Reihenfolge. Die Roadmap reimt sich mit der Architektur.

Die Fallstudie, mit der Microsoft den Schritt verkauft, Unifi (Aviation Ground Handling), reduzierte die Vertragsbearbeitung von Tagen auf Minuten durch die Kombination von Agents mit deterministischen Workflows. Ich merke an, dass die Tage-zu-Minuten-Zahl keinen veröffentlichten Baseline, keine Fehlerrate, keine Kosten pro Lauf und keine Ende-zu-Ende-Latenz hat, was sie in dieselbe Kategorie stellt wie jede andere Vendor-Fallstudie der letzten fünf Jahre. Nehmen Sie sie als Richtung, nicht als Quantität. Der numerische Anspruch, dem im Primärquellen-Set zu trauen ist, ist der Temporal-eine: 10 bis 50 Millisekunden Overhead pro Activity-Dispatch, gegen LLM-Aufrufe von 1 bis 30 Sekunden. Dieses Verhältnis ist der Engineering-Case für das Rückgrat, in einer Zahl.

Wo die These verliert

Ich würde dieses Argument nicht ohne Nennung der Stellen veröffentlichen, an denen es bricht. Das deterministische Rückgrat hat drei reale Fehlermodi, und so zu tun, als gäbe es sie nicht, wäre unehrlich.

Der erste ist die Decke beim emergenten Reasoning. Die kontrarische Lesart, argumentiert im deepset-Blog, lautet, dass der Wert eines Agents seine Fähigkeit zu Multi-Hop-Reasoning ist, das kein Graph-Autor vorhergesehen hat. Ein vorgezeichnetes Rückgrat schränkt den Entscheidungsraum auf den Graphen ein, den der Autor sich vorstellte. Wenn Ihr Problem von der Art ist, die von emergenten Pfaden durch die Tool-Fläche profitiert (offene Recherche, neuartiges Debugging, kreative Komposition), wollen Sie weniger Schienen, nicht mehr. Das Rückgrat ist die richtige Antwort für eine Customer-Care-Mailbox. Es ist die falsche Antwort für einen Research-Agent, und ich würde keinen Workflow-Graphen gegen ein Problem deployen, dessen Form ich nicht im Voraus aufzählen kann. Die deepset-Rahmung "Spektrum, nicht binär" ist korrekt; das Rückgrat ist ein Ende davon.

Der zweite ist die Low-Code-Versionskontrolle-Story. Ein code-definierter Temporal-Workflow lebt in git, wird in einem Pull Request reviewt, läuft durch Ihre CI, deployed über Ihre Pipeline und rollbackt mit einem Revert. Ein Copilot-Studio-Workflow lebt in der Platform, wird in einem Dialog reviewt, läuft durch einen Publish-Button, deployed sofort und rollbackt über die Version-History-UI. Diese letzte Fläche ist real (Microsoft liefert Compare, Preview und Restore bei jedem Workflow), aber sie ist nicht dasselbe Primitiv wie git revert. Enterprise-DevOps-Kommentare sind seit einem Jahrzehnt konsistent: Low-Code-Platforms sitzen in einer unangenehmen Mitte, zu visuell, um echte Geschäftslogik zu tragen, zu code-lastig, um vom Ops-Team gepflegt zu werden, und die Lücke verbreitert sich bei Skalierung. Die Audit-Fläche ist gut. Die Change-Control-Fläche ist schwächer. Beides ist gleichzeitig wahr.

Der dritte ist die Skalengrenze. Das Rückgrat-Pattern ist am besten, wenn der Graph auf einen Bildschirm passt und das Team jeden Knoten besitzt. Sobald ein Workflow konservativ über 30 bis 40 Knoten wächst, beginnt der Graph sich wie ein Sarg zu verhalten: Jede Änderung birgt eine ungewollte Verzweigung, jeder neue Knoten plädiert für einen neuen Sub-Graphen, und das Diagramm wird zur Dokumentation. Code hat dieses Problem nicht, weil Code Funktionen hat. Visuelle Graphen lösen es mit Sub-Flow-Composition, aber die Disziplin, in einem visuellen Editor gut zu komponieren, ist keine Disziplin, die die meisten Teams haben. Das Blueprint-first-arXiv-Paper (2508.02721) steht auf der Pro-Rückgrat-Seite; die deepset-Kritik auf der anderen. Ich denke, beide haben innerhalb ihrer Reichweite recht.

Wenn Sie zwischen einem code-definierten Rückgrat (Temporal, LangGraph, Durable Task) und einem visuellen Rückgrat (Copilot Studio Workflows) wählen, ist die entscheidende Frage nicht die Architektur. Sie ist, wer das Artefakt besitzt: ein Platform-Team, das in git lebt, oder ein Business-Team, das im Power-Platform-Tenant lebt. Die Architektur ist dieselbe. Der Besitzer nicht.

Was das heißt, wenn Sie 2026 Agents bauen

Wenn Sie dieses Jahr Agents bauen und Ihr Design keinen benannten Harness hat, bauen Sie die Prototyp-Version von etwas, von dem drei Vendors bereits eine Production-Version ausgeliefert haben. Dieser Satz ist schärfer, als er klingt.

  • Hören Sie auf, reine konversationale Agents als Antwort auf mehrstufige Geschäftsprozesse zu pitchen. Sie sind ein Knoten in der Antwort, nicht die Antwort.
  • Wenn Sie auf dem Microsoft-Stack sind und Ihr Problem aufzählbar ist, ist Copilot Studio Workflows jetzt der Default. Agent-only ist die Ausnahme, die Sie rechtfertigen, nicht die Annahme, mit der Sie starten.
  • Wenn Ihr Problem nicht aufzählbar ist, ist das Rückgrat immer noch die richtige Form, aber Sie wollen die code-definierte Variante (Temporal, LangGraph, Durable Task), damit der Graph sich im Tempo von git ändern kann.
  • Entwerfen Sie jeden Agent so, dass er explizite Boolean-Flags zurückgibt (requires_approval, needs_followup, is_terminal), sodass das Rückgrat deterministisch auf Agent-Output verzweigen kann. Freitext-Antworten auf eine Control-Flow-Frage sind ein Kategorienfehler.
  • Behandeln Sie die Workflow-Event-History als System of Record für Agent-Verhalten. Das Chat-Log ist es nicht. Das Trace ist es. Das ist dieselbe Lektion, über die ich für Copilot-Studio-Integration-Patterns geschrieben habe: Die Audit-Story muss in der Platform leben, nicht im Prompt.

Das deterministische Rückgrat ist jetzt Table Stakes. Das Argument der nächsten zwei Jahre wird nicht sein, ob man das LLM in einen Graphen wickelt. Es wird sein, welcher Graph, in welchem Team-Besitz, mit welchen Notausgängen, wenn die Aufzählung falsch ist.

Offene Fragen

Ich beobachte drei Dinge an dieser Fläche, und ich erwarte, dass mindestens eines meine Rahmung ändert.

Das erste ist die Grenze zwischen Copilot Studio Workflows und dem code-first Microsoft Agent Framework, das durable Workflows auf derselben konzeptionellen Basis ausliefert. Microsoft betreibt jetzt sowohl eine Low-Code- als auch eine Code-first-Version derselben Architektur. Die interessante Frage ist, ob die Low-Code-Fläche ein permanentes Produkt ist oder eine Zwangsfunktion, das Durable-Task-Pattern in die Hände der Power-Platform-Install-Base zu bekommen. Ich erwarte die Antwort in den nächsten beiden Release-Wellen.

Das zweite ist Governance unter Fan-Out. Das MAC-Agent-Inventory und die Workflow-Audit-Fläche sind beide gut auf Per-Agent- und Per-Workflow-Basis. Sie sind weniger offensichtlich gut, wenn ein Workflow zehn Agents aufruft, die zehn Workflows aufrufen. Die Kombinatorik zählt; die Audit-Story benennt sie noch nicht. Ich beobachte die Wave-2-Governance-Docs auf ein hierarchisches Trace-Primitiv.

Das dritte ist der Fehlermodus des visuellen Rückgrats bei Skalierung. Ich habe noch keinen Copilot-Studio-Workflow nördlich von 50 Knoten in Produktion gesehen. Das Pattern funktioniert in Demo-Größe; die Frage ist, ob Editor und Versionskontrolle-Story die Größe überleben, die reale Enterprise-Prozesse erreichen. Wenn Sie einen davon betreiben, möchte ich hören, was Sie tatsächlich damit tun.

Ich erwarte, dass Teile davon schlecht altern. Wenn Sie denken, ich liege bei der Grenze zwischen Copilot Studio Workflows und den code-first Agent-Frameworks daneben, oder wenn Sie einen Workflow-Graphen jenseits der 50-Knoten-Grenze betreiben und die Versionskontrolle-Story hält, ist der schnellste Weg, mich umzustimmen, ein konkretes Gegenbeispiel. Erreichen Sie mich unter marcus-duwe.de/contact.