De la demo que sale bien al agente que aguanta encendido

Un creador de contenido conectó Claude a su vida y a su negocio, y grabó lo que pasó. La serie se llama, más o menos, “esto es lo que se rompió”.

No “mira qué maravilla”. Lo que se rompió.

Y ahí está la parte interesante, la que casi nadie enseña. Todo el mundo publica el vídeo en el que el agente hace algo asombroso a la primera. El problema es que ese vídeo dura tres minutos. Tu vida dura un poco más.

Una demo es un actor en el escenario; producción es la obra los 365 días

Una demo funciona porque alguien ha preparado el decorado. Los ficheros en su sitio, el ejemplo que sabemos que sale, el prompt afinado la noche anterior. Es teatro con los bastidores bien colocados: desde la butaca todo es magia.

Producción es otra cosa. Producción es el agente encendido un martes a las tres de la mañana, con un fichero que no esperaba, un permiso que le falta y nadie mirando. Ahí no hay decorado. Ahí se rompe.

Llevo más de veinte años con esto. No con IA: con sistemas críticos. Líneas robotizadas de soldadura para General Motors, robots hace veinticinco años, en fábricas donde si el sistema se para, se para la producción de coches de verdad. Y lo primero que aprendes en ese mundo no es a hacer que algo funcione. Es a hacer que algo siga funcionando cuando tú no estás delante.

Son dos disciplinas distintas. La demo pertenece a la primera. El agente sobre tu vault pertenece a la segunda.

Puestas una al lado de la otra se ve mejor dónde está el salto:

	La demo	Producción
Quién mira cuando ocurre	Tú, en directo	Nadie, y son las tres de la mañana
Los datos de entrada	Los que has elegido	Los que aparezcan
Cuando algo falla	Lo repites y ya	Se acumula hasta que alguien lo nota
El éxito se mide en	Que salga una vez	Que no rompa en un mes
Permisos	Todos, para que no moleste	Los mínimos, y declarados
Si cambia el entorno	Reescribes el prompt	El sistema se entera solo, o avisa
Coste de un error	Repetirlo	Un fichero tocado que no tocaba
Qué demuestra	Que se puede	Que aguanta

La columna de la izquierda se consigue en una tarde. La de la derecha es un oficio.

Lo que se rompe casi siempre es lo mismo

Cuando conectas un agente a algo que te importa de verdad, tu conocimiento, tu negocio, tus datos, los fallos no son exóticos. Son aburridos y repetidos:

• El 90/10. El agente hace lo correcto nueve de cada diez veces y la décima hace algo que no querías, sin avisar. Lo cual es peor que fallar siempre: si fallara siempre lo habrías apagado el primer día.
• El permiso de más. Le das acceso a todo “para que no moleste” y un día toca lo que no debía.
• El cambio silencioso. Alguien mueve una carpeta, renombra un fichero, y la automatización que llevaba semanas funcionando deja de encontrar nada.
• El fallo que no se ve. No da error. Simplemente hace la mitad del trabajo y sigue tan tranquilo.

Ninguno de esos fallos sale en la demo. Todos salen en producción. Por eso los vídeos de “esto se rompió” valen más que los otros: son el único sitio donde alguien te enseña la parte cara.

Yo tengo el sistema encendido, no la diapositiva

Aquí es donde dejo las cartas sobre la mesa. Yo no opino de agentes desde una prueba de un rato. Opino desde un Mac Mini funcionando 24 horas al día, con agentes trabajando de verdad sobre mi sistema de conocimiento. No siempre acierto. Pero cuando algo se rompe, se rompe en mi casa y lo arreglo yo.

Esa diferencia lo cambia todo. Cuando hablas desde el sistema encendido, no puedes contar la versión bonita, porque el lunes siguiente el sistema te desmiente. Te obliga a ser honesto.

Y lo que el sistema encendido enseña, resumido, es esto:

Un agente no vale por lo que hace bien un día. Vale por lo que no rompe en un mes.

Vamos con la factura de esa frase.

Dos días trabajando con el motor apagado

Mi sistema reparte el trabajo con tarjetas. Una tarjeta dice qué hay que hacer, un repartidor determinista la casa con el agente que sabe hacerlo y lanza el proceso. El agente trabaja, cierra la tarjeta y se muere. Temporero, no empleado.

El 31 de agosto me quedé sin crédito mensual en OpenRouter. El proveedor devolvía un 402 y todos los agentes que pasaban por ahí caían, dos días seguidos. Avería fea pero honesta: se veía.

Así que hice lo sensato. Monté un respaldo: si una tarjeta ya había fallado una vez, el siguiente intento salía por otro proveedor. Dormí muy tranquilo.

Una semana después, la noche del 7 de septiembre, caducó la sesión de Claude Code que usaban los agentes. No la había tocado nadie: era un «/login» del 9 de agosto y esas sesiones duran unos treinta días. Veintinueve días y veintiuna horas después de entrar, se apagó sola.

Y entonces pasó lo que no estaba en el guion. El respaldo funcionó. Funcionó tan bien que me escondió la avería durante dos días.

Mira la mecánica, porque es la parte que importa:

1. El agente arranca por el proveedor primario y muere sin hacer nada.
2. La tarjeta se queda huérfana. A los 45 minutos, el rescate de procesos colgados la devuelve a la cola.
3. Como ya lleva un intento fallido, sale por el respaldo. Y sale bien.
4. La tarjeta se cierra con normalidad y se archiva.

¿Qué veía yo por la mañana? Un tablero limpio. Todo hecho. Ni una alarma.

El vigilante que tengo para esto solo mira tarjetas dormidas más de 24 horas, y ninguna llegaba a dormir 24 horas: el respaldo las recogía en 45 minutos. La degradación quedaba anotada en el historial de cada tarjeta, sí. Pero nadie lee el historial de una tarjeta que salió bien.

Lo descubrí por casualidad, al encontrar caída la sesión del agente continuo. Dos días pagando el doble de latencia, usando el proveedor de emergencia como si fuera el normal y sin saberlo.

El arreglo fueron dos cosas, y ninguna es “poner más cuidado”. La primera: caer al respaldo dispara un aviso inmediato al móvil, nombrando qué proveedor se ha caído, qué tarjeta lo ha descubierto y quién la ha recogido. La segunda: los agentes dejaron de usar mi sesión de usuario y pasaron a una credencial propia de un año, inyectada solo en el momento del lanzamiento y solo con permiso para hablar con el modelo, nada más.

La lección que me llevé no fue “vigila tus tokens”. Fue esta otra, bastante peor de digerir:

Cada arreglo que pones trae su propio punto ciego. El respaldo que te salva de la avería de agosto es exactamente lo que te impide ver la de septiembre.

Y el segundo, más tonto: alguien movió una carpeta

Este mismo artículo lleva en su cabecera la referencia a la selección de tendencias de la que salió. Al ampliarlo, esa ruta ya no existía: la carpeta «ideas a valorar» se había reorganizado y hoy se llama «02 seleccion».

Nadie rompió nada. Nadie recibió un error. Simplemente el puntero apuntaba al vacío, tan tranquilo, y habría seguido apuntando al vacío indefinidamente si no llega a pasar por ahí alguien que comprueba los ficheros antes de fiarse de ellos.

Y no es un caso aislado. Al renombrar los informes de tendencias, las dos selecciones que apuntaban a ellos con la ruta escrita a mano se quedaron señalando ficheros inexistentes. Si hubieran apuntado con un enlace interno del propio Obsidian, se habrían actualizado solas. Ahí está el arreglo, y no tiene nada de inteligencia artificial: una referencia que el editor entiende sobrevive a un renombrado; una cadena de texto, no.

Es el fallo más aburrido de la lista, y el más común. No requiere agentes ni nada sofisticado: requiere una persona ordenando su vault un domingo.

Cómo se pasa de la prueba a algo que aguanta

Si estás en el punto de “me ha funcionado una vez, ¿y ahora qué?”, el camino no es un truco. Es oficio prestado del mundo industrial:

Perímetro antes que potencia. Un agente no necesita acceso a todo. Necesita acceso exactamente a lo que su trabajo requiere, y nada más. En una fábrica no le das a un robot llave de todas las máquinas. Le das la de la suya. Con tu vault, igual. Y el perímetro se cablea explícitamente en cada sitio: nada se hereda solo. Si algo “debería estar protegido” y no lo declaraste, no lo está.

Un trabajo, un agente. El agente que lo hace todo es el que falla en todo a la vez. Prefiero varios agentes pequeños, cada uno con una función que entiendo entera, antes que uno grande que es una caja negra. Cuando algo peta, sé cuál mirar.

Deja que falle en pequeño primero. Antes de soltarlo sobre lo importante, lo pones a trabajar sobre una copia, sobre datos que no duelen. Que se rompa ahí. Que se rompa barato.

Que hable mientras trabaja, no solo al terminar. Un agente que solo escribe cuando ha acabado es indistinguible de un agente colgado. En mi sistema, cada uno deja una línea nada más aceptar el encargo diciendo qué va a hacer. Parece burocracia hasta el día que te evita matar un proceso que iba bien.

Todo lo que se degrada, se declara. Si el agente no encuentra una herramienta y tira por la vía lenta, lo escribe antes de hacerlo. Un fallo ruidoso te cuesta un minuto de lectura. El silencioso de septiembre me costó dos días.

El humano firma al final. Un borrador de artículo lo escribe el agente; publicarlo lo decido yo. Un agente que actúa solo sobre lo que importa, sin nadie que firme, no es autonomía: es una apuesta.

Y cada avería termina en una comprobación automática. Si un fallo real solo deja un párrafo de explicación, vuelve. Si deja un test, no vuelve. Las dos averías que te he contado tienen hoy su prueba correspondiente, y por eso puedo dejar de pensar en ellas.

Nada de esto es más rápido. Es más lento y más seguro. Más largoplacista. Pero es la diferencia entre una anécdota que enseñas en un vídeo y una herramienta con la que trabajas todos los días.

“Ya, Marcos, pero esto es sobreingeniería para un vault personal”

Lo es, si tu agente se ejecuta cuando tú le das al botón y tú estás delante mirando. Entonces el vigilante eres tú y no necesitas nada más.

Deja de estar delante y ya no lo es. Un solo agente, un solo cron, una sola carpeta que le importe: eso ya es producción. La escala cambia el tamaño del desastre, no su naturaleza.

“Yo no tengo ocho agentes ni un Mac Mini encendido, esto no me aplica.”

Mis dos averías no fueron de escala. Una fue una sesión que caducó a los treinta días. La otra, una carpeta renombrada. Las dos te pueden pasar con un único agente y un único script, y de hecho es peor: con uno solo no tienes con qué comparar, así que tardas más en notarlo.

“Los modelos mejorarán y todo esto sobrará.”

Ninguno de los tres fallos que he contado fue culpa del modelo. Crédito agotado, credencial caducada, carpeta movida. Un modelo más listo no te renueva el token ni adivina dónde has puesto la carpeta. Esa parte no la arregla la IA: la arreglas tú, o no se arregla.

Los errores que más caros salen

Darle todos los permisos “de momento”. El “de momento” dura hasta que se te olvida. Y el día que se te olvida coincide, por ley natural, con el día que el agente interpreta mal una instrucción.

Dejar que las claves pasen por el modelo. Una credencial que entra en el contexto de un LLM ha salido de tu control: viaja, se registra, se queda en sitios que no controlas. En mi sistema las claves las maneja solo código determinista, y hay un agente jubilado que da fe de ello: existió exactamente un envío antes de que decidiera que ese trabajo no era para un LLM.

Poner un respaldo sin ponerle una alarma. Ya sabes por qué. Un respaldo silencioso no es resiliencia: es una avería con retraso.

Medir por tarjetas cerradas. El tablero verde fue justo lo que me tranquilizó mientras el sistema iba a medio gas. Si tu única métrica es “lo hecho”, no tienes métrica: tienes un espejo.

Construir el agente que lo hace todo. Es cómodo al principio y una tortura al primer fallo, porque no hay nada que aislar. La ingeniería de mantener algo encendido consiste casi entera en poder responder rápido a “¿cuál de todos?”.

Y el más caro de todos: preguntarle al agente qué tal ha ido. Hubo un obrero que, ante un problema, terminó su turno preguntando “¿deseas que la bloquee?”, a nadie, porque no había nadie. Se quedó ahí, esperando educadamente una respuesta que no iba a llegar, hasta que el rescate se lo llevó por delante. Un agente que trabaja solo no puede tener dudas: tiene que tener políticas.

El efecto compuesto también va para los agentes

Un agente que te ahorra veinte minutos hoy es una curiosidad. Un agente que lleva funcionando seis meses sin que tengas que vigilarlo es otra categoría entera. Ahí está el efecto compuesto: no en el destello de la demo, sino en el sistema que sigue de pie mes tras mes, sumando sin que lo mires.

Aunque hay un matiz que aprendí en septiembre y que no estaba en mis cuentas: el efecto compuesto también corre hacia el otro lado. Dos días de sistema degradado no son dos días perdidos. Son dos días de decisiones tomadas sobre un tablero que mentía.

La pregunta buena, entonces, no es “¿qué cosa impresionante puede hacer este agente?”.

Es esta: ¿qué se rompe cuando lo dejo solo una semana?

Y si te cuesta responderla, hay un ejercicio que cuesta diez minutos y vale por diez artículos: coge el último trabajo que hizo tu agente, el que salió bien, y busca la prueba de que salió bien por el camino que tú crees. No el resultado. El camino.

Casi siempre está. El día que no esté, entenderás de golpe todo lo que he escrito aquí arriba.

Si sabes responderla, ya no tienes una demo. Tienes un sistema.

Y esa, y no otra, es la conversación que merece la pena tener.