Agent-Shells: Wie schaltest du Agent-Funktionen per Feature Toggle über Umgebungen hinweg?

Multi-Agent-Shells verrotten, wenn jeder neue Assistent zu einem if-else auf Agent-IDs wird. Mikrotexte spalten sich ab. Exportpräfixe spalten sich ab. Zugriffsprüfungen spalten sich ab. Bald ist die SPA ein Einzelstück-Katalog, der so tut, als wäre er ein Produkt.

Standardmäßig offen, mit Overlays. Feature Flags des Produkts steuern die gemeinsame UX. Overlay-Zeilen pro Agent tragen die Unterschiede. Die SPA erfindet nie Richtlinien aus einem JWT. Der Core bleibt sauber, weil spezialisierte Agents Daten sind und keine Code-Abspaltungen.

Abbildung 1. Standardmäßig offen, mit Overlays. Flags steuern die gemeinsame UX. Overlay-Zeilen tragen die Unterschiede zwischen Agents. Die Katalog-API entscheidet, was die SPA zeigen darf.

Kontext und Rahmenbedingung

Agent-Kataloge wachsen meist schneller, als die gemeinsame UX sie aufnehmen kann. Jeder "schnelle" Sonderfall für einen Assistenten hat dem nächsten Engineer beigebracht, dass Hartcodieren normal ist. Feature Flags plus Overlay-Zeilen haben eine einzige Shell mit vielen Agents zurückgebracht.

Wenn Starter, Exportnamen und Zugriffslisten im Code neben den Agent-IDs liegen, will jedes Team eine Abspaltung. Wenn sie in Overlay-Zeilen hinter Flags liegen, bleibt der Core langweilig und der Katalog ehrlich. Die Autorisierung gehört weiterhin in die API. Overlays beschreiben, was die API der Shell ohnehin zu zeigen erlaubt.

Abbildung 2 zeigt die Oberfläche aus Learn zur Verwaltung von Feature Flags. Behandle sie als Produkthaltung für gemeinsame Oberflächen, nicht als Ort, um Teamvorlieben in React zu codieren.

Abbildung 2. Die gemeinsame Shell-UX ist ein Produktfeature. Unterschiede zwischen Agents gehören in Overlay-Zeilen, die die API bereits autorisiert. Quelle: Microsoft Learn: Feature Flags verwalten.

Abbildung 3 zeigt den Schalter zum Anlegen eines Flags. Flags steuern Oberflächen. App-Rollen entscheiden weiterhin, was der Katalog zeigen darf.

Abbildung 3. Feature Flags steuern Oberflächen. App-Rollen entscheiden weiterhin, was der Katalog zeigen darf. Die SPA sollte keine Richtlinien aus JWTs erfinden. Quelle: Microsoft Learn: Feature Flags verwalten.

Design

1. Gemeinsame UX standardmäßig offen hinter Flags

Chat-Layout, Zitat-Schubladen, Exportfunktionen und Chips für Folgefragen sind Produktfeatures. Steuere sie mit Flags, damit du eine Oberfläche abschalten kannst, ohne einen Agent zu löschen. Flags dienen der Produkthaltung, nicht dazu, Teamvorlieben in React zu codieren.

2. Overlay-Zeilen pro Agent, nicht pro abgespaltener Shell

Jede Agent-Zeile kann Scope-Labels, Starter-Prompts, Exportpräfixe und Zugriffslisten tragen. Unterschiede zwischen Deployments sollten auswählen, welche Zeilen geladen werden, statt die Shell umzuschreiben. Overlays skalieren, Abspaltungen vervielfachen den Support. Abbildung 4 zeigt die Form der Zeile.

Abbildung 4. Die Overlay-Zeile als Daten. Scope, Starter, Exportpräfixe und Zugriffslisten reisen mit dem Agent. Zeilen auszuwählen heißt nicht, die Shell umzuschreiben.

3. Zugriffslisten ohne JWT-Archäologie in der SPA

Die Katalog-API liefert, was dieser Aufrufer sehen darf. Die SPA rendert diese Liste. Rollen im Browser zu decodieren, um hartcodierte IDs zu filtern, dupliziert die Richtlinie und driftet ab. Eine einzige Zugriffs-Payload schlägt drei Kopien von Rollen-Strings. Abbildung 5 zeigt die Aufteilung der Verantwortung.

Abbildung 5. Die Katalog-API verantwortet die Sichtbarkeit. React, das JWTs decodiert und hartcodierte Agent-IDs filtert, ist der Weg, auf dem die Richtlinie von der API wegdriftet.

4. Mikrotexte bleiben unter den übergeordneten Toggles

Tonfall und Hilfetexte eines Features gehören zum Feature Flag, nicht verstreut neben Agent-IDs. Sonst korrigierst du einen Tippfehler in vier Verzweigungen und übersiehst die fünfte. Übergeordnete Toggles halten Texte prüfbar.

5. Der Core bleibt frei von spezialisierten Agents

Spezialisierte Packs kommen als Daten und Konfiguration. Das Core-Repo sollte nicht jedes Mal einen Pull Request brauchen, wenn für ein Team ein spezialisierter Agent dazukommt. Wenn die Liste der Core-PRs vor allem aus Agent-IDs besteht, hast du die Architektur umgedreht.

6. Tests über eine Flag-Matrix erweitern

Teste nur allgemeine Agents, nur spezialisierte, Flag aus und Flag an. Pflege keine eigene Test-Suite pro abgespaltener Shell. Wenn ein Flag seinen Standardwert ändert, sollte CI es dir sagen, bevor ein Release es tut.

Wie Overlays und Autorisierung Freunde bleiben

Overlays sind kein zweites Autorisierungssystem. Sie schmücken einen Katalog, der bereits autorisiert ist. Wenn eine Zugriffsliste in einer Zeile der Rollenprüfung der API widerspricht, gewinnt die API, und die Zeile ist falsch. Bau einen Validator, der CI scheitern lässt, wenn die Zugriffsangaben eines Overlays über das hinausgehen, was Rollen gewähren können. Konfiguration, die zu viel verspricht, ist ein Sicherheitsfehler mit freundlichem JSON-Gesicht.

Migration weg von hartcodierten IDs

Erfasse jede Verzweigung nach Agent-ID. Ordne jede als Produktfeature, als Overlay-Feld oder als echten Einzelfall ein, der ein Flag sein sollte. Verschiebe die Felder in Zeilen. Ersetze Verzweigungen durch Flag-Prüfungen. Lösche tote ID-Listen. Halte ein kurzes ADR fest, damit der nächste Engineer nicht "nur ein einziges if" für einen Lieblings-Agent wieder einführt. Auch Lieblings-Agents sind Zeilen.

Betriebsfähigkeit für die Rufbereitschaft

Wenn ein Starter-Prompt falsch ist, sollte die Rufbereitschaft Overlay-Daten oder eine Konfiguration hinter einem Flag ändern, statt einen Hotfix der Shell auszuliefern. Wenn sich ein Feature für alle falsch verhält, schalte das übergeordnete Flag um. Trenne diese Runbooks. Wer "einen Agent reparieren" und "Zitate global abschalten" im selben Panikpfad vermischt, legt die falsche Oberfläche lahm.

Häufige Fehler

if-else-Kataloge. Jede Agent-ID bringt einen neuen Sonderfall bei.

JWTs in React parsen. Die Richtlinie driftet von der API weg. Abbildung 5 macht genau diesen Fehler sichtbar.

Abgespaltene Texte. Dasselbe Feature, fünf Formulierungen, kein Verantwortlicher.

Verzweigungen pro Team. Aus einer Shell werden viele Apps.

Flag-Suppe ohne Verantwortliche. Niemand weiß, was "true" in Produktion bedeutet.

Tests pro Abspaltung. Das Tempo stirbt, die Angst vor dem Merge wächst.

So übernehmen oder anpassen

So übernehmen

• Die gemeinsame Shell-UX wird über Feature Flags des Produkts gesteuert, nicht über Verzweigungen nach Agent-ID.
• Overlays pro Agent tragen Scope, Starter, Exportpräfixe und Zugriffslisten als Daten.
• Die SPA nutzt autorisierte Katalog-Payloads. Für die Sichtbarkeit von Agents werden keine Rollen aus JWTs geparst.
• Spezialisierte Agents kommen als Packs und Konfiguration. Der Core bleibt frei von teamspezifisch hartcodierten Agents.
• CI wird über eine Matrix aus Flags und Rollen erweitert, nicht über abgespaltene Shells.
• Die Zugriffsangaben der Overlays werden gegen die Autorisierungsregeln der API geprüft.

Vor dem Einsatz anpassen

Flags und Overlays bringen zusätzliche Konfigurationsfläche mit. Hartcodierte IDs fühlen sich bei den ersten paar Agents schneller an und brechen zusammen, wenn der Katalog wächst. Kataloge, die von der API gesteuert werden, brauchen Tests auf API-Ebene. Rollen-Parsing im Browser braucht Stammeswissen. Verantwortung für Flags und Disziplin bei ihrer Benennung sind Pflicht, unbenannte Flags werden zu Landminen. Ein sauberer Core mit Overlays kostet vorab Arbeit am Packaging und erspart danach für immer die Steuer der Abspaltungen.

Wichtigste Quellen: die Hinweise zu Feature Flags in Azure App Configuration und, wo zutreffend, die Doku zu Microsoft Foundry beziehungsweise deiner Agent-Katalog-API auf Microsoft Learn. Verbinde die Doku der Produkt-Flags mit dem ADR zur Autorisierung, damit Toggles nie zu einer Hintertür werden.

Steuere die gemeinsame UX mit Flags. Beschreibe Agents als Overlays. Lass die Richtlinie in der API. Teste die Matrix. Die Shell sollte sich wie ein einziges Produkt anfühlen, auch wenn der Katalog aus vielen Spezialisten besteht.