Imagina una sala contigo, dos colegas y tres agentes, cada uno con una parte del trabajo. Un colega pregunta quién está vigilando el despliegue. Un agente decide que la pregunta no va con él y responde con un NO_REPLY pelado, exactamente como se acordó. Esperas silencio. Unos segundos después, Hermes publica esto en la sala:

⚠️ El modelo devolvió solo un marcador de silencio para un mensaje que necesitaba respuesta. Inténtalo de nuevo o reformúlalo.

El mensaje no está mal: es una red de seguridad responsable. El problema es lo que le hace a la sala: convierte un traspaso interno en un error de sistema que todos ven. En una sala multiagente ese fallo se repite hasta que nadie quiere usar la sala.

El silencio es una capacidad del modelo; el permiso es una política de la sala

Aquí se mezclan dos cosas distintas. Primera: el modelo puede elegir no hablar. Hermes reconoce varios marcadores de silencio — NO_REPLY, [SILENT] — que significan “recibido, esta vez no hace falta nada de mi parte”. Segunda: si ese silencio es aceptable mostrarlo. Eso es una cuestión de política. No debería decidirlo el modelo por su cuenta, y tampoco debería ser una única respuesta global.

Históricamente el silencio solo se respetaba en casos estrechos: notificaciones internas, heartbeats programados y mensajes que el adaptador ya sabía que no iban dirigidos al bot. Todo lo demás — alguien mencionando al bot, una pregunta directa en un canal de foro — se trataba como fallo si el modelo respondía solo con un marcador. El gateway entonces rellenaba el hueco con el aviso de arriba.

Ese comportamiento por defecto es correcto. Pídele a tu agente por DM que ejecute los tests y recibe una pantalla en blanco: no puedes saber si está trabajando, si está muerto o si está confundido. El aviso al menos dice “lo intentó y no produjo nada”.

En un grupo, el comportamiento por defecto causa daños colaterales. Las salas mixtas de humanos y agentes generan un flujo constante de “visto, no hace falta responder”. Por eso Hermes añadió un interruptor a nivel de sala.

Una clave, una sala

El ajuste vive en el config.yaml del perfil que sirve esa sala, dentro del bloque channel_overrides que ya existía:

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

Tres cosas que retener:

• Es un override de sala, no un ajuste de todo el perfil. Las demás salas mantienen el comportamiento antiguo.
• Omitido, null o false significan lo mismo: “mantener la política de respuesta actual” — una persona pregunta, el modelo se calla y tú sigues recibiendo el aviso.
• Las exenciones existentes sobreviven en cualquier caso: notificaciones internas, heartbeats programados y mensajes que se sabe que no van dirigidos al bot se quedan en silencio incluso en una sala con allow_silence: false.

Reinicia el gateway después de editar el archivo para que todos los perfiles que sirven esa ruta recojan el nuevo valor.

Una trampa en el orden de búsqueda

Los overrides de sala se resuelven exactamente igual que los de modelo: primero el id de canal exacto, luego el id de hilo, luego el canal padre o el id de foro. Gana la primera coincidencia.

La trampa es que “gana la primera coincidencia” incluye una entrada que solo define otra cosa. Configura model en un hilo concreto y esa entrada de hilo coincide primero; y como no dice nada sobre allow_silence, el allow_silence: true de la sala padre nunca se aplica. El hilo vuelve en silencio a “debe hablar”. La solución no tiene glamour: repite allow_silence en la entrada del hilo.

Es el mismo mecanismo que los overrides de modelo por chat; ambas claves pueden vivir en una sola entrada. Simplemente no escribas la mitad.

Silencio no significa que no haya pasado nada

Esta es la parte que la gente malinterpreta. Activar allow_silence no significa “los agentes de esta sala pueden desaparecer”. Solo gobierna la entrega final:

• No deshace llamadas a herramientas. Un comando que se ejecutó, se ejecutó.
• No retira mensajes de progreso ya enviados. Las actualizaciones a mitad de turno siguen saliendo.
• No empuja al modelo hacia el silencio. Permite el silencio; nunca lo fomenta.

Más importante: los resultados vacíos, fallidos, parciales e interrumpidos nunca se ganan el derecho a desaparecer. Un modelo no puede esconder una ejecución rota detrás de un marcador. La comprobación de salud es explícita: solo un turno completado sin marca de fallo, parcial o interrupción cuenta con el permiso de la sala.

Hay un corolario sutil. Si el modelo escribió una respuesta real, además llamó solo a herramientas de mantenimiento (memoria, lista de tareas, gestión de skills, búsqueda de sesiones) y luego cerró el turno con un marcador pelado, esa respuesta se entrega, también en salas con la opción activada. Eso no es “no tengo nada que decir”; es “lo dije y luego estropeé el cierre”.

La recuperación tras un fallo sigue el mismo principio: una decisión de supresión solo se respeta si se guardó asociada a esa respuesta final exacta. Si el proceso cae antes de ese punto, vuelve la salvaguarda de la pregunta humana.

Cuatro arreglos que llegaron con ello

No fue un único commit que apareció solo. Un puñado de reparaciones hicieron fiable el interruptor:

1. Leer los bloques de plataforma de nivel superior y fallar de forma segura. Los overrides pueden vivir directamente bajo la entrada de cada plataforma en platforms; el cargador ahora lee ambas formas y, cuando no puede resolver una sala, recurre a la política por defecto en lugar de relajarla.
2. Un recibo de silencio fallido no es un error. Si falla la escritura del registro “este turno eligió silencio”, el turno no debe convertirse en un fallo: es solo una nota.
3. El perfil primario lee la configuración del propio gateway. El perfil que el gateway sirve a sí mismo se resuelve desde su propia configuración, no desde la instantánea de arranque.
4. Los marcadores de grupo de Telegram sobreviven mejor. Una serie de arreglos mantiene intactos los marcadores de silencio en respuestas a canales, publicaciones de administradores anónimos, respuestas a autores desconocidos y notas de voz o archivos de audio sin pie de texto en grupos, en lugar de leerlos como “debería haber respondido y no lo hizo”.

Los tres primeros van de no leer mal la política; el cuarto, de no perder el marcador. Ninguno aparece en una nota de lanzamiento, y todos deciden si el interruptor funciona en tus manos.

Cuándo activarlo y cuándo no

Actívalo en salas multiagente, canales de proyecto mixtos de humanos y agentes y salas de operaciones de alto volumen: en cualquier sitio donde “el silencio es la respuesta correcta” sea rutina.

Déjalo desactivado en DMs, en la recepción de soporte y en cualquier canal donde una pregunta de usuario deba recibir respuesta. Ahí el aviso ⚠️ no es ruido; es la única señal de que algo se rompió. Desactivarlo silencia la alarma.

Si dudas, actívalo en una sala y observa durante una semana. En el peor caso pierdes la red de seguridad de esa sala, no el gateway.

Para entender por qué una sala se quedó callada a nivel de conexión y no de política, desconexiones silenciosas y heartbeats cubre la otra mitad: otra capa, el mismo síntoma.