Stand: 24. Mai 2026

Multi-Agenten-Orchestrierung klingt zunächst nach einem Thema für Forschungslabore oder sehr große Plattformteams. In der betrieblichen Praxis von KMU ist der Begriff jedoch deutlich nüchterner zu verstehen. Es geht um die Frage, wie KI-Arbeit so verteilt wird, dass sie fachlich kontrollierbar, technisch wiederholbar und wirtschaftlich tragfähig bleibt.
Der produktive Einsatz von KI-Agenten unterscheidet sich deutlich vom gelegentlichen Prompt in einem Chatfenster. Sobald mehrere Webseiten, Content-Strecken, Bildvarianten, technische Prüfungen und Dokumentationsschritte zusammenkommen, entsteht ein kleiner Produktionsprozess. Dieser Prozess verbraucht nicht nur Zeit, sondern auch Token, Modellkontingente, Bildbudgets und menschliche Aufmerksamkeit.
Am 24. Mai 2026 wurde ein realer Vormittagslauf über mehrere Firmen-Websites hinweg ausgewertet. Ergebnis dieses Laufs waren 4 Blogartikel und 34 Hero-Bilder. Der entscheidende Punkt war nicht, dass ein System Texte erzeugte. Entscheidend war die Orchestrierung. Ein steuernder Haupt-Agent verteilte Arbeit an spezialisierte Subagenten. Jeder Subagent lief im günstigsten Modell, das für seine Aufgabe ausreichend war. Token-schwere Arbeit wurde auf ein separates OpenAI und Codex Budget ausgelagert. Bilder liefen über ein eigenes Bild-Budget. Die Subagenten meldeten nur kurze Ergebnisberichte zurück, nicht ihre vollständigen Zwischenausgaben.
Für Entscheider in B2B-KMU ist diese Beobachtung relevant, weil sie eine bekannte IT-Frage in den KI-Betrieb überträgt. Nicht das stärkste Werkzeug für jede Aufgabe ist wirtschaftlich. Wirtschaftlich ist eine Architektur, die Leistungsfähigkeit nach Risiko, Schwierigkeit und Wiederholbarkeit dosiert. Genau hier wird IT als Grundlage für KI konkret.
Problem
Wer KI-Agenten ernsthaft für Produktion einsetzt, stößt schnell an zwei Grenzen. Die erste Grenze sind direkte Modellkosten. Ein Top-Modell für jede Aufgabe einzusetzen ist bequem, aber betriebswirtschaftlich schwach. Eine einfache Formatprüfung, eine mechanische Dateiliste oder eine kurze Statusnotiz braucht nicht dieselbe Modellklasse wie eine strategische Argumentation oder eine riskante Codeänderung.
Die zweite Grenze ist der Kontext. In langen Sitzungen sammelt ein Agent immer mehr Material an. Dazu gehören gelesene Dateien, Zwischenergebnisse, Build-Logs, Bildbestätigungen, Recherchefragmente und technische Statusmeldungen. Jeder weitere Schritt muss gegen diesen wachsenden Kontext arbeiten. Dadurch steigen Kosten und kognitive Last. Gleichzeitig sinkt die Präzision, weil relevante Informationen zwischen immer mehr Begleitmaterial liegen.
Im betrachteten Lauf war genau das der Auslöser. Das Token-Budget war fast aufgebraucht. Eine naive Fortsetzung hätte bedeutet, alles in der teuersten Modellklasse und in einer immer längeren Sitzung weiterzuführen. Damit wäre der knappe Hauptkontext weiter belastet worden. Der Produktionsprozess hätte zwar formal weiterlaufen können, aber mit steigenden Kosten und sinkender Steuerbarkeit.
Diese Situation ist für Unternehmen typisch, sobald KI vom Experiment in wiederkehrende Arbeit übergeht. Ein einzelner Text ist selten das Problem. Problematisch wird die Summe aus Planung, Recherche, Generierung, Prüfung, Bildproduktion, Metadaten, Dateipflege und Übergabe. Wenn all diese Schritte im gleichen Kontext und im gleichen Modell stattfinden, entsteht eine verdeckte Quersubvention. Das teure Modell erledigt triviale Arbeit. Der Hauptkontext speichert Material, das für die nächste Entscheidung nicht mehr nötig ist.
Die Kostenlogik ist dabei nicht linear im intuitiven Sinn. Es geht nicht nur darum, dass ein Modell pro Million Tokens teurer ist als ein anderes. Es geht auch darum, dass ein wachsender Kontext immer wieder mitverarbeitet wird. Eine lange Sitzung kann deshalb wirtschaftlich schlechter werden, obwohl jeder einzelne Arbeitsschritt für sich plausibel aussieht.
Für KMU im DACH-Raum ist diese Unterscheidung wichtig. Viele Organisationen betrachten KI-Kosten noch als Werkzeugkosten einzelner Lizenzen. Im Agentenbetrieb entsteht jedoch eine Betriebsarchitektur. Dort zählen Routing, Budgettrennung, Protokollierung und Kontrollpunkte. Ohne diese Architektur droht ein Muster, das aus klassischer IT bekannt ist. Ein leistungsfähiges System wird eingesetzt, aber ohne Betriebsmodell. Es funktioniert kurzfristig, skaliert aber teuer und schwer steuerbar.
Plan
Der Plan bestand aus drei Hebeln. Der erste Hebel war Modell-Routing nach Schwierigkeit. Einfache mechanische Arbeit gehört in ein günstiges Modell. Mittlere Arbeit gehört in ein mittleres Modell. Nur Hochrisiko-Aufgaben oder Aufgaben mit hoher strategischer Dichte gehören in das teure Top-Modell.
Diese Logik ähnelt einer sauberen Rollenverteilung im Unternehmen. Nicht jede Aufgabe gehört auf Geschäftsführungsniveau. Nicht jede Prüfung braucht einen Senior Architect. Gute Organisation entsteht dadurch, dass Verantwortung angemessen verteilt wird. Multi-Agenten-Orchestrierung überträgt diese Organisationslogik auf KI-Arbeit.
Der zweite Hebel war Anbieter-Routing. Token-schwere Generierung wurde auf ein zweites Budget ausgelagert, hier auf OpenAI und Codex. Das schont nicht nur den Kontext des Haupt-Agenten, sondern auch das knappe Hauptbudget. Diese Unterscheidung ist zentral. Kontextdisziplin allein reduziert Unordnung. Anbieter-Routing reduziert zusätzlich die wirtschaftliche Belastung eines bestimmten Kontingents.
Der dritte Hebel war Kontext-Disziplin. Subagenten arbeiteten isoliert und lieferten kurze Berichte zurück. Lange Build-Logs, 30 Bildbestätigungen, ein Commit mit 60 Dateien oder umfangreiche Rohausgaben blieben außerhalb des Hauptkontexts. Der Haupt-Agent behielt damit die Rolle des Koordinators. Er musste Entscheidungen treffen, aber nicht jede operative Einzelheit dauerhaft mitführen.
In einem KMU-Kontext ist diese Trennung besonders wertvoll. Die Geschäftsleitung benötigt nicht jedes technische Detail, sondern verlässliche Entscheidungsvorlagen. Ein IT-Leiter benötigt nicht jede Rohdatei, sondern Befunde, Risiken und nächste Schritte. Genau diese Verdichtung sollte auch eine Agentenarchitektur leisten.
Die Preisbasis wurde transparent geführt. Stand Mai 2026 lagen die genannten Preise bei Claude Opus 4.7 bei 5 USD Input und 25 USD Output je 1 Mio. Tokens, Vertrauensstufe mittel. Claude Sonnet 4.6 lag bei 3 USD Input und 15 USD Output, Vertrauensstufe hoch. Claude Haiku 4.5 lag bei 1 USD Input und 5 USD Output, Vertrauensstufe hoch. GPT-5.2 und GPT-5.2-Codex lagen bei 1,75 USD Input und 14 USD Output, Vertrauensstufe hoch bis mittel. gpt-image-2 in High-Quality mit 1536 mal 1024 Pixeln wurde mit 0,20 USD pro Bild angesetzt, Vertrauensstufe mittel. Der Wechselkurs wurde mit 1 USD rund 0,86 EUR angesetzt, Vertrauensstufe hoch. Preisquellen waren die offiziellen Preislisten von Anthropic unter https://docs.anthropic.com/en/docs/about-claude/pricing und OpenAI unter https://openai.com/api/pricing.
Für die Rechnung wurde bewusst konservativ angenommen, dass rund 80 Prozent Input und 20 Prozent Output anfielen, ohne Cache-Rabatt. Daraus ergaben sich gemischte Sätze von rund 9 USD je 1 Mio. Tokens für Opus, rund 5,40 USD für Sonnet, rund 1,80 USD für Haiku und rund 4,20 USD für GPT-5.2. Diese Werte sind keine Scheingenauigkeit, sondern Rechengrößen für eine nachvollziehbare Einordnung.
Lösung
Der konkrete Lauf zeigte, wie stark diese drei Hebel zusammenwirken. Gemessen wurden bei den Claude-Subagenten 8 Sonnet-Läufe mit zusammen rund 457.000 Tokens, Vertrauensstufe hoch. Diese Läufe umfassten Schreiben, Verifikation, Bild-Pipeline-Steuerung, Recherche und Commit-Arbeit. Zusätzlich lief ein Haiku-Subagent mit rund 100.000 Tokens für die Aktualisierung einer Vault-Notiz, ebenfalls gemessen mit Vertrauensstufe hoch.
Der Haupt-Orchestrator auf Opus wurde bewusst klein gehalten. Er koordinierte und entschied, trug aber nicht die vollständigen Rohausgaben aller Subprozesse. Ergänzend liefen 3 Codex-Läufe auf GPT-5.2 für Texte und ein Bild-Manifest über ein separates OpenAI-Budget. Die Bildproduktion umfasste 34 Bilder über gpt-image-2 und lief ebenfalls über ein separates Bild-Budget.
Aus den konservativen Annahmen ergab sich folgende Größenordnung. Die Sonnet-Arbeit kostete rund 2,50 USD. Die Haiku-Arbeit kostete rund 0,20 USD. Die Codex-Arbeit wurde auf rund 0,40 USD geschätzt. Der Haupt-Orchestrator auf Opus wurde auf rund 1,50 USD geschätzt. Die Bilder kosteten 34 mal 0,20 USD, also 6,80 USD. Der gesamte Lauf lag damit bei rund 11 bis 12 USD, also grob 10 EUR.
Die wichtigste Erkenntnis ist nicht der exakte Centbetrag. Die wichtigste Erkenntnis ist die Verschiebung der Kostentreiber. Sobald konsequent das günstigste ausreichende Modell gewählt wird, ist nicht mehr der Text der größte Kostenposten, sondern die Bildproduktion. In diesem Lauf entfielen 6,80 USD von rund 11 USD auf 34 Bilder. Für Website-Produktion ist das strategisch relevant, weil visuelle Asset-Produktion separat geplant und budgetiert werden sollte.
Der Vergleich mit dem naiven Weg macht den Effekt deutlicher. Wenn dieselbe Arbeitsmenge im teuren Top-Modell und in einer einzigen Sitzung durchgeführt worden wäre, läge der reine Rechenanteil grob beim Zwei- bis Dreifachen. Der Grund ist doppelt. Erstens würde jeder Schritt zum Top-Satz laufen. Zweitens würde der Kontext immer weiter anwachsen und in späteren Schritten erneut verarbeitet.
Die realistische Spanne für den reinen Rechenanteil lag hier bei rund 5 USD verteilt gegenüber rund 10 bis 15 USD naiv. Das entspricht rund 50 bis 65 Prozent Ersparnis beim Rechenanteil. Die Bildkosten bleiben in beiden Fällen gleich. Deshalb wäre es unredlich, die gesamte Ersparnis auf den Gesamtbetrag einschließlich Bilder zu übertragen. Präzise formuliert lautet die Aussage: Die Orchestrierung senkte den Rechenanteil deutlich, während die Bildkosten als eigener Block bestehen blieben.
Der zusätzliche Gewinn war qualitativ. Der knappe Hauptkontext blieb frei genug, damit die Arbeit überhaupt sauber zu Ende geführt werden konnte. Der Haupt-Agent musste nicht 34 Bildbestätigungen, lange Logs und operative Zwischenergebnisse behalten. Er konnte sich auf Koordination, Entscheidungen und Übergabe konzentrieren. Damit wurde aus einer fast ausgeschöpften Sitzung wieder ein steuerbarer Produktionsprozess.
Für Entscheider ist diese Erkenntnis wichtiger als die einzelne Kostentabelle. Multi-Agenten-Orchestrierung ist kein Selbstzweck. Sie ist ein Betriebsmodell für wiederkehrende KI-Arbeit. In der Content-Produktion verteilt sie Recherche, Entwurf, redaktionelle Prüfung und Metadatenpflege. In der Website-Pflege trennt sie technische Prüfung, Bildverwaltung, Textanpassung und Veröffentlichungsvorbereitung. In der Dokumentation kann sie Rohdaten auswerten, strukturieren, prüfen und als kurze Entscheidungsvorlage zurückgeben. In wiederkehrenden Auswertungen kann sie Datenaufbereitung, Interpretation und Berichtserstellung voneinander trennen.
Die Voraussetzung ist eine solide IT-Grundlage. Ohne klare Dateiablage, Rechtekonzept, Protokollierung, Versionierung und definierte Übergaben wird eine Agentenlandschaft schnell unübersichtlich. Genau deshalb ist die Linie “IT als Grundlage für KI” mehr als ein Slogan. Sie beschreibt die Reihenfolge. Erst müssen Daten, Zugriffe, Prozesse und Kontrollpunkte belastbar sein. Dann kann KI diese Prozesse beschleunigen.
KI-Berater Hamburg unterstützt Unternehmen dabei, diese Arbeitsweise konkret aufzusetzen. Dazu gehören eine Agenten-Pipeline für wiederkehrende Aufgaben, ein Modell-Routing nach Schwierigkeit und Risiko, eine saubere Trennung von Text-, Bild- und Hauptbudget sowie einfache Kontrollpunkte für Kosten und Qualität. Der Einstieg muss nicht groß sein. Ein geeigneter Anfang ist eine klar abgegrenzte Produktionsstrecke, etwa Website-Content, Angebotsdokumentation, interne Wissenspflege oder regelmäßige Auswertungen.
Wer KI im Unternehmen wirtschaftlich einsetzen will, sollte deshalb nicht nur nach dem stärksten Modell fragen. Die bessere Frage lautet: Welche Aufgabe braucht welches Modell, welches Budget und welche Rückmeldung? Genau aus dieser Frage entsteht ein belastbarer KI-Betrieb. KI-Berater Hamburg begleitet diesen Aufbau strategisch und technisch, mit Fokus auf KMU im DACH-Raum und mit der nötigen Bodenhaftung für reale IT-Umgebungen. Kontakt und Einordnung über https://ki-berater.hamburg.