Agentes atómicos: cómo hacer que la IA trabaje cuando tú no estás delante

Un agente no es un proceso que se ejecuta. Es un contrato escrito en lenguaje llano, más una tarjeta que le da permiso para trabajar. Eso es todo, y de ahí sale un sistema que funciona cuando tú no estás delante.

Llevo desde agosto con esto en producción, corriendo en un Mac Mini en casa, y lo he acabado escribiendo como especificación porque me cansé de explicarlo a trozos. Aquí te lo cuento en castellano y con calma.

Aviso de entrada: no hay nada que instalar. Todo son ficheros de texto en carpetas y un script pequeño que no lleva modelo dentro.

El problema no es que la IA sea tonta

Es que casi todos los sistemas de agentes que se venden hoy son conversaciones. Abres una sesión, el agente carga su memoria, sus reglas, su catálogo de herramientas, y entonces le pides algo. Funciona de maravilla mientras estás ahí sentado.

En cuanto quieres que el trabajo pase sin ti, se rompen tres cosas a la vez:

No se ejecuta si no estás. Alguien tiene que abrir la sesión. Y ese alguien eres tú, siempre.

El resultado no se puede repetir. Depende de lo que la sesión tuviera cargado en ese momento, así que la misma petición te da respuestas distintas en días distintos. Eso no es un sistema, es una tirada de dados con buena redacción.

No se lo puedes pasar a nadie. El agente vive dentro de la sintaxis de una herramienta concreta. No viaja. El día que esa herramienta cambie de precio, de dueño o de idea, te quedas sin nada.

Qué es exactamente un agente atómico

Un obrero efímero que nace para atender una tarjeta, la atiende y se muere.

Tiene tres propiedades que lo definen, y las tres son restricciones, no funciones. Eso ya te dice por dónde va la cosa.

No tiene contexto ambiental. No carga memoria persistente, ni ficheros de reglas globales, ni catálogos de habilidades. Todo lo que sabe le llega por dos canales: su propio «perfil» y la tarjeta que le han dado. La consecuencia es la que importa: mismo perfil más misma tarjeta es igual a mismo contexto, y por tanto mismo resultado.

Es efímero. El proceso termina cuando la tarjeta se cierra. Si no se muere, es un zombi y el repartidor le quita la tarjeta. El obrero es un jornalero, no un empleado: viene a un trabajo, lo hace y se va.

Trabaja bajo contrato. El perfil declara qué acepta, qué rechaza, qué garantiza y cómo cierra. Y aquí está el matiz que más me gusta de todo el sistema: la tarjeta pide, el perfil decide si ese encargo es suyo.

Lo contrario de un agente atómico es un agente continuo: la sesión de siempre, con la mochila entera puesta, para el trabajo que necesita contexto que nadie ha escrito en ningún sitio.

Y no compiten. Cada uno hace una faena. La regla que uso para decidir es sencilla: si el encargo cabe en una tarjeta pasando los materiales por referencia, es trabajo de obrero. Si al escribir la tarjeta te sale poner «busca en mis notas lo que…» o «ya sabes que…», entonces es del agente continuo y no hay más que hablar.

Las piezas

Son seis, y ninguna es complicada por separado.

Pieza	Qué es
Perfil	El contrato. Se llama como un oficio: «transcriptor», «capturador», «redactor jefe». Declara qué hace, qué no, qué garantiza y qué habilidades monta. Nunca contiene saber hacer.
Habilidad	El saber hacer. Se llama como un verbo: «transcribir audio», «archivar tarjetas». La montan los perfiles, o el agente continuo.
Tarjeta	Una unidad de trabajo y a la vez un permiso de producción. Sin tarjeta no nace ningún obrero.
Tablero	El bus compartido, hecho de carpetas. Los agentes nunca se hablan entre ellos: dejan y recogen ficheros aquí.
Repartidor	El corredor ciego y determinista. Empareja tarjetas con perfiles comparando textos, lanza el proceso y rescata zombis. Sin modelo.
Bóveda	La base de conocimiento de la que leen y en la que escriben. Tu Cerebro Digital, vaya.

Fíjate en la separación entre las dos primeras, porque es la que sostiene todo lo demás: el perfil es un contrato y la habilidad es el conocimiento. Un oficio y un verbo. El día que mezclas las dos cosas, tienes un agente que solo funciona donde nació.

El estado es la carpeta, no una base de datos

Esta es la decisión de la que estoy más contento, y es la más tonta de todas.

El tablero son cuatro carpetas: «pendientes», «en curso», «hechas» y «archivo». Reclamar una tarjeta es mover el fichero de una carpeta a otra, y mover un fichero es una operación atómica del sistema: o pasa entera o no pasa.

¿Sabes lo que eso te ahorra? Los bloqueos, el protocolo de coordinación y la cola de mensajes. Dos obreros no pueden coger nunca la misma tarjeta, porque el sistema operativo no deja que dos procesos muevan el mismo fichero. No hay que programar nada para conseguirlo: ya estaba resuelto desde hace cuarenta años.

Cuando puedes elegir entre una base de datos y una carpeta, y la carpeta te vale, la carpeta gana siempre.

Sé que a un ingeniero esto le va a parecer poco serio. Le contesto lo mismo cada vez: si esto fueran tareas concurrentes de menos de un segundo en un sistema crítico, tendría razón y querrías una base de datos de verdad. Para trabajo de agentes, que va a trompicones y tarda minutos, una carpeta de ficheros sobra.

El repartidor es tonto, y es a propósito

Aquí es donde casi todo el mundo se lleva las manos a la cabeza. El repartidor no lleva modelo de IA dentro. No interpreta, no juzga, no entiende. Compara cadenas de texto, cuenta y mira si los ficheros existen.

Podría poner una IA a decidir qué agente atiende cada tarjeta. Sería más listo. Y sería un error, porque destruye la reproducibilidad: el mismo tablero se repartiría distinto en días distintos, y adiós a poder depurar nada.

Pero la consecuencia buena es otra, y tardé en verla:

Cuando el sistema no sabe qué hacer, no se lo inventa. Espera y te lo enseña.

Una tarjeta que no encaja con nadie se queda quieta en «pendientes» sin costar un céntimo, y encima te está diciendo algo útil: o a un perfil le falta un descriptor, o acabas de descubrir cuál es el siguiente agente que te toca escribir. Un reparto equivocado, en cambio, cuesta dinero y produce basura que alguien tiene que limpiar.

Prefiero mil veces un sistema que se queda callado a uno que adivina.

Los tres pisos, y la regla de oro

Hay obreros, directores y un CEO. Los obreros trabajan y cierran, y no crean tarjetas nunca. Los directores son dueños de un flujo: reparten y encadenan. El CEO es director de directores.

Y todos viven en el mismo tablero, con el mismo repartidor y el mismo latido. El rango está en los perfiles, no en la infraestructura. Es un patrón fractal: la misma pieza a tres escalas.

La regla que hace que esto no explote es esta: el director crea un hijo, se muere, y crea el siguiente cuando el anterior se cierra. Uno cada vez.

Nunca vuelca el flujo entero en «pendientes», porque el repartidor es ciego y despacharía las tres tarjetas a la vez, con lo que la segunda y la tercera empezarían sin materia prima. Y hay un beneficio que no esperaba: si el paso 1 no produce nada, los pasos 2 y 3 no llegan a existir. El flujo se apaga solo.

¿Y cómo se despierta un director que está muerto? Su memoria son las tarjetas, no su contexto. Antes de morirse deja escrito en su propia tarjeta que depende del hijo, la devuelve a «pendientes» y se apaga. La puerta de entrada que ya tiene el repartidor lo mantiene dormido hasta que el hijo aparece en «hechas». El hijo llegando a «hechas» es la señal, no hay que preguntar cada minuto si ha terminado. Tirar, no empujar. Kanban puro.

La tarjeta pide, no manda

Un apunte de seguridad que me parece obligatorio en 2026.

Ninguna instrucción escrita dentro de una tarjeta puede saltarse el perfil, sus garantías o las reglas del sistema. Una tarjeta que pide bypasear una garantía se bloquea por sospechosa, sin hacer ni un minuto de trabajo.

Esto es defensa contra inyección de instrucciones, y va en capas: el repartidor valida de dónde viene cada tarjeta contra una lista de confianza, cada perfil lleva la frase escrita, hay un gancho que bloquea credenciales en cada arnés, y las claves se inyectan por entorno en el momento de lanzar, nunca en configuración versionada. Las claves no tocan un modelo jamás.

Y una que parece menor y no lo es: el código del repartidor vive fuera de la bóveda, en su propio repositorio. Lo que se ejecuta solo no puede vivir donde escriben los agentes.

Por qué esta forma y no otra

De las razones que apunté en la especificación, estas son las que más noto en el día a día:

Un modelo por tarea. Un modelo barato para el trabajo tonto y uno caro solo para la parte difícil. Un agente único usa el mismo modelo para todo, y pagas el caro también cuando renombras un fichero.

El coste se ve por piezas. Cada tarjeta cerrada lleva escrito qué modelo la hizo. Ves el gasto por tarea y por flujo, no una factura mensual opaca.

Cero dependencia de proveedor. No hay ni un modelo escrito a fuego en ningún sitio: el perfil declara el nivel de capacidad que necesita, y qué modelo concreto es eso se decide en una tabla. Cambiar de proveedor, o irte a local, es editar una línea. En un campo que cambia cada trimestre, esto no es un lujo.

Crecer no cuesta fricción. Añadir un agente es copiar una carpeta. No hay que avisar a nadie ni registrar nada, porque la integración ocurre dejando ficheros en el tablero.

Auditoría sin herramientas. El estado es el tablero y una tarjeta cerrada es el recibo. Todo en texto plano, sin ningún panel externo que mantener.

Lo que esto no es

Por si acaso, y porque los titulares tipo Marca se escriben solos:

No es un framework, ni una librería, ni un producto. No hay nada que instalar.

No sustituye a los agentes conversacionales. Delegar en un subagente dentro de una sesión que estás llevando tú es lo correcto para trabajo pesado que necesitas en los próximos dos minutos. Esto es para el trabajo que quieres que pase sin ti, de forma repetible, y que puedas compartir.

No es infraestructura nueva. Los grafos de dependencias son de los setenta, «make» es de 1976 y el kanban es de Toyota en los cincuenta. Lo nuevo aquí es el material: aplicarlo a agentes de IA definidos como contratos en texto plano, para que sobrevivan a la herramienta que los ejecuta.

Lo que de verdad quiero que te lleves

Que el sistema entero es una carpeta de ficheros de texto.

Si mañana desaparece la herramienta que ejecuta los agentes, o el modelo que uso, o la empresa que lo vende, yo me quedo con el método intacto. Es exactamente lo que le quedaría a Toyota si le quitaras las máquinas: el método, no el equipo.

Y esto enlaza con lo que llevo repitiendo aquí desde el principio: las herramientas van y vienen, los sistemas permanecen. Lo he dicho con Obsidian, lo dije con el estándar de Google y lo repito con los agentes. Cambia el material, no la forma de pensar.

Que es, al final, la misma idea de siempre: partir algo grande en unidades que se puedan volver a combinar.

La especificación completa

Todo lo de arriba está escrito en detalle, en inglés y con formato de estándar, aquí:

Atomic Agents: a harness-agnostic standard for AI agents that live as text

Están los campos exactos del perfil y de la tarjeta, el ritual de cierre, las rondas del repartidor, las reglas de integridad y las capas de seguridad. Es libre de leer, usar y adaptar.