Tag: LLM

Multi-agente sin orquestador: cuándo sí, cuándo no

Tiempo estimado de lectura: 4 min

Resumen rápido (lectores con prisa)

Un sistema multi-agente sin orquestador (coreografía) permite que varios agentes LLM intercambien contexto sin una máquina de estados central. Úsalo para simulaciones, brainstorming y generación de datos sintéticos donde la impredecibilidad es valor. Evítalo en sistemas transaccionales, atención crítica o cuando necesitas trazabilidad determinista. Empieza siempre con un agente único y herramientas tipadas; escala a múltiples agentes solo si el límite es cognitivo, no de diseño.

Multi-agente sin orquestador: definición y contexto

Un sistema multi-agente sin orquestador (coreografía) es aquel en que varios agentes LLM se transfieren contexto entre sí sin una máquina de estados central que valide transiciones. Frameworks experimentales como OpenAI Swarm exploran handoffs ligeros entre agentes. En contraste, soluciones orquestadas usan grafos de estado deterministas: LangGraph, n8n o XState.

La diferencia crítica: en la orquestación, la infraestructura controla el flujo; en la coreografía, el flujo emerge de decisiones probabilísticas del modelo. Esa diferencia tiene consecuencias prácticas en latencia, trazabilidad y tolerancia al error.

Cuándo SÍ usar multi-agente sin orquestador

• Simulaciones con actores contrapuestos. Cuando el objetivo es generar comportamiento emergente o modelar negociaciones entre agentes con incentivos opuestos, la autonomía produce diversidad útil.
• Investigación y brainstorming creativo. Si buscas múltiples perspectivas no filtradas para enriquecer creatividad, dejar que agentes critiquen y propongan sin una regla rígida puede aportar hallazgos inesperados.
• Generación de datos sintéticos. Interacciones caóticas entre agentes generan datasets variados útiles para entrenamiento o evaluación.

Estos usos comparten dos características: no arriesgan datos reales ni SLAs estrictos, y toleran impredecibilidad como una funcionalidad, no un bug.

Cuándo NO usar multi-agente sin orquestador

Evita coreografías si hay dinero, integridad de datos o experiencia de usuario en juego:

• Sistemas transaccionales con escrituras en BD, ERPs o CRMs: necesitas rollbacks y garantías ACID; la orquestación es obligatoria.
• Atención al cliente y workflows críticos: latencias y respuestas incoherentes son inaceptables.
• Modelos con presupuesto de tokens limitado: los enjambres tienden a entrar en bucles costosos (cortesías, indecisiones).

Además, si necesitas auditoría y trazabilidad determinista, la coreografía complica el post-mortem.

Por qué un solo agente supera a cinco encadenados (ejemplos técnicos)

1) Context Loss

Cada handoff serializa el razonamiento en texto. El receptor procesa un resumen; pierde activaciones internas y matices. Resultado: degradación progresiva del contexto. Un solo agente mantiene la cadena lógica en una ventana de contexto continua.

2) Latencia y coste

Cinco llamadas secuenciales multiplican TTFT y factura. Para servicios con SLA de respuesta o coste por token relevante, el impacto es directo en UX y en la cuenta.

3) Roles que deberían ser tools

A menudo se crean agentes por rol cuando lo que se necesita son herramientas especializadas. Un agente único con acceso a una herramienta de ejecución de código (sandbox Python), a DB queries parametrizadas y a validadores Zod/JSON Schema resuelve mejor que cinco agentes que no comparten capacidades. Usa Zod para tipos estrictos y pgvector para retrieval cuando necesites seleccionar herramientas por semántica.

Criterios concretos previos al diseño (decide antes de codificar)

Aplica estas tres pruebas rápidas:

1. Conflicto de system prompts

¿Los prompts necesarios entran en conflicto (alta creatividad vs. máxima precisión)? Si sí, separa agentes u orquesta. Si no, usa uno solo.

2. Determinismo del flujo

¿El paso B requiere que A sea validado con certeza? Si sí, la infraestructura debe controlar la transición (n8n, LangGraph). El LLM debe ejecutar acciones, no decidir el avance del workflow.

3. Coste del fallo

Calcula el impacto de un error en el tercer agente de la cadena (tokens perdidos, rollback requerido, datos corruptos). Si el coste excede el umbral tolerable, no uses coreografía.

Mide antes de decidir: precisión de selección de herramienta, retries por fallo, tokens gastados en reintentos. Define umbrales y automatiza tests de estrés que simulen handoffs y fallos.

Patrón recomendado de inicio

1. Un agente central con tools tipadas (schemas, enums).
2. Validación server-side estricta y Result pattern para errores, evitando throws incontenidos.
3. Retira herramientas del prompt con Dynamic Tool Retrieval (RAG) para reducir la entropía. Usa embeddings + búsqueda vectorial para inyectar solo las herramientas relevantes.

Escala a múltiples agentes solo cuando hayas demostrado que la solución simple falla por límite cognitivo del prompt y no por diseño.

La arquitectura correcta no es la más sofisticada, es la que puedes operar, auditar y reparar. En producción, predecible vence a impresionante.

FAQ

Gestión de contexto: la regla del 60% para sesiones en Claude Code

Tiempo estimado de lectura: 5 min

• Regla operativa: nunca dejes que una sesión consuma más del 60% de la ventana de contexto sin persistir el estado y limpiar la memoria.
• Patrón de trabajo: dividir tareas en Research → Plan → Implement → Validate, con artefactos en disco y limpieza de contexto entre fases.
• Artefactos clave: /CLAUDE.md, /RESEARCH.md, /PLAN.md, /TASK_STATE.md, /VALIDATION_REPORT.md y commits atómicos por módulo.
• Señales y métricas: observar contradicciones, repeticiones de contexto y fallos por “olvidos”; medir % de tareas con rework y tiempo de retoma.

Introducción

La frase “gestión de contexto: la regla del 60%” no es un eslogan. Es la regla operativa que evita que sesiones largas con agentes como Claude Code produzcan código coherente hoy y deuda técnica mañana. Si trabajas con LLMs en ingeniería, aplica esto desde el primer día: nunca dejes que una sesión consuma más del 60% de la ventana de contexto sin persistir el estado y limpiar la memoria.

Resumen rápido (lectores con prisa)

La regla del 60% limita cuánto de la ventana de contexto puede usar una sesión antes de persistir el estado. Úsala para fragmentar trabajo en sesiones controladas y guardar artefactos versionados (archivos en el repo). Aplica especialmente con agentes que leen/escriben repositorios como Claude Code.

Qué significa “Gestión de contexto: la regla del 60%” y por qué importa

Los modelos de lenguaje tienen una ventana finita de tokens. Cuando esa ventana se aproxima a su límite —y en la práctica cuando supera el 60%— el modelo comienza a priorizar lo más reciente. Eso no produce errores ruidosos: produce decisiones de diseño que olvidan criterios definidos al inicio, bugs detectados temprano y validaciones que ya no se tienen en cuenta.

La regla del 60% obliga a fragmentar el trabajo en sesiones controladas y a externalizar el estado en artefactos versionados (archivos en el repo). Con Claude Code esto es práctico y repetible porque el agente puede leer/escribir el repositorio: https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview y https://www.anthropic.com/claude.

El patrón operativo: 4 fases limpias por sesión

Divide cualquier tarea compleja en cuatro fases: Research → Plan → Implement → Validate. Cada fase debe terminar con un artefacto en disco y una limpieza explícita del contexto antes de pasar a la siguiente.

1) Research — auditoría

– Objetivo: mapear dependencias, puntos de dolor y deuda técnica sin cambiar nada.

– Salida: RESEARCH.md con módulos auditados, preguntas abiertas y riesgos priorizados.

– Acción: cerrar sesión. No cargar más archivos que los estrictamente necesarios.

2) Plan — diseño acotado

– Objetivo: con RESEARCH.md + CLAUDE.md (contrato del proyecto) definir módulos, orden y criterios de aceptación.

– Salida: PLAN.md con tareas atómicas y criterios verificables.

– Acción: validar el plan con un humano; cerrar sesión.

3) Implement — sesiones por módulo

– Objetivo: una sesión por módulo. Cargar solo PLAN.md, CLAUDE.md y archivos del módulo.

– Salida por módulo: commit atómico + actualización de TASK_STATE.md (estado por módulo) y tests unitarios.

– Acción: limpiar contexto entre módulos (reiniciar sesión o instanciar subagente nuevo).

4) Validate — verificación objetiva

– Objetivo: sesión en blanco que lea PLAN.md y ejecute validaciones (tests unitarios, integración, contratos).

– Salida: VALIDATION_REPORT.md con pass/fail y pasos de corrección.

– Acción: abrir PR / merge si pasa; en caso contrario, agregar tareas correctivas al plan y repetir ciclo.

Ejemplo práctico (prompt y artefactos)

Estructura de archivos mínima:

/CLAUDE.md
/RESEARCH.md
/PLAN.md
/TASK_STATE.md
/VALIDATION_REPORT.md
/tasks/auth-migration.md

Prompt de recuperación inicial (Research → Plan):

Lee /RESEARCH.md y /CLAUDE.md. Propón un PLAN.md que divida la migración de Auth en módulos atómicos,
cada uno con criterios de aceptación y tests mínimos. No implementes código.
Guarda PLAN.md y termina la sesión.

Prompt para Implement (módulo user-service):

Lee PLAN.md y CLAUDE.md. Trabaja únicamente en src/services/user-service.* según el criterio de la tarea "UserService".
Agrega tests unitarios que validen los criterios. Actualiza TASK_STATE.md antes de hacer commit.
No toques otros módulos.

Regla inquebrantable: actualizar TASK_STATE.md y hacer commit antes de terminar la sesión.

Señales de que estás cruzando el 60% (y qué hacer)

– Necesitas repetir contextos largos en prompts para que el agente recuerde una regla inicial.

– El agente empieza a contradecir decisiones anteriores sin justificación.

– Validaciones fallan por “olvidos” de requisitos que estaban en el RESEARCH.md.

Si ves cualquiera de estas señales: persiste el estado en disco, cierra la sesión y reinicia con el artefacto correspondiente.

Ventajas prácticas y métricas que importan

Aplicar la regla del 60% reduce ruido y mejora trazabilidad:

• Menos reverts por decisiones olvidadas.
• Mayor porcentaje de tasks que pasan CI en el primer commit.
• Tiempo de retoma por sesión < 5 minutos (leer artefacto) en vez de re-auditar todo.

Mide: % de tareas con rework, número de bugs registrados en TASK_STATE.md, tiempo desde apertura de sesión hasta reanudación efectiva.

Límites y advertencias

Esto no sustituye especificaciones claras ni revisiones humanas. Si la planifica es ambigua, la IA persistirá ambigüedades más rápido. El patrón reduce riesgos operativos, no el riesgo conceptual de malas decisiones de diseño. Además, no necesitas este overhead para fixes rápidos o scripts aislados: aplica la regla cuando el alcance y la duración lo justifiquen.

La regla del 60% es una disciplina: no es bonita, pero evita que la IA genere parches brillantes que fallan en integración. Si automatizas en serio, diseña tu flujo con RESEARCH.md, PLAN.md, TASK_STATE.md y VALIDATION_REPORT.md, obliga a commits atómicos y reinicia sesiones a tiempo. Con eso, la memoria del modelo deja de ser un talón de Aquiles y se convierte en parte auditable de tu pipeline.

Continuación práctica y recursos: Dominicode Labs

FAQ