Orkestra: KI-Agenten im großen Maßstab orchestrieren
> 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
Warum wir unsere Code-Suche auf voyage-4-large upgegradet haben_
Wir haben unsere Code-Embeddings auf voyage-4-large umgestellt — aktuell die Nummer eins im öffentlichen RTEB-Code-Retrieval-Leaderboard. Die ehrliche Version: der Trade-off, den wir eingehen, was wir tatsächlich indizieren, und warum wir für Premium-Embeddings bezahlen.
Language Recursive Self-Improvement: Code Intelligence über ~280 Sprachen hinweg grinden_
Wir unterstützen Code Intelligence für ~280 Sprachen. Das kann kein Mensch von Hand auditieren. Also haben wir eine Language-Recursive-Self-Improvement-Loop gebaut — Stichprobe, LLM-as-Judge, eine Sache reparieren, erneut validieren — und lassen sie mit einer Flotte isolierter Agenten laufen, bis die Extraktion tatsächlich stimmt, nicht nur grün ist.
Multi-Modal Fusion Search: Für jede Query den richtigen Retriever wählen_
Eine Query wie 'wo ist parseConfig definiert' braucht eine andere Suche als 'wie funktioniert Auth'. Maguyva klassifiziert die Intention, gewichtet vier Retrieval-Modalitäten entsprechend und fusioniert die Ergebnisse mit gewichteter Reciprocal Rank Fusion.