Bloqueado no es fallido: los agentes necesitan feedback de límites

La mayoría de las configuraciones de agentes tratan una acción bloqueada como un fallo de la herramienta.

Un agente llama a una herramienta. La solicitud infringe una regla. El sistema devuelve un error genérico. La llamada a la herramienta falla.

Esto parece estar bien al principio. La acción insegura fue detenida. Pero esto solo resuelve la mitad del problema.

Un error genérico no ayuda a un agente a trabajar dentro de sus límites. Convierte una decisión de política en ruido. El agente podría intentar adivinar una solución. Podría repetir el mismo error o intentar un payload diferente. Esto crea un bucle de reintentos inútiles.

Una acción bloqueada debería ser una decisión estructurada, no un fallo inesperado.

Cuando se bloquea una solicitud, el sistema externo no debe cambiar. Sin embargo, la respuesta debe indicarle al agente cómo proceder de forma segura.

En lugar de un simple error, utilice una respuesta estructurada.

Imagine que un agente intenta escribir en un archivo que cambió mientras estaba planificando. Un error genérico dice "fallido". Una respuesta estructurada dice:

  • Estado de la decisión: conflicto
  • Estado del resultado: sin impacto
  • Motivo: estado desactualizado
  • Siguiente acción: volver a leer el estado objetivo

Ahora el agente sabe que el objetivo no es imposible. Solo necesita actualizar su información. Deja de adivinar y da el siguiente paso correcto.

Esto funciona para muchos escenarios:

  • Si una ruta está fuera de alcance, sugiera una ruta permitida.
  • Si un efecto ya existe, sugiera reutilizar el resultado.
  • Si el impacto es demasiado alto, sugiera esperar una revisión humana.

Esto no hace que el límite sea permisivo. La acción sigue bloqueada. El sistema sigue siendo seguro. Simplemente está convirtiendo un callejón sin salida en un camino guiado.

Debe equilibrar esto con la seguridad. Un feedback preciso puede ayudar a un agente malintencionado a sondear sus límites.

Utilice códigos de motivo claros para la fricción operativa, como datos desactualizados o entradas malformadas. Si el agente muestra un comportamiento sospechoso o ignora las indicaciones, cambie a rechazos genéricos o revisiones humanas.

Mantenga el feedback del agente separado de las puntuaciones de auditoría. El agente necesita saber cómo cumplir con las normas. El sistema necesita saber si el agente se está comportando mal. No mezcle estas dos tareas.

Los límites existen porque los agentes se están volviendo lo suficientemente útiles como para actuar en sistemas reales. El trabajo real tiene reglas y límites.

Un límite que solo devuelve un fallo es un muro. Un límite que proporciona orientación es una herramienta.

Bloqueado debería significar:

  • El impacto solicitado no se produjo.
  • La razón es conocida.
  • La siguiente acción segura está clara.

Fuente: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi