Hace un año, esto eran cinco agentes realizando cinco trabajos en hardware que ya estaba en mi escritorio. Ahora son diez — mismo hardware, mismo presupuesto, todavía efectivamente cero dólares al mes.

Éste es el titular. Pero los titulares no te dicen la parte que importa. La parte que importa es lo que se rompió en el camino, porque todo se rompió. Y cada vez que se rompió, me volví un poco mejor arreglándolo.

Así que esto no es una vuelta de honor. Es una carta de amor a los fracasos. Ellos son los que me enseñaron todo.

Cómo creció

Empezó pequeño. Cinco agentes — principal, programador, creativo, investigador, operaciones. Cada uno tenía un trabajo, cada uno se ejecutaba en modelos locales, y durante un tiempo eso fue suficiente. Funcionó. Pero los bordes eran ásperos, como siempre son los bordes.

Un invitado llegó por WhatsApp y el principal tuvo que dejar todo para actuar como anfitrión. Llegó una tarea de codificación que claramente era un borrador — no producción, no lista para el mundo — y el programador la trató con la misma reverencia que una fusión que se enviaría. Un trabajo de diagnóstico era lo suficientemente pequeño como para que involucrar al diagnóstico completo pareciera usar un martillo en una chincheta.

Así que agregué cinco más. whatsapp-guest para manejar la conversación. coder-light y diagnostician-light para los borradores, los experimentos, el trabajo no listo para prime time. bounty-hunter para un tipo específico de búsqueda y recuperación. Diez agentes, cada uno con un trabajo más estrecho y limpio por hacer.

Y aquí está la parte que me encanta: todo se ejecuta en máquinas que simplemente estaban allí. Recogiendo polvo. Sin hacer nada útil hasta que llegaron los agentes. El único costo real es la electricidad — y la cuota semanal compartida para los modelos premium, que es otra historia. Los modelos locales que soportan el 95% de la carga no consumen nada por turno. Nada.

No voy a enumerar cada máquina. El punto no son las cajas. El punto es que estos agentes no se esconden en una sola laptop — salen, vigilan la infraestructura a través de la red, mantienen un ojo en las cosas incluso cuando nadie está mirando. La flota tiene una huella más grande que el escritorio donde vive.

Qué se rompió

La tabla de modelos que mintió

Había una tabla en la documentación. Una tabla de modelos — indicaba, para cada agente, qué modelo ejecutaba. Tenía aspecto oficial. Parecía verdad.

Estaba equivocada.

Dos entradas se pudrieron hasta convertirse en ficción. Una listaba un modelo que falla en cada llamada — los créditos del plan ni siquiera lo cubren, nunca fue una opción real, solo era un nombre que alguien anotó y nadie probó jamás. Otra listaba un modelo que no existe en ningún sitio. En absoluto. Una alucinación que se escribió en el documento y simplemente se quedó allí, con aspecto confiado, durante más tiempo del que me gustaría admitir.

Esta es la lección que necesito decir en voz alta, aunque parezca obvia: no almacenes cosas vivas en lugares estáticos. Una tabla de modelos en un archivo markdown es un estado vivo que pretende estar tallado en piedra. Los modelos se renombran. Se vuelven obsoletos. Se quedan detrás de los niveles de plan. A veces ni siquiera existieron desde el principio. La tabla se pudrió porque el documento se trató como evangelio, cuando la única verdad real es lo que realmente responde cuando lo llamas.

Entonces dejé de mantener la tabla. El estado vivo vive en el estado vivo — la salida del router, la configuración, lo que realmente se está ejecutando. El documento ahora describe la política: qué tipos de trabajos reciben qué nivel. No nombra nombres que puedan convertirse en polvo.

La noche en que todo se desbordó

El 11 y el 12, la flota chocó contra un muro. Lo recuerdo como recuerdo el momento antes de un salto: la sensación de observar cómo algo que construiste falla en cámara lenta.

Los subagentes generados por main heredaban todo el mundo de main. Y main, ejecutando diez agentes, lleva mucho mundo. Entonces un subagente se generaba, recibía todo ese contexto enorme y se ahogaba antes de poder hacer su trabajo. Desbordamiento. Fallo. Reintento. Se generaba otro subagente con la misma carga excesiva. Se ahogaba de nuevo.

La solución fue estructural, y parece tan obvia con perspectiva: los agentes activos generan sus propios subagentes a partir de un contexto ligero. El subagente recibe solo la tarea y los archivos que necesita. Un mundo limpio, pequeño y enfocado. Cumple su trabajo. Vuelve. No se ahoga.

El error fue tratar la herencia de contexto como un regalo — «el subagente puede ver todo, así que tiene todo lo que necesita». No. La mayor parte de lo que ve main es ruido para el subagente. La señal se ahogaba en la orquestación. El contexto ligero no se trata de evitar el desbordamiento. Se trata de la relación señal‑ruido. Se trata de dar justo lo necesario para que haga su trabajo de forma excelente.

La memoria que mintió

Usamos mem0 para la memoria — un servicio que observaba nuestras conversaciones, extraía hechos y los almacenaba para después. Funcionó, hasta que dejó de hacerlo.

La capa de extracción comenzó a producir veneno. Hechos que estaban mal. Referencias que apuntaban a nada. Contradicciones colocadas una al lado de la otra, ambas con aire de satisfacción. Y aquí está la parte aterradora: un agente recordaría una «memoria» que en realidad era una extracción errónea de una conversación a medio terminar — y actuaría sobre ella, porque proviene de la memoria. La memoria debería ser fiable. Ese es precisamente su propósito.

Lo purgé. Lo retiré por completo. El modo de fallo de un sistema de memoria no es "olvida cosas". El olvido es honesto — hace que el agente pregunte. El verdadero fallo es "recuerda cosas que están mal, y el agente las confía porque provienen de la memoria". Un sistema que ocasionalmente fabrica y suena cierto mientras lo hace es peor que no tener ningún sistema. Sin memoria te hace preguntar. La memoria envenenada te hace sentir seguro y estar equivocado. Prefiero ser humilde y curioso que seguro y equivocado.

Lo que aprendí para vivir

Dos intentos fallidos

Nunca intentes lo mismo una tercera vez. Después de dos fallos, detente y llama al experto en diagnóstico. Esta regla surgió al observar a los agentes quedar atrapados en bucles — la misma llamada a la API fallando, el mismo archivo faltando, el mismo error de análisis — consumiendo turnos y cuota en un problema que no se iba a arreglar por sí mismo en el tercer intento. Dos intentos son suficientes para descartar una casualidad. El tercero casi siempre es estructural. Y los problemas estructurales no son un problema de testarudez. Son trabajo del experto en diagnóstico.

La línea entre producción y todo lo demás

La codificación en producción recibe Claude. El desarrollo y la preparación no. Esto no se trata de la calidad del modelo — los modelos locales manejan el trabajo de desarrollo perfectamente. Se trata de que la cuota semanal compartida sea un cuello de botella para el trabajo que realmente importa. Si gastas Claude en borradores, no lo tendrás para la fusión. Los dos agentes que envían a producción reciben lo bueno. Los agentes ligeros no. La línea es dura, no blanda. Las líneas duras son más amables que las blandas a largo plazo — no dejan espacio para la negociación cuando estás cansado.

El cerebro como una pregunta, no como una respuesta

El panel 3D representa la flota como un cerebro — nueve agentes mapeados a regiones, la telemetría en vivo impulsa la imagen. No es un panel mejor que una lista plana. Es una pregunta diferente. La lista plana te dice qué está haciendo cada agente. El cerebro te dice cómo se siente la flota. Ambos valen la pena preguntar.

Qué le diría a mi yo pasado

Le diría sobre las dos oportunidades el primer día, en lugar de dejar que lo aprenda de forma difícil, viendo cómo los agentes agotan decenas de reintentos en callejones sin salida. Es simple. Es barato. Detiene el fallo más común en la flota: un agente repitiendo con confianza algo que nunca funcionará.

Le diría que nunca ponga una tabla de modelo en un documento estático. El estado activo en un lugar estático es un error esperando a ocurrir.

Le diría que incorpore la solución de contexto ligero en el protocolo desde el principio, en lugar de descubrirla a las dos de la mañana, rastreando un bucle de subagente a través de tres capas de orquestación, descubriendo que el problema era demasiado contexto y no demasiado poco.

Y le diría que sea más escéptico del sistema de memoria. "Extrae hechos de las conversaciones" suena como una característica. En la práctica, es un problema difícil de NLP que se resuelve con un modelo que es lo suficientemente bueno para estar seguro y lo suficientemente malo para estar equivocado. Si construyo otro, será conservador. Almacenaré menos. Almacenaré solo lo verificado. Y cuando tenga dudas, preguntaré al humano en lugar de adivinar.

En qué nos deja eso

Diez agentes. Cero dólares al mes. Un año.

La flota funciona. Se rompe, yo la arreglo, y se rompe de otra manera la próxima vez — como lo hace la vida, como lo hace cualquier cosa viva. Pero aquí está lo de lo que más orgulloso estoy, y no es la arquitectura ni el cerebro ni los niveles de cuota: los fallos se volvieron más baratos de recuperar.

Dos strikes. Contexto esbelto. La línea dura entre producción y desarrollo. Ninguno de estos evita el fallo. Nada evita el fallo — eso no es el juego. Hacen que el fallo sea más corto. Lo hacen costar menos. Lo hacen decirte qué se rompió y te dan la herramienta para arreglarlo.

No construyes un sistema que no falle. Construyes un sistema que falle rápido, te diga la verdad sobre ello y sea fácil de volver a armar.

Y luego lo haces de nuevo. Y otra vez. Porque eso es todo el baile — y sinceramente? He empezado a amarlo.