Multi-Agent-Systeme im Mittelstand — was SAPs „Autonomous Enterprise" Ihnen über Architektur beibringt

SAP hat auf der Sapphire Anfang Mai 2026 vorgestellt, wie sie sich „Autonomous Enterprise" denken: über 200 spezialisierte Joule-Agenten, die in Finanz, Einkauf, HR, Kundenservice und Supply Chain als Orchester zusammenspielen. Anthropic, Microsoft, NVIDIA und Palantir liefern die Modelle und die Infrastruktur. Das klingt nach Hyperscaler-Theater — Sie haben weder ein eigenes ERP noch 50 Millionen Euro Budget für KI.

Aber: Das Architekturprinzip dahinter ist nicht eine Frage der Unternehmensgröße. Es ist eine Designentscheidung, die Sie ab dem ersten ernst gemeinten KI-Workflow treffen müssen — und die meisten Mittelständler treffen sie 2026 unbewusst falsch. Wer das nachholt, hat in 18 Monaten eine KI-Landschaft, die wächst. Wer nicht, hat eine, die irgendwann gegen ihre eigene Komplexität läuft.

Der zentrale Unterschied: ein Agent vs. viele Agenten

Single-Agent-Architektur. Sie haben eine zentrale KI, die alles kann. „Beantworte Anfragen, schreibe Angebote, klassifiziere Mails, pflege das CRM, analysiere Reports." Es ist der natürliche erste Schritt — und der Sackgassen-Schritt, wenn die Workflows komplex werden.

Das Problem: Ein Agent, der alles kann, kann nichts gut. Sein System-Prompt wird zu einem 8.000-Token-Monster. Jede Anpassung in Workflow A bricht etwas in Workflow B. Logs werden unübersichtlich. Wartung wird zur Detektivarbeit.

Multi-Agent-Architektur. Sie haben spezialisierte Agenten — einer für Lead-Qualifizierung, einer für Angebotsgenerierung, einer für Service-Triage, einer für CRM-Pflege. Jeder hat einen klaren Auftrag, klare Schnittstellen, klare Erfolgsmaße. Eine dünne Orchestrierungs-Schicht entscheidet, welcher Agent welche Aufgabe bekommt.

Das Prinzip ist nicht neu — Software-Architektur predigt seit 30 Jahren Trennung der Belange. Es ist nur 2026 zum ersten Mal in der KI-Welt wirtschaftlich sinnvoll umsetzbar, weil Modell-Calls billig und Orchestrierungs-Tools (LangGraph, Inngest, Temporal) reif geworden sind.

Warum SAPs Ansatz auch für 50-Mitarbeiter-Unternehmen lehrreich ist

Sie sind nicht SAP. Sie brauchen keine 200 Agenten. Aber Sie brauchen die Strukturentscheidung, die SAP getroffen hat. Drei Lehren übertragen sich ohne Skalierungsabschlag.

Lektion 1: Domänen-Trennung statt Funktions-Bündelung. SAP gruppiert Agenten nach Domäne — Finanz, HR, Einkauf — nicht nach technischer Funktion. Das spiegelt, wer im Unternehmen verantwortlich ist. Ihr Mittelstands-Pendant: Ein Agent für Vertrieb (mit Untermodulen Lead/Angebot), einer für Service, einer für Operations. Wenn der Vertriebsleiter ein Problem hat, weiß er, an wen er sich wendet. Bei einem Monolith-Agent wendet er sich an „die IT" — und das ist meist niemand.

Lektion 2: Eine zentrale Orchestrierung. SAP nennt das „Business AI Platform". Im Mittelstand-Maßstab ist das ein dünner Service-Layer (in Ihrem Code, gerne in Next.js) — er entscheidet, wer wann was tut. Diese Schicht ist nicht trivial, aber überschaubar: maximal 1.000 Zeilen Code für eine mittelständische Konfiguration. Ohne sie haben Sie sechs Tools, die nicht miteinander reden — wie die SaaS-Hölle vor KI, nur teurer.

Lektion 3: Modell-Pluralismus. SAP arbeitet mit Anthropic, AWS, Google, Microsoft, NVIDIA — nicht einem Anbieter. Im Mittelstand-Maßstab heißt das: Routing-Layer, kein Modell-Lock-In. Aufgabe A geht zu Claude, Aufgabe B zu GPT, Aufgabe C zu Mistral lokal. Wer das von Anfang an einplant, kann jederzeit optimieren.

Wie eine Multi-Agent-Architektur konkret aussieht

Lassen Sie uns ein realistisches Beispiel durchspielen — ein mittelständischer Handwerksbetrieb mit 60 Mitarbeitern und KI-Ambition.

Agent 1: Lead-Qualifizierung. Nimmt Anfragen aus Web-Formular, Telefon (via Voice Agent) und E-Mail entgegen. Klassifiziert (passt-passt-nicht), reichert mit Firmen-Daten an, schreibt Lead in CRM. Übergibt qualifizierte Leads an Agent 2 oder direkt an einen Menschen.

Agent 2: Angebotsgenerierung. Nimmt qualifizierten Lead plus Anfragedetails, generiert Angebot mit korrekter Kalkulation, holt Freigabe (wenn nötig), sendet PDF an Kunden, legt Folgetermin an.

Agent 3: Voice Agent. Telefonische Erstannahme, qualifiziert, bucht Termine, übergibt Anrufe an Mensch bei Bedarf. Schreibt Anrufprotokolle ins CRM.

Agent 4: Service-Triage. Klassifiziert eingehende Service-Anfragen, beantwortet Standardfragen direkt, eskaliert komplexe Fälle mit Vor-Recherche an Techniker.

Agent 5: CRM-Hygiene. Läuft nachts durch Datenbestand, ergänzt fehlende Felder, identifiziert veraltete Datensätze, meldet Reaktivierungs-Trigger.

Orchestrator. Eine dünne Web-App mit Login, Dashboard, Routing-Regeln, Eskalations-Workflow. Sie sehen, wer was wann macht — und können eingreifen, wenn ein Agent „durchläuft" oder „hängt".

Das ist nicht „SAP für Arme". Das ist eine pragmatische Architektur, die Sie über 3–5 Monate aufbauen, in kleinen Schritten produktiv schalten und über Jahre weiterentwickeln.

Was Mittelständler beim Multi-Agent-Aufbau falsch machen

Drei wiederkehrende Fehler.

Mehrere Agenten ohne Orchestrierung. „Wir haben jetzt drei KI-Tools" reicht nicht. Wenn sie nicht miteinander reden, sind es drei Inseln — und der Aufwand verdoppelt sich, weil dieselben Daten dreimal gepflegt werden.

Modell-Monogamie. „Wir haben uns für ChatGPT entschieden, also läuft alles über ChatGPT." 2024 vernünftig, 2026 ineffizient. Kosten pro Workflow sinken um 40–70 %, wenn Sie pro Anwendungsfall optimal routen.

Keine klare Verantwortlichkeit pro Agent. Wenn niemand „Eigentümer" eines Agenten ist, gibt es keinen, der bei Drift, Fehlern oder neuen Anforderungen handelt. Jeder Agent braucht eine namentlich genannte Person — im Mittelstand oft der Abteilungsleiter — die dafür verantwortlich ist.

Wie Sie das schrittweise aufbauen, nicht als Big-Bang

Niemand startet mit fünf Agenten. Sie starten mit einem, der gut funktioniert.

Monat 1–2: Ein Agent, klar abgegrenzt. Wählen Sie den Workflow mit dem höchsten Schmerz und der klarsten Messbarkeit. Bauen Sie ihn sauber, betreiben Sie ihn drei Monate produktiv.

Monat 4–6: Zweiter Agent — und gleichzeitig die Orchestrierung. Wenn Sie den zweiten Agenten dazustellen, brauchen Sie schon die Orchestrierungsschicht. Genau jetzt — nicht erst beim fünften. Weil das Datenmodell, die Logs, die Eskalationen sonst nicht zueinander passen.

Monat 7–12: Dritter und vierter Agent. Mit etablierter Orchestrierung wird das deutlich schneller. Pro Agent rechnet man jetzt mit 4–6 Wochen, nicht mehr 12.

Ab Jahr 2: Optimierung statt Aufbau. Sie haben eine funktionierende Plattform. Jetzt geht es um Verfeinerung, Routing-Optimierung, Drift-Korrektur — und gelegentlich neue Agenten.

Was passiert, wenn Sie das nicht tun

Sie werden eine Reihe von KI-Tools haben, die einzeln gut funktionieren, aber als System nicht zusammenpassen. In 18–24 Monaten sind das vier Mini-SaaS, zwei eigene Skripte und ein Voice-Agent-Tool eines Drittanbieters, die jeweils ein eigenes Login, ein eigenes Logging, eine eigene Vertrags-Compliance haben. Niemand weiß mehr, welcher Agent die Wahrheit über einen Kunden hat. Die Mitarbeiter wechseln zwischen sieben Oberflächen.

Genau dieses Szenario ist 2026 die häufigste Form von „KI-Erfolg" im deutschen Mittelstand — und es ist eine Schein-Erfolg. Funktional gibt es KI, strategisch gibt es eine Belastung, die in 24 Monaten wieder weg-konsolidiert werden muss.

SAP zeigt im Großen, was im Kleinen genauso gilt: KI wird zum Wettbewerbsvorteil, wenn sie als architektonisches System gedacht wird — nicht als Sammlung von Tools. Wer diese Designentscheidung früh trifft, baut auf einem Fundament. Wer sie nicht trifft, baut Stockwerk für Stockwerk auf Sand.