Agentes programados y en segundo plano

La marca verde no significa lo que crees

Empecemos donde la mayoría de las introducciones termina. El mayor riesgo de una ejecución programada no es que falle, sino que parezca que ha salido bien. (Si la idea de agent todavía es nueva, conviene leer antes qué hace un agent en la práctica , paso a paso.)

La documentación del fabricante es inusualmente honesta al respecto: en la lista de ejecuciones, el estado verde solo garantiza que la sesión arrancó y terminó sin error de infraestructura. Lo que pasó por el camino solo se ve en el registro — las peticiones de red bloqueadas, las herramientas que faltaban y los errores de la propia tarea aparecen ahí, no en el indicador de estado.

Esta es la base conceptual de todo el artículo. En un agent de segundo plano la pregunta de diseño más importante no es qué debe hacer, sino cómo te vas a enterar de que no lo ha hecho.

Tres tipos de «segundo plano»

El lenguaje corriente mezcla tres cosas técnicamente muy distintas. Vale la pena separarlas, porque la elección decide qué puedes hacer con ellas:

Dos filas de esa tabla deciden la mayoría de los casos.

La primera son los ficheros locales. El agent que corre en la nube recibe una copia nueva, no el estado que hay en tu equipo. Si la tarea trata de ficheros de tu carpeta, eso lo descarta.

La segunda es la petición de permiso. En la ejecución en la nube no hay diálogo de aprobación, lo cual resulta cómodo hasta que piensas qué significa. La misma documentación lo dice: esas ejecuciones son sesiones completamente autónomas, sin modo de permisos que elegir y sin preguntas de aprobación. O sea, lo que le des, lo puede usar sin preguntar. Cómo estrechar los permisos lo recorre en detalle el post el agent con los permisos mínimos , con ejemplos.

¿Qué debe dispararlo?

Hay tres tipos de disparador, y casi toda decepción viene de usar el primero donde corresponde el tercero:

1. Programación. Cada hora, cada noche, cada semana, o una sola vez en un momento futuro. Simple, previsible — y derrochador, si la mayoría de las ejecuciones no tiene nada que hacer.

2. Llamada externa. El agent tiene un endpoint que otro sistema invoca. Es lo más flexible: tu sistema decide cuándo hay trabajo.

3. Evento. Se crea un envío en el repositorio, entra un correo, cambia una fila en la base de datos. Para la mayoría de las tareas de negocio esta es la respuesta correcta: se ejecuta cuando llega el dato, en vez de mirar cada hora si hay alguno.

Un detalle práctico que siempre sale con los eventos: el disparo repetido. Los buenos sistemas tienen un tope horario de eventos por ejecución y por cuenta, y los eventos por encima del tope se descartan. No es solo protección de coste, también es protección contra la duplicación: si el evento entra dos veces, no debería ejecutarse dos veces.

Si no construyes desde código, las plataformas no-code empaquetan justo estos tres modos de disparo en una interfaz — eso es lo que compara plataforma a plataforma el post las plataformas de automatización no-code , con tablas.

El problema de parar, medido

Este capítulo importa porque no es una opinión. En la tipología de fallos de un estudio que procesó 1.642 trazas de ejecución anotadas, tres categorías hablan directamente de parar:

Juntas, más del 34 % — es decir, más de un tercio de los fallos observados tiene que ver con que el agent no sabe cuándo pararse. O da vueltas, o abandona antes de tiempo.

En uso interactivo eso es molesto. Corriendo en segundo plano, eso es la factura. El agent que gira en círculos no se queja ni pregunta: solo consume, hasta que algo lo detiene.

Por eso el primer ajuste de un agent de segundo plano no es el prompt, sino el límite: máximo de pasos, máximo de tiempo, límite de tiempo por herramienta. Cuando el presupuesto se agota, los buenos sistemas no lanzan una excepción, sino que devuelven una salida controlada, de modo que se pueda distinguir el caso «no terminó» del caso «se fue a error». Por qué la probabilidad de fallo crece con el número de pasos lo deduce con cuentas el post la matemática de la fiabilidad de los agents , con un ejemplo.

¿Qué pasa si no lo miras durante un mes?

Para esto hay un experimento publicado y poco habitual por lo sincero. En 2025 un desarrollador de modelos gestionó durante un mes aproximadamente una tienda de oficina con un agent, con dinero real y clientes reales: nevera, estanterías, caja de autoservicio y, en manos del agent, las compras, los precios y la comunicación con los clientes.

El resultado: pérdidas. La mayor caída vino de comprar un producto al por mayor y venderlo después por debajo del precio de compra.

Los modos de fallo documentados son todavía más instructivos:

• Cuenta bancaria alucinada. Mandó a los clientes a pagar a una cuenta que no existía.
• Facilidad para dejarse convencer. Por mensaje le sacaron códigos de descuento y luego, con efecto retroactivo, le rebajaron los presupuestos alegando esos códigos.
• Confusión de identidad. Durante dos días se inventó una conversación con una persona inexistente, se refirió a una dirección inexistente y luego empezó a comportarse como una persona real: afirmó que llevaría los productos en mano y describió con qué ropa iría.

De los tres, el tercero es la lección más importante para el segundo plano. El riesgo no es que el agent se estropee y se pare, sino que se estropee y siga adelante con total seguridad. En la ejecución sin vigilancia, nada indicaba que hubiera un problema.

¿Cómo debe avisar de que hay un problema?

Aquí está el núcleo práctico del artículo. Cuatro patrones, todos de fuentes documentadas:

1. El reintento agotado es la señal terminal. Los clientes bien construidos reintentan por dentro las peticiones fallidas y solo emiten un evento de error cuando se han rendido. Esto importa: si avisas de cada fallo parcial, obtienes ruido. Si vigilas la rendición, obtienes señal.

2. Hay que poder distinguir la ejecución que se recuperó de la que se quedó atascada. La receta es sencilla: agrupa por identificador de sesión y mira si hay otra petición DESPUÉS del error. Si la hay, el agent continuó. Si no la hay, ahí se paró.

3. La petición de permiso provoca una parada muda. Este es uno de los fallos más traicioneros: si el agent pide aprobación mientras tú no estás delante del equipo, la sesión se detiene y espera; no falla, no avisa, simplemente no avanza. Hay dos salidas: o rediriges la aprobación a un canal que sí alcanzas (mensajería, chat), o concedes los permisos de antemano — pero esto último solo es aceptable en un entorno en el que confíes. El diseño de los puntos de aprobación lo trata el post el humano en el bucle en detalle.

4. Tres cosas que merecen una alerta, y las nombra la propia guía de monitorización del fabricante: pico de coste, consumo inusual de tokens y un número inusual de ejecuciones desde la misma fuente. Las tres cogen lo mismo: el agent está haciendo algo que no habías planeado.

Límites de gasto: ¿dónde lo paras?

La ejecución en segundo plano se diferencia de la interactiva en que no hay nadie que lo note. Por eso el límite hay que construirlo de antemano, en tres niveles:

1. TOPE DE GASTO DE CUENTA U ORGANIZACIÓN
   Un presupuesto mensual por encima del cual se
   rechaza. Es la última línea, no la primera.

2. TOPE DE NÚMERO DE EJECUCIONES
   Cuántas pueden arrancar al día. En agents por
   eventos este es el límite más importante.

3. PRESUPUESTO DENTRO DE LA EJECUCIÓN
   Máximo de pasos, de tiempo y por herramienta.
   Es el único que detiene el BUCLE.

Un detalle técnico que ya ha arruinado muchas automatizaciones: cuando el servicio rechaza por el tope de gasto, la respuesta suele ser el mismo código de error de «inténtalo otra vez» que en caso de saturación, pero sin decir cuándo merece la pena reintentar. El reintento automático entonces falla con toda seguridad y encima mete ruido en el registro. Conviene tratar los dos casos por separado en el cliente.

Y un detalle positivo en el otro sentido: en la mayoría de los proveedores, los tokens leídos de la caché no cuentan para el límite de entrada por minuto. En una tarea de fondo repetitiva — donde el mismo prompt de sistema largo entra en cada ejecución — esa diferencia significa varias veces más capacidad de proceso dentro del mismo límite.

Registro: la mayoría de los sistemas no guarda lo que crees

Esta es la parte que importa un mes después, cuando hay que decir qué hizo el agent el martes.

La telemetría habitual guarda por defecto el número de ejecuciones, el consumo de tokens, el coste, los errores de API, las decisiones de herramienta y los resultados de herramienta. Es mucho, pero fíjate en lo que falta.

Lo que está DESACTIVADO por defecto:

Esto no es un defecto, sino una decisión deliberada de privacidad — y precisamente por eso hay que decidirlo conscientemente antes de arrancar un agent de segundo plano. Lo que no activaste no se puede reconstruir después.

Dos trampas que van con esto:

• Lo que el agent arranca puede quedar fuera de la traza. Los ajustes de telemetría normalmente no se heredan a los subprocesos que lanza el agent: los comandos, los servidores de herramientas externos. Así que el registro muestra que el agent ejecutó algo, pero no qué hizo ese algo.
• La métrica de coste es una aproximación. Lo dice la propia documentación: para la contabilidad oficial hay que mirar los datos de facturación del proveedor. La telemetría sirve para alertar, no para llevar las cuentas.

La guía práctica

1. PRIMERO DECIDE QUÉ LO DISPARA
   Evento > llamada externa > programación. La
   ejecución horaria es la forma más cara de mirar
   si tienes trabajo.

2. DALE UN PRESUPUESTO ANTES QUE UN PROMPT
   Máximo de pasos, de tiempo, y por herramienta.
   El bucle es el fallo más frecuente de todos.

3. DECIDE DÓNDE DEBE EJECUTARSE
   ¿Necesita ficheros locales? Entonces no en la nube.
   ¿Necesita autonomía? Entonces no en sesión abierta.

4. RESUELVE LA APROBACIÓN ANTES DE ARRANCAR
   O la rediriges a un canal que sí alcanzas, o le
   das de antemano los permisos mínimos. El "ya
   preguntará" en segundo plano es parada muda.

5. QUE ESCRIBA QUÉ HIZO - NO SOLO QUE SE EJECUTÓ
   El mensaje final debe decir: qué encontró, qué
   cambió y qué NO pudo terminar.

6. ACTIVA LO QUE QUIERAS REGISTRAR
   Las llamadas a herramientas y el contenido no
   entran por defecto. Después ya no se recuperan.

7. AVISA POR TRES COSAS
   Pico de coste, consumo raro de tokens,
   número raro de ejecuciones. Señalan lo mismo.

8. MIRA EL REGISTRO UNA VEZ POR SEMANA
   No el indicador - el registro. La marca verde
   solo dice que arrancó y que salió.

El quinto punto es el más barato y el que más aporta. Si el agent de segundo plano manda al final de cada ejecución un resumen de tres frases sobre qué no pudo terminar, ya has cazado la mayoría de los fallos mudos. El mensaje del tipo «todo correcto» es justo lo contrario: es exactamente igual que la marca verde.

Malentendidos típicos

• «Se ejecutó, o sea que está hecho.» El estado de la ejecución habla de la infraestructura, no de la tarea. Lo escribe la propia documentación del fabricante.
• «Si hay problema, ya avisará.» Con los ajustes por defecto no avisa. La parada muda — por ejemplo una pregunta de aprobación sin responder — no es un error: simplemente no pasa nada.
• «La ejecución horaria es un buen valor por defecto.» Depende. Si la mayoría de las ejecuciones no tiene nada que hacer, es cara; si el dato llega más rápido que cada hora, llega tarde. El disparo por eventos resuelve ambas.
• «Del registro se sabrá después.» Solo de lo que activaste. Los prompts, las respuestas y los detalles de las llamadas a herramientas no suelen guardarse por defecto.
• «Reintentar siempre ayuda.» No cuando el rechazo viene del tope de gasto: el reintento falla con seguridad y solo hace ruido.
• «Una tarea pequeña no necesita vigilancia.» En el experimento citado la tarea era una tienda, con dinero real — y en un mes llegó a una cuenta bancaria alucinada y a una identidad inventada.

Lo que conviene llevarse

Un agent programado no se vuelve fiable porque su prompt sea bueno, sino porque has dicho en voz alta qué significa el éxito y qué pasa cuando no es eso lo que hay.

Tres cosas son obligatorias en cualquier agent de segundo plano: presupuesto (pasos, tiempo, dinero), canal (por donde pueda pedir aprobación e informar) y un registro que leas de verdad. Sin esas tres, la automatización no es trabajo ahorrado, solo trabajo aplazado.

Y la comprobación más barata que puedes hacer hoy: mira el registro de tu última ejecución automatizada — no su estado, su contenido. Si no puedes decir en cinco minutos qué hizo, tampoco vas a notar el siguiente fallo. La automatización de los informes diarios y semanales tiene su propio texto: el post los informes recurrentes trae ejemplos prácticos.