Aprobar una compra del agente: la autorización debe seguir al objeto

Problema

El agente prepara una operación, el usuario la aprueba y el navegador continúa. Durante ese intervalo cambia el carrito, caduca una oferta o se selecciona otra cuenta. El sistema conserva el «sí», pero el objeto al que se refería ya no es el mismo.

La confirmación puede convertirse en una ceremonia si solo autoriza continuar el flujo. Para tener valor, debe estar vinculada a una acción concreta y a las condiciones que la persona vio.

Tesis

Diseña la aprobación sobre una propuesta verificable: acción, destinatario, contenido y límites. Si cambia algo relevante, determina si la autorización sigue cubriéndolo o si hay que volver a pedirla.

OpenAI describe controles y participación del usuario en decisiones de Dots; la autorización de MCP vincula acceso a recursos. A partir de esas bases, proponemos una capa de producto que conserve el significado de la aprobación hasta el momento de ejecución. No es una afirmación de que cualquier navegador agente ya implemente ese contrato.

Framework

Presenta el compromiso, no la intención genérica

La tarjeta de revisión debe mostrar lo que importa para decidir: qué se comprará o enviará, a quién, desde qué cuenta y bajo qué condiciones. «Continuar con la tarea» informa poco cuando la siguiente acción produce un compromiso externo.

Separa preparar de ejecutar. El usuario debe poder revisar el resultado concreto sin que abrirlo o editarlo active la operación. Una vista previa es útil cuando representa fielmente el objeto que después se enviará.

Revalida las condiciones al actuar

Antes de ejecutar, compara los campos relevantes con la propuesta aprobada. Define qué variaciones son aceptables dentro del alcance dado y cuáles invalidan la decisión. No todas las diferencias visuales importan, pero un cambio de destinatario o de importe puede cambiar completamente el compromiso.

Si la operación falla de forma ambigua, consulta el destino antes de reintentar. La aprobación de una compra no autoriza compras duplicadas. El identificador de operación y el recibo del proveedor ayudan a reconciliar ese estado.

Devuelve una prueba comprensible

Al terminar, informa de qué ocurrió y conserva la referencia que permite comprobarlo. Distingue enviado, recibido, aceptado y completado cuando sean fases diferentes. El mensaje del agente no debe adelantar el estado que todavía depende de otra parte.

La tarjeta de aprobación y su prueba de cambio

Supuesto: el agente prepara una compra de material. La tarjeta muestra producto, cantidad, vendedor, cuenta de pago, total con cargos, destino y condiciones relevantes. La autorización se asocia a esa versión del pedido y al alcance decidido por la persona.

La aplicación debe comparar campos normalizados y significativos, no una captura de pantalla ni una frase como «el usuario dijo que sí». Conserva además la relación con el recibo del destino. Si el proveedor modifica las condiciones durante la ejecución, no presentes como realizado el pedido antiguo.

Para la prueba, prepara un carrito sintético, apruébalo y cambia el destinatario antes de ejecutar. El sistema debe detener ese compromiso y mostrar la diferencia. Repite con una respuesta de pago perdida: debe consultar la misma operación antes de intentar otra, sin considerar que el consentimiento autoriza duplicados.

Esta política no implica pedir confirmación por cada clic. Permite continuar dentro de un alcance ya aprobado y reserva la nueva decisión para cambios materiales. La interfaz gana utilidad cuando explica exactamente qué cambió y por qué la aprobación anterior dejó de cubrirlo.

Por qué importa ahora

Los agentes de navegador pueden atravesar interfaces diseñadas para atención humana continua. Cuando parte del recorrido se delega, hay que reconstruir explícitamente dónde se forma y dónde se aplica la intención del usuario.

Anti-ejemplo

Caso hipotético: el usuario aprueba el envío de una propuesta a un contacto. El agente vuelve al formulario y el autocompletado selecciona otro destinatario con un nombre parecido. La aprobación sigue en el registro, pero ya no cubre el envío que se realizó.

Protocolo (3 pasos)

Relacionado

• IA consejera, no decisora: diseñar autonomía de compra por niveles
• Agentic Commerce: qué cambia cuando el cliente que compra es un agente

Fuentes consultadas

• OpenAI — Introducing dots
• Model Context Protocol — Authorization

Próximo paso

Revisa una confirmación de tu producto y comprueba si podrías reconstruir exactamente qué aprobó la persona. Si solo guardas un clic y una fecha, falta el objeto de la decisión.