Patrones GoF en agentes IA: el mapeo completo

Los patrones GoF existen hace treinta años: Factory, Observer, Command, Singleton. Son formas probadas de organizar código.

En agentes IA, estos patrones reaparecen con nuevos nombres y un propósito más claro.

Antes de seguir: este artículo es técnico, pero no necesitas ser un experto. Es útil conocer algunos conceptos básicos, pero te lo explicaremos paso a paso con ejemplos fáciles de entender.

Los patrones GoF en treinta segundos

En 1994 salió un libro muy famoso con 23 soluciones para resolver problemas que todos los programadores enfrentan. No son líneas de código, sino formas probadas de organizar tu programa para que sea más fácil de cambiar y de entender.

Imagina que son como planos de construcción: en vez de inventar cómo construir cada casa, usas un plano que ya funcionó.

Los patrones se dividen en grupos según qué resuelven:

• Creacionales: cómo crear las cosas (como decirle a una máquina que fabrique un objeto)

• Estructurales: cómo conectar cosas entre sí (como ensamblar piezas)

• De comportamiento: quién hace qué y en qué orden (cómo coordinan las acciones)

• Empresariales: cómo organizar sistemas muy grandes

En sistemas de agentes IA (máquinas que piensan y actúan solas), casi todos estos patrones reaparecen con nuevos nombres. La siguiente tabla muestra cómo los patrones antiguos sirven para los agentes modernos. No te preocupes si no entiendes la tabla completa ahora: explicaremos los más importantes paso a paso.

El mapa completo

Patrón clásico	Familia	Equivalente agéntico
Factory	Creacional	Crea el subagente correcto según el tipo de tarea
Builder	Creacional	Construye el contexto del agente de forma incremental
Prototype	Creacional	Templates de prompt reutilizables y clonables
Singleton	Creacional	Registro centralizado de herramientas (tool registry)
Adapter	Estructural	MCP: adapta cualquier API al formato que espera el modelo
Decorator	Estructural	Guardarraíles: envuelven al agente sin tocar su lógica
Proxy	Estructural	Router de modelos: redirige según coste o capacidad
Composite	Estructural	Agent-of-agents: un agente que coordina otros agentes
Command	Comportamiento	Tool call: acción encapsulada que el modelo puede invocar
Observer	Comportamiento	Hooks: reaccionan a eventos del agente
Strategy	Comportamiento	Selección de modelo según la tarea
Mediator	Comportamiento	Orquestador: coordina agentes sin que se hablen entre sí
Chain of Responsibility	Comportamiento	Pipeline de agentes encadenados
Template Method	Comportamiento	System prompt: define la estructura de respuesta esperada
Repository	PoEAA	RAG: abstrae la recuperación de conocimiento externo
DTO	PoEAA	Structured outputs: objetos con schema definido entre agentes
Service Layer	PoEAA	Capa de agentes orquestadores con responsabilidad clara
Saga	EIP	Transacciones agénticas de larga duración con compensación
Pub-Sub	EIP	Agentes que reaccionan a eventos asíncronos
Scatter-Gather	EIP	Debate multi-agente y síntesis de la mejor respuesta
Circuit Breaker	Resiliencia	Límite de iteraciones máximas en el tool loop
Bulkhead	Resiliencia	Aislamiento de presupuesto y contexto por agente
Fallback	Resiliencia	Cadena de modelos alternativos si el principal falla

La tabla da el mapa. Las secciones siguientes explican los patrones que más aparecen en los primeros sistemas agénticos reales.

Patrones creacionales: cómo nace un agente

Factory es como un trabajador que elige el especialista correcto para cada tarea.

Si necesitas escribir código, llama al experto en programación. Si necesitas buscar en internet, llama al experto en búsqueda. Si necesitas analizar un documento, llama al experto en análisis. Factory automáticamente elige al especialista adecuado, sin que tengas que decirle manualmente cuál usar.

// Factory: devuelve el agente correcto según el tipo de tarea
function createAgent(taskType: string): Agent {
  switch (taskType) {
    case "análisis-documentos":
      return new DocumentAnalysisAgent({
        model: "claude-opus-4-6",
        tools: [readFile, extractText, summarizeContent],
        systemPrompt: "Eres un experto en análisis de documentos complejos..."
      });
    
    case "generación-código":
      return new CodeGenerationAgent({
        model: "claude-opus-4-6",
        tools: [writeFile, runTests, linter],
        systemPrompt: "Eres un ingeniero de software sénior..."
      });
    
    case "research-web":
      return new ResearchAgent({
        model: "claude-haiku-4-5-20251001",
        tools: [webSearch, fetchArticle],
        systemPrompt: "Eres un investigador que recopila información actualizada..."
      });
    
    default:
      throw new Error(`Tipo de agente no soportado: ${taskType}`);
  }
}

// Uso: el sistema elige automáticamente el mejor agente según la tarea
const agente = createAgent("análisis-documentos");
await agente.run(nuevaTarea);

Builder es útil cuando necesitas preparar un agente paso a paso, como si fuera armar un rompecabezas.

Primero le das las instrucciones básicas (“eres un experto en análisis”). Luego le añades el historial de conversaciones anteriores. Luego los documentos que necesita. En vez de darle todo de golpe, lo haces en pasos, y cada paso es una pieza que se encaja en su lugar.

Prototype es cuando tienes un modelo o plantilla que reutilizas.

Por ejemplo: tienes un “prompt” (instrucción) que funciona bien para analizar código. En lugar de escribir instrucciones nuevas para cada proyecto, copias esta plantilla y la adaptas un poco para cada caso. Es como tener un formulario que llenas con diferentes datos, pero la estructura es siempre la misma.

Singleton resuelve un problema concreto: el tool registry. Un punto único desde el que el sistema conoce todas las herramientas disponibles. Cada herramienta se registra una sola vez; los agentes la invocan por nombre. Sin este registro centralizado, acabas con tools definidas en varios sitios con schemas que no coinciden. Pequeño, pero corrige un error que aparece pronto.

Patrones estructurales: cómo se conecta todo

Imagina que tu agente IA es como una persona en una oficina. Estos cuatro patrones son las “infraestructuras” que hacen que todo funcione juntos:

Adapter: es como un traductor entre idiomas

Piensa que tu agente necesita usar diferentes herramientas externas: Google, una base de datos, una API privada de tu empresa. El problema es que cada una “habla” en un formato diferente. El Adapter es un traductor que convierte cada formato a uno que tu agente entienda. Así, tu agente no necesita aprender 10 idiomas distintos. El traductor se encarga de la conversión automáticamente.

Decorator: es como un guardaespaldas que revisa tus acciones (sin meterse en tu cabeza)

Tu agente quiere ejecutar una acción: borrar archivos, cambiar una configuración, enviar dinero. Antes de que lo haga, le envuelves con una capa de control que verifica: “¿Estás seguro de que quieres hacer esto?” o “¿Esta acción cumple las reglas de seguridad?”. El agente no se entera de que hay un guardaespaldas revisando. Sigue pensando normalmente. El Decorator solo actúa como filtro externo.

Proxy: es como un recepcionista inteligente que enruta las peticiones

Cuando alguien entra en la oficina, el recepcionista decide: “Esta pregunta simple la maneja un Junior. Esta otra pregunta compleja la maneja el Senior.” El Proxy es así: recibe la petición, evalúa qué tan complicada es, y enruta hacia el modelo correcto (Haiku para tareas sencillas, Opus para tareas complejas). Tu código sigue siendo el mismo; el recepcionista toma la decisión.

Composite: es como un director de proyecto que coordina especialistas

Imagina que tu agente principal es un director que no hace todo el trabajo solo. Es más inteligente: tiene especialistas bajo su mando (un agente de análisis, otro de búsqueda, otro de escritura). Desde afuera, parece que hay una sola persona trabajando en el proyecto. Por dentro, es un equipo coordinado. El director (agente principal) decide quién hace qué, pero el esfuerzo es colectivo.

Patrones de comportamiento: cómo actúa el agente

Imagina que tu agente IA es como un asistente que necesita hacer cosas. Estos patrones explican cómo funciona ese asistente, qué acciones puede tomar y cómo se coordinan todas esas acciones.

Command es como darle una lista de tareas escritas en una nota

Tu agente tiene una lista de cosas que puede hacer: buscar en internet, escribir un documento, analizar una imagen, etc. Cada tarea está escrita claramente en una nota con:

• Qué se llama (por ejemplo: “buscar en internet”)
• Para qué sirve (por ejemplo: “encuentra información actualizada”)
• Qué información necesita (por ejemplo: “un texto para buscar”)

Cuando el agente necesita hacer algo, le das una nota con esa tarea específica. El agente lee la nota, entiende qué necesita hacer y lo ejecuta. Tú controlas qué tareas están disponibles en la lista.

Observer es como tener alarmas que suena en momentos específicos

Imagina que tienes alarmas que suenan cuando pasan ciertas cosas:

• Una alarma que suena cuando el agente termina una búsqueda
• Una alarma que suena cuando el agente comienza a escribir
• Una alarma que suena cuando termina completamente

Cuando suena cada alarma, ejecutas una acción (por ejemplo: guardar el resultado, enviar una notificación, actualizar una base de datos). El agente no sabe que hay alarmas. Simplemente hace su trabajo, y las alarmas responden a lo que hace.

Strategy es como tener diferentes caminos para llegar al mismo destino

Tienes varias formas de resolver un problema:

• Preguntarle al modelo A (rápido pero menos precisión)
• Preguntarle al modelo B (lento pero más exacto)
• Preguntarle al modelo C (muy preciso pero muy caro)

Según la situación, eliges un camino: si la tarea es urgente y no es importante, usas el modelo rápido. Si necesitas precisión, usas el modelo exacto. La lógica del agente sigue siendo la misma; solo cambias cuál modelo utiliza según lo que necesites en ese momento.

Mediator es como tener un director de orquesta

Imagina que tienes varios especialistas:

• Uno busca información
• Otro analiza documentos
• Otro escribe reportes

Sin un director, cada especialista tendría que saber cómo comunicarse con los otros, quién necesita qué información, etc. Es un caos.

Con un director (Mediator), todos hablan solo con el director:

• El buscador dice: “Encontré esta información”
• El director la recibe y la envía al analista
• El analista dice: “Ya analicé esto”
• El director se la envía al escritor
• El escritor entrega el reporte final

El director es el único que sabe cómo funcionan todas las partes. Los especialistas solo necesitan conocer al director.

Patrones empresariales: PoEAA y EIP

Son formas de organizar sistemas grandes y complejos. Te lo explicamos con ejemplos simples:

Repository: es como una “puerta de entrada a los datos”

Tu agente necesita buscar información. En vez de que el agente sepa dónde están los datos (¿están en una base de datos? ¿en archivos? ¿en internet?), existe una puerta única: pide la información y alguien la busca donde haga falta. RAG (patrón para que los agentes accedan a conocimiento externo) funciona así: tu agente solo pide, sin importarle de dónde viene la respuesta.

DTO (envío de información estructurada): es como un sobre con campos claramente definidos

Cuando dos agentes necesitan comunicarse, no envían texto suelto. Envían un “sobre” con estructura clara: esto es un nombre, esto es un número, esto es una fecha. Menos confusión, menos errores.

Scatter-Gather: pregunta a varios a la vez y junta las respuestas

Tienes un problema difícil. En lugar de preguntarle a un solo modelo (que puede equivocarse), le preguntas a tres modelos en paralelo. Todos resuelven el mismo problema desde sus perspectivas. Luego juntas las respuestas y sacas la mejor conclusión. Es como pedir consejo a varios amigos en lugar de uno solo.

Saga: es un plan con “Plan B” si algo sale mal

Tu agente necesita hacer cinco pasos seguidos (paso 1, paso 2, paso 3, paso 4, paso 5). Si el paso 4 falla, ¿qué pasa con los pasos 1, 2 y 3? Saga es un plan que dice: si aquí falla, deshaz esto; si allá falla, deshaz lo otro. Así el sistema sigue funcionando sin quedar roto a mitad de camino.

Resiliencia: cuando el agente falla o se atasca

Imagina que tu agente es como una persona trabajando en una tarea. A veces se atasca: sigue intentando lo mismo una y otra vez sin avanzar, gastando tiempo y dinero sin resultado.

Circuit Breaker: es como un pulsador de emergencia

El agente intenta hacer algo hasta 10 veces (o el número que definas). Si después de esas 10 intentos no lo logra, el sistema se detiene. Sin este límite, el agente atascado seguiría intentando indefinidamente, gastando tu dinero en tokens sin terminar nunca la tarea.

// Pulsador de emergencia: detiene si intenta más de 10 veces
if (intentosRealizados > 10) {
  detenerse_ahora();
}

Bulkhead: es como darle a cada agente su propio presupuesto

Si tienes varios agentes trabajando a la vez, cada uno tiene su límite de dinero (tokens). Si uno se desboca y gasta su límite, los otros siguen funcionando con su presupuesto. Uno no arruina a todos.

Fallback chains: es como tener un plan B

Si el agente intenta con el modelo Claude (el más potente pero caro) y falla, automáticamente intenta con el modelo Sonnet (más barato). Si ese también falla, intenta con Haiku (el más rápido). El sistema siempre tiene una opción alternativa.

Lo que no tiene equivalente clásico

Estos son los patrones agénticos genuinamente nuevos. No están en GoF, no están en Fowler ni en Hohpe.

Context engineering: gestionar activamente qué información entra en la ventana de contexto (el espacio de memoria que tiene el modelo durante una conversación) en cada momento. No es caching ni carga diferida. Es una decisión explícita sobre qué sabe el modelo y qué no sabe, tomada paso a paso.

Eval harness: infraestructura para medir si el agente funciona bien. El testing clásico no aplica porque las salidas del modelo son probabilísticas, no deterministas. Un eval harness define casos de prueba, ejecuta el agente varias veces y agrega métricas para detectar degradación.

LLM-as-Judge: usar un modelo para evaluar la calidad de la respuesta de otro modelo. No existe equivalente clásico porque en software tradicional los tests son binarios. Aquí el “juez” razona sobre calidad, coherencia o corrección semántica.

Sandbox execution: ejecutar el código generado por el agente en un entorno aislado antes de que toque producción. El agente escribe. El sandbox verifica. Solo si pasa, se despliega. Sin este patrón, cada run del agente es una apuesta.

Cost/latency-aware routing: enrutar peticiones a modelos distintos no solo por capacidad, sino con restricciones explícitas de coste y latencia. Strategy resuelve el “cómo elegir”. Este patrón añade “cuánto puedes gastar y cuánto puedes esperar” como ciudadanos de primera clase en la decisión.

La diferencia entre estos cinco y los patrones GoF es que requieren razonar sobre incertidumbre. GoF asume que el código hace lo que le dices. Los patrones agénticos asumen que el modelo puede sorprenderte.

Errores comunes al mapear estos patrones

Confundir Decorator con Proxy

Son estructuralmente parecidos, pero la intención es diferente. Decorator añade comportamiento a la salida del agente (verificar, filtrar, enriquecer). Proxy controla el acceso al agente o al modelo (redirigir, limitar, autenticar). Si estás verificando output, es Decorator. Si estás redirigiendo peticiones, es Proxy. Mezclarlos lleva a guardarraíles que hacen demasiado, o a routers que también validan, y ninguno de los dos se puede cambiar sin romper el otro.

Aplicar Factory cuando solo tienes un tipo de agente

Factory tiene sentido cuando tienes dos o más variantes con lógica distinta. Si solo tienes un agente con una sola configuración, Factory es sobreingeniería pura. Empieza con una función directa. Añade Factory cuando el segundo tipo de agente aparezca de verdad.

Ignorar Circuit Breaker hasta que el problema ocurre

He visto esto en los primeros proyectos agénticos con los que trabajé en producción: el tool loop se atasca en un bucle, el agente sigue llamando a la misma herramienta esperando un resultado diferente, y el gasto de tokens se multiplica sin que nadie lo note hasta que llega la factura. El límite de iteraciones no es una optimización. Es la primera línea de defensa.

Usar Saga sin definir las compensaciones primero

Saga sin compensaciones es simplemente una secuencia de pasos que no sabe recuperarse si algo falla. Antes de implementar Saga, escribe en papel qué hace el sistema si el paso 3 de 5 falla. Si no puedes responder esa pregunta, todavía no estás listo para Saga.

Checklist de implementación

• Los subagentes se crean con Factory según el tipo de tarea, no con lógica condicional dispersa

• Cada tool call está modelado como un Command object con schema explícito y description clara

• Los guardarraíles están implementados como Decorator, externos a la lógica del agente

• El orquestador centraliza la comunicación entre agentes (Mediator), los agentes no se llaman entre sí

• El tool loop tiene un Circuit Breaker con límite de iteraciones definido antes de poner en producción

• RAG abstrae el acceso a conocimiento externo (Repository), el agente no conoce la fuente de datos

• Los outputs entre agentes usan structured outputs con schema tipado (DTO)

• El sistema tiene al menos un eval harness básico antes de desplegarse

• Las herramientas que ejecutan código del usuario corren en un sandbox aislado antes de tocar producción

Preguntas Frecuentes

¿Necesito conocer los patrones GoF para empezar con agentes?

No. Puedes construir agentes funcionales sin haber leído el libro de 1994. Pero si ya los conoces, este mapa te da ventaja: en vez de aprender conceptos agénticos desde cero, reconoces estructuras familiares con nuevos roles. Factory ya lo sabes usar. Que ahora cree subagentes en vez de objetos de negocio es un paso pequeño.

¿Qué patrón debo aprender primero si empiezo desde cero?

Command=tool call. Es el más fundamental de todos. Si no entiendes que cada herramienta que le das al modelo es un Command object con nombre, descripción y schema, el resto de los patrones no tiene base sólida. Todo lo demás construye sobre ese concepto.

¿Cuál es la diferencia entre Decorator y Proxy en un sistema agéntico?

Decorator añade comportamiento: los guardarraíles que verifican o filtran la salida del agente. Proxy controla el acceso: el router que decide a qué modelo enviar la petición. La estructura de código es casi idéntica, pero la intención es diferente. En la práctica: si estás modificando o verificando output, es Decorator. Si estás redirigiendo peticiones, es Proxy.

¿El patrón Singleton sirve para algo en agentes?

Sí, para el tool registry: un registro centralizado de todas las herramientas disponibles, accesible desde cualquier parte del sistema. Cada herramienta se registra una sola vez. Los agentes la invocan por nombre. Sin este registro, acabas con herramientas definidas en múltiples sitios con schemas inconsistentes.

¿Los patrones de resiliencia (Circuit Breaker, Bulkhead) son para sistemas avanzados?

Circuit Breaker no. Es el primero que deberías implementar, antes incluso que cualquier patrón de orquestación. Un agente sin límite de iteraciones es un agente que puede costarte dinero de forma impredecible. Bulkhead sí es más relevante cuando tienes varios agentes corriendo en paralelo y necesitas que el fallo de uno no afecte a los demás.