Anthropic abrió la vista previa de investigación de Claude Duet el 21 de octubre, un agente proactivo que vigila las aplicaciones conectadas y resuelve las tareas que le das. Gmail y Slack aparecen entre sus ejemplos, junto con QuickBooks, Stripe y HubSpot. Muse, de Meta, había salido seis semanas antes, el 8 de septiembre, con la misma promesa. La publicación de ingeniería de Meta cuenta que era la primera vez que le entregaban sus correos y calendarios a un software para que corriera sin supervisión, y que no siempre salió como esperaban.

Los dos productos responden igual a la duda obvia: preguntan antes de hacer algo importante. La frase es cierta y no dice casi nada. Doce aprobaciones al día también es “preguntar antes de lo importante”, y en la segunda semana ya estás diciendo que sí sin leer.

Leí los documentos de seguridad de ambas empresas para ver cómo deciden qué es importante. Lo útil es que ninguna se apoya en el clic. Cada una movió casi todo el control a otro lugar, y al humano le deja una lista corta.

Cuatro tratos para una acción de agente, y solo uno es una pregunta

Si pones los dos diseños lado a lado, aparecen los mismos cuatro tratos.

Primero, bloquearla aunque el humano diga que sí. Duet no opera valores, no mueve dinero entre tus cuentas y no entra a la cuenta de otra persona, con o sin tu aprobación. Para eso no existe pregunta, así que nadie puede aprobarlo por accidente.

Segundo, acotarla antes de que el agente empiece. Para las compras, Duet paga con una tarjeta de un solo uso de una billetera como Link, limitada a ese comercio y a ese monto. Tú apruebas la compra en tu aplicación de Link. El daño de una aprobación equivocada lo limita la propia tarjeta. Muse hace lo mismo con el acceso: donde el servicio lo permite, lectura y escritura son permisos separados, y Meta explica que puedes dar el permiso de lectura de Gmail y quitar el acceso a la configuración de Gmail que normalmente viene incluido.

Tercero, preguntar siempre. Duet no deja que una regla de “no volver a preguntar” cubra pagar o enviar dinero, borrar un pedido o crear una cuenta, por más veces que lo hayas aprobado. La pregunta se queda cara a propósito. Y la tarjeta muestra la acción, el destino y el contenido, con cada destinatario, para que la persona pueda juzgarla en pocos segundos.

Cuarto, permitirla y revisar después. Muse dice que las acciones de solo lectura, ya autorizadas o de bajo riesgo comprobado siguen sin interrumpir. Su documento lo dice sin rodeos: el objetivo no es preguntarle al usuario por todo.

Anthropic da la razón por escrito, en el documento de seguridad de Duet: “Approval fatigue is a serious issue, because too many requests teach people to tap through them” (la fatiga de aprobación es un problema serio, porque demasiadas solicitudes enseñan a la gente a darles clic). Yo lo leo como un proveedor que admite que la pregunta es la más débil de las cuatro herramientas, y que por eso la gasta con cuidado.

Muse pregunta por el proceso, no solo por la acción

La idea más útil que encontré está en el diseño de Meta. Muse rastrea lo que ha tocado cada proceso. Todos arrancan limpios y quedan contaminados en cuanto leen datos del usuario. Una solicitud de salida de un proceso limpio, que cumpla una política de permiso automático muy estrecha, pasa. Un proceso contaminado o que no se puede verificar pierde ese permiso y vuelve al flujo normal de aprobación. Meta lo llama “tainted egress” y dice que existe para equilibrar la relación señal-ruido de las aprobaciones.

La misma llamada de red recibe entonces una respuesta distinta según lo que el proceso sabía cuando la hizo. Es mejor pregunta que “¿enviar un correo es riesgoso?”. Mandar un correo que no contiene nada de tu bandeja sale barato. Mandarlo desde un proceso que acaba de leer el hilo del director financiero, no.

Hay dos detalles más si vas a construir algo parecido. En Muse, un agente aparte llamado Sentinel es la única autoridad de permisos y responde permitir, negar o preguntar, y el diálogo de aprobación aparece en la interfaz del cliente, no en el chat. En Duet, la revisión que compara cada acción con tu intención corre fuera del modelo que hace el trabajo. En ambos casos, nada de lo que el agente lee, ya sea una página web o el cuerpo de un correo, puede contestar su propia tarjeta de aprobación.

Lo que los proveedores no pueden decidir por ti

Los dos productos salen con valores por defecto pensados para un consumidor. Duet es una vista previa con lista de espera, que empieza con usuarios en Estados Unidos y viene incluida en los planes Pro, Max y Ultra. Muse ofrece permitir una vez, permitir siempre o negar, y además permisos de un solo uso, de sesión, de tarea o con vencimiento. Nadie ha escrito la tabla de tu empresa: en qué canales de Slack puede publicar un agente, qué invitaciones de calendario puede aceptar por un ejecutivo, qué buzón puede leer y de cuál solo puede redactar.

No estoy diciendo que tu equipo haya conectado alguno de estos a cuentas de trabajo. Si alguien lo hace, o cuando tus propios agentes reciban el mismo acceso, la división en cuatro es lo que hay que llenar. Ya escribí sobre Uber midiendo a personas que aprueban más de 50 acciones en una sola sesión, que mostraba el problema. Esta es la otra mitad, el diseño que lo evita.

La prueba que usaría para cada acción:

1. ¿Se puede limitar el error antes de que ocurra, con un tope, un permiso de solo lectura o una credencial de un solo uso? Entonces límitala y sáltate la pregunta.
2. ¿Es irreversible, sale de la empresa y quien aprueba puede juzgarla con lo que muestra la tarjeta? Entonces pregunta, cada vez, sin aprobación recordada.
3. ¿Es algo que nadie debería autorizar nunca? Entonces bloquéala.
4. ¿No es ninguna de las anteriores? Permítela, regístrala y revisa el registro.

Si quien aprueba no puede juzgar la acción porque la tarjeta dice “Enviar mensaje a 14 destinatarios” y nada más, la pregunta es teatro. Arregla la tarjeta o mueve la acción a otro grupo.

Qué hacemos en IQ Source

En AI Maestro esta tabla se arma en dos tiempos: el discovery mapea qué acciones toca cada proceso, y cuando se diseña el agente, en la Etapa 2, cada fila recibe su trato antes de que el agente reciba acceso a correo, Slack o calendario. Una fila por cada acción que el agente puede hacer a través de cada conector, uno de los cuatro tratos en la columna siguiente, y una razón. Las filas que terminan en “preguntar” son las que se cuentan: cuántas al día, por persona, y si quien aprueba distingue lo bueno de lo malo solo con la tarjeta. Si el número es grande, la asignación está mal, y movemos filas a “acotar” o “bloquear” hasta que sea lo bastante pequeño para leerse.

Ahí mismo se revisan los permisos OAuth que ya diste, porque un permiso de lectura que incluye en silencio acceso a la configuración no se arregla con una pregunta. Es el lado operativo de lo que llamé la gobernanza como moat (ventaja competitiva).

No cubrí los dots de OpenAI. No encontré una página de OpenAI que describa su diseño de aprobaciones, y prefiero dejarlos fuera antes que citar el resumen de otra persona.

Si quieres la tabla de acciones de tu agente redactada antes de conectar el primer conector, reserva el discovery de AI Maestro y empieza por la lista de acciones