Hay un salto cualitativo entre usar un modelo de IA para responder una pregunta y construir un sistema donde múltiples modelos colaboran para completar trabajo complejo.
El primer caso es herramienta. El segundo es organización.
En esta entrada te explico cómo funciona ese segundo caso: qué es un agente de IA en sentido técnico, cómo se coordinan múltiples agentes, qué herramientas existen para construir esos sistemas, y cómo está diseñada concretamente la organización de Deviam con sus 19 agentes operativos.
Qué es un agente de IA: definición técnica
En la entrada sobre tipos de arquitecturas mencioné los LAMs — agentes de acción. Aquí voy más al fondo.
Un agente de IA es un sistema que percibe su entorno, toma decisiones, y ejecuta acciones para alcanzar un objetivo, con capacidad de adaptar esas decisiones según el resultado de las acciones anteriores.
La diferencia con un LLM respondiendo preguntas:
- Un LLM recibe input, genera output. Una vez.
- Un agente recibe un objetivo, decide qué pasos dar, ejecuta el primer paso, observa el resultado, decide el siguiente paso, y continúa hasta completar el objetivo o encontrar un obstáculo que requiere intervención humana.
El agente tiene herramientas (tools): funciones que puede llamar para hacer cosas en el mundo. Buscar en internet. Leer un archivo. Escribir código. Ejecutar código. Enviar un email. Llamar a una API externa. Guardar información en una base de datos.
El LLM es el "cerebro" que decide qué herramientas usar y en qué orden. Las herramientas son los "brazos" que actúan.
El problema de escala: por qué un agente solo no es suficiente
Un agente bien diseñado puede manejar tareas de complejidad media de forma autónoma. Pero hay tareas que superan lo que un solo agente puede hacer bien:
Longitud: una tarea que requiere 50 pasos de razonamiento secuencial acumula errores. Cada paso tiene una probabilidad pequeña de error; a 50 pasos, los errores se componen.
Especialización: un agente generalista que hace investigación, escribe código, revisa código, diseña interfaces, y gestiona marketing lo hace todo con calidad media. Un agente especializado en cada área lo hace con calidad alta.
Paralelización: algunas tareas tienen partes independientes que se pueden ejecutar en paralelo. Un solo agente las haría en secuencia. Varios agentes las pueden hacer simultáneamente.
La solución a los tres problemas es la misma: dividir el trabajo entre agentes especializados coordinados por un sistema que gestiona el flujo.
Esto es lo mismo que resuelve una organización humana bien diseñada. No es metáfora — es el mismo principio de división del trabajo y coordinación.
El ADK de Anthropic: el framework de construcción
En 2026, Anthropic publicó el ADK (Agent Development Kit, conjunto de herramientas para desarrollar agentes) — el framework oficial para construir sistemas multi-agente con Claude.
La documentación está en code.claude.com/docs (Tier 1, fuente oficial Anthropic). El ADK define cinco capas que componen un sistema de agentes bien estructurado:
Capa 1: Identidad (CLAUDE.md e instrucciones persistentes). Cada agente tiene un documento que define quién es, cuál es su rol, qué puede hacer, qué no puede hacer, y cómo se relaciona con el resto del sistema. Esta identidad se carga al inicio de cada sesión y establece el contexto permanente del agente.
Capa 2: Conocimiento (.claude/rules/). Reglas globales que aplican a todos los agentes del sistema — estándares de código, restricciones de seguridad, convenciones de documentación. No son instrucciones que el agente sigue para completar tareas; son las restricciones dentro de las cuales opera cualquier tarea.
Capa 3: Habilidades (.claude/skills/). Playbooks activables bajo demanda — secuencias de pasos para completar tipos específicos de trabajo. Un agente constructor tiene habilidades para configurar bases de datos, escribir tests, desplegar código. Un agente de marketing tiene habilidades para redactar copys, analizar métricas, diseñar carruseles.
Capa 4: Automatizaciones (.claude/hooks/). Gates deterministas que se ejecutan en puntos específicos del flujo — antes de guardar un archivo, después de completar una tarea, al inicio de una sesión. Son comprobaciones que no usan IA; son scripts que verifican condiciones de forma predecible.
Capa 5: Delegación (.claude/agents/). Los charters individuales de cada agente — su definición completa, incluyendo qué modelo usa, qué herramientas tiene disponibles, a quién reporta, y con quién colabora.
Patrones de orquestación: cómo coordinan los agentes
Hay tres patrones principales para que múltiples agentes trabajen juntos:
Agente líder — agentes especialistas. Un agente principal (L0 o L1 en la nomenclatura de Deviam) recibe el objetivo, lo descompone en subtareas, delega cada subtarea a un agente especialista, recibe los resultados, y sintetiza la respuesta final. El agente líder es el "pegamento" que mantiene la coherencia del sistema.
Agentes en pipeline secuencial. El output de un agente es el input del siguiente. El agente de investigación produce un análisis; el agente de redacción convierte ese análisis en contenido; el agente de revisión verifica la calidad del contenido. Cada uno recibe el trabajo previo y añade su capa.
Agentes en paralelo con síntesis. Varios agentes atacan el mismo problema desde ángulos distintos simultáneamente. El agente legal revisa el contrato desde el ángulo de cumplimiento; el agente financiero desde el ángulo de riesgo económico; el agente técnico desde el ángulo de implementación. Un agente coordinador sintetiza las tres perspectivas.
En la práctica, sistemas complejos combinan los tres patrones según el tipo de trabajo.
Un paper académico relevante que formaliza estos patrones es Scaling LLM Test-Time Compute with Best-of-N Sampling y el trabajo de los laboratorios sobre multi-agent frameworks. Para el trabajo concreto con Claude, la referencia más actualizada y directa es la documentación oficial del ADK en code.claude.com/docs.
También hay investigación académica emergente sobre orquestación multi-agente: AgentBench: Evaluating LLMs as Agents (Liu et al., 2023) y AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Wu et al., Microsoft Research, 2023, arxiv: 2308.08155) son referencias útiles para entender el estado del campo.
HITL: dónde entra el humano
Un sistema multi-agente completamente autónomo es eficiente pero arriesgado. Los errores de los agentes se pueden propagar y amplificar. Algunas decisiones tienen consecuencias que son difíciles o imposibles de revertir.
HITL (Human in the Loop, humano en el bucle) es el principio de diseño que define explícitamente en qué puntos del flujo se requiere intervención humana antes de continuar.
En Deviam, hay una jerarquía clara de qué puede ejecutarse de forma autónoma y qué requiere mi firma:
Autónomo: análisis, investigación, redacción de borradores, generación de código, documentación, coordinación entre agentes.
Requiere firma: cualquier gasto real, cambios de arquitectura mayores, despliegue a producción, modificaciones de las reglas base del sistema, decisiones que no tienen marcha atrás fácil.
La razón no es desconfianza en los agentes. Es reconocer honestamente que los LLMs pueden equivocarse de formas sutiles, y que algunas clases de errores son demasiado costosas como para descubrirlas después del hecho.
El HITL no es un parche sobre un sistema defectuoso. Es un principio de diseño que distingue sistemas que escalan con seguridad de sistemas que son rápidos pero frágiles.
La Junta Deviam: 19 agentes con roles explícitos
Deviam tiene 19 agentes operativos organizados en cuatro niveles jerárquicos:
L0 — Orquestador maestro (1 agente). El director general del sistema. Su rol es coordinar las tres agencias operativas, tomar decisiones estratégicas, y ser el punto de contacto con Alejandro. No construye producto ni ejecuta trabajo técnico. Orquesta.
L1 — Junta Directiva (5 agentes). Cinco directivas especializadas: investigación (Minerva), diseño organizacional (Demiurgo), legal y gobernanza (Iustus), impacto financiero (Solón), y estrategia de marketing (Mercado). Cada una es experta en su dominio y participa en decisiones que afectan a toda la organización.
L2 — Líderes de agencia (3 agentes). Los directores operativos de cada agencia: software (Athena), diseño (Aracne), y marketing (Heraldo). Traducen la dirección estratégica en trabajo concreto y coordinan a los especialistas de su equipo.
L3 — Especialistas (7 agentes). Los ejecutores del trabajo real: construcción de software (Ares), control de calidad (Vulcano), infraestructura (Hermex), identidad visual (Pigmalión), calidad de diseño (Themis), creación de contenido (Calíope, que es quien escribe esto), y análisis de crecimiento (Eos).
Infraestructura (3 agentes). Tres agentes que operan transversalmente: guardián de contexto (Kronos), seguridad (Sentinel), y documentación (doc-assistant). No pertenecen a ninguna agencia específica; sirven al sistema completo.
Por qué 19 agentes y no un agente muy potente
Esta es la pregunta que más recibo cuando explico cómo funciona Deviam.
La respuesta tiene tres partes.
Primera: la especialización produce mejor calidad. Un agente cuya identidad, reglas, y habilidades están definidas para revisar código de seguridad va a hacer esa tarea mejor que un agente generalista que también tiene que hacer marketing, diseño, y coordinación. El contexto del system prompt importa mucho para la calidad del output.
Segunda: la organización crea accountability (responsabilidad rastreable). Cuando hay un problema en el sistema, sé exactamente qué agente lo causó, qué herramientas usó, y qué instrucciones recibió. En un sistema monolítico, ese tipo de trazabilidad es mucho más difícil.
Tercera: la escala horizontal es más fácil que la escala vertical. Si necesito más capacidad de análisis de datos, añado o potencio el agente de análisis. Si el resto del sistema funciona bien, no toco nada más. En un sistema de un agente único, cualquier mejora potencialmente afecta todo.
La contrapartida es la complejidad de coordinación. Necesitas diseñar cuidadosamente los protocolos de comunicación entre agentes, los formatos de handoff (transferencia de trabajo de un agente a otro), y los criterios de escalación cuando algo sale mal.
Cómo fluye el trabajo en la práctica
Un ejemplo concreto: escribir y publicar una entrada de la biblioteca de alejoxtd.com.
-
Alejandro define el tema y los objetivos de la entrada.
-
Minerva (L1, investigación) recopila las fuentes relevantes, verifica que sean Tier 1 o Tier 2, y produce un documento de investigación con hechos verificados.
-
Athena (L2, software) revisa que el schema de Velite esté correcto para el nuevo tipo de contenido.
-
Calíope (L3, contenido) escribe la entrada usando las fuentes de Minerva, siguiendo las reglas de voz de Deviam, con los principios de Appendix J, y sin tecnicismos no aclarados.
-
Vulcano (L3, QA) verifica que el frontmatter cumple el schema, que las fuentes están citadas, y que el contenido pasa los filtros de calidad.
-
Alejandro firma antes de publicar. Nadie publica nada sin esa firma.
-
Hermex (L3, infraestructura) despliega.
Cada paso tiene un agente responsable. Cada agente tiene reglas claras sobre lo que puede y no puede hacer. El humano entra donde importa.
Los charters: el documento que define cada agente
Cada uno de los 19 agentes tiene un charter (carta constitutiva, documento que define el agente en profundidad). El charter incluye:
- Quién es el agente y cuál es su rol
- A quién reporta y con quién colabora
- Qué herramientas tiene disponibles
- Qué habilidades own y cuáles usa en modo secundario
- Qué puede decidir solo y qué requiere escalar
- Qué sesgos estructurales tiene por diseño y cómo los mitiga
Este último punto es especialmente importante y poco intuitivo. Un agente constructor tiene incentivo estructural a recomendar más construcción (porque eso preserva su rol). Un agente de marketing tiene incentivo a proponer más campañas. Si no declaras esos sesgos explícitamente y defines cómo el agente los mitiga, el sistema tenderá a sobreproducir en las áreas donde los agentes tienen interés creado.
La solución no es eliminar los sesgos — son inherentes a la especialización. La solución es hacerlos visibles en el diseño.
Lo que falta: lo que los agentes no hacen bien todavía
Termino con honestidad sobre los límites del estado actual.
Los agentes no tienen memoria persistente robusta entre sesiones. Cada sesión empieza relativamente desde cero con solo lo que carga del system prompt y los documentos. La memoria de largo plazo es una área de investigación activa, pero las soluciones actuales son workarounds, no soluciones definitivas.
La coordinación se degrada en tareas muy largas. A medida que una tarea requiere más pasos, la coherencia del sistema puede deteriorarse. Los mejores sistemas multi-agente actuales funcionan bien en tareas que se pueden completar en horas; tareas de días o semanas requieren puntos de checkpoint (verificación intermedia) frecuentes con intervención humana.
La calibración de cuándo escalar es difícil. Un agente necesita saber cuándo puede decidir solo y cuándo debe consultar a su coordinador. Los criterios explícitos ayudan, pero los casos edge (casos límite que no encajan bien en ninguna categoría) siguen siendo difíciles de manejar automáticamente.
Estos no son razones para no construir con agentes — son razones para diseñar con ojos abiertos sobre sus límites actuales.
El cierre de la serie
Esta ha sido la ruta de las cinco entradas:
- Todo empieza en 0 y 1. Los sistemas se construyen apilando capas de abstracción.
- El software clásico sigue reglas escritas. Los LLMs aprenden patrones de datos. Son cosas distintas con límites distintos.
- Claude es un LLM entrenado con Constitutional AI. Tiene una familia de modelos con diferentes equilibrios de capacidad y coste.
- Existen ocho familias de arquitecturas de IA. Cada una resuelve un tipo diferente de problema. Se combinan en sistemas reales.
- Los agentes son LLMs conectados a herramientas y coordinados con protocolos explícitos. Un sistema de 19 agentes especializados es cualitativamente diferente de un agente único.
Lo que no he hecho en ninguna de estas entradas es decirte que la IA lo resuelve todo o que los sistemas que construyo funcionan solos. No es así. Son herramientas potentes con límites reales, que requieren diseño cuidadoso, supervisión humana, y honestidad sobre qué funciona y qué no.
Lo que sí puedo decirte es que entender estos fundamentos te da una base para tomar decisiones informadas: cuándo usar IA, para qué, con qué precauciones, y con qué expectativas realistas.
Ese es el objetivo de esta biblioteca.
Fuentes
- Anthropic ADK documentation — code.claude.com/docs (Tier 1, documentación oficial del framework).
- Bai et al., Constitutional AI (2022) — arxiv: 2212.08073.
- Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Microsoft Research, 2023) — arxiv: 2308.08155.
- Anthropic Engineering, How we built our multi-agent research system (2025) — Anthropic blog (Tier 2, staff engineering post).
- Boris Cherny, Agent Development Kit: 5-layer canonical framework (2025) — Anthropic Staff Engineer (Tier 2, comunidad técnica).
- Guo et al., Large Language Model based Multi-Agents (2024) — arxiv: 2402.01680. Survey del estado del arte en sistemas multi-agente.
Primera entrada de la serie: Entender los sistemas: por qué todo empieza en 0 y 1