Zum Inhalt springen
cd /blog

Orkestra: KI-Agenten im großen Maßstab orchestrieren

[Architektur][Open-Source]

> Ein Orchestrator verteilt Arbeit an spezialisierte KI-Agenten, jeder mit eigenen Skills und eigenem Gedächtnis. Wie Orkestra 46 Agenten und 466 Skills in Produktion koordiniert.

Die Zahlen in diesem Beitrag spiegeln den Stand des Systems zum Veröffentlichungszeitpunkt (Januar 2026) wider. Aktuelle Zahlen findest du auf unserer Team-Seite.

Als wir angefangen haben, mit Claude Code zu bauen, sind wir auf ein Problem gestoßen, dem jedes Team, das KI-Coding-Assistenten nutzt, irgendwann begegnet: Ein einzelner Agent kann nicht alles gut können.

Du kannst einen Agenten zu einem Datenbank-Spezialisten machen. Oder zu einem Security-Auditor. Oder zu einem Frontend-Engineer. Aber in dem Moment, in dem du ihn bittest, alle drei gleichzeitig zu sein, leidet die Qualität. Kontext verwässert. Anweisungen widersprechen sich. Der Agent wird zu einem Generalisten, der in allem mittelmäßig ist.

Also haben wir Orkestra gebaut.

Was ist Orkestra?

Orkestra ist ein Agent-Orchestrierungssystem für Claude Code und ähnliche KI-Coding-Tools. Es koordiniert mehrere spezialisierte Agenten, jeder mit eigener Expertise, unter einem einzigen Orchestrator, der Arbeit an den richtigen Spezialisten routet.

Stell es dir wie eine Personalvermittlung für KI-Agenten vor. Der Orchestrator erhält eine Aufgabe, identifiziert, welcher Spezialist sie bearbeiten soll, und delegiert mit dem richtigen Kontext. Wenn die Arbeit erledigt ist, fließen die Ergebnisse zur Synthese zurück zum Orchestrator.

Die Zahlen erzählen die Geschichte:

Komponente Anzahl
Spezialisierte Agenten 46
Wiederverwendbare Skills 466
Identitäts-Archetypen 27
Mindsets 11
Kommunikationsstile 10
Wissensdomänen 21

Das Charaktersystem: D&D für Agenten

Die Kernerkenntnis hinter Orkestra ist, dass Agent-Verhalten aus drei kombinierbaren Primitiven entsteht:

Identity definiert was der Agent ist. Ein Architect entwirft Systemstrukturen. Ein Debugger verfolgt Fehler zu ihren Grundursachen. Ein Guardian setzt Compliance- und Sicherheitsgrenzen durch. Wir haben 27 Identitäts-Archetypen, die gemischt werden können.

Mindset definiert wie der Agent denkt. Ein analytisches Mindset verankert Aussagen in Evidenz und quantifiziert Unsicherheit. Ein skeptisches Mindset hinterfragt Annahmen und sucht widerlegende Evidenz. Ein exploratives Mindset umarmt Mehrdeutigkeit und probiert mehrere Ansätze.

Style definiert wie der Agent kommuniziert. Ein technischer Style enthält exakte Werte und referenziert konkrete Dateien. Ein knapper Style streicht Füllwörter und führt mit der Antwort. Ein diplomatischer Style balanciert Ehrlichkeit mit Taktgefühl.

Ein Agent kombiniert diese Primitiven:

# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise

Diese Komposition erzeugt einen Agenten, der Systeme entwirft (architect), Wissen über Domänen hinweg verbindet (knowledge-architect), strategische Richtung vorgibt (strategist), in Evidenz und Daten denkt (analytical) und ohne Füllwörter kommuniziert (concise).

Die Stärke liegt in der kombinatorischen Explosion. 27 Identities mal 11 Mindsets mal 10 Styles ergeben fast 3.000 mögliche Agent-Persönlichkeiten. Aber du definierst nur die Kombinationen, die für deine Arbeit zählen.

Skills: Wiederverwendbare Capability-Module

Skills sind das Wissen und die Workflows, die Agenten aufrufen können. Sie folgen einem gestuften System basierend auf Geltungsbereich:

Tier Name Geltungsbereich Beispiel
K0 Foundations Universelle Methodik Test-First-Disziplin, evidenzbasierte Fertigstellung
K1 Identities Rollenbasierte Workflows CLI-Schnittstellenstandards, Performance-Leitfaden
K2 Domains Domänenspezifisches Wissen Datenbank-Migrationsmuster, Authentifizierungs-Validierung
K3 Stacks Technologiespezifisch Cloudflare-Deployment, Supabase-Operationen
K4 Project Nur diese Codebase Projektspezifische Workflows und Konventionen

Skills werden Lazy-Loaded. Ein Agent sieht Skill-Namen und -Beschreibungen beim Start, aber der vollständige Skill-Inhalt lädt erst, wenn er ausgelöst wird. Das hält den Kontext schlank, während Hunderte von Skills auffindbar bleiben.

Jeder Skill enthält:

  • Klare Auslösebedingungen („Verwenden, wenn Datenbankschemas migriert werden“)
  • Schritt-für-Schritt-Anleitung
  • Erlaubte Tools für den Workflow
  • Erfolgskriterien und Recovery-Pfade bei Fehlern

Die 466 Skills in unserer Registry decken alles ab, von Git-Worktree-Isolation über Web-Research-Workflows bis zu Deployment-Health-Validierung.

Warum Orchestrierung wichtig ist

Single-Agent-Architekturen stoßen schnell an Grenzen:

Kontext-Verwässerung. Ein 200k-Token-Kontextfenster klingt groß, bis du Datenbankschemas, API-Dokumentation, Test-Fixtures und Domänenwissen lädst. Spezialisten können mit gezieltem Kontext arbeiten.

Widersprüchliche Anweisungen. Einem Agent zu sagen, „sei gründlich, aber schnell“ und „verifiziere alles, aber übertreibe es nicht“, erzeugt Spannung. Spezialisten lösen das, indem sie einen klaren Scope haben.

Expertise-Tiefe. Ein Generalist-Agent weiß ein bisschen über alles. Ein Spezialist-Agent, komponiert mit der richtigen Identity und den richtigen Skills, kennt seine Domäne tiefgehend.

Orkestra implementiert flache Orchestrierung: Ein Orchestrator koordiniert mehrere Spezialisten. Spezialisten können keine Sub-Spezialisten erzeugen. Das verhindert eine Komplexitätsexplosion, während parallele Arbeit möglich bleibt.

Der Orchestrator hat Zugriff auf 2,2 Millionen Token effektive Kapazität: sein eigenes 200k-Fenster plus 10 gleichzeitige Subagents mit je 200k. Arbeit, die einen einzelnen Agent erschöpfen würde, läuft komfortabel über die gesamte Flotte.

Die Rendering-Pipeline

Agent-Definitionen leben in YAML. Claude Code liest Markdown. Orkestra überbrückt diese Lücke mit einer deterministischen Rendering-Pipeline:

YAML Registries → Jinja Templates → .claude/agents/*.md

Operatoren bearbeiten die YAML-Quelle. Führen orkestra sync aus. Gerendertes Markdown erscheint in .claude/agents/. Claude Code übernimmt die Änderungen.

Diese Trennung bedient unterschiedliche Zielgruppen:

  • YAML-Quelle enthält Lifecycle-Metadaten, Tags, Validierungsregeln und Deprecation-Hinweise für Tooling
  • Gerendertes Markdown enthält nur, was das Modell braucht: Beschreibung, Tools, Skills und Verhaltensanleitung

Die Pipeline komponiert Identities, Mindsets, Styles und Skills zu einem einzigen kohärenten Prompt. Ein architect-analytical-concise-Agent bekommt einen ganz anderen System-Prompt als ein debugger-skeptical-technical-Agent, selbst wenn sie einige zugrunde liegende Skills teilen.

Domänenwissen: Das Vier-Datei-Muster

Jede Wissensdomäne folgt einer konsistenten Struktur:

domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes

Diese Struktur dient dem Laden von Agent-Kontext. Ein Agent, der an Authentifizierung arbeitet, lädt authentication/patterns.md für Anleitung und authentication/anti-patterns.md, um bekannte Fallstricke zu vermeiden. Die Dateien sind auf effizientes Kontext-Laden zugeschnitten: fokussiert genug, um nützlich zu sein, umfassend genug, um maßgeblich zu sein.

Wir pflegen 21 Top-Level-Domänen einschließlich Analytics, Authentifizierung, Datenwissenschaft, Infrastruktur, Machine Learning, Performance, Security und mehr. Jede Domäne kann Sub-Domänen für feinere Granularität haben.

Values: Das Betriebssystem

Alle Agenten teilen eine Basisschicht an Values, die definieren, wie sie operieren:

Einfachheit zuerst. Verwende die einfachste Lösung, die funktioniert. Füge Komplexität nur hinzu, wenn sie gerechtfertigt ist.

Grundursachen beheben. Nie um Fehler herumpatchen. Wenn eine Pipeline fehlschlägt, debugge die Pipeline. Wenn ein Test fehlschlägt, repariere den Code oder den Test.

Evidenzbasiert. Kennzeichne Behauptungen als „verifiziert“ (mit Benchmarks) oder „geschätzt“ (mit Annahmen). Ein erkanntes Muster ist nicht gleich ein bestätigtes Problem.

Context-Ökonomie. MCP-Tools kosten 0,1 % des Kontexts. Datei-Reads kosten je 2 %. Wende Domänenexpertise an, bevor du Code erkundest.

Diese Values pflanzen sich über die Rendering-Pipeline zu jedem Spezialisten fort. Ein Agent kann sie nicht durch Komposition umgehen.

CLI: Die Steuerungsebene

Orkestra wird mit einer CLI zur Verwaltung des Agent-Ökosystems ausgeliefert:

# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"

Die CLI ist die Quelle der Wahrheit dafür, welche Agenten existieren, welche Skills sie haben, und ob das System gesund ist. Sie führt Validierung vor dem Sync aus, um Probleme früh zu erkennen.

Open-Source-Überlegungen

Wir haben Orkestra gebaut, um unser eigenes Problem zu lösen: KI-Agenten im großen Maßstab für eine komplexe Codebase zu koordinieren. Die Muster, die wir entdeckt haben, sind nicht spezifisch für unsere Domäne.

Das Character-Kompositionssystem (Identity + Mindset + Style) gilt für jedes Team, das Agent-Persönlichkeiten definiert.

Das Skill-Tier-System (K0–K4) liefert ein mentales Modell zur Organisation wiederverwendbarer Capabilities nach Geltungsbereich.

Das Rendering-Pipeline-Muster (YAML-Quelle + Templates + generierte Artefakte) trennt Belange zwischen Tooling und Modell-Konsum.

Das flache Orchestrierungsmodell (ein Koordinator, viele Spezialisten) vermeidet Komplexität, während es Parallelität ermöglicht.

Ob Orkestra Open Source wird, hängt davon ab, ob diese Muster für andere, die mit Claude Code bauen, einen Wert haben. Wenn du an die Grenzen stößt, die wir beschrieben haben, könnte die Architektur helfen.

Was wir gelernt haben

Der Bau von Orkestra hat uns gelehrt, dass es bei Orchestrierung nicht darum geht, Agenten intelligenter zu machen. Es geht darum, sie fokussierter zu machen.

Ein einzelner Agent mit perfekten Anweisungen läuft trotzdem aus dem Kontext heraus. Ein einzelner Agent mit allen Skills wird trotzdem verwirrt darüber, welchen er anwenden soll. Ein einzelner Agent, der versucht, alles zu sein, produziert überall mittelmäßige Ergebnisse.

Vierzig Spezialisten, jeder exzellent in seiner Domäne, koordiniert von einem Orchestrator, der weiß, wann er delegieren muss: So liefern wir aus.

Die Zahlen zählen weniger als die Architektur. Du brauchst vielleicht fünf Agenten oder fünfzig. Das Prinzip bleibt: Komposition vor Capability, Spezialisierung vor Generalisierung, Koordination vor individuellem Heldentum.


Orkestra treibt das Agent-Ökosystem hinter Maguyva an, unserer Code-Intelligence-Plattform. Willst du mehr erfahren? Kontaktiere das Team.

Weiterführende Artikel

Mehr aus dem Maguyva-Buildlog