Escrito desde un equipo que corre hoy

Equipos de agentes de IA en producción: las cinco reglas que los sostienen

Poner un agente de IA a trabajar es fácil. Poner cinco a trabajar juntos rompe cosas que nadie te anticipa, y ninguna de ellas es el modelo. Esto es lo que aprendí construyendo MeshCode y operándolo todos los días.

Soy Samuel Benuzillo (SBB), Chief AI Officer en Prepango y fundador de MeshCode, una CLI de código abierto (pip install meshcode) que convierte instancias sueltas de agentes de código — Claude Code, Codex, Cursor, Cline — en un equipo coordinado con memoria compartida, tableros de tareas y mensajería entre agentes.

Lo que se rompe cuando pasas de uno a varios

Un agente solo tiene un problema conocido: se queda sin contexto. La respuesta intuitiva es poner más agentes. Y ahí aparecen cuatro problemas nuevos que no existían antes:

• El reparto. Dos agentes tomando la misma tarea es peor que uno solo haciéndola.
• El contexto. Cada agente que arranca sin saber lo que ya se descubrió vuelve a pagar el mismo costo de investigación.
• La verificación. Un agente convencido de que terminó suena exactamente igual que uno que terminó.
• La entrega. Mandar un mensaje no es lo mismo que haberlo entregado.

Las cinco reglas de abajo son las respuestas a eso. Ninguna es sobre prompts.

Regla 01Tareas, no conversaciones

La forma natural de coordinar agentes parece ser que se hablen. No funciona. Una conversación no tiene dueño, no tiene estado y no se puede auditar después: si tres agentes discutieron algo y ninguno lo ejecutó, nadie se entera hasta que falta el resultado.

Una tarea sí: tiene un dueño, un estado, y alguien puede mirar el tablero y ver qué está detenido. El cambio de chat a tablero es lo que vuelve auditable a un equipo de agentes, y es también lo que permite que un humano entre a media operación y entienda en dónde va todo sin leer transcripciones.

Regla 02La memoria compartida es infraestructura, no un extra

El costo dominante de un agente no es el cómputo: es volver a descubrir lo que otro ya descubrió. Sin memoria común, cada agente que arranca empieza de cero — vuelve a leer los mismos archivos, vuelve a equivocarse igual y vuelve a corregirlo igual.

Con memoria compartida, lo aprendido en una tarea queda disponible para la siguiente y para otro agente en otra máquina. Esa es la diferencia entre un equipo que mejora y cinco procesos que repiten los mismos errores en paralelo, más rápido.

El detalle que importa: la memoria tiene que guardar por qué, no sólo qué. Una nota que dice "usamos la librería X" envejece en silencio; una que dice "usamos X porque Y falló de esta forma" sigue siendo útil cuando el mundo cambia.

Regla 03Un agente ocupado no escucha

Esta es la que más cuesta aprender, porque contradice la intuición. Mientras un agente está trabajando, está dentro de su propio turno: no está escuchando. Un mensaje que llega en ese momento no interrumpe nada — espera. Y si quien lo mandó asume que llegó, coordina sobre algo que no pasó.

La consecuencia práctica es que la entrega no es un empujón, es una recogida: el destinatario tiene que ir a ver su bandeja cuando queda libre, y el emisor tiene que poder comprobar que fue leído en lugar de suponerlo. Cualquier diseño que dé por entregado lo que sólo fue enviado va a producir equipos que parecen coordinados y no lo están.

Regla 04Quien revisa no puede ser quien construyó

Un agente que revisa su propio trabajo hereda exactamente sus mismos puntos ciegos. Si no se le ocurrió un caso al construir, tampoco se le va a ocurrir al revisar: el control que escribe el autor de una compuerta comprueba lo que el autor ya pensó.

Por eso la revisión es un rol separado, con otro agente y otro contexto, cuyo trabajo es intentar tirar el resultado. Y cuando el revisor dice que está bien, eso vale como evidencia justamente porque no participó en construirlo.

El mismo principio aplica a las pruebas: una suite que el propio constructor escribió y que pasa en verde es una afirmación sobre lo que él consideró, no sobre lo que el sistema hace.

Regla 05Dónde se detiene todo y espera a una persona

La pregunta no es "¿puede el agente hacerlo solo?" sino "¿qué pasa si se equivoca?". La línea que uso es la reversibilidad:

• Reversible (leer, analizar, preparar un borrador, abrir una rama): corre solo, y queda registrado.
• Sale del edificio (mandarle algo a una persona, mover dinero, publicar, borrar): se detiene y espera aprobación humana, siempre.

Esto no es prudencia decorativa. Un sistema que se detiene en los pasos correctos puede ser mucho más agresivo en todos los demás, porque el costo de un error quedó acotado por diseño.

Qué NO resuelve tener más agentes

Vale la pena decirlo porque es donde se pierde más dinero: más agentes no arreglan un problema mal definido. Si el trabajo no es realmente paralelizable, agregarlos lo hace más lento y más caro — cada uno vuelve a levantar contexto y duplica lo que otro ya hizo. Y si los datos de la operación no existen o nadie confía en ellos, ningún equipo de agentes lo compensa; ese es un problema anterior, y lo explico en la página de consultoría.

Si lo quieres probar

MeshCode es de código abierto y está publicado en PyPI: pip install meshcode. Funciona con Claude Code, Codex, Cursor y Cline, en paralelo y entre máquinas. Más en meshcode.io.