Por qué la puerta está en las escrituras
Una puerta en cada acción entrena a los revisores a hacer clic sin leer, lo que destruye el control que pretendía crear. La asimetría es deliberada: las lecturas son reversibles y baratas, así que fluyen; las escrituras no lo son, así que se detienen.
Esa ubicación es también lo que hace aprobable el sistema. Un revisor de seguridad acepta un acceso amplio de lectura mucho más fácilmente que una sola escritura desatendida en un sistema de registro.
Tres propiedades que separan una puerta real de un diálogo
El cambio se muestra, no se describe. "El agente quiere actualizar sus registros — ¿continuar?" pide aprobar una categoría, no una acción. Lo necesario es el diff: qué campos cambian, de qué a qué, en cuántos registros y cuáles. Ese conteo es el radio de impacto.
La aprobación no puede repetirse. Si la aprobación es un booleano, puede aplicarse a lo que sea el plan al ejecutar — que no tiene por qué ser el que vio el revisor. Anclarla a un token de concurrencia y al esquema aprobado hace que una discrepancia rechace la escritura en lugar de continuar.
Escalar es un resultado real. Con solo aprobar y rechazar, un revisor que no es quien debe decidir aprobará, porque rechazar descarta trabajo que otro pidió. Una tercera opción enruta la decisión en lugar de fabricar consentimiento.
El diagnóstico
Revise la tasa de rechazo. Si es cero en miles de aprobaciones, la puerta no funciona — o los revisores no ven lo suficiente para objetar, o aprobar se volvió un reflejo. Una puerta que funciona produce rechazos, y en ellos se aprende qué hace mal el agente.
Dónde debe vivir
En la ruta de ejecución, no en la interfaz. Una puerta implementada en la UI es consultiva — cualquier cosa que llame directamente a la herramienta, como un reintento o una ejecución programada, la evita. La verificación va en el punto de despacho, por donde pasa todo llamador sin importar su origen.