Die Build-vs.-Buy-Entscheidung für Enterprise-KI hat für die meisten Mittelständler eine geklärte Antwort: Modelle kaufen, Integration bauen. Doch diese Antwort wirft sofort die nächste Frage auf — die Integration bauen womit? Mit einer Low-Code-Plattform, die in Tagen liefert, oder mit einem Pro-Code-Framework, das Wochen bis Monate braucht, dafür aber eine architektonische Tiefe erschließt, die früher außer Reichweite lag?
Das ist keine Frage der Technologiepräferenz, sondern eine Architekturentscheidung mit direkten finanziellen Konsequenzen. Wer richtig wählt, geht schneller in Produktion, potenziert Wert über Funktionen hinweg und vermeidet die teure Plattformmigration mitten im Projekt — jenen Moment, in dem ein System Monate nach Start einer strategischen Initiative an seine Decke stößt. Wer falsch wählt, über-engineert entweder einen trivialen Use Case (und verbrennt ein sechsstelliges Budget für etwas, das eine Low-Code-Plattform in einer Woche geliefert hätte) oder unter-engineert einen komplexen — und stellt erst fest, dass der Agent keinen geteilten Speicher führen, keine Cross-System-Logik ausführen oder kein eigenes Governance-Modell tragen kann, nachdem die halbe Organisation bereits Workflows um seine Grenzen herum gebaut hat.
Ein wichtiger Hinweis vorweg, weil sich der Markt 2025 spürbar bewegt hat: Die alte Faustregel „Low-Code kann nur Chatbots, alles Autonome braucht Pro-Code" stimmt so nicht mehr. Microsoft hat Copilot Studio auf der Build 2025 um echte Multi-Agent-Orchestrierung, autonome ereignisgesteuerte Trigger, Agent-to-Agent-Kommunikation, Model-Context-Protocol-Anbindung und „Deep Reasoning" erweitert. Die Grenze zwischen Low-Code und Pro-Code ist damit nicht verschwunden, aber sie verläuft an einer anderen Stelle als noch vor einem Jahr. Dieser Artikel zieht sie neu — entlang dessen, was die Plattformen heute tatsächlich leisten, nicht entlang von Marketing-Versprechen oder veralteten Annahmen.
Eines bleibt unverändert wahr: Die Plattformentscheidung ist sekundär gegenüber dem Workflow-Redesign, das den Wert schafft. Aber die Plattform beschränkt, welches Redesign möglich ist. Man kann einen Prozess nicht um geteilten Agent-Speicher herum gestalten, wenn die Plattform keinen führt; man kann ihn nicht um eigene Eskalationslogik herum gestalten, wenn man nur die vorgegebenen Governance-Bausteine hat. Die Plattform schafft nicht den Wert — aber sie definiert seine Obergrenze.
Der Kern-Trade-off
Low-Code-Plattformen — Copilot Studio, Power Platform und verwandte Tools — tauschen Kontrolle und architektonische Freiheit gegen Geschwindigkeit und Zugänglichkeit. Pro-Code-Frameworks — LangGraph, CrewAI, das Microsoft 365 Agents SDK, das Claude Agent SDK — tauschen Geschwindigkeit gegen Tiefe und Ownership. Keine Seite ist per se überlegen. Die richtige Wahl hängt vom konkreten Use Case ab, von der KI-Reife der Organisation und von der strategischen Ambition für das System, das gebaut wird.
Low-Code optimiert für Time-to-First-Value. Ein Wissens-Agent, der Fragen zu internen Richtlinien beantwortet, kann in wenigen Tagen produktiv sein. Ein Routing-Agent, der eingehende Anfragen per Intent-Klassifikation an spezialisierte Sub-Agenten verteilt, lässt sich in einer Woche konfigurieren. Ein Beschaffungsassistent, der Bestellungen in natürlicher Sprache aufnimmt, ist in zwei Wochen lauffähig. Diese Zeitrahmen sind keine Schönrechnerei — sie sind möglich, weil die Plattform die Infrastruktur abstrahiert: Retrieval-Pipelines, Modell-Hosting, Authentifizierung, Logging und Monitoring kommen mitgeliefert. Im DACH-Mittelstand, wo die Engineering-Kapazität fast immer der Engpass ist, ist das der entscheidende Vorteil.
Pro-Code optimiert für die architektonische Obergrenze. Ein Finanz-Monitoring-System, in dem Research-, Analyse-, Portfolio-, Risiko- und Compliance-Agenten denselben Speicher teilen, Erkenntnisse über Interaktionen hinweg akkumulieren und das Verhalten anderer Agenten überstimmen können, bleibt Pro-Code-Terrain — nicht weil einzelne Bausteine fehlen, sondern weil die Kontrolle über Zustand, Eskalationslogik und Lerndynamik vollständig in der Hand des Teams liegen muss. Solche Systeme brauchen Wochen statt Tage. Sie sind aber auch der Ort, an dem die Wertschöpfung wirklich potenziert. Bain ordnet Agenten-Fähigkeiten im Technology Report 2025 in vier Stufen — von LLM-gestützter Informationsabfrage über Einzelaufgaben-Workflows und Cross-System-Orchestrierung bis zu lose gekoppelten Multi-Agent-Konstellationen — und beobachtet, dass Vorreiter durch das Skalieren der ersten beiden Stufen EBITDA-Verbesserungen im Bereich von 10 bis 25 Prozent erzielten. Entscheidend ist Bains Befund, dass diese Gewinne aus dem Prozess-Redesign und der Datenbereinigung kommen, nicht aus dem Tool allein — und genau diese Arbeit lässt sich nicht überspringen.
Wann Low-Code gewinnt
Es gibt eine substanzielle Kategorie von Enterprise-Use-Cases — bei den meisten Organisationen die deutliche Mehrheit dessen, was sie in den ersten zwei Jahren angehen —, in der Low-Code nicht nur ausreicht, sondern die bessere Wahl ist. Ein Pro-Code-Framework dafür einzusetzen, ist, als engagiere man einen Statiker, um ein Regal aufzuhängen.
Interne Wissens-Agenten. Richtlinien-Q&A, HR-FAQs, IT-Helpdesk, Produktdokumentation, Compliance-Lookup. Hochfrequente Use Cases mit strukturierten Daten, begrenzten Fragetypen und Anforderungen, die das eingebaute RAG der Plattform sauber bedient. Die Copilot-Studio-Bewertung beschreibt im Detail, wie der Knowledge-Bereich Retrieval und Grounding ohne eigene Pipeline übernimmt.
Einfache Routing-Orchestrierung. Ein Master-Agent, der Anfragen empfängt und sie per Intent-Klassifikation an fünf bis zehn spezialisierte Sub-Agenten verteilt — Abrechnung, technischer Support, Terminierung, Retouren, Account-Management. Das Muster ist Hub-and-Spoke, die Routing-Logik überschaubar, die Sub-Agenten haben klare Erfolgskriterien. Genau für dieses Multi-Agent-Pattern hat Microsoft die Orchestrierung in Copilot Studio gebaut: Agenten tauschen Daten aus, delegieren Teilaufgaben und führen Ergebnisse wieder zusammen.
M365-native Workflows. Alles, was in SharePoint, Teams, Outlook oder Azure SQL lebt, profitiert von den vorgefertigten Connectors. Agenten, die Meeting-Notizen aus Teams zusammenfassen, Action Items aus E-Mail-Threads extrahieren oder überfällige Aufgaben in SharePoint markieren, entstehen mit Copilot Studio schneller als mit jedem Framework — die Integrationsarbeit ist bereits erledigt. Für den großen Teil des DACH-Mittelstands, der ohnehin auf Microsoft 365 standardisiert ist, ist das der pragmatische Default.
Citizen-Developer-Enablement. Fachbereiche, die Agenten ohne das Engineering-Team bauen und iterieren. Das Marketing baut seinen Kampagnenanalyse-Agenten, das Controlling seinen Reporting-Agenten, Operations seinen Qualitäts-Monitor — ohne in einer Engineering-Warteschlange zu warten. In einem Umfeld, in dem KI-Engineering-Talent knapp und teuer ist, ist diese Selbstständigkeit ein realer Kraftmultiplikator und keine Komfortfunktion.
Governance-first-Umgebungen. DLP-Policies, Admin-Kontrollen, Connector-Berechtigungen und Audit-Trails sind eingebaut. Für Organisationen in regulierten Branchen, in denen jedes KI-System dokumentierte Kontrolle braucht, sparen diese Bordmittel Monate an Eigenentwicklung — und der Vorteil potenziert sich, weil jeder neue Agent das bestehende Governance-Framework automatisch erbt. Das ist kein kosmetischer Punkt: Ab dem 2. August 2026 greifen unter der EU-KI-Verordnung die Pflichten für Hochrisiko-Systeme und die Transparenzvorgaben. Betreiber müssen menschliche Aufsicht durch kompetente Personen sicherstellen, automatisch erzeugte Logs mindestens sechs Monate aufbewahren und gegebenenfalls eine Grundrechte-Folgenabschätzung durchführen. Eine Plattform, die Logging und Audit-Trails von Haus aus liefert, nimmt einem Teile dieser Pflichten konstruktiv ab.
Wann Pro-Code erforderlich ist
Der verbleibende Teil der Use Cases — die mit dem höchsten Wert und der größten strategischen Differenzierung — verlangt nach Pro-Code. Nicht weil Pro-Code im Abstrakten besser wäre, sondern weil bestimmte Anforderungen die Kontrolle über die Internals voraussetzen, die eine verwaltete Plattform bewusst abstrahiert.
Geteilter Speicher und Lernsysteme. Agenten, die Wissen akkumulieren, Erkenntnisse abteilungsübergreifend teilen und über die Zeit potenzieren. Ein Customer-Intelligence-System, in dem jede Support-Interaktion, jedes Verkaufsgespräch und jedes Produktfeedback eine geteilte Wissensbasis anreichert, aus der alle Agenten schöpfen — ein System, das mit jeder Interaktion klüger wird, statt jedes Mal bei null anzufangen. Das ist die Kernthese des AI Operating System, und sie verlangt volle Kontrolle über das Speicher- und Zustandsmodell, die nur Pro-Code bietet.
Echte Autonomie mit eigener Entscheidungslogik. Plattformen bieten heute zwar ereignisgesteuerte Trigger und autonome, langlaufende Abläufe — ein Agent kann auf ein Ereignis warten und eine definierte Aktionskette auslösen. Der Bruch kommt nicht beim „Auslösen ohne menschliche Konversation", sondern bei der Tiefe und Verlässlichkeit der Entscheidungslogik darunter. Ein Supply-Chain-Agent, der Bestände überwacht, Nachfrageanomalien erkennt, Nachbestellvorschläge gegen Budgetgrenzen und Lieferantenverträge prüft, innerhalb vorab genehmigter Parameter selbst auslöst und Ausnahmen sauber eskaliert — mit nachvollziehbarem, testbarem und versioniertem Verhalten an jedem Entscheidungspunkt — braucht determinierbare Kontrolle über genau diese Logik. Je höher der Einsatz pro Fehlentscheidung, desto eher landet man bei Pro-Code.
Cross-System-Orchestrierung jenseits eines Ökosystems. Copilot Studio orchestriert hervorragend innerhalb der Microsoft-Welt und über Connectors hinaus. Sobald ein Workflow gleichberechtigt SAP für ERP, Salesforce für CRM, ein selbst gehostetes Modell für die Dokumentenverarbeitung (aus Datensouveränitätsgründen) und mehrere Cloud-Umgebungen umspannt, verschiebt sich der Schwerpunkt. Plattformgebundene Lösungen behandeln das eigene Ökosystem erstklassig und alles Übrige als Anhängsel. Wo keine Umgebung „die Heimat" ist, gewinnt ein Framework, das alle gleich behandelt.
Self-Hosting und Air-Gapped Deployments. Unternehmen — gerade in regulierten DACH-Branchen —, bei denen alle Daten und Modelle on-premises oder im eigenen Cloud-Tenant verbleiben müssen. Copilot Studio verarbeitet Daten über die Infrastruktur von Microsoft. Manche Use Cases mit personenbezogenen, finanziellen oder schützenswerten Industriedaten verlangen Verarbeitung strikt innerhalb des Unternehmensperimeters. Pro-Code-Frameworks laufen dort, wo man sie deployt — im eigenen Rechenzentrum, im eigenen Tenant, im abgeschotteten Netz.
Iteratives Reasoning mit eigenen Verifikationsketten. Multi-Agent-Debatte, Verifikationsschleifen, Research-Synthese-Validierungs-Loops. Ein Due-Diligence-System, in dem ein Agent ein Zielunternehmen recherchiert, ein zweiter die Ergebnisse gegen öffentliche Register validiert, ein dritter Diskrepanzen identifiziert und das System iteriert, bis Konsens erreicht ist. Plattformen bieten zunehmend „Deep Reasoning", aber wer die Schleifenführung, die Abbruchkriterien und die Validierungslogik selbst definieren und testen muss, braucht Code.
Custom Governance jenseits von DLP. Governance, die über Data-Loss-Prevention hinaus in geschäftsspezifische Entscheidungsframeworks reicht. Ein System, in dem der Compliance-Agent den Operations-Agenten überstimmen kann, in dem Eskalationspfade nach Deal-Größe und Kundensegment definiert sind, in dem sich Regeln je nach regulatorischer Jurisdiktion ändern — diese Tiefe an Governance-Customizing verlangt Code. Und mit Blick auf die Hochrisiko-Pflichten der EU-KI-Verordnung ab August 2026 ist das kein Nice-to-have: Wo die menschliche Aufsicht, die Protokollierung und die Folgenabschätzung selbst Teil des Produktdesigns sein müssen, gibt Pro-Code die nötige Kontrolle über den Nachweis.
Die hybride Architektur
Die stärkste Position ist nicht Entweder-oder, sondern eine geschichtete Architektur, die jeden Ansatz dort einsetzt, wo er am stärksten ist.
Copilot Studio als geschäftsseitige Schicht. Citizen Developer bauen und iterieren an den Agenten, die den Großteil der alltäglichen Use Cases abdecken. Governance ist eingebaut, das Microsoft-365-Ökosystem angebunden, die Time-to-Value wird in Tagen gemessen. Diese Schicht trägt Wissens-Bots, Routing, Dokumentenassistenz und einfache Automatisierung. Sie ist die sichtbare Schicht — die, mit der Mitarbeitende täglich arbeiten, die die Geschäftsführung in Demos sieht und die Quick Wins und organisatorisches Buy-in erzeugt.
Azure AI Foundry als Brücke. Wenn ein Use Case mehr Modellflexibilität braucht, als Copilot Studio bietet — eine Aufgabe, die ein starkes Reasoning-Modell verlangt, ein kosteneffizientes Modell für Massenklassifikation oder ein eigenes Fine-Tuned-Modell für domänenspezifische Extraktion —, liefert Foundry den von Microsoft gehosteten Mittelweg: Pro-Code in der Fähigkeit, plattformgesteuert in der Infrastruktur. Das richtige Tool, wenn der Engpass die Modellauswahl ist und nicht die architektonische Tiefe.
Pro-Code-Framework darunter für die harten Probleme. Geteilte Speichersysteme, anspruchsvolle autonome Logik, ökosystemübergreifende Orchestrierung, eigene Reasoning-Schleifen — die hochwertigen, hochkomplexen Fähigkeiten, die Level 2 und Level 3 der Integration definieren. Diese Schicht bleibt für die meisten Nutzer unsichtbar. Sie ist der Motor des sich potenzierenden Werts: das Wissen, das über Interaktionen wächst, die autonomen Prozesse ohne menschlichen Anstoß, die funktionsübergreifende Koordination, die kein einzelner Agent leistet.
Die Integrationspunkte entscheiden. Die hybride Architektur funktioniert nur, wenn die Schichten miteinander reden. Die Pro-Code-Schicht zieht aus denselben Quellen wie die Copilot-Studio-Schicht. Die Erkenntnisse des autonomen Monitoring-Agenten tauchen in der Copilot-Studio-Oberfläche auf, wo Mitarbeitende mit ihnen arbeiten. Der geteilte Speicher speist Kontext in die Low-Code-Agenten, sodass diese vom akkumulierten Wissen profitieren, ohne eigenen Code zu brauchen. Das Design dieser Schnittstellen — die API-Verträge, die Datenflüsse, die Event-Trigger, und in welcher Schicht die EU-AI-Act-Logs konsolidiert anfallen — ist die kritische architektonische Arbeit. Sie entscheidet, ob das Hybridmodell ein einheitliches System ist oder zwei entkoppelte Stacks, die zufällig nebeneinanderstehen.
Das Entscheidungsframework
Vier Fragen bestimmen den richtigen Ansatz für jede KI-Agent-Initiative.
Was ist die architektonische Obergrenze des Use Case? Verlangt der Agent geteilten Speicher, anspruchsvolle eigene Autonomielogik, ökosystemübergreifende Orchestrierung oder eigene Verifikationsschleifen — beginnen Sie mit Pro-Code. Verlangt er nichts davon — beginnen Sie mit Low-Code. Im Zweifel starten Sie Low-Code und akzeptieren, später ggf. einen einzelnen Agenten zu migrieren. Diese Migration kostet weit weniger, als jeden Agenten von Tag eins an zu über-engineeren.
Wie reif ist die Organisation? Wer auf Level 1 startet — die KI-Reise mit Assistenten und Copilots beginnt —, sollte mit Low-Code anfangen. Die Quick Wins bauen Fähigkeit auf, das Governance-Framework etabliert sich, und das Team lernt, was KI im eigenen Kontext kann und was nicht. Zu Pro-Code zu springen, bevor die Organisation ihre Workflows, ihre Datenqualität und ihre Governance-Anforderungen versteht, produziert teure Fehlschläge.
Wer baut und wartet das System? Sind die Erbauer Business-Analysten und Citizen Developer, ist Low-Code praktisch alternativlos. Sind es Software-Engineers mit KI-Erfahrung, erschließt Pro-Code Fähigkeiten, die Low-Code nicht erreicht. Lautet die ehrliche Antwort „Wir haben eine Entwicklerin, die mal mit einem Framework experimentiert hat", sind Sie noch nicht bereit für ein produktives Pro-Code-Multi-Agent-System. Talentbereitschaft bestimmt die Plattformwahl stärker als jede technische Evaluation.
Was ist der strategische Zeithorizont? Muss die Initiative in 30 Tagen Wert zeigen, gewinnt Low-Code. Muss das System Wert über Jahre potenzieren, ist Pro-Code gerechtfertigt — weil sich die Investitionen in geteilten Speicher, autonome Logik und Cross-System-Integration über die Zeit auszahlen, nicht sofort. Die kumulierenden Kosten der Untätigkeit gelten auch hier: Wer auf Level 1 verharrt, weil Low-Code bequemer ist, fällt hinter jene zurück, die in Level-2-Fähigkeiten investieren — selbst wenn diese länger zur Rendite brauchen.
Der Fehler, den die meisten Organisationen machen
Der häufigste Fehler ist nicht die falsche Plattform. Es ist, irgendeine Plattform zu wählen, bevor man den Workflow versteht, in dem sie laufen soll. Wer Copilot Studio oder ein Framework auswählt, bevor er den tatsächlichen Workflow abgebildet hat — den realen Prozess, nicht die idealisierte Version —, optimiert das Falsche. Die Plattform verstärkt jeden Workflow, in den man sie setzt. In einen kaputten Prozess deployt, erhält man einen schnelleren kaputten Prozess. In einen neu gestalteten Workflow deployt, erhält man die Transformation, die — wie auch Bain betont — aus dem Prozess-Redesign kommt, nicht aus dem Tool.
Die Reihenfolge ist entscheidend: erst den Workflow verstehen, dann den Zielzustand gestalten, dann die Plattform wählen, die diesen Zielzustand ermöglicht. Nicht umgekehrt.
Ein Fit Call beginnt bei Ihren Workflows, bildet sie auf die drei Level der Integration ab und prüft, ob Ihre aktuelle oder geplante Plattform — Low-Code, Pro-Code oder hybrid — das Wertniveau und die EU-AI-Act-Pflichten trägt, die auf Sie zukommen, bevor die Architekturentscheidung Sie festlegt.
Referenzen: Bain & Company, „State of the Art of Agentic AI Transformation — Technology Report 2025", 2025 (bain.com); Microsoft, „Multi-agent orchestration, maker controls, and more — Copilot Studio announcements at Microsoft Build 2025", Microsoft Copilot Blog, 2025 (microsoft.com); Europäische Union, „AI Act — Article 26: Obligations of Deployers of High-Risk AI Systems", artificialintelligenceact.eu.