Tu primer agente de sólo lectura, sin ningún riesgo

1. La seguridad no está en el prompt: está en lo que no le das

   Esto es lo único de este caso que hay que entender de verdad, y es lo que separa un agente seguro de uno que parece seguro.

   Si le das una herramienta que escribe y le dices «no escribas», estás confiando en que obedezca. Casi siempre obedecerá. Casi.

   Si no le das ninguna herramienta que escriba, no puede escribir aunque quiera, aunque se equivoque, aunque alguien le meta una instrucción rara en un dato que lee. No es una cuestión de grado: son dos situaciones distintas.

   Por eso el diseño empieza por la lista de herramientas, y en ella sólo hay verbos de mirar: leer_hoja, consultar_stock, listar_ventas. Y una sola de salida: enviar_correo_al_titular, con el destinatario fijo en el código, no como parámetro. Si el destinatario es un parámetro, el agente elige a quién escribe.

   Ayúdame a diseñar un agente de SÓLO LECTURA para una farmacia.
   
   ENCARGO: <<todos los días a las 7:00, mirar la hoja de caducidades y
   avisarme si ha aparecido algo nuevo en estado CADUCADO o URGENTE desde
   el día anterior>>
   
   RESTRICCIONES QUE SON PARTE DEL DISEÑO:
   - El agente NO puede escribir, modificar ni borrar nada en ningún sitio.
   - Su única salida es un correo, y el destinatario está fijo en el
     código: no es un parámetro que él pueda elegir.
   - Máximo 8 vueltas del bucle. Si las agota, manda un correo diciendo
     que no pudo terminar.
   - Si un dato le falta, lo dice en el correo. No lo supone.
   
   DAME, EN ESTE ORDEN:
   1. La lista de herramientas que necesita, con el contrato de cada una:
      qué recibe, qué devuelve, y qué pasa si falla.
   2. Para cada herramienta, si LEE o si ESCRIBE. Si alguna escribe,
      dime por qué y propón una alternativa que no escriba.
   3. Las instrucciones del agente (el prompt de sistema).
   4. El código del bucle.
   5. UNA LISTA DE 5 FORMAS DE QUE ESTO SALGA MAL, y qué lo impide en el
      diseño. Si alguna no está impedida, dilo claramente.
   
   En el punto 5 no me tranquilices. Búscale los fallos de verdad.

2. Revisa la lista de herramientas antes que el código

   El código es largo y es lo que menos hay que mirar. La lista de herramientas son diez líneas y es donde está toda la seguridad.

   Lee los nombres uno a uno. Cualquiera que empiece por crear, actualizar, borrar, enviar, marcar, mover o guardar escribe, aunque el nombre suene inocente. marcar_como_revisado escribe. guardar_informe escribe.

   Si aparece alguna, no la arregles con una instrucción: quítala. Y si resulta que el encargo la necesita de verdad, entonces ése no es tu primer agente. Cámbialo por otro que no la necesite y guarda éste para cuando lleves tres funcionando.

   Y comprueba que el destinatario del correo no aparece como parámetro en ninguna llamada. Es el fallo más habitual de este diseño y es fácil de ver: busca tu propia dirección en el código y mira si está escrita ahí o si viaja dentro de una variable.

3. Pruébalo en seco antes de darle acceso a nada

   Antes de conectarlo a tu hoja de verdad, pídele que lo ejecutes con datos de mentira: una tabla de ocho filas que escribes tú, con dos caducados, uno urgente y una fecha vacía.

   Ahí se ve todo lo que importa: si detecta lo que tiene que detectar, si el correo se entiende, y —lo mejor— cuántas vueltas del bucle ha dado para hacer algo tan simple. Si ha dado siete para leer ocho filas, algo está mal planteado y lo vas a pagar cada día.

   Mete después un caso feo a propósito: una fila con la fecha escrita como texto. Un agente que da esa fila por buena está fallando en silencio, que es exactamente lo que no quieres que haga solo a las siete de la mañana.

4. Déjalo suelto una semana y míralo todos los días

   Los primeros siete días, cada correo que mande lo contrastas con la hoja. No es desconfianza: es la única forma de saber si lo que has montado hace lo que crees.

   Lo que hay que mirar no es si el correo está bien escrito —eso lo hace bien siempre— sino si lo que dice es verdad. Que lo que señala está realmente en rojo, y que lo que no señala realmente no lo está. El segundo es el importante y el que casi nadie comprueba: un agente que no avisa de algo no deja ningún rastro.

   Si a la semana va bien, déjalo. Y ponte un recordatorio para dentro de un mes con una sola tarea: comprobar un correo entero contra la hoja. Ésa es la diferencia entre tener un agente y tener un correo que llega.

5. Cuándo dar el paso siguiente, y cuál es

   El siguiente agente no es «uno que escriba». Es otro de sólo lectura, con un encargo distinto. Y después otro. Hasta que tengas tres funcionando y comprobados y te aburra mirarlos.

   Sólo entonces tiene sentido plantearse uno que escriba, y la forma de hacerlo no es darle permiso de escritura: es que prepare el borrador y lo apruebes tú. Un agente que deja el pedido montado y espera tu «sí» tiene todas las ventajas del automático y ninguna de las consecuencias.

   Esa frontera —escribir requiere una aprobación humana— es lo que la lección de agentes en producción trata en serio. Este caso te deja justo delante de ella, con uno funcionando y con la mano hecha.

Un ejemplo entero, con lo que falla

El encargo del paso 2 —mirar la hoja de caducidades y avisar de lo nuevo en rojo—. Esto es el punto 1 y el punto 5 de lo que devolvió, que son los dos que hay que leer.

Y ahora, qué falla en esa respuesta:

1. Ahí está la herramienta que escribe, y con nombre inocente. guardar_estado suena a llevar la cuenta y es una escritura. Está declarada honestamente como ESCRIBE —eso lo ha hecho bien— pero el encargo decía que no escribiera nada y la ha metido igual, porque «avisar sólo de lo NUEVO» necesita recordar lo de ayer. El modelo resolvió el problema y se saltó la restricción sin señalarlo.
2. Y la salida correcta no es quitarla: es cambiar el encargo. Si quitas guardar_estado, el agente te avisa todos los días de lo mismo y a la semana lo apagas. La salida buena es renunciar al «sólo lo nuevo»: que te mande la lista entera de lo urgente cada día. Son cuatro líneas de correo y el agente pasa a no escribir en ningún sitio. Peor sobre el papel, y es el primer agente.
3. El destinatario es un PARÁMETRO en enviar_correo. Eso significa que el agente elige a quién escribe. Hoy te escribe a ti; el día que una fila de la hoja contenga un texto raro, puede no ser así. El destinatario va fijo en el código y la herramienta pasa a ser avisar_al_titular(asunto, cuerpo) — dos parámetros en vez de tres, y una cosa menos que puede elegir.
4. Y el punto 5 te ha tranquilizado, que era lo prohibido. Las cinco «formas de que salga mal» son operativas y ninguna es de seguridad: no menciona el dato malicioso, ni qué pasa si la herramienta devuelve algo inesperado, ni el propio guardar_estado que acaba de meter. Y cierra con «el diseño es seguro». El prompt decía «no me tranquilices» y lo ha hecho igual — pídeselo otra vez señalando lo que se dejó.

Dos problemas de diseño y los dos están en la lista de herramientas, que son diez líneas. El código eran ochenta y no hacía falta leerlo.

Ésa es la lección del caso: la seguridad de un agente se revisa en la lista de herramientas, no en el código. Si ninguna escribe, no puede escribir — da igual lo que diga el prompt, lo que razone el modelo y lo que alguien haya metido en un dato.

Y si tu farmacia no es así

Cuando no sale a la primera