v2.2.0 to v3.1.0

+ version: 3.1.0

+ updated: 2026-10-11

+ description: Rollenbasierte Multi-Modell-Strategie. Modellkatalog liegt in einer lokalen Konfigurationsdatei statt im Skill-Text -- Rollen (Denker/Entscheider, Dauer-Worker, Entwurfsgenerator, Reviewer/Abnahme, Eskalation), Reasoning-Effort als eigene Achse, Abnahmepflicht für Entwurfsmodelle, Anbieterwechsel für unabhängige Reviews, Kontingente, Delegationsablauf und Kosten/Qualität kleiner Worker.

+ tags: [model-switching, orchestration, multi-model, cost-optimization, routing, cross-agent, advisor, roles]

+ > Rollenbasierte Multi-Modell-Strategie: Konfiguration statt Textkatalog, Rollen statt starrer

+ > Score-Tabelle, Abnahmepflicht für Entwürfe, Anbieterwechsel für unabhängige Reviews.

+ ## 0. Konfiguration

+ **Modelle gehören nicht in diesen Text.** Welche konkreten Modelle, Provider und Aufrufwege

+ gerade existieren, ändert sich schneller als ein Skill sinnvoll gepflegt werden kann — und ist

+ pro Nutzer verschieden. Dieser Skill beschreibt deshalb nur **Rollen und Prinzipien**; der

+ tatsächliche Katalog lebt in einer Konfigurationsdatei im Skill-Ordner.

+ ### Ladereihenfolge

+ 1. **Lokale Datei** im Skill-Ordner: `models.local.json` oder `models.private.json` (beide

+ Namensmuster sind in der `.gitignore` dieser Bibliothek bereits als privat erfasst,

+ `skills/**/*.local.*` bzw. `skills/**/*.private.*` — nie veröffentlichen, nie committen).

+ Wenn vorhanden, ist das der maßgebliche Katalog.

+ 2. **Beispieldatei** `models.example.json` im selben Ordner — neutrale Platzhalter-Vorlage, die

+ das Schema zeigt. Dient nur als Vorlage zum Anlegen der eigenen lokalen Datei, nicht als

+ Katalog für echte Läufe.

+ 3. **Live-Erhebung**, wenn beide Dateien fehlen oder unvollständig sind: welche Modelle bietet

+ die aktuelle Runtime tatsächlich an (z. B. das `model`-Enum eines nativen Subagenten-Werkzeugs,

+ `codex debug models --bundled`, eine App-eigene Modellliste)? Ein geratenes Modell ist

+ schlechter als ein kurz erhobenes.

+ **Bei Widerspruch gilt die Live-Messung.** Eine Konfigurationsdatei kann veraltet sein (ein

+ Modell wurde abgeschaltet, umbenannt oder ersetzt); eine frische Messung an der Runtime selbst

+ schlägt jede Textquelle, inklusive der eigenen lokalen Konfiguration. Widerspruch kurz benennen

+ und die Konfigurationsdatei danach aktualisieren, statt ihn stillschweigend zu übergehen.

+ **`deprecated: true` heißt: nie einsetzen.** Ein als `deprecated` markierter Katalogeintrag

+ bleibt aus Erkennungs-/Historiengründen stehen (damit ein Agent eine alte Erwähnung einordnen

+ kann), wird aber für keine neue Aufgabe mehr gewählt — auch nicht als Fallback.

+ ### Schema (siehe `models.example.json`)

+ Jeder Katalogeintrag trägt: `id`, `provider`, `invoke` (Aufrufmuster, keine echten Pfade im

+ Beispiel), `effort_levels`, `roles` (siehe Abschnitt 1), `strengths`, `weaknesses`, `guardrails`

+ (Zuverlässigkeits-Einschränkungen wie „nur Entwurf", „nicht selbst ins Dateisystem schreiben",

+ „enge Abnahme" — siehe Abschnitt 3), `budget_hint` (Verweis auf den Skill `budgetierung`),

+ `verified` (Verfügbarkeit in der eigenen Runtime belegt, siehe Abschnitt 5) und `deprecated`.

+ ## 1. Rollen statt starrer Modell-Hierarchie

+ Eine Modellwahl beantwortet zuerst **welche Rolle** eine Aufgabe braucht, danach erst welches

+ konkrete Modell diese Rolle aktuell am besten/günstigsten füllt. Rollen sind stabiler als

+ Modellnamen — ein Modell wird ausgetauscht, die Rolle bleibt.

+ | Rolle | Frage | Typisches Merkmal |

+ |---|---|---|

+ | **Denker/Entscheider** | Architektur, Strategie, mehrdeutige Anforderungen, Abwägung von Alternativen | teurer, wird gezielt statt durchgehend eingesetzt |

+ | **Dauer-Worker** | laufende Umsetzung über viele Schritte: Implementierung, Debugging, Standardaufgaben | güns­tig genug, um durchgehend zu laufen |

+ | **Entwurfsgenerator** | schnelle erste Fassung (Design, Text, Code, Struktur, Übersetzung) | schnell, aber grundsätzlich mit Abnahmepflicht (Abschnitt 3) |

+ | **Reviewer/Abnahme** | prüft Ergebnisse anderer Modelle | wirkt am stärksten bei einem anderen Anbieter als der Ersteller (Abschnitt 4) |

+ | **Eskalation** | wird nur für den einzelnen schwierigsten Schritt hinzugezogen | nie für den ganzen Lauf, immer kurz begründet |

+ Ein Modell kann mehrere Rollen tragen (z. B. gleichzeitig Dauer-Worker und gelegentlicher

+ Reviewer). Welche Modelle welche Rollen aktuell füllen, steht in der Konfiguration

+ (Abschnitt 0), nicht hier. Zur kleinsten Worker-Klasse (Kosten pro Auftrag, Qualität

+ je Aufgabentyp) siehe Abschnitt 7.

+ ### Grobe Schwierigkeits-Orientierung (keine feste Tabelle)

+ Eine Score-Rechnung über feste Dimensionen (Klarheit, Komplexität, Kreativität, Kontext,

+ Kritikalität) kann als **grobe Orientierung** dienen, um zwischen Dauer-Worker und

+ Denker/Eskalation zu unterscheiden — sie ist kein verbindlicher Mechanismus, der ein Modell

+ automatisch bestimmt:

+ SCORE = (10 - KLARHEIT) + KOMPLEXITAET + KREATIVITAET + KONTEXT + KRITIKALITAET (je Dimension 0-10)

+ Niedriger Score → Dauer-Worker oder sogar ein günstiges/token-freies lokales Modell reicht.

+ Hoher Score (durchgehend widersprüchliche Anforderungen, mathematische Beweisführung, Statistik

+ mit weitreichenden Konsequenzen) → Denker/Eskalation, meist mit anschließendem Review. Dazwischen

+ liegt der breite Normalfall des Dauer-Workers. Die konkrete Schwelle, ab der eskaliert wird,

+ hängt vom aktuellen Katalog ab (manche Nutzer haben nur zwei, andere sechs Rollen-Füllungen) und

+ gehört deshalb nicht in eine feste Tabelle in diesem Text.

+ ## 2. Reasoning-Effort als eigene Achse

+ Reasoning-Effort (z. B. `low`/`medium`/`high`/`xhigh`/`max`, oder eine feinere/andere Staffelung

+ je Anbieter) ist eine **von der Modell-/Rollenwahl unabhängige Achse**: Erst ein fachlich

+ geeignetes, live verfügbares Modell für die Rolle wählen, dann seine Denktiefe passend zur

+ Schwierigkeit staffeln.

+ - Niedrige Stufen für Routine und gut definierte Teilaufgaben.

+ - Hohe Stufen für Wissenschaft, Beweisführung, Architekturentscheidungen mit Tragweite.

+ - Eine Breitenroute (parallele, klar getrennte Teilaufgaben statt mehr Tiefe in einem Strang)

+ nur, wenn die aktuelle Runtime dafür einen eigenen Modus anbietet und die ohnehin geltende

+ Bestätigungs-/Kostenregel für größere oder schwer kalkulierbare Fan-outs erfüllt ist.

+ **Keine Effort-Stufe erweitert Schreib-, Kosten-, Freigabe- oder Publikationsrechte.**

+ Delegationen bleiben innerhalb der bestehenden Autorität (siehe Abschnitt 5). Ist eine Stufe in

+ der aktuellen Runtime nicht verfügbar, wird das benannt und auf eine belegt verfügbare Stufe

+ ausgewichen — nicht stillschweigend das billigere Verhalten als Erfolg gemeldet.

+ Lang laufende oder rechenintensive Einzelschritte gehören — unabhängig von der Effort-Stufe —

+ auf den dafür vorgesehenen Compute-Host, nicht auf die lokale interaktive Maschine; die Schwelle

+ dafür ist eine Umgebungsregel, keine Modellstrategie-Regel.

+ ## 3. Abnahmepflicht für Entwurfsmodelle

+ Modelle in der Rolle **Entwurfsgenerator** liefern grundsätzlich einen Entwurf, keine fertige

+ Lieferung — unabhängig davon, wie gut der erste Eindruck ist. Das ist keine pauschale Abwertung

+ eines einzelnen Modells, sondern eine Eigenschaft der Rolle: schnelle erste Fassungen sind

+ wertvoll, weil sie schnell sind, und genau deshalb fehleranfälliger.

+ Daraus folgen drei feste Regeln, unabhängig vom konkreten Modell:

+ 1. **Jeder Entwurf wird vor Übernahme geprüft** — durch ein Dauer-Worker- oder Reviewer-Modell,

+ nie durch bloßes Vertrauen in die Entwurfsqualität.

+ 2. **Ein Entwurfsmodell schreibt bevorzugt nicht selbst in das Zielsystem** (Zieldateisystem,

+ Produktionsdatenbank, veröffentlichter Ort). Es liefert das Ergebnis zurück; ein geprüftes

+ Modell setzt es ein. Diese Guardrail steht konkret im jeweiligen Katalogeintrag

+ (`guardrails`), weil sie je Werkzeug unterschiedlich technisch umgesetzt wird.

+ 3. **Fachlich enge Bereiche** (z. B. LaTeX, Rechts- oder Zahlentexte, sicherheitsrelevanter Code)

+ bekommen eine **engere** Abnahme als allgemeiner Text, auch wenn das Entwurfsmodell dort

+ erfahrungsgemäß gut abschneidet.

+ ---

+ ## 4. Anbieterwechsel für unabhängige Reviews

+ Ein Review ist am aussagekräftigsten, wenn Ersteller und Prüfer **nicht denselben Anbieter und

+ nicht dasselbe Modell** nutzen — sonst teilen sie möglicherweise dieselben blinden Flecken.

+ - **Review-Muster:**

+ | Muster | Wie es funktioniert | Wann einsetzen |

+ |---|---|---|

+ | **Session-Advisor** | Nutzer setzt einen Reviewer in der laufenden Session, Agent ruft ihn gezielt | Standard bei Beweis/Architektur |

+ | **Orchestrator-als-Reviewer** | das stärkere/koordinierende Modell reviewt den Output eines Worker-Subagenten | Orchestrator ist ohnehin leistungsfähiger als der Worker |

+ | **Gegen-Agent / Anbieterwechsel** | Modell A (Anbieter 1) arbeitet, Modell B (Anbieter 2) prüft adversarial | unabhängige Verifikation, zwei Perspektiven, höchste Aussagekraft |

+ | **Empfehlung statt Eigenausführung** | Agent empfiehlt explizit: „diese Aufgabe mit Rolle Eskalation + Review bearbeiten" | aktuelle Session ist für den Schritt zu schwach |

+ - **Wann Review einsetzen:** mathematische Beweisführung, Architekturentscheidungen mit

+ langfristigen Konsequenzen, statistische Methodik/Studiendesign, komplexe Bugs nach mehreren

+ erfolglosen Debug-Zyklen, jeder Entwurf aus Abschnitt 3.

+ - **Wann kein Review nötig ist:** Routine-Code, Content, Formatierung; gut definierte,

+ unkritische Aufgaben im Rahmen eines bereits geprüften Vorgehens.

+ - **Dokumentierte Schwächen bleiben in der Konfiguration, nicht hier** — z. B. „Modell X ist für

+ mathematische Reviews ungeeignet" gehört als `weaknesses`-Eintrag in den Katalog, weil er sich

+ mit dem Modell ändert, nicht mit dem Skill.

+ ## 5. Rechte hängen am Auftrag, nicht am Modell

+ Es gibt bewusst **keine Berechtigungsmatrix nach Modellname** (welches Modell darf löschen,

+ welches Systembefehle ausführen). Eine solche Matrix suggeriert, Rechte seien eine Eigenschaft

+ des Modells — sie sind eine Eigenschaft des **Auftrags und der erteilten Autorität**:

+ - Was ein Agent lesen, schreiben, löschen oder ausführen darf, ergibt sich aus der aktuellen

+ Runtime-Sandbox, dem Scope des Auftrags und einer etwaigen Nutzerfreigabe — nicht daraus, ob

+ gerade ein teures oder ein günstiges Modell antwortet.

+ - Guardrails im Katalog (`guardrails`-Feld) sind **Zuverlässigkeits-Hinweise**, keine

+ Rechteerweiterung oder -beschränkung: „nur Entwurf" sagt, wie sehr dem Ergebnis zu trauen ist,

+ nicht, was technisch erlaubt wäre.

+ - Eine Delegation (an einen Subagenten, einen externen Agenten, ein anderes Modell) bleibt

+ innerhalb der Autorität des delegierenden Laufs. Sie erweitert nichts.

+ ### Eskalation und De-Eskalation (Muster, nicht Modellnamen)

+ - **Nach oben (Rolle wechselt zu Denker/Eskalation):** Architektur-Entscheidung gefordert,

+ mehrere Systeme müssen integriert werden, Anforderungen widersprüchlich/unklar, strategische

+ Planung nötig, kritischer Bug nach mehreren erfolglosen Zyklen.

+ - **Lateral (andere Rolle, gleiche Ebene):** fachfremde Recherche, unabhängiges Review,

+ Spezialwerkzeug eines anderen Anbieters.

+ - **Nach unten (De-Eskalation):** Konzept ist definiert → Dauer-Worker übernimmt Umsetzung;

+ Aufgabe ist trivial/repetitiv → ein günstigeres Modell übernimmt; reine Textaufgabe ohne

+ Werkzeugzugriff → ein lokales/token-freies Modell übernimmt, falls im Bestand verfügbar und

+ belegt (`verified: true` im Katalog).

+ ### Transparenzregel bei Modellwechsel

+ **Ein stiller Modellwechsel gegenüber der konfigurierten Besetzung ist zu melden.** Wählt eine

+ Runtime aus eigenem Antrieb (Kontingent, Verfügbarkeit, interner Default) ein anderes Modell als

+ in `models.local.json`/`models.private.json` festgelegt, ist das kein Fehler, aber es gehört

+ transparent benannt — nicht stillschweigend als Erfolg der geplanten Strategie gemeldet. Das

+ gilt unabhängig davon, welche zwei Modelle konkret betroffen sind; frühere Fassungen dieses

+ Skills nannten hier ein bestimmtes Modellpaar als Präzedenzfall — die Regel ist seither bewusst

+ neutral gehalten, weil sie nicht an einem einzelnen Modellwechsel hängen soll.

+ ## 6. Kontingente, Ablauf und Rollenzuschnitt — Verweise statt Doppelpflege

+ Dieser Skill beantwortet **welche Rolle** und **mit welcher Sorgfalt (Effort, Review)**. Zwei

+ benachbarte Fragen werden bewusst nicht hier beantwortet, um Doppelpflege zu vermeiden:

+ - **„Wie oft darf ich ein teures/knappes Modell einsetzen?"** → Skill `budgetierung`: Aushandlung

+ von Kontingenten je Zeitfenster, laufendes Konto, Puzzleteil-Vorverfahren vor Eskalation.

+ `budget_hint` im Katalog verweist genau hierhin.

+ - **„Wie zerlege ich die Aufgabe, delegiere ich Arbeitspakete und nehme ich Ergebnisse ab?"** →

+ Skill `orchestrator` (Protokoll zum Zerlegen, Beauftragen, Abnehmen) bzw. Skill

+ `choose-your-orchestrator` (wenn die passende Orchestrierungsform selbst erst ausgehandelt

+ werden muss — Session-Vertrag für Modellslots, Parallelität, Spawn-Tiefe, Schreibgrenzen,

+ Abnahme, Eskalation).

+ ## 7. Kleine Worker (Haiku-Klasse): Qualität und Kosten pro Auftrag

+ Messung 2026-10 (Haiku 5.5, `claude-haiku-5-5`; Familie damals Fable 5.1, Opus 5.5, Sonnet 5.5,

+ Haiku 5.5; rund 30 Einsätze, gegen Sonnet 5.5 verglichen). Preise je Mio. Tokens (Stand 2026-10-06):

+ Haiku 5.5 $0,10/$0,50 (bis 100k Prompt), Sonnet 5.5 $2/$10, Opus 5.5 $4/$20 — pro Token ≈ 1/20

+ Sonnet, 1/40 Opus. Preise und Befunde veralten mit den Modellen: bei Abweichung gilt die frische

+ Messung (Abschnitt 0).

+ **Effizienz-Falle: billig pro Token ≠ billig pro Auftrag.** Ein Haiku-Subagent im Claude-Code-Harness

+ kostet ~180–360k Tokens je Auftrag, auch für eine 193-Zeilen-Datei. Die Grundlast (~45–65k Tokens

+ je Turn) stammt aus dem Harness (Skill-/Agenten-/MCP-Listen, Start-Hooks), nicht aus der

+ Projekt-`CLAUDE.md` (Wiederholung nach Kürzung der Regeldatei: 186k → 182k). Gegenmittel:

+ - **Bündeln:** mehrere Teilaufgaben je Worker, damit die Grundlast nur einmal anfällt; nie ein

+ Subagent je Dokument.

+ - **Naiver Headless-Worker** für Massenaufgaben mit fester Eingabe: `claude -p --model haiku

+ --strict-mcp-config --mcp-config '{"mcpServers":{}}' --disable-slash-commands --tools Read,Write`

+ → gemessen $0,018 je README-Übersetzung (gleiches Tokenprofil: Sonnet ≈ $0,35, Opus ≈ $0,66).

+ `--bare` (ohne `CLAUDE.md` und Hooks) spart weiter, braucht aber einen API-Key. Bei sehr großen

+ Mengen API/Batch statt Subagent.

+ - **Ergebnis als Datei plus Meldung von 3–5 Zeilen**, wenige Tool-Aufrufe.

+ **Qualität je Aufgabentyp (gemessen):**

+ | Aufgabentyp | Befund |

+ |---|---|

+ | Treueprüfung alt → neu (Prüfschwarm) | sehr gut; fand 2 kritische Fehler, die Autor und Prüfskript übersahen; ~6 % Fehlalarme |

+ | Einzeldatei-Code-Review | gut; 8 echte Funde gegen 6 des Vergleichsmodells, in einer zweiten Datei 4 Zusatzfunde; jeder Fund braucht Gegenprüfung |

+ | Übersetzung (z. B. READMEs DE→EN) | gut (~9/10); vollständige Parität; Fachbegriffe schwanken zwischen Läufen → Glossar; UI-Labels/Platzhalter brauchen Kontext |

+ | Doku↔Code-Abgleich | gut; keine Fehlalarme in Stichproben |

+ | Dubletten-Kartierung | brauchbar; ~85–90 % Recall gegen das Vergleichsmodell, ~1 Fehlalarm je Abschnitt |

+ | Kleiner, klar spezifizierter Fix mit Test | gut |

+ | Mechanik (Tests im Worktree, Rebase, PR, Lagebild) | gut; meldet Flakiness und Blockaden ehrlich, umgeht keine Guards |

+ **Empfehlungen:**

+ 1. Massenübersetzungen (Docs, READMEs, i18n-Strings): sehr geeignet, mit Glossar-Datei, 1:1-Paritätsregel und Stichprobe durch ein stärkeres Modell; viele Dokumente je Worker bündeln oder den naiven Headless-Worker bzw. die Batch-API nutzen — nie ein Subagent je Dokument.

+ 2. Prüfschwärme (Treue alt→neu, Doku↔Code, Vorher/Nachher, Link-/Pfad-Existenz): der beste Einsatz — unabhängiger Zweitleser, der findet, was dem Autor entgeht.

+ 3. Dokumentationsbasis aktualisieren im Muster *kleines Modell kartiert → Dauer-Worker schreibt → kleines Modell prüft → Denker nimmt ab*; normative Texte nie allein vom kleinen Modell umschreiben lassen.

+ 4. Code-Review-Vorprüfung je Datei und kleine, klar spezifizierte Fixes mit Test.

+ 5. Mechanik: Testläufe, Readbacks, Log-Auswertung, Lagebilder per `git grep`.

+ 6. **Nicht** für Architektur-, Merge- und Sicherheitsentscheidungen, normative Regeldateien und große dateiübergreifende Synthesen.

+ 7. Effizienzregeln: Aufgaben je Worker bündeln, Ergebnis als Datei plus 3–5-Zeilen-Meldung, wenige Tool-Aufrufe; Ergebnisse nie ungeprüft übernehmen (Abschnitt 3 gilt auch hier).

+ **Einsatzregel:** Das Modell ist ein Entwurfs- und Prüfwerkzeug (Rolle *Entwurfsgenerator* bzw.

+ Zweitleser im Prüfschwarm, Abschnitt 1) — keine Abnahme-Instanz und kein Standard-Dauer-Worker.

+ Produktivarbeit läuft über den Dauer-Worker der Konfiguration; die kleine Klasse nur auf

+ ausdrücklichen Auftrag des Nutzers. Massenaufgaben mit fester Eingabe laufen bevorzugt über die

+ API (Batch, ≈ $0,001 je README), nicht als Subagent im Harness.

+ ### 3.1.0 (2026-10-11) — Kleine Worker (Haiku-Klasse) gemessen

+ - Neuer Abschnitt 7: Haiku 5.5 als Worker, Messung 2026-10 (Qualität je Aufgabentyp, Preise, Empfehlungen)

+ - Effizienz-Falle dokumentiert: Subagent ~180–360k Tokens je Auftrag (Harness-Grundlast ~45–65k je

+ Turn); Gegenmittel Bündeln, naiver Headless-Worker ($0,018 je README-Übersetzung), API/Batch für

+ Massenaufgaben

+ - Einsatzregel: kleine Klasse nur auf ausdrücklichen Auftrag, Produktivarbeit über den Dauer-Worker

+ - Schema-Liste in Abschnitt 0 um `verified` ergänzt (Feld war in `models.example.json` und

+ Abschnitt 5 bereits in Gebrauch)

+

+ ### 3.0.0 (2026-10-03) — Breaking: Modellkatalog ausgelagert

+ - Modellkatalog aus dem Skill-Text entfernt und in `models.example.json` (getrackt, neutral)

+ plus eine lokale, nicht veröffentlichte Konfigurationsdatei (`models.local.json` /

+ `models.private.json`, bereits über `.gitignore` als privat erfasst) verlagert

+ - Ladereihenfolge dokumentiert: lokale Datei → Beispieldatei → Live-Erhebung; bei Widerspruch

+ gewinnt die Live-Messung; `deprecated: true` wird nie eingesetzt

+ - Starre Level-1-bis-4-Modellhierarchie und feste Score→Modell-Tabelle ersetzt durch fünf Rollen

+ (Denker/Entscheider, Dauer-Worker, Entwurfsgenerator, Reviewer/Abnahme, Eskalation); Score

+ bleibt nur noch als grobe Orientierung

+ - Abnahmepflicht für Entwurfsmodelle als eigener Abschnitt (Prüfpflicht, keine

+ Direktschreibrechte ins Zielsystem, engere Abnahme in fachlich engen Bereichen)

+ - Anbieterwechsel für unabhängige Reviews als Prinzip statt fester Modellpaar-Empfehlung

+ - Berechtigungsmatrix nach Modellname entfernt — Rechte hängen am Auftrag/der Autorität, nicht

+ am Modell; Guardrails sind Zuverlässigkeits-Hinweise, keine Rechteklausel

+ - Konkreter Companion-1.0.4-Aufrufweg, feste Ollama/Haiku-Eskalationskette und die

+ Fable/Opus-4.8-Präzedenzregel entfernt bzw. in eine neutrale „stiller Modellwechsel ist zu

+ melden"-Regel überführt

+ - Kontingente an den Skill `budgetierung`, Delegationsablauf/Rollenzuschnitt an `orchestrator`

+ und `choose-your-orchestrator` verwiesen statt doppelt gepflegt

+

+ - Reasoning-Effort als orthogonale Achse zur Modellwahl ergänzt (`xhigh`, gezieltes `max`,

+ breitenorientiertes `ultracode`)

+ - PRÄZEDENZ-REGEL: ein bestimmtes Modell ersetzt ein anderes in allen Level-4-/Reviewer-/

+ Beweis-Empfehlungen (User-Entscheid; inzwischen mit 3.0.0 neutralisiert)

+ - Stiller-Modellwechsel-Warnung ergänzt

+ - Cross-Agent-Delegation: externe Agenten und ein lokales Modell als Routing-Ziele

+ - Advisor-Pairing: 4 Muster (Session-Advisor, Orchestrator-als-Reviewer, Gegen-Agent,

+ User-Empfehlung)

+ - Erreichbarkeits-Matrix: Subagent-startbar vs. User-only dokumentiert

+ - Laterale Eskalation zu externen Agenten (Recherche, Review)

+ - Score-Schwellwerte erweitert

+ *Portiert aus BACH v3.8.0 | Rollenbasiert seit 3.0.0*