Stell dir einen Raum vor mit dir, zwei Kolleginnen und drei Agenten, von denen jeder ein Stück der Arbeit verantwortet. Eine Kollegin fragt, wer den Deploy im Blick hat. Ein Agent entscheidet, dass ihn diese Frage nichts angeht, und antwortet mit einem blanken NO_REPLY, genau wie vereinbart. Du erwartest Stille. Ein paar Sekunden später setzt Hermes das hier in den Raum:

⚠️ Das Modell hat für eine Nachricht, die eine Antwort brauchte, nur einen Stille-Marker zurückgegeben. Versuch es erneut oder formuliere anders.

Die Meldung ist nicht falsch – sie ist ein verantwortungsvolles Sicherheitsnetz. Das Problem ist, was sie mit dem Raum macht: Sie verwandelt eine interne Übergabe in einen Systemfehler, den alle sehen. In einem Multi-Agenten-Raum wiederholt sich dieser Fehlschlag, bis niemand den Raum mehr benutzen will.

Stille ist eine Modellfähigkeit, Erlaubnis ist eine Raumrichtlinie

Hier werden zwei verschiedene Dinge vermischt. Erstens: Das Modell kann sich entscheiden zu schweigen. Hermes kennt einige Stille-Marker – NO_REPLY, [SILENT] – die „empfangen, in diesem Turn braucht es nichts von mir“ bedeuten. Zweitens: ob diese Stille gezeigt werden darf. Das ist eine Richtlinienfrage. Sie sollte nicht das Modell allein entscheiden, und sie sollte auch keine einzige globale Antwort sein.

Bisher wurde Stille nur in engen Fällen respektiert: interne Benachrichtigungen, geplante Heartbeats und Nachrichten, von denen der Adapter bereits wusste, dass sie nicht an den Bot gerichtet waren. Alles andere – jemand erwähnt den Bot, eine direkte Frage in einem Forum-Kanal – galt als Fehler, wenn das Modell nur mit einem Marker antwortete. Das Gateway füllte die Lücke dann mit der Warnung oben.

Diese Voreinstellung ist richtig. Frag deinen Agenten in einer DM, die Tests laufen zu lassen, und du bekommst einen leeren Bildschirm: Du kannst nicht erkennen, ob er arbeitet, tot ist oder verwirrt. Die Warnung sagt zumindest „er hat es versucht und nichts produziert“.

In einer Gruppe richtet die Voreinstellung Kollateralschäden an. Gemischte Mensch-Agent-Räume erzeugen einen ständigen Strom von „gesehen, keine Antwort nötig“. Deshalb hat Hermes einen Schalter auf Raumebene bekommen.

Ein Schlüssel, ein Raum

Die Einstellung liegt in der config.yaml des Profils, das diesen Raum bedient, im bestehenden Block channel_overrides:

platforms:
  matrix:
    channel_overrides:
      "!exampleTeamRoom:example.org":
        allow_silence: true

Drei Dinge solltest du dir merken:

• Es ist ein Raum-Override, keine profilweite Einstellung. Andere Räume behalten das alte Verhalten.
• Weggelassen, null oder false bedeuten alle „behalte die aktuelle Antwortrichtlinie“ – ein Mensch fragt, das Modell bleibt still, und du bekommst weiterhin die Warnung.
• Die bestehenden Ausnahmen bleiben unabhängig davon erhalten: interne Benachrichtigungen, geplante Heartbeats und Nachrichten, die bekanntermaßen nicht adressiert sind, bleiben still, auch in einem Raum mit allow_silence: false.

Starte das Gateway nach dem Bearbeiten der Datei neu, damit jedes Profil, das diese Route bedient, den neuen Wert übernimmt.

Eine Falle in der Auflösungsreihenfolge

Raum-Overrides werden genau wie Modell-Overrides aufgelöst: zuerst die exakte Kanal-ID, dann die Thread-ID, dann der Elternkanal beziehungsweise die Forum-ID. Der erste Treffer gewinnt.

Die Falle ist, dass „der erste Treffer gewinnt“ auch einen Eintrag einschließt, der nur etwas anderes setzt. Konfigurierst du model für einen einzelnen Thread, trifft dieser Thread-Eintrag zuerst – und weil er zu allow_silence nichts sagt, greift das allow_silence: true des Elternraums nie. Der Thread fällt still auf „muss sprechen“ zurück. Die Lösung ist unspektakulär: allow_silence im Thread-Eintrag wiederholen.

Es ist derselbe Mechanismus wie bei den Modell-Overrides pro Chat; beide Schlüssel können in einem Eintrag stehen. Schreib nur nicht die Hälfte davon.

Stille heißt nicht, dass nichts passiert ist

Das ist der Teil, der missverstanden wird. allow_silence zu aktivieren bedeutet nicht „Agenten in diesem Raum dürfen verschwinden“. Es regelt ausschließlich die finale Zustellung:

• Es macht Werkzeugaufrufe nicht rückgängig. Ein Befehl, der gelaufen ist, ist gelaufen.
• Es zieht bereits gesendete Fortschrittsmeldungen nicht zurück. Updates mitten im Turn gehen weiterhin raus.
• Es drängt das Modell nicht zur Stille. Es erlaubt Stille, es ermutigt sie nie.

Wichtiger noch: leere, fehlgeschlagene, teilweise und unterbrochene Ergebnisse erhalten nie das Recht zu verschwinden. Ein Modell kann einen kaputten Lauf nicht hinter einem Marker verstecken. Die Prüfung ist ausdrücklich: Nur ein abgeschlossener Turn ohne Fehler-, Teil- oder Unterbrechungsflag zählt auf die Erlaubnis des Raums.

Daraus folgt ein feiner Unterschied. Wenn das Modell eine echte Antwort geschrieben, außerdem reine Haushaltswerkzeuge aufgerufen hat (Memory, Todo-Liste, Skill-Verwaltung, Session-Suche) und den Turn dann mit einem blanken Marker beendet hat, wird diese Antwort zugestellt – auch in Räumen, die zugestimmt haben. Das ist kein „nichts zu sagen“, das ist „gesagt und dann den Schluss verpatzt“.

Die Crash-Erholung folgt demselben Prinzip: Eine Unterdrückungsentscheidung gilt nur, wenn sie gegen genau diese finale Antwort gespeichert wurde. Stürzt es davor ab, kehrt die Absicherung für menschliche Fragen zurück.

Vier Korrekturen, die mitgeliefert wurden

Das war nicht ein einzelner Commit, der allein auftauchte. Ein paar Reparaturen machten den Schalter vertrauenswürdig:

1. Plattform-Blöcke auf oberster Ebene lesen und sicher scheitern. Overrides dürfen direkt unter platforms.<name> liegen; der Loader liest jetzt beide Formen und fällt, wenn er einen Raum nicht auflösen kann, auf die Standardrichtlinie zurück, statt sie zu lockern.
2. Eine fehlgeschlagene Stille-Quittung ist kein Fehler. Wenn das Schreiben des Datensatzes „dieser Turn hat Stille gewählt“ scheitert, darf daraus kein fehlgeschlagener Turn werden – es ist nur eine Notiz.
3. Das Primärprofil liest die eigene Konfiguration des Gateways. Das Profil, das das Gateway selbst bedient, löst aus seiner eigenen Konfiguration auf, nicht aus dem Start-Snapshot.
4. Stille-Marker in Telegram-Gruppen überleben besser. Eine Reihe von Korrekturen hält Stille-Marker bei Antworten auf Kanäle, bei Posts anonymer Admins, bei Antworten an unbekannte Absender und bei Sprach- oder Audiodateien ohne Beschriftung in Gruppen intakt, statt sie als „hätte antworten sollen, hat es aber nicht“ zu lesen.

Die ersten drei drehen sich darum, die Richtlinie nicht falsch zu lesen; die vierte darum, den Marker nicht zu verlieren. Keine davon taucht in einem Launch-Post auf, und alle entscheiden darüber, ob der Schalter in deinen Händen funktioniert.

Wann einschalten, wann nicht

Einschalten in Multi-Agenten-Räumen, gemischten Mensch-Agent-Projektkanälen und stark frequentierten Operations-Räumen – überall dort, wo „Stille ist die richtige Antwort“ Routine ist.

Aus lassen in DMs, im Support-Eingang und in jedem Kanal, in dem eine Nutzerfrage eine Antwort bekommen muss. Dort ist die ⚠️-Warnung kein Rauschen, sondern das einzige Signal, dass etwas kaputt ist. Sie abzuschalten stellt den Alarm stumm.

Wenn du unsicher bist, aktiviere es für einen Raum und beobachte eine Woche. Im schlimmsten Fall verlierst du das Sicherheitsnetz dieses Raums, nicht das Gateway.

Um zu verstehen, warum ein Raum auf Verbindungsebene still wurde statt auf Richtlinienebene, deckt stille Verbindungsabbrüche und Heartbeats die andere Hälfte ab – andere Schicht, gleiches Symptom.