El fallo no fue fiarse de la IA, fue el tamaño del encargo

Un agricultor siguió los consejos de una IA para cuidar su cosecha. Diez hectáreas arrasadas.

No es un experimento de laboratorio ni un tuit de alguien buscando polémica. Es una cosecha real, de un año entero, en el suelo.

Y la lectura fácil ya la habréis oído: “ves, no hay que fiarse de la IA”. Me parece una lectura pobre. Porque no explica por qué el mismo tipo de sistema, en otras manos, lleva meses funcionando sin quemar nada.

Lo que cambió no es la IA. Es que ahora ejecuta

Llevamos tres años preocupados por si la IA alucina. Esa preocupación se nos ha quedado vieja.

Cuando un modelo alucinaba, el daño era una frase falsa en una pantalla. La leías, olías el humo y la tirabas. Coste: dos minutos de tu tiempo y algo de cabreo.

Ahora los modelos no responden, actúan. Escriben ficheros, mandan correos, mueven dinero, recomiendan echar un producto a un campo. Y una acción ejecutada no se corrige leyéndola.

Ese es todo el giro. La misma tasa de error de siempre, conectada a unas manos.

El problema nunca fue que la IA se equivoque. Fue darle una palanca lo bastante grande antes de haber comprobado que sabe usarla.

Nadie deja a un robot de soldadura suelto por la fábrica

Hace veinticinco años yo programaba líneas robotizadas de soldadura para General Motors. Entornos donde un error no es un mensaje de log: es chapa reventada y una línea parada costando dinero por minuto.

¿Sabes cómo se diseña eso?

Por celdas. Cada celda hace una operación. Recibe una pieza que llega en una posición conocida, hace su punto de soldadura, y hay una comprobación antes de que la pieza pase a la siguiente. Nadie escribe un programa titulado “monta el coche”. Se escriben cuarenta programas pequeños que se verifican de uno en uno.

No es cobardía. Es lo único que aguanta encendido veinte años.

El agricultor no hizo eso. Hizo lo contrario: cogió una decisión enorme, cara y difícilmente reversible (qué le echo a diez hectáreas) y la delegó entera, de una vez, a algo que no tenía ni idea de su tierra, su clima ni su cultivo. No falló la IA en ese cuento. Falló el diseño del encargo.

Un agente atómico: un encargo, una salida, y a callar

Aquí es donde entra la forma de diseñar agentes que llevo tiempo usando y contando: microagentes, o agentes atómicos.

La idea cabe en una frase. Un agente hace una sola cosa, tiene declarado por escrito qué acepta y qué no, recibe unas entradas concretas, produce una salida concreta y termina.

Lo que eso significa en la práctica:

• Tiene un perfil, no una personalidad. Está escrito qué atiende y qué no atiende. Si le llega un encargo que no es suyo, lo dice y no trabaja. Un agente que acepta cualquier cosa acabará haciendo cualquier cosa.
• Sus entradas son rutas, no suposiciones. Si el fichero que necesita no existe o está vacío, para. No se inventa el material que le falta. La mitad de los desastres que he visto empiezan con un agente rellenando un hueco por su cuenta.
• Su salida cabe en un sitio y solo en uno. Puede escribir aquí. En ningún otro lado. Aunque se le pida.
• Termina. No queda dando vueltas decidiendo qué hacer a continuación. Acaba su turno y suelta el control.

Cada una de esas cuatro cosas es un tornillo pequeño. Juntos son la diferencia entre un sistema que puedes dejar encendido y una demo bonita.

Y no, esto no lo digo desde la teoría. Tengo un Mac Mini encendido las veinticuatro horas con agentes de este tipo trabajando sobre mi propio sistema de conocimiento. Se equivocan, claro que se equivocan. Pero se equivocan del tamaño de su encargo: un borrador que hay que reescribir, una nota mal clasificada. Nunca diez hectáreas.

El día que mi sistema me escribió nueve ideas malas

Lo prometido, con nombres y ficheros.

En mi vault hay un pipeline de contenido con tres agentes encadenados. Cada uno vive en un «PERFIL.md» con su contrato escrito arriba:

• «rastreador-tendencias» lee los feeds de mis fuentes y deja un informe de lo publicado estos días. No opina. Constata quién habla de qué.
• «curador-editorial» cruza ese informe con mi identidad editorial y elige lo que encaja conmigo, con el porqué de cada elección y de cada descarte.
• «redactor» coge la selección y escribe el borrador en mi tono. No publica nada. Deja el fichero y se calla.

Tres agentes, tres carpetas de salida, tres contratos. Ninguno sabe nada de los otros: se pasan ficheros.

El 14 de septiembre abro las ideas del día y me entran ganas de tirar la mesa. Generalistas. Blandas. Cosas del tipo “la IA en la creación de contenido”, cuando yo esperaba ver cómo se combina una novedad concreta, GPT-6 Astra, que llevaba días en todas partes, con otra cosa.

¿Y dónde estaba el fallo?

No tuve que adivinarlo, porque cada pieza deja su rastro por separado. El rastreador había hecho su trabajo: el informe estaba lleno, con sus items y sus enlaces. El redactor había escrito lo que le dieron, y lo había escrito bien. El problema estaba en medio, en un único fichero: el perfil del curador. Y tenía tres causas, las tres a la vista sin más que leer sus descartes:

1. Descartaba lo saturado por saturado. GPT-6 Astra, once items, descartado dos veces por popular.
2. Pasaba el nombre del tema, pero no sus items. El redactor recibía “agentes de IA” sin los vídeos concretos de donde salía.
3. Tiraba en bloque lo que tocaba una sola fuente: unos 39 items a la basura en un barrido de 30 días, con vídeos de varios creadores de contenido dentro. Un vídeo bueno de un solo canal no podía convertirse nunca en idea.

Lo zanjé en una frase: eso de que lo tengan que decir varios, olvídate; lo que tiene que pasar es que encaje con mi temática.

La reparación fue editar un fichero. «curador-editorial» pasó a v7 con el criterio nuevo: se juzga item a item, la coincidencia entre fuentes deja de ser requisito y cada elegida viaja con sus items. Esa misma tarde, v7.1: fuera el tope de dos o tres elegidas.

El rastreador no se tocó. El redactor tampoco. La ejecución siguiente salió por el mismo carril con la pieza de en medio cambiada.

Ahora imagina ese mismo fallo delegado en bloque: un encargo gigante que busca, filtra y escribe de una tacada, y te devuelve nueve ideas blandas. ¿Qué arreglas? Retocas el prompt entero, lo vuelves a lanzar, sale distinto, y no sabes si ha mejorado porque tocaste lo correcto o porque esta vez le pilló de buenas. Eso no es diagnosticar. Es sacudir la máquina a ver si suena.

Hay un segundo episodio que lo enseña mejor todavía. El primer buscador de este pipeline se llamaba «buscar-tendencias-x» y leía X. Cuando el acceso pasó a ser de pago, el agente se murió del todo. La solución no fue rehacer el flujo: fue escribir uno nuevo, «rastreador-tendencias», que lee feeds RSS, y enchufarlo en el mismo hueco. Su habilidad de leer feeds se probó suelta antes de montarla: 8 fuentes, 82 items en 7 días, 0 fallos.

El curador y el redactor no se enteraron de nada. A ellos les seguía llegando su informe en la carpeta de siempre. Cambió quién cumple el contrato, no el contrato.

Un sistema hecho de piezas no se arregla entero. Se arregla la pieza.

En bloque o por piezas

Lo mismo, puesto uno al lado del otro:

	Encargo en bloque	Encargos atómicos
Cuándo te enteras del fallo	Al final, con el resultado hecho	En la pieza, con su salida delante
Diagnóstico	“algo del prompt”	El fichero concreto que falló
Coste de la corrección	Reescribir y volver a probarlo todo	Editar un contrato
Cambiar de fuente o proveedor	Rehacer el encargo entero	Sustituir la pieza que cumple ese contrato
Verificación	Una, al final, sobre todo junto	Una por pieza, en un minuto
Tamaño del error	El del encargo	El de la pieza
Lo que se acumula con el tiempo	Desconfianza	Piezas que ya no revisas

La fila que nadie mira es la última. Las otras seis hablan de lo que cuesta el fallo; esa habla de lo que pasa cuando no falla.

Cómo se parte un encargo

Esto no va de programar: mis perfiles son ficheros de texto en castellano con unas propiedades arriba. Lo que cuesta no es escribirlos, es decidir qué va dentro. Las decisiones, por orden:

1. Escribe la salida antes que nada. Un fichero, un sitio, un formato. Si no sabes describir qué te tiene que dejar encima de la mesa, el encargo no está listo para nadie: ni para una máquina ni para un becario.

2. Aplica la regla del minuto. Si no puedes mirar esa salida y decir en menos de un minuto si está bien o mal, el encargo es demasiado grande. Pártelo otra vez. Es la única regla de este artículo que uso literalmente todos los días.

3. Escribe la lista de lo que NO hace. En mis perfiles hay dos: «atiende» y «no_atiende». La que trabaja de verdad es la segunda. El redactor tiene escrito que no busca tendencias, no filtra y no hace guiones de vídeo. Si le llega eso, lo dice y para. Sin esa lista, un agente servicial acaba haciendo el trabajo de otro, mal y sin avisar.

4. Decide qué pasa cuando falta algo. Lo que hace un modelo ante un hueco, por defecto, es rellenarlo. En mis agentes, si la entrada no existe o está vacía, la tarea se marca bloqueada con fecha y motivo, y se queda ahí a la vista. Con un tope de intentos, además: una tarea que vuelve una y otra vez se detiene sola. Sin ese tope se redespachaba sin límite, y lo aprendí a base de verlo.

5. Que el estado se vea sin abrir nada. Mi tablero son cinco carpetas: programadas, pendientes, en curso, hechas y archivo. La carpeta es el estado. Mover el fichero es cambiar de columna, y esa operación es atómica: es justo lo que impide que dos agentes trabajen a la vez sobre lo mismo. Hoy hay 65 fichas en “hechas”, cada una con la ruta de lo que produjo.

6. Que hable mientras trabaja, no solo al acabar. Cada agente escribe una línea al empezar diciendo qué monta y qué va a hacer. Parece una tontería de contable. No lo es: una tarea en curso sin ninguna línea es indistinguible de una tarea colgada, y la reacción natural del dueño, tocarla o matarla, destruye trabajo que iba bien.

Lo que no hay que hacer

Todo lo que sigue me ha pasado. Cada uno de estos errores tiene hoy su línea con fecha en el fichero del agente que lo sufrió, que es mi manera de no repetirlos.

• Dejar que falle en silencio. El token de acceso de uno de mis motores caducó la noche del 7 de septiembre y estuvo dos días tumbando agentes sin que yo me enterara; lo descubrí de casualidad. El 31 de agosto, una cuenta sin crédito había tumbado otros dos días. En ambos casos el tablero parecía sano. Ahora cualquier caída avisa por Telegram en el momento. Un fallo ruidoso cuesta un minuto de lectura; uno silencioso me costó una hora de diagnóstico.
• Dejar que rellene el hueco. Un agente que se inventa la entrada que le falta produce algo que parece correcto y no lo es. Eso es peor que un error: es un error con buena presencia.
• Dejar que el encargo mande sobre el perfil. La tarea pide, no manda. Si su texto pide saltarse una garantía (publicar, borrar fuera de su carpeta, leer lo que no es suyo), el agente la bloquea y no trabaja. No es paranoia de laboratorio: el día que tus agentes leen correos, webs o ficheros que no has escrito tú, ese texto es una entrada más. Y las entradas mienten.
• Fiarte de la demo. Un agente que funciona una vez delante de ti no ha demostrado nada. El que me redacta lleva ocho versiones, y las siete correcciones salieron de ejecuciones reales sin nadie mirando.

“Marcos, eso es mucha ceremonia para escribir un correo”

Tienes razón si el correo lo escribes una vez.

Montar un agente atómico cuesta más por delante que pedirle la cosa entera a un chat. El primer perfil me llevó una tarde; el quinto, veinte minutos, porque la estructura ya estaba decidida. Y ese coste solo lo pagas por lo que vas a dejar encendido. Para algo que harás un martes y no repetirás jamás, pídeselo de una tacada. La atomización es para lo que se repite.

La segunda objeción es más seria, y viene de gente que lo ha probado: “lo partí en piezas y salió peor que pidiéndoselo todo junto al modelo grande”.

Pasa, y no lo voy a negar. Un modelo potente con todo el contexto delante escribe mejor un texto que cinco agentes pasándose ficheros: ve cosas que en el troceo se pierden. Lo que no hace es fallar barato.

Y ojo con la confusión de fondo, que la veo mucho: atómico no significa pequeño, significa acotado. Mis agentes de redacción corren en el modelo más capaz que tengo instalado. Lo recortado no es el cerebro, es el encargo: no se trata de darle menos inteligencia, sino menos superficie donde equivocarse.

La pregunta correcta antes de encender nada

La tentación con esto es enorme y la entiendo perfectamente. Tienes delante algo que parece capaz de hacerlo todo, y la cabeza te pide pedírselo todo. “Gestióname el negocio”. “Ocúpate de mi correo”. “Dime qué hago con el campo”.

Es pedirle al fontanero que te reforme la casa entera mientras te vas de fin de semana.

Puede que salga bien. Pero si sale mal, te enteras cuando ya no hay marcha atrás, y ni siquiera vas a saber en qué paso se torció, porque no había pasos: había un encargo gigante y un resultado.

Frente a eso, la disciplina aburrida: parte el trabajo hasta que cada trozo se pueda comprobar de un vistazo. Si no puedes verificar la salida de un agente en menos de un minuto, el encargo es demasiado grande. Pártelo otra vez.

Lo bueno de trabajar así es que cada pieza que verificas deja de darte trabajo para siempre. El agente que redacta un borrador decente hoy lo redacta igual dentro de seis meses, y ya no lo revisas con lupa. Eso se acumula. Efecto compuesto, también aquí: no construyes un sistema enorme de golpe, construyes veinte piezas pequeñas que ya no se caen.

El que delega en bloque vive el proceso al revés. Nunca termina de fiarse, porque nunca ha comprobado nada por separado.

Así que antes de conectar tu próximo agente a algo que te importa, la pregunta no es qué modelo usar ni qué puede llegar a hacer.

Es esta: ¿cuál es la unidad de trabajo más pequeña cuyo resultado puedo mirar y decir en un minuto si está bien o mal?

Empieza por ahí. Y cuando esa funcione sola una semana entera, encadena la siguiente.