Agenten so konfigurieren, dass Rollen und Kosten klar bleiben
Agenten bringen in QuantenRam erst dann echten Mehrwert, wenn Rollen, Modelle und Handoffs sauber zusammenspielen. Nicht der Name einer Persona ist entscheidend, sondern ob Planung, Umsetzung und Review in einer reproduzierbaren Reihenfolge laufen und pro Schritt das passende Aliastier verwenden.
Die praktischste Konfiguration beginnt mit wenigen klaren Rollen. Ein Planner oder Prometheus-artiger Agent ordnet den Auftrag und bleibt kostenbewusst auf einem Start-Modell. Eine Implementierungsrolle wie Hephaestus oder Sisyphus bekommt den schnellen Coding-Pfad. Eine Review-Rolle wie Oracle oder Momus wird nicht zum Default für alles, sondern nur für Architektur, Risiko oder finale Abnahme aktiviert. So bleibt Multi-Agent-Arbeit nachvollziehbar und Billing-Eskalation gezielt statt zufällig.
Planung
Planungsrollen sammeln Kontext, zerlegen Aufgaben und definieren den Verify-Loop. In QuantenRam sollten sie standardmässig auf quantenram-start/* bleiben, weil hier meist Strukturschärfe wichtiger ist als maximale Modellstärke.
Umsetzung
Implementierungsrollen arbeiten auf quantenram-coding/*, wenn Diff-Analyse, Refactoring und Tool-gestützte Schleifen im Vordergrund stehen. Diese Lane ist für längere Coding-Sessions meist die wirtschaftlichste und betrieblich sauberste Wahl.
Review
Review-Rollen sollten an klare Trigger gebunden sein, etwa Architekturentscheidungen, sicherheitsrelevante Änderungen oder finale Risikoabwägungen. Genau dort lohnt sich quantenram-zenmaster/*, während Routineprüfungen besser in günstigeren Lanes bleiben.
Rollen und Verantwortungen konfigurieren
Eine gute Agentenkonfiguration ordnet jeder Rolle drei Dinge zu: ein Primarmodell, optional einen Fallback und eine Eskalationsbedingung. Damit ist bereits vor dem ersten Prompt klar, warum eine Rolle existiert und wann sie ueberhaupt eingesetzt werden darf. Für Teams ist das viel wert, weil daraus keine persönliche Vorliebe, sondern ein wiederholbarer Betriebsvertrag entsteht.
{
"agents": {
"prometheus": {
"model": "quantenram-start/glm-5",
"fallback_model": "quantenram-start/deepseek-chat"
},
"hephaestus": {
"model": "quantenram-coding/qwen3codernext",
"fallback_model": "quantenram-coding/qwen3.5-9b"
},
"oracle": {
"model": "quantenram-zenmaster/gpt-5.4",
"trigger": "architecture-or-risk"
}
}
}Das Entscheidende an dieser Konfiguration ist nicht die exakte Syntax, sondern die Betriebslogik dahinter. Der Planner bleibt billig und schnell, die Umsetzungsrolle bekommt den coding-orientierten Pfad, und die Review-Rolle hat einen klaren, seltenen Trigger. Genau so sehen gute Multi-Agent-Setups in QuantenRam aus.
Multi-Agent-Workflows ohne Kontextverlust
Mehrere Agenten helfen nur dann, wenn Uebergaben sauber sind. Jede Rolle sollte deshalb immer mit einem konkreten Artefakt weitergeben: einem Plan, einer Diff-Grenze, einem Teststatus oder einer offenen Risikofrage. Wer bloss "uebergibt", ohne Ziel und Verifikationsstand mitzuschicken, produziert doppelte Recherche und macht spätere Review-Loops unnötig teuer.
Für QuantenRam ist besonders nützlich, Eskalation mit Billing- und Tier-Logik zu koppeln. Wenn ein Review-Agent auf Zenmaster arbeitet, sollte diese Entscheidung im Workflow schon begründet sein, bevor der Schritt gestartet wird. Ein sauberer Trigger wie architecture-or-risk oder release-review-only macht später sowohl Kosten als auch Qualitätsgewinne nachvollziehbar.
Agenten an Team und Projekt anpassen
Die beste Anpassung ist fast immer eine Vereinfachung. Statt für jede Kleinigkeit eine neue Rolle einzuführen, beginne mit Planung, Umsetzung und Review. Erweitere erst dann, wenn ein wiederkehrender Uebergabepunkt im Alltag wirklich sichtbar wird. Typische Erweiterungen sind eine Librarian-Rolle für Kontextaufbau oder eine zweite Review-Stufe für heikle Releases. Auch dann gilt: Jede neue Rolle braucht einen eindeutigen Auftrag, ein Aliastier und eine definierte Abnahmebedingung.
Agenten werden in QuantenRam dann stark, wenn Rollen nicht nach Persona, sondern nach Arbeitsphase konfiguriert werden: Start für Planung, Coding für Umsetzung und Zenmaster nur für klar begründete Eskalation.