Arquitectura Pulpo para Agentes de IA: Así se Construyen Sistemas Multi-Agente que Funcionan

🧠 De dónde sale la arquitectura pulpo

En junio de 2026, Geoff Goodman publicó un artículo en su blog explicando cómo diseñó TorkBot, su agente de IA personal. La idea es simple pero potente: un cerebro central (el "foreground") que coordina múltiples apéndices semi-autónomos (los "lanes"), cada uno con su propio contexto y capacidad de trabajar en paralelo.

Lo interesante no es el nombre — que es bastante bueno — sino que Goodman llegó a esta arquitectura por necesidad, no por postureo. Después de chocar contra varios callejones sin salida, el diseño emergió como la única forma de resolver tres problemas a la vez: capacidad de respuesta (el usuario no puede esperar 30 segundos), capacidad de hacer trabajo complejo (delegar tareas pesadas) y continuidad (el agente debe mantener una personalidad y memoria coherentes).

Personalmente, llevo meses probando distintos patrones de agentes — desde CrewAI hasta LangGraph — y este enfoque resuelve algo que los demás manejan fatal: la gestión del contexto. Cuando tienes 3, 5 o 10 agentes trabajando, el contexto explota. La arquitectura pulpo lo contiene.

🧩 Caso 1: Un asistente de programación que no se queda colgado

Imagina que estás construyendo un agente que te ayuda a programar. Le dices "refactoriza este módulo para que use async/await" y esperas que funcione. Con un agente monolítico — un solo LLM haciendo todo — tienes dos opciones malas: o limitas el número de herramientas que puede usar (pierdes capacidad) o le das acceso a todo y rezas para que no se atasque (pierdes velocidad).

Con la arquitectura pulpo funciona así:

1. El foreground recibe tu mensaje. Es rápido porque su contexto es ligero: prompt estable, intención actual, actividad reciente.

2. Delega a un lane sandbox. El foreground detecta que necesita hacer cambios en múltiples archivos y lanza un apéndice con una VM Linux completa. Le dice: "refactoriza estos 4 archivos a async/await, ejecuta los tests, y si algo falla itera".

3. El apéndice trabaja solo. Puede hacer 20 tool calls, leer documentación, ejecutar tests, fallar dos veces y reintentar. Toda esa basura se queda en su contexto. El foreground no se entera.

4. El apéndice informa. Cuando termina (o se atasca de verdad), manda un resumen al foreground: "listo, 4 archivos modificados, 12 tests pasan".

Esto es exactamente lo que describe Anthropic en su guía de agentes efectivos: el patrón orchestrator-workers. Un orquestador que descompone tareas y las manda a workers, cada uno con su propio turno de LLM. La diferencia con el pulpo es que aquí los apéndices pueden ser de larga duración — no solo workers efímeros.

He probado este enfoque con mi Raspberry Pi 5 ejecutando un agente local y la diferencia en latencia es brutal: el foreground responde en 2-3 segundos aunque un apéndice lleve 45 segundos compilando.

🧩 Caso 2: Atención al cliente con agentes que no se pisan

Otro caso donde brilla esta arquitectura es en sistemas de soporte. Según la experiencia de Anthropic con docenas de empresas, el soporte al cliente es el caso de uso donde los agentes realmente están generando valor hoy.

El problema clásico: un usuario escribe al chat con una incidencia compleja ("mi pedido no ha llegado y además necesito cambiar la dirección de facturación"). Un solo agente intentando resolver ambas cosas a la vez se lía. Dos agentes separados se pisan.

Con pulpo:

• Foreground: recibe el mensaje, entiende que hay dos problemas independientes.

• Apéndice A (lane de pedidos): consulta la API de logística, verifica el tracking, detecta que el paquete está en reparto. Respuesta en 8 segundos.

• Apéndice B (lane de facturación): accede al CRM, actualiza la dirección, confirma el cambio. Respuesta en 5 segundos.

• Foreground: recibe ambos resultados y los sintetiza en una respuesta coherente al usuario. Sin duplicar información, sin contradicciones.

La clave aquí es que los apéndices se comunican entre sí solo cuando es necesario, y lo hacen en texto plano. Nada de protocolos complejos ni formatos raros — Goodman apuesta por prosa como portadora de intención. Los modelos están entrenados para entender texto, no JSON anidado.

🧩 Caso 3: Investigación multi-fuente que no se ahoga en contexto

Este es mi favorito porque yo mismo lo uso para este blog. Cuando preparo un artículo como este, necesito consultar 6-8 fuentes, extraer datos concretos y sintetizarlos. Si meto todo en un solo prompt, el modelo se vuelve perezoso con las fuentes del medio (el famoso "lost in the middle").

Con arquitectura pulpo:

• Foreground: define la pregunta de investigación y los criterios.

• Apéndices de lectura (3-4 lanes en paralelo): cada uno lee 2-3 fuentes, extrae datos relevantes y devuelve un resumen estructurado con referencias.

• Apéndice de síntesis: recibe los 3-4 resúmenes y los cruza. Detecta contradicciones ("MuyComputer dice 20% más rápido, Xataka dice 15%"), las resuelve volviendo a la fuente original.

• Foreground: recibe la síntesis y la convierte en texto publicable.

Esto no es teoría. Marktechpost comparó 5 arquitecturas de agentes (jerárquica, enjambre, meta-learning, modular y evolutiva) y la arquitectura modular — que es esencialmente lo mismo que el pulpo — salió ganando en tareas de investigación porque permite especialización sin pérdida de contexto.

El Google ADK (Agent Development Kit) que acaba de salir en su versión 2.0 también apuesta por esto: graph workflows con collaborative agents que mantienen sus propios contextos y se comunican vía el protocolo A2A (Agent-to-Agent). Mismo concepto, distinto nombre.

🧩 Caso 4: Pipeline de contenido que no se rompe a la mitad

Un pipeline de creación de contenido — ideas → borrador → revisión → publicación — es el clásico candidato para prompt chaining. Pero el chaining lineal tiene un problema: si el paso 2 falla, pierdes todo lo del paso 1. Y si quieres probar 3 borradores en paralelo para elegir el mejor, el chaining no te sirve.

Con pulpo el pipeline es así:

• Foreground: recibe el topic y la audiencia objetivo.

• Apéndices de borrador (3 lanes en paralelo): cada uno escribe un borrador con un enfoque distinto (técnico, divulgativo, opinión).

• Apéndice evaluador: recibe los 3 borradores, los evalúa según criterios (claridad, datos, enganche), elige el mejor o pide mejoras.

• Apéndice de revisión: corrige el borrador ganador, verifica datos, añade links.

• Foreground: recibe el artículo listo para publicar.

Esto es el patrón evaluator-optimizer de Anthropic llevado a multi-agente. Y en CrewAI se puede implementar con un crew de 4 agentes (researcher, writer, reviewer, publisher) usando proceso jerárquico. Pero ojo: CrewAI mete todo en un solo hilo, así que si tienes 3 writers en paralelo, el contexto se dispara. El pulpo lo resuelve aislando cada apéndice.

🔧 Cómo implementarlo sin volverte loco

Después de trastear con esto un par de semanas, aquí van las cosas que de verdad importan:

1. El foreground debe ser aburrido. Prompt estable, pocas tools, contexto ligero. Si el foreground se complica, todo el sistema se arrastra. Goodman lo dice claro: "la cabeza necesita estar disponible". Los brazos pueden estar ocupados.

2. Comunicación entre apéndices = texto plano. No inventes protocolos. No hagas JSON schemas de 400 líneas. Los LLMs entienden prosa. Un apéndice le dice a otro: "encontré esto en el archivo X, compruébalo tú". Funciona.

3. Compactación asíncrona. Cada apéndice comprime su contexto periódicamente. Si un apéndice lleva 30 turnos, resume los primeros 25 en 3 frases y libera tokens. Esto evita que el contexto explote y mantiene los costes de API bajo control.

4. Filesystem virtual compartido. Los apéndices comparten un directorio ./shared. En lugar de pasarse datos enormes por texto, se pasan referencias a archivos. "El análisis está en ./shared/report-2026.json".

5. Usa sandboxes para trabajo sucio. Si un apéndice va a ejecutar código, modificar archivos o hacer 50 tool calls, dale su propia VM o contenedor. No manches el foreground con eso.

Y una cosa más: no necesitas frameworks. Lo dice Anthropic y lo repite Goodman. Un lane es básicamente un bucle: recibe mensaje → decide acción → ejecuta tool → recibe resultado → decide si seguir o terminar. Eso son 30 líneas de Python. No necesitas LangGraph, CrewAI ni nada parecido para empezar.

⚡ Comparación rápida: Pulpo vs otras arquitecturas

Para que no te pierdas entre tanto nombre:

• Anthropic Workflows (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer): Son patrones, no arquitecturas. Puedes combinarlos. El pulpo usa orchestrator-workers + evaluator-optimizer + parallelization, todo a la vez.

• CrewAI: Multi-agente con roles fijos (researcher, writer, reviewer). Bueno para prototipos rápidos, malo para producción porque el contexto compartido se desborda. Proceso secuencial o jerárquico, pero no verdaderamente paralelo.

• Google ADK 2.0 + A2A: Lo más parecido al pulpo en el ecosistema mainstream. Graph workflows con nodos que son agentes independientes, comunicación vía protocolo A2A. Más complejo de montar pero más escalable.

• LangGraph: Grafos de estados con nodos agentivos. Muy flexible, muy complejo. Si no sabes exactamente qué estás haciendo, acabas con un grafo de 40 nodos que nadie entiende.

El pulpo gana en simplicidad conceptual y en gestión de contexto. Pierde en tooling (no tiene framework, tienes que montarlo tú). Para proyectos pequeños-medianos — que es el 90% de lo que vas a construir — es la mejor opción.