Coordinar agentes de IA sin depender de la nube

Por qué un solo agente no alcanza

Pedirle a un único agente de IA que en la misma conversación investigue un tema, lo estructure, redacte el texto final y luego revise su propio trabajo suele producir resultados menos precisos que dividir esas cuatro tareas. La razón es simple: cada tarea necesita un contexto distinto, y mezclarlas todas en un mismo hilo hace que el agente arrastre información de una etapa a la siguiente cuando no debería. Anthropic señala este mismo problema como motivo para separar su propio trabajo interno en subagentes especializados, cada uno enfocado en una sola función. La misma lógica está detrás de los llamados subagentes de Claude Code (una herramienta de programación asistida por IA de Anthropic): en vez de un solo agente generalista, cada subagente recibe una instrucción acotada y una ventana de contexto propia. Si alguna vez una IA que "hace de todo" falló en una tarea con varios pasos, este es el motivo antes de pasar a la solución: repartir el trabajo en roles separados.

Las cuatro piezas de un harness: orquestador, roles, turnos y estado

Un harness de ejecución local es, en esencia, un ensamblaje de cuatro piezas simples. Pensarlo como un director de orquesta ayuda: el director no toca ningún instrumento, solo indica quién entra y en qué momento.

La primera pieza es el orquestador: un programa que decide qué rol actúa a continuación, pero no resuelve la tarea de fondo por sí mismo. La segunda son los roles, definidos como instrucciones declarativas escritas en Markdown (un formato de texto plano con reglas simples de formato) — cada rol fija su objetivo, qué información recibe y en qué forma debe entregar su resultado, sin que haga falta escribir código para definirlo. La tercera pieza son los turnos aislados: cada rol arranca sin memoria de la conversación completa, solo con su propia instrucción y el trabajo ya validado de los roles anteriores. La cuarta es el estado persistido: un archivo en formato JSON (un formato de texto para guardar datos estructurados) que registra en qué fase y turno se encuentra cada trabajo, de modo que el proceso pueda retomarse donde quedó sin repetir lo ya hecho.

El ejemplo más concreto y verificable de este patrón es el propio pipeline editorial que produce este artículo: un script en Python (el lenguaje de programación con el que está escrito el orquestador) decide qué rol sigue, un conjunto de archivos Markdown define cada rol —scout, arquitecto, redactor, editor— y una carpeta con archivos JSON guarda en qué fase y turno está cada trabajo en curso.

El patrón tampoco es exclusivo de un proveedor: aparece también en frameworks como CrewAI, donde cada agente se define por un rol, un objetivo y un trasfondo, y varios agentes se agrupan en "crews" que se ejecutan de forma secuencial o jerárquica. "Harness", en este sentido, no nombra una tecnología exótica: nombra este ensamblaje de piezas simples.

¿Coordinar varios agentes mejora el resultado?

Hay evidencia concreta de que sí, con matices. El sistema de investigación multiagente de Anthropic —un orquestador que reparte el trabajo entre varios subagentes que corren en paralelo— superó a un agente único por 90,2% en su evaluación interna. Vale presentar esta cifra con su origen a la vista: proviene de un post de ingeniería publicado por la propia Anthropic, no de una medición independiente, así que conviene tomarla como el dato más concreto disponible y no como una verdad cerrada.

Ese mismo resultado vino acompañado de un costo: un consumo de tokens (las unidades en las que un modelo de lenguaje procesa y factura el texto) unas 15 veces mayor que el de una interacción simple, frente a un múltiplo de 4 en el caso de un agente individual. Ese costo no depende de si el orquestador corre en la nube o en una computadora local: depende de cuántas llamadas al modelo dispara el patrón elegido. Coordinar agentes puede mejorar el resultado, pero no es gratuito, y ese costo es el mismo sin importar dónde viva el orquestador.

El guardrail: quién frena un error antes de que se propague

Un guardrail, en este contexto, es una validación que ocurre entre turnos y que impide que el error de un rol pase sin control al siguiente: por ejemplo, que un rol de revisión compruebe que el resultado del rol anterior cumple lo que se le pidió antes de dejarlo avanzar.

Este concepto no tiene un nombre único estandarizado en la industria: aparece como nodos de validación en frameworks como LangGraph, como "hooks" (puntos de enganche que ejecutan una verificación automática) en Claude Code, y como un rol de revisión explícito en pipelines editoriales como este.

Acá aparece una diferencia real frente a un entorno cloud gestionado por un tercero: un harness que corre en la propia máquina del usuario no tiene, por defecto, el aislamiento de un entorno de pruebas ("sandbox") administrado externamente. Si un guardrail está mal definido, el radio de impacto de un error es la máquina local y sus credenciales, no un contenedor descartable que se puede destruir sin consecuencias. Definir bien los guardrails es, entonces, responsabilidad de quien arma el harness, no algo que una plataforma resuelva de forma automática: es un tradeoff de control, no un defecto menor de la ejecución local.

Lo que la ejecución local no resuelve

Comparar ejecución local y agentes autónomos en la nube no es cuestión de elegir un bando ganador, sino de sopesar tradeoffs concretos.

La ejecución local acumula latencia: turnos que corren uno después del otro suman tiempo total, frente a arquitecturas que paralelizan varios subagentes a la vez, como el sistema de investigación mencionado antes. También es difícil de depurar: un cambio pequeño en una instrucción puede producir comportamientos muy distintos entre turnos, y un archivo de estado más registros de actividad dan una trazabilidad básica —en qué turno falló algo— pero no explican por qué el modelo tomó una decisión puntual dentro de ese turno. Además, un proceso único está acotado por el cómputo de la máquina donde corre: no escala automáticamente a muchos turnos en paralelo, aunque el estado persistido sí permite retomar el trabajo tras una caída en lugar de reiniciarlo todo desde cero.

Lo que sí se evita es depender de un proveedor cloud adicional para gestionar el estado y los entregables intermedios del pipeline —aunque el contenido de cada turno igual viaja hacia la API (la interfaz por la que un programa envía datos a un modelo externo) si el harness usa un modelo alojado fuera de la propia máquina. Local o en la nube no es una elección de mejor contra peor: es una elección entre control y simplicidad de un lado, y paralelismo y elasticidad de cómputo del otro, según lo que el caso concreto necesite.

Antes de sumar más agentes a un flujo de trabajo

Antes de sumar más agentes de IA a un flujo de trabajo propio, o de confiar en uno de un proveedor externo, conviene poder responder tres preguntas sobre cualquier sistema que se use: ¿quién orquesta?, ¿cada rol tiene instrucciones propias y visibles?, ¿el estado del progreso queda guardado en algún lugar auditable si algo falla?

Si las tres respuestas son claras, el sistema es auditable, sea local o en la nube, simple o sofisticado. Si no lo son, ningún despliegue de infraestructura adicional lo compensa. La pregunta que vale la pena hacerse el lunes no es "local o nube", sino si el sistema que ya se usa —o el que se está por adoptar— puede responder esas tres preguntas hoy mismo.