flowchart LR
A[Solicitud] --> B[Router]
B --> C[Worker contractual]
B --> D[Worker privacidad]
B --> E[Worker seguridad]
C --> F[Critic]
D --> F
E --> F
F --> G[Evaluator]
G --> H{¿Requiere autorización?}
H -- Sí --> I[Human gate]
H -- No --> J[Salida]
I --> J
Patrones de diseño
Seis patrones simples para organizar sistemas agentes sin partir por arquitecturas innecesariamente complejas: router, planner, worker, critic, evaluator y human gate.
La página anterior introdujo los sistemas multiagente y una idea intuitiva: cuando una tarea es grande, podemos dividir el trabajo entre componentes especializados.
Pero esa idea abre inmediatamente un problema de diseño.
Si tenemos varios componentes capaces de investigar, analizar, redactar, revisar o decidir qué hacer después, ¿cómo los organizamos?
Podríamos inventar una arquitectura distinta para cada caso. También podríamos caer en el extremo opuesto: construir desde el comienzo un conjunto de agentes que conversan entre sí, con múltiples capas de coordinación, cuando el problema podía resolverse mediante dos o tres relaciones simples.
Las clases adoptan una estrategia más prudente: antes de pensar en “muchos agentes”, aprender algunos patrones de diseño comprensibles.
Un patrón no es un producto, una marca ni una arquitectura completa. Es una forma recurrente de organizar una responsabilidad dentro del sistema.
Idea central
Para este handbook utilizaremos seis patrones pedagógicos:
Router · Planner · Worker · Critic · Evaluator · Human gate.
Cada uno responde a una pregunta distinta:
- Router: ¿qué ruta o especialista corresponde?
- Planner: ¿cómo se divide el objetivo en pasos?
- Worker: ¿quién ejecuta una subtarea concreta?
- Critic: ¿qué errores u omisiones tiene el resultado?
- Evaluator: ¿cumple los criterios de aceptación?
- Human gate: ¿debe una persona autorizar antes de continuar?
No es necesario que cada patrón sea implementado mediante un modelo o “agente” separado. Lo importante es separar funciones que conviene poder diseñar, evaluar y controlar de manera distinta.
Patrón no significa tipo de agente
En páginas anteriores clasificamos agentes por capacidad y por función profesional. Los patrones de esta página operan en otro nivel.
Un agente investigador describe una función profesional.
Un router describe cómo se decide a qué función enviar un caso.
Un agente planificador describe una capacidad de planificación.
El patrón planner describe dónde colocamos esa responsabilidad dentro de una arquitectura.
La diferencia puede parecer sutil, pero evita convertir cualquier nombre útil en una nueva categoría de producto.
Por ejemplo, una sola aplicación podría contener:
No necesitamos llamar “agente” a cada caja. El diagrama sólo distribuye responsabilidades.
Router: elegir la ruta adecuada
Un router recibe una entrada y determina a qué ruta, capacidad o especialista debe enviarse.
La intuición es familiar para cualquier organización.
Un correo puede ingresar a una mesa común y luego ser derivado a:
- contratos;
- privacidad;
- litigios;
- propiedad intelectual;
- compliance.
El router automatiza esa primera selección.
En el caso conductor podría recibir:
“Necesitamos revisar este proveedor de IA antes de firmar.”
Y clasificar que el expediente requiere, además de revisión contractual general:
- privacidad, porque tratará datos personales;
- seguridad, porque tendrá acceso a documentación interna;
- compras, porque supera un umbral económico.
Qué debe decidir un router
Un buen router no necesita resolver el fondo del problema. Su función es más estrecha:
identificar correctamente qué camino corresponde.
Eso permite evaluarlo con preguntas específicas:
- ¿envió el caso al especialista correcto?;
- ¿omitió una ruta obligatoria?;
- ¿envió todo a todos, anulando el beneficio del enrutamiento?;
- ¿sabe reconocer casos fuera de alcance?;
El error típico del router
Un router deficiente puede producir un error temprano que contamine todo lo posterior.
Si clasifica una consulta de protección de datos como simple revisión contractual, el resto del sistema puede funcionar perfectamente sobre una ruta equivocada.
Por eso una arquitectura modular no elimina los errores: los hace localizables.
Planner: convertir un objetivo en un plan
El planner recibe un objetivo que todavía no contiene todos los pasos y propone una secuencia de subtareas.
Por ejemplo:
“Prepara los antecedentes para evaluar este proveedor.”
El planner podría proponer:
- identificar el servicio;
- verificar documentos disponibles;
- clasificar tratamientos de datos;
- revisar cláusulas críticas;
- detectar información faltante;
- preparar matriz de hallazgos;
- solicitar revisión humana donde corresponda.
Ya estudiamos la planificación como capacidad. Aquí interesa el patrón arquitectónico: separar el momento de planificar del momento de ejecutar.
Esto permite introducir un control intermedio:
flowchart LR
A[Objetivo] --> B[Planner]
B --> C[Plan propuesto]
C --> D{¿Plan permitido?}
D -- Sí --> E[Workers]
D -- No --> F[Corregir o escalar]
La separación es especialmente útil cuando un plan puede incluir acciones sensibles.
Un modelo puede proponer “enviar un correo al proveedor”. La arquitectura todavía puede exigir que esa acción sea validada antes de ejecutarse.
Worker: ejecutar una subtarea acotada
El worker es probablemente el patrón más sencillo.
Recibe una tarea suficientemente delimitada y la ejecuta.
Ejemplos:
“Extrae todas las cláusulas que regulen subcontratación.”
“Compara la cláusula 14 con el estándar interno adjunto.”
“Calcula el plazo entre notificación y terminación.”
“Prepara una tabla de los subprocesadores identificados.”
El valor de un worker está precisamente en que no necesita decidirlo todo.
Cuanto más clara sea la frontera de la subtarea, más fácil resulta definir:
- entradas;
- salida esperada;
- herramientas disponibles;
- criterios de aceptación;
- errores posibles.
Especialización sin multiplicar modelos
Dos workers pueden utilizar el mismo modelo subyacente.
Uno recibe instrucciones, herramientas y fuentes de privacidad.
Otro recibe criterios contractuales.
La especialización puede estar en el contexto y en las herramientas, no necesariamente en los pesos del modelo.
Critic: buscar errores y omisiones
El critic no intenta necesariamente producir una mejor respuesta desde cero.
Su función es atacar el resultado existente.
Puede preguntar:
- ¿qué hallazgo no tiene evidencia?;
- ¿qué documento relevante no fue revisado?;
- ¿qué inferencia excede el texto?;
- ¿qué riesgo está duplicado?;
- ¿qué excepción contractual contradice la conclusión?;
- ¿qué instrucción no fue cumplida?;
En trabajo jurídico este patrón es especialmente útil porque la primera respuesta puede ser plausible y coherente sin ser suficientemente completa.
Un critic bien diseñado debería operar con criterios concretos.
No basta:
“Sé crítico y encuentra problemas.”
Puede ser mejor:
“Revisa la matriz exclusivamente para detectar: (a) afirmaciones sin fuente, (b) contradicciones entre hallazgo y cláusula, (c) omisiones respecto de las ocho materias obligatorias, y (d) conclusiones formuladas con mayor certeza que la evidencia disponible.”
Crítica no equivale a corrección
El critic puede señalar que algo parece incorrecto.
Eso no significa automáticamente que su objeción sea correcta.
Por eso conviene distinguir el critic del siguiente patrón.
Evaluator: decidir si se cumplen criterios
El evaluator compara el resultado contra un estándar de aceptación.
La pregunta no es simplemente:
“¿Qué está mal?”
Sino:
“¿Cumple el producto los criterios definidos para pasar a la siguiente etapa?”
Supongamos que una revisión contractual sólo puede considerarse completa cuando:
- se revisaron todas las materias obligatorias;
- cada hallazgo tiene evidencia;
- la información faltante está identificada;
- no existen contradicciones abiertas;
- las desviaciones altas fueron escaladas.
El evaluator puede comprobar cada criterio y devolver:
COMPLETITUD: cumple
EVIDENCIA: no cumple
CONTRADICCIONES: cumple
ESCALAMIENTOS: cumple
RESULTADO: NO APTO PARA CIERRE
MOTIVO: dos hallazgos carecen de referencia verificable.Critic y evaluator no son lo mismo
Podemos resumir:
| Patrón | Pregunta principal | Producto |
|---|---|---|
| Critic | ¿Qué problemas encuentro? | Objeciones, errores, omisiones |
| Evaluator | ¿Cumple el estándar? | Juicio contra una rúbrica o umbral |
Un critic puede ser exploratorio.
Un evaluator necesita criterios definidos.
Esta separación será importante cuando estudiemos calidad: no basta con pedir “revisión”; debemos saber qué cuenta como resultado aceptable.
Human gate: detener antes de una acción sensible
El human gate introduce deliberadamente una pausa en la automatización.
No es una señal de que el sistema “fracasó”. Es una pieza de diseño.
Su función es simple:
antes de una acción determinada, una persona debe revisar y autorizar.
Por ejemplo:
flowchart LR
A[Agente prepara correo] --> B{Human gate}
B -- Aprobar --> C[Enviar]
B -- Modificar --> D[Corregir]
B -- Rechazar --> E[Cancelar]
D --> B
La aprobación puede ser necesaria antes de:
- enviar una comunicación externa;
- aceptar una excepción contractual;
- modificar permisos;
- registrar una aprobación definitiva;
- eliminar información;
- ejecutar una acción difícil de revertir.
Google describe el patrón human-in-the-loop precisamente como una pausa deliberada antes de acciones significativas. Las clases lo traducen a una regla pedagógica especialmente útil para el Derecho: capacidad técnica no equivale a autoridad para actuar.
El human gate debe ser real
Agregar un botón “aprobar” no garantiza supervisión efectiva.
La persona necesita poder ver información suficiente para decidir:
- qué acción se propone;
- por qué;
- sobre qué evidencia;
- qué efectos tendrá;
- si es reversible.
Una aprobación sin contexto puede convertirse en automatización con una formalidad humana decorativa.
Un patrón mínimo para trabajo jurídico
La combinación más útil para comenzar no suele requerir seis patrones simultáneos.
Las clases proponen una arquitectura mínima de tres funciones:
flowchart LR
A[Planner] --> B[Worker]
B --> C[Critic / Reviewer]
C --> D{¿Cumple?}
D -- No --> B
D -- Sí --> E[Human gate si corresponde]
E --> F[Salida]
La lógica es importante:
- separar la planificación de la ejecución;
- separar la ejecución de la revisión;
- separar la revisión de la autorización cuando hay efectos relevantes.
Esto evita que un mismo componente produzca, justifique y apruebe su propio trabajo sin una instancia diferenciada de control.
Un ejemplo completo: revisión de proveedor de IA
Imaginemos que llega un contrato, un DPA y una ficha comercial.
Router
Clasifica el expediente como:
- contractual;
- privacidad;
- seguridad.
Planner
Define que primero deben identificarse documentos y tratamientos de datos; después se revisarán cláusulas y finalmente se consolidarán hallazgos.
Workers
Tres workers ejecutan tareas acotadas:
- extracción contractual;
- revisión de datos;
- revisión de controles de seguridad.
Critic
Busca afirmaciones sin evidencia, contradicciones y materias omitidas.
Evaluator
Comprueba si el expediente cumple los criterios mínimos de completitud.
Human gate
Antes de enviar preguntas al proveedor y antes de registrar una decisión de aceptación, una persona autorizada revisa la propuesta.
El sistema ya parece sofisticado, pero cada pieza continúa respondiendo una pregunta comprensible.
Eso es precisamente lo que buscamos con los patrones.
Qué puede salir mal
Multiplicar agentes sin necesidad
Crear un agente para cada microfunción aumenta coordinación, latencia y costo.
Un worker simple puede ser suficiente.
Hacer que todos revisen todo
Si router, planner, worker, critic y evaluator reciben todos los documentos y vuelven a ejecutar el mismo análisis, hemos creado redundancia, no arquitectura.
Confundir crítica con autoridad
Que un critic objete un resultado no significa que tenga autoridad para bloquear institucionalmente un caso. Esa regla pertenece al proceso y a los controles.
Utilizar human gates indiscriminados
Si cada operación requiere autorización, el sistema puede producir más carga que la que elimina.
El gate debe ubicarse donde el impacto lo justifica.
No definir criterios
Un evaluator sin rúbrica es simplemente otro generador de opinión.
Qué debes recordar
Los patrones de diseño ayudan a distribuir responsabilidades.
El router selecciona una ruta.
El planner organiza un plan.
El worker ejecuta una subtarea.
El critic busca errores.
El evaluator verifica criterios.
El human gate preserva una decisión o autorización humana antes de acciones relevantes.
No es necesario convertir cada patrón en un agente independiente.
La pregunta correcta es:
¿qué responsabilidades conviene separar para que el sistema sea más comprensible, evaluable y gobernable?
El problema que todavía queda abierto
Ya sabemos distribuir funciones dentro de la arquitectura.
Pero cada una de esas funciones depende de algo que todavía no hemos examinado de manera sistemática:
¿qué información recibe el modelo en cada paso?
Un planner necesita instrucciones, estado y herramientas disponibles.
Un critic necesita evidencia y criterios.
Un router necesita suficiente contexto para clasificar.
La siguiente página introduce context engineering: el diseño dinámico del conjunto de instrucciones, evidencia, herramientas, estado, memoria y ejemplos que se coloca a disposición del modelo para cada inferencia.