Imagina a tu responsable de soporte un jueves por la tarde, tres horas dentro de un turno en el que el nuevo asistente de IA le ha pedido confirmar cuarenta y una llamadas a herramientas. Las seis primeras las leyó línea por línea, revisando argumentos y comparando IDs con el ticket. Hacia la llamada treinta ya pulsa el botón verde como tú pulsas Enter en un aviso de composer update: por memoria muscular, con la vista ya puesta en lo siguiente. No hay nada negligente en eso. Las personas hacemos esto con cualquier aviso que aparezca con suficiente frecuencia. Y es exactamente así como espero que muchos equipos usen la flamante función de aprobación de Laravel AI SDK 1.0.

Un resumen rápido por si te perdiste el lanzamiento del 23 de septiembre. Una herramienta que implementa el contrato Approvable e incorpora el trait InteractsWithApprovals ya no se ejecuta sin más cuando el modelo la elige. El agente se detiene y te entrega las llamadas pendientes junto con los argumentos que eligió el modelo. Tú respondes a cada una: dejarla pasar, rechazarla con un motivo que el modelo verá, o cambiar los argumentos antes de que se ejecute. Funciona con prompt, stream, queue y los métodos de broadcast, así que un agente en cola puede quedarse suspendido hasta que alguien se ocupe de él. Buena ingeniería, y me alegra que venga incluida en el framework.

Mi postura es que trates Approvable como la última línea de tu diseño, nunca como la primera. Si una herramienta es lo bastante peligrosa como para que quieras que una persona revise cada llamada, pregúntate primero si puedes hacerla menos peligrosa. Eso es mejor que pedirle a alguien cansado que sea tu mecanismo de seguridad cuarenta veces por turno. Una herramienta llamada `DeleteFile` que acepta cualquier ruta es una pregunta con trampa. Una herramienta que solo puede mover archivos de una carpeta concreta de un tenant a una papelera de borrado lógico que se vacía a los treinta días normalmente no necesita confirmación alguna, porque lo peor que puede hacer es molesto y reversible.

La misma versión te da una palanca más discreta que, para esto, me parece más interesante. El middleware ahora se ejecuta en cada paso de generación en lugar de una vez por prompt, y recibe un PendingStep que puedes modificar. Puedes cambiar a otro modelo, quitar herramientas de la lista o recortar el presupuesto de tokens mientras el agente está en marcha. Para mí, eso convierte la retirada de capacidades en un concepto de primera clase. ¿El agente ya leyó la factura que necesitaba? Quítale las herramientas de escritura para todos los pasos siguientes. El modelo no puede llamar a una herramienta que no tiene, y nadie tiene que hacer clic en nada para que esa garantía se cumpla. A la gente de Go le encanta presumir de interfaces pequeñas. Esta es nuestra oportunidad de mantener pequeña también la caja de herramientas de un agente, paso a paso.

Ahora el contraargumento honesto, porque es sólido. Hay acciones que no se vuelven seguras por mucho que las acotes. Un reembolso es un reembolso. Un correo a un cliente no se puede recuperar, por muy bien que delimites la plantilla. Ahí una persona tiene que mirar de verdad, y una pausa bien construida es mejor que cualquier apaño casero con un flag en la base de datos que haya visto en apps de Laravel a lo largo de los años. Poder corregir un argumento equivocado, en vez de tirar toda la ejecución, también le da a quien revisa un motivo para leer de verdad lo que tiene en pantalla. Acepto todo eso. Lo mío va de volumen. La aprobación solo conserva su sentido mientras sea lo bastante rara como para que una persona se tome en serio cada una.

También hay un tipo de riesgo que ningún botón de aprobación puede cubrir. Gabriele Pieretti, que desarrolla un producto de espejo virtual para peluquerías, escribió sobre esta versión desde la perspectiva de una app que envía fotos de clientes a Gemini en Vertex AI en una región de la UE. Ese producto solo hace la llamada generativa cuando ya existe un consentimiento explícito registrado en el servidor. Pienses lo que pienses de los detalles, la lección para nosotros es sencilla: algunas reglas pertenecen a tu capa HTTP y al estado de tu sesión, mucho antes de que empiece cualquier bucle de agente. Si la comprobación vive en un prompt, ya ha perdido.

Así que este es, a grandes rasgos, el orden que sigo en mis propios proyectos. Haz la herramienta tan acotada y tan reversible como permita el negocio. Usa middleware por paso para quitar todo lo que el agente ya no necesita. Aplica las reglas estrictas en PHP de toda la vida antes siquiera de llamar al modelo. Después usa Approvable para lo que quede, y cuenta cuántas veces se dispara. Si una persona ve más de un puñado de aprobaciones al día, yo lo trataría como un bug de diseño y no como prueba de diligencia.

Me gustaría saber dónde pones tú ese límite. Si ya tienes agentes con pasos de aprobación en producción, ¿cuántas confirmaciones por persona y día aguanta tu equipo antes de que se conviertan en un sello automático, y qué cambiaste cuando viste que estaba pasando?