Diseñar sistemas multiagente como si fueran microservicios
La disciplina que hizo confiables a los microservicios event-driven se aplica casi 1:1 a los sistemas multiagente con LLMs. Acá va la traducción.
Todos los que estamos construyendo con agentes hoy estamos redescubriendo los sistemas distribuidos —normalmente por las malas. La buena noticia: ya sabemos cómo construir sistemas a partir de componentes independientes y poco confiables que se comunican por red. Lo venimos haciendo hace una década. Se llama microservicios, y casi todas las lecciones aplican.
Un agente es un servicio con un contrato difuso
Un microservicio recibe un request, hace trabajo y devuelve una respuesta. Puede fallar, hacer timeout o devolver basura. Eso lo manejamos con reintentos, timeouts, idempotencia y circuit breakers.
Un agente es lo mismo con un giro: su contrato es probabilístico. Con la misma entrada puede producir salidas distintas. Eso no rompe el modelo de microservicios —solo significa que el límite entre agentes tiene que ser explícito y validado, igual que un schema en el borde de un servicio.
Una sola responsabilidad por agente
Los diseños multiagente que se caen a pedazos son los del “súper agente” que planifica, recupera, escribe y critica en un solo loop. Eso es un monolito: difícil de testear, difícil de observar e imposible de razonar cuando se porta mal.
Separalo como separarías un servicio: un planner, workers que dueñan una capacidad cada uno, y un crítico que valida contra el objetivo.
Cuando el sistema está diseñado como microservicios, debuggear deja de ser “el LLM hizo algo raro” y pasa a ser “el crítico rechazó el paso 3, acá está el trace”.
Esa es la diferencia entre una demo y un sistema que podés correr en producción.