Un sistema de agentes se juzga por lo que se rompe cuando no estás

Un sistema de agentes no se juzga cuando funciona. Se juzga por lo que se rompe cuando nadie está mirando.

Esta semana un creador de contenido ha publicado cómo convertir Claude Code y Opus 5.5 en tu «sistema operativo agéntico». En tres pasos.

Tres.

No digo que el vídeo esté mal. Seguramente funciona. El problema es la palabra sistema. Un sistema no se demuestra el día que lo montas, delante de la cámara, con el café caliente. Se demuestra la primera noche que corre sin nadie delante.

Y esa noche no sale en ningún vídeo.

El sistema no es el agente, es lo que queda escrito

La confusión de base es esta: pensamos que el sistema es el agente. El modelo, el prompt, la herramienta que lo ejecuta.

No.

El agente es el obrero. Llega, hace un trabajo y se va. Y se va de verdad: cuando termina, no recuerda nada. Lo que hace que mañana se pueda seguir donde se quedó hoy no está en el agente. Está en lo que dejó escrito.

En mi vault eso tiene forma de tablero kanban hecho de ficheros. Cada encargo es una nota markdown, una tarjeta. Y la carpeta donde vive la tarjeta es su estado:

• «programadas»: las que se repiten (el artículo diario, el mantenimiento, el resumen de canales).
• «pendientes»: esperando a que un agente la reclame.
• «en curso»: reclamada, con alguien trabajando.
• «hechas»: cerrada, con las rutas de lo que produjo.

No hay una propiedad «estado» que mantener al día. Mover el fichero es cambiar de columna. Y mover un fichero es una operación atómica: o se ha movido o no. Por eso dos agentes no pueden pisarse la misma tarjeta. El primero que la mueve a «en curso» se la queda y escribe en ella «agente» y «reclamada» con la hora.

Encima de eso hay un proceso muy tonto, el lanzador. Cada sesenta segundos mira el tablero, ve qué hay pendiente, decide qué perfil lo atiende y lo lanza. No tiene memoria. Hace una pasada y muere. Toda la memoria está en las carpetas.

Esto, que parece un detalle de fontanería, es la decisión más importante de todo el montaje. Si el estado vive en la cabeza del agente, cada fallo te lo borra. Si vive en disco, cada fallo deja rastro.

Un sistema de agentes es tan bueno como lo que puedes leer de él a la mañana siguiente.

Tres maneras de romperse de noche

Llevo más de veinte años con sistemas que tienen que funcionar cuando no estás. Líneas robotizadas de soldadura para General Motors, hace veinticinco años. Y allí aprendí algo que vale igual para un robot que para un agente de IA: lo que define un sistema es su forma de fallar, no su forma de funcionar. Funcionar, a la primera, funciona casi todo.

De noche, un sistema de agentes falla de tres maneras. Las he sufrido las tres. Con fecha.

Se para, y nadie se entera

El 10 de septiembre, a la 01:27, macOS decidió actualizarse. Abrió una cuenta atrás de reinicio y dejó el sistema en un modo raro, «solo bajo demanda», en el que el planificador del Mac deja de arrancar tareas nuevas.

Mi lanzador era una de esas tareas. Se arrancaba cada minuto desde el planificador.

Doce horas sin despachar una sola tarjeta.

Lo peor no fueron las doce horas. Lo peor es que nada avisó. El vigilante, el que mira si hay tarjetas dormidas, también dependía del mismo planificador. Estaba igual de muerto. El reinicio que había provocado todo, por cierto, nunca llegó a ocurrir.

Lo curioso es que otro proceso que ya estaba vivo en ese momento sobrevivió intacto. El modo raro bloquea arranques nuevos, no mata lo que ya corre. Así que la solución fue cambiar de idea: el lanzador ya no se arranca cada minuto. Se arranca una vez y se queda vivo, en un bucle, y si muere el sistema lo resucita.

Y añadí un latido: un fichero que el bucle toca solo si la pasada ha terminado bien. Si el lanzador empieza a fallar en cada vuelta, el bucle sigue vivo pero el latido se enfría, y eso dispara el aviso. Un bucle vivo ejecutando basura es peor que un bucle muerto: al menos el muerto se nota.

Se atasca, y lo parece todo bien

Segundo modo. El sistema está vivo, el lanzador gira, pero una tarjeta se queda parada.

El 24 de septiembre, a la 01:15, el publicador cogió su tarea de cada noche: publicar en el blog la siguiente propuesta pendiente. Encontró dos. Una repetía la anécdota y la tesis de un artículo ya publicado. La otra no tenía ficha: ni fecha, ni categoría, nada donde anotar que se había publicado.

Hizo lo correcto. No eligió por su cuenta. Marcó la tarjeta como «bloqueada», escribió el motivo en una línea y la devolvió a pendientes, para mí.

Nadie la miró. Al día siguiente, otra igual.

El 27 de septiembre, a las 02:30, el vigilante mandó un aviso al móvil: dos tarjetas dormidas, una de 73 horas y otra de 49, las dos bloqueadas con el mismo motivo. Esa misma mañana quedó resuelta: una propuesta marcada para no publicarse y la otra corregida y publicada ese día.

Fíjate en lo que funcionó aquí. El agente no adivinó. Se paró, dijo por qué y dejó la tarjeta donde yo podía verla. Y el vigilante, que no sabe nada de artículos, solo sabe contar horas, fue el que hizo que me enterara. Ninguno de los dos es listo. Son honestos.

Hay un tope, además: cada tarjeta lleva un contador de «intentos», y a los dos fallos el sistema deja de reintentar y avisa. El 14 de septiembre la criba de tendencias falló dos veces seguidas por una entrada que no existía, y en lugar de girar toda la noche quemando tokens, a las 17:46 me llegó un mensaje: bloqueado en criba, límite alcanzado, no se reintenta.

Se salta trabajo, y nadie lo dice

El tercero es el peor, porque es el único que parece éxito.

A finales de septiembre, el agente que redacta los artículos dejó uno (el de los canales de YouTube hechos con IA) sin la ficha del principio. El publicador tiene una regla fija: solo publica propuestas con ficha. Así que cada noche miraba la carpeta, no veía nada publicable y cerraba su tarjeta como «no queda nada pendiente».

Tres noches. Tarjeta en «hechas». Todo verde.

Mentira.

No había ningún error que capturar. Cada agente hizo exactamente lo que decía su perfil. El fallo estaba en el hueco entre los dos: uno producía algo que el otro no reconocía, y el que no lo reconocía lo ignoraba en silencio en lugar de decir «aquí hay un fichero que no entiendo».

La corrección fue doble: el redactor escribe la ficha siempre, sin excepción, y queda apuntado en su perfil como cicatriz con fecha. Este mismo artículo empieza por esa ficha.

Lo que enseña un tutorial y lo que hace falta para dormir

	El sistema del tutorial	El sistema que aguanta la noche
Dónde vive el estado	En la conversación con el agente	En ficheros, en carpetas que son columnas
Quién arranca el trabajo	Tú, escribiendo	Un lanzador sin memoria, cada minuto
Si dos agentes van a por lo mismo	No se plantea	Reclamo atómico: mover el fichero
Si algo falla	Lo ves en pantalla	Queda «bloqueada» con fecha y motivo
Si falla en bucle	No aplica	Tope de «intentos» y aviso
Si se para todo	Lo notas al volver	Latido que se enfría y aviso al móvil
Si un agente no entiende lo que recibe	Improvisa	Para y lo dice; nunca lo ignora
Cómo sabes qué pasó	Te acuerdas	El Registro de cada tarjeta

La columna de la izquierda no es mala. Es el día uno. Todos empezamos ahí. El problema es creer que el día uno ya es el sistema.

Cómo se monta la parte que no sale en el vídeo

No hace falta copiar mi montaje. Hace falta tomar unas cuantas decisiones antes de dejar nada corriendo de noche. Pasito a pasito:

1. Saca el estado de la conversación. Cada encargo, un fichero. Cada estado, una carpeta. Si cierras la sesión y el encargo desaparece, no tienes sistema: tienes un chat.
2. Haz que reclamar sea un gesto atómico. Mover el fichero a «en curso» y anotar quién y cuándo. Sin eso, el día que tengas dos agentes, se pisarán.
3. Dale a cada tarjeta una sección ## Registro en el cuerpo. El agente escribe ahí un hito nada más empezar («admitida, monto tal habilidad sobre tal cosa») y otro al cerrar, con lo que produjo. En mi tablero esto es norma: una tarjeta en curso sin hitos es indistinguible de una colgada.
4. Pon un vigilante tonto. Que no sepa nada del trabajo. Solo que cuente horas: toda tarjeta que lleve más de 24 horas sin moverse, aviso. Es el componente más simple y el que más veces me ha salvado.
5. Pon un latido al propio lanzador. El vigilante vigila tarjetas; alguien tiene que vigilar al que mueve las tarjetas.
6. Limita los reintentos. Dos intentos y aviso. Un agente que reintenta sin fin no es perseverante, es caro.
7. Prohíbe el silencio. Cada perfil tiene que preferir parar y decir «esto no lo entiendo» antes que seguir como si nada. Escríbelo en el perfil de cada agente. Literalmente.

Y una prueba que vale más que todas las anteriores: deja el sistema corriendo una noche y, a la mañana siguiente, intenta contar qué pasó solo leyendo las tarjetas. Sin abrir logs, sin preguntarle a nadie. Si no puedes, todavía no está listo.

«Ya, Marcos, pero yo solo quiero que me resuma las notas»

Lo sé. Y me parece bien.

Si tu uso es abrir una sesión, pedir algo, leerlo y cerrar, no necesitas nada de esto. Tú eres el sistema: estás delante en cada paso. Ahí el tutorial de tres pasos te sobra y te basta.

El problema llega el día que dices «esto que hago cada mañana, que lo haga solo». Ese día cambias de oficio sin darte cuenta. Ya no estás usando una herramienta, estás operando algo que corre sin ti. Y lo que corre sin ti tiene que poder contarte qué ha hecho.

La otra objeción es la de la sobreingeniería: «carpetas, contadores, latidos… para un vault personal». Mira lo que he contado. Una actualización del sistema operativo. Un artículo sin ficha. Un borrador repetido. Nada exótico. Son exactamente las cosas que le pasan a cualquiera. La diferencia es si te enteras a las doce horas por un aviso o a las tres semanas porque el blog lleva parado y no sabes desde cuándo.

Los errores que más caros salen

• Confiar en el planificador como si fuera el sistema. El planificador arranca cosas. No te dice cuándo deja de arrancarlas. Me costó doce horas aprenderlo.
• Vigilar con el mismo mecanismo que vigilas. Mi vigilante dependía del mismo planificador que el lanzador. Cayeron juntos. El que vigila tiene que poder sobrevivir a lo que vigila.
• Contar «hecha» como «bien hecha». Una tarjeta cerrada solo dice que el agente terminó. Por eso en mi tablero no se puede cerrar una tarjeta con «rutas» vacío: si dice que ha hecho algo, tiene que señalar dónde está.
• Dejar que el agente adivine. Si la entrada no está o no tiene lo que debería, el agente bloquea la tarjeta y lo dice. Un borrador hecho sobre una suposición vale menos que una tarjeta bloqueada.
• Formatos sueltos entre agentes. El fallo de la ficha fue eso: un contrato que uno cumplía y otro no. Si un agente produce lo que otro consume, el formato se escribe en el perfil de los dos.
• Romper el fichero de estado. Un «frontmatter» con un error de sintaxis hace la tarjeta invisible a la vez para el tablero y para el lanzador. El 26 de agosto el mantenimiento detectó una así y avisó. Desde entonces lo comprueba cada día, y ningún agente puede inventarse campos en la cabecera de una tarjeta.

La noche es el examen

Un sistema de agentes no se gradúa el día que funciona. Se gradúa la primera noche que algo sale mal y, por la mañana, lo tienes contado en una línea, con hora, sin haber tenido que buscarlo.

Eso no lo da un modelo mejor ni un tutorial más corto. Lo da el estado en disco, el vigilante tonto y la regla de que nadie calla.

Y aquí también aplica el efecto compuesto. Cada avería que queda escrita en el perfil del agente que la tuvo es una avería que no vuelve. Mi redactor lleva once versiones. Casi todas tienen una fecha y algo que se rompió una noche.

El vídeo te da los tres pasos. Las noches te dan el sistema.