Cómo diseñar agentes con Claude Code sin quemar el contexto

Para automatizar tareas complejas con Claude Code, la regla práctica es simple: usa subagentes cuando necesites aislar una subtarea del contexto principal, recurre a Agent Teams cuando varias instancias deban colaborar en paralelo sobre el mismo objetivo, y elige el Agent SDK cuando necesites incrustar el bucle agéntico dentro de tu propia aplicación. Estos tres patrones cubren la mayoría de los casos que verás al construir agentes con Claude Code, y elegir mal entre ellos es la causa número uno de facturas de tokens fuera de control.

El checklist mínimo para poner en marcha tu primer agente es corto: define un CLAUDE.md con el contexto del proyecto, restringe allowed_tools a lo estrictamente necesario, fija un maxTurns conservador y prueba con una tarea acotada antes de delegar nada a subagentes.

• Subagentes: subtareas que devuelven un resumen, no todo el proceso.
• Agent Teams: colaboración paralela con lista de tareas compartida (experimental, requiere activación explícita).
• Agent SDK: control programático del bucle completo desde TypeScript o Python.

Consejo profesional: Antes de escalar a un equipo de agentes, comprueba si un solo subagente con buenas herramientas resuelve el problema. El coste en tokens de duplicar instancias suele superar el beneficio de la paralelización.

Los dos riesgos que hay que vigilar desde el primer día son la inundación del contexto (pasar demasiada información innecesaria al agente principal) y los permisos mal configurados, que pueden dejar que una herramienta como Bash ejecute algo que no querías autorizar.

Puntos clave

Diseñar agentes con Claude Code que funcionen en producción depende de aislar el contexto con subagentes, fijar límites de turnos y herramientas desde el inicio, y escalar a equipos solo cuando el paralelismo compense el coste en tokens.

Punto	Detalles
Elige el patrón por contexto compartido	Usa subagentes para tareas que generan ruido intermedio, equipos para trabajo paralelo genuinamente independiente.
Controla los turnos desde el prototipo	Fija maxTurns conservador y revisa el ResultMessage para calibrar límites reales, no estimados.
Restringe herramientas de forma gradual	Empieza con Read, Grep y Glob, y amplía solo cuando la tarea lo justifique.
Los equipos de agentes son experimentales	Requieren activar una flag de entorno y su coordinación tiene límites conocidos que hay que evaluar antes de producción.
Coordina flujos recurrentes con agent-swarm	agent-swarm.dev delega desde un agente líder hacia trabajadores especializados con memoria compartida entre sesiones.

Tabla de contenidos

• Subagentes, equipos de agentes y Agent SDK: qué patrón usar
• Cómo funciona el bucle agéntico y qué implica para tu diseño
• Qué herramientas exponer y cómo controlar los permisos
• Primeros pasos para crear tu primer agente con Claude Code
• Cuándo delegar trabajo a subagentes o equipos de agentes
• Controles de seguridad, coste y monitoreo antes de producción
• Ejemplos reales de agentes con Claude Code en producción
• Errores comunes y cómo depurarlos rápido
• Lo que la práctica enseña que la documentación no dice del todo
• agent-swarm.dev: coordinar agentes sin montar la infraestructura desde cero
• Fuentes
• Preguntas frecuentes

Subagentes, equipos de agentes y Agent SDK: qué patrón usar

El ecosistema de Claude Code ofrece tres formas de paralelizar y estructurar el trabajo agéntico, y cada una se adapta a una necesidad distinta de aislamiento y coordinación. Elegir entre ellas depende de cuánta información necesita compartirse y de cuánto control quieres mantener sobre lo que hace cada pieza.

Los subagentes se ejecutan en su propia ventana de contexto y devuelven solo un resumen al agente principal, lo que los convierte en la forma recomendada de aislar subtareas que, de otro modo, inflarían el historial de conversación. Piensa en un subagente como un becario al que le encargas investigar un tema concreto: vuelve con un informe de una página, no con las cien pestañas del navegador abiertas.

Los equipos de agentes (Agent Teams) permiten coordinar múltiples instancias mediante una lista de tareas compartida y mensajería directa entre compañeros, pero están deshabilitados por defecto y deben activarse con una flag experimental. Son útiles cuando el trabajo se beneficia genuinamente de varias perspectivas trabajando a la vez, como una auditoría de código sobre un repositorio grande dividido por módulos.

El Agent SDK incrusta el bucle agéntico completo en tu propia aplicación TypeScript o Python, dándote control directo sobre herramientas, permisos y límites de ejecución. Es la opción cuando necesitas que el agente forme parte de un producto propio, no una sesión interactiva puntual.

La diferencia de coste entre estos enfoques no es trivial. Los subagentes ahorran contexto porque colapsan su trabajo en un resumen; los equipos de agentes, en cambio, multiplican instancias y, con ellas, el consumo de tokens. Antes de activar un equipo de tres o cuatro agentes en paralelo, vale la pena preguntarse si el problema realmente necesita esa concurrencia o si es un subagente disfrazado de proyecto ambicioso.

• Investigación aislada o refactorización acotada → subagente.
• Auditoría masiva sobre múltiples módulos o revisión de PR con distintos enfoques → agent team.
• Producto propio que necesita orquestar Claude Code programáticamente → Agent SDK.

Ninguno de los tres es superior en abstracto. La pregunta correcta no es «¿cuál es mejor?» sino «¿cuánto contexto compartido necesita realmente esta tarea?».

Cómo funciona el bucle agéntico y qué implica para tu diseño

Cada sesión de Claude Code sigue el mismo ciclo interno, y entenderlo es la diferencia entre depurar un agente con criterio o a base de prueba y error. El proceso es el siguiente:

1. El agente recibe un prompt (la instrucción inicial o la respuesta de una herramienta anterior).
2. Evalúa qué hacer: responder directamente o invocar una herramienta.
3. Si decide usar una herramienta, genera una llamada (tool call) con sus parámetros.
4. El sistema ejecuta esa herramienta y devuelve el resultado al agente.
5. El ciclo se repite hasta que Claude produce una respuesta sin más llamadas a herramientas.
6. En ese momento se entrega el resultado final de la sesión.

Cada vuelta completa de este ciclo se llama un turno, y los turnos siguen acumulándose mientras el agente decida que necesita más información antes de responder.

Durante ese proceso circulan varios tipos de mensajes que conviene distinguir al depurar una sesión. El SystemMessage de inicialización marca el arranque y contiene metadatos de configuración. Los AssistantMessage representan cada intervención del modelo, incluidas las llamadas a herramientas. El ResultMessage final resume el coste, la duración y el resultado de toda la sesión. Si has trabajado con logs de sistemas distribuidos, la analogía es directa: son trazas que te dicen exactamente dónde se fue el tiempo y el dinero.

La implicación práctica más importante es que el número de turnos no es gratis. Cada vuelta del bucle consume tokens de entrada (todo el historial acumulado) y de salida (la respuesta y las llamadas a herramientas). Un agente sin límite de turnos que entra en un ciclo de reintentos fallidos puede agotar un presupuesto de tokens en minutos sin producir nada útil.

Por eso el parámetro maxTurns no es un detalle de configuración menor, sino una de las primeras decisiones de diseño. Fijarlo demasiado bajo corta tareas legítimas a mitad de camino; fijarlo demasiado alto convierte un error de lógica en una factura sorpresa.

Consejo profesional: Registra el ResultMessage de cada sesión desde el primer prototipo, incluso en pruebas locales. Ver cuántos turnos consumió una tarea sencilla te da una línea base real para calibrar maxTurns en producción, en lugar de adivinar un número.

Qué herramientas exponer y cómo controlar los permisos

El bucle agéntico solo es tan seguro como las herramientas que le permites usar. Claude Code incluye herramientas integradas de archivo (Read, Edit, Glob), de ejecución (Bash), y de búsqueda web (WebSearch), además de la posibilidad de definir herramientas personalizadas y servidores MCP que corren dentro del mismo proceso.

• Read y Glob: exploración de archivos y búsqueda de patrones, de bajo riesgo.
• Edit: modificación de código, requiere revisión antes de aplicarse en producción.
• Bash: ejecución de comandos del sistema, la herramienta con la mayor superficie de riesgo.
• WebSearch: acceso a información externa, útil para investigación pero difícil de auditar sin logging.
• Servidores MCP personalizados: conectan el agente con servicios propios (bases de datos, APIs internas, paneles de control).

MCP (Model Context Protocol) es el mecanismo estándar para exponer capacidades externas a un agente sin escribir integraciones ad hoc para cada servicio. En lugar de codificar a mano cómo Claude debe hablar con tu base de datos Turso o con Linear, defines un servidor MCP que expone esas operaciones como herramientas normales dentro del bucle agéntico. El propio Agent SDK permite crear estos servidores in-process con funciones como createSdkMcpServer(), evitando el sobrecoste de levantar procesos separados para cada integración.

La estrategia de permisos más sensata combina tres capas. Primero, allowed_tools limita qué puede invocar el agente en absoluto, dejando fuera cualquier herramienta que no necesite para su tarea específica. Segundo, las aprobaciones (approvals) obligan a una confirmación humana o automatizada antes de ejecutar acciones sensibles, como escribir en un repositorio de producción. Tercero, los hooks interceptan llamadas antes o después de su ejecución para auditar, transformar o bloquear comportamientos inesperados.

Consejo profesional: Empieza con Read, Grep y Glob únicamente, incluso si sabes que necesitarás más. La práctica recomendada en la documentación oficial es ampliar herramientas de forma gradual: verás mucho antes si el agente entra en bucles de llamadas innecesarias cuando el catálogo de herramientas es pequeño.

Un error habitual en equipos que llegan de la programación tradicional es tratar allowed_tools como una lista de conveniencia en lugar de un control de seguridad real. Cada herramienta que añades amplía lo que el agente puede hacer sin supervisión directa, así que la pregunta antes de habilitar cualquier herramienta nueva debería ser «¿qué es lo peor que puede pasar si el agente usa esto mal?», no «¿podría necesitarlo?».

Primeros pasos para crear tu primer agente con Claude Code

Poner en marcha un agente funcional no requiere una arquitectura elaborada. Requiere disciplina en tres cosas: autenticación, estructura del proyecto y límites de ejecución desde el primer prototipo.

1. Instalación y autenticación. Instala el CLI de Claude Code o el paquete del Agent SDK correspondiente a tu lenguaje (TypeScript o Python), y autentica con tu clave de API. Si vas a integrar el bucle agéntico dentro de una aplicación existente, el SDK es la vía directa; si vas a trabajar de forma interactiva en un repositorio, el CLI es suficiente para empezar.

2. Estructura mínima del proyecto. Un proyecto bien configurado tiene tres piezas:

• Un archivo CLAUDE.md en la raíz con el contexto del proyecto: convenciones de código, estructura de carpetas, y qué NO debe tocar el agente.
• Una carpeta .claude/skills con instrucciones reutilizables para tareas recurrentes (por ejemplo, cómo ejecutar los tests o cómo generar un changelog).
• Una configuración explícita de allowed_tools que arranque restrictiva y se amplíe según necesidad real.

3. Configura los límites antes de ejecutar nada. Define maxTurns en un valor conservador (entre 10 y 20 para tareas de tamaño medio suele ser un buen punto de partida), especifica el modelo que quieres usar, y confirma que allowedTools refleja exactamente lo que la tarea necesita, ni más ni menos.

4. Ejecuta una tarea acotada como prueba. No empieces con «refactoriza todo el módulo de autenticación». Empieza con «lee estos tres archivos y explica cómo se relacionan». Una tarea pequeña te permite observar el número de turnos, las herramientas invocadas y el ResultMessage final sin arriesgar nada.

5. Itera sobre el resultado, no sobre la intuición. Revisa el log de la sesión: ¿cuántos turnos consumió? ¿Llamó a herramientas que no esperabas? ¿El resumen final refleja bien lo que pasó?

Una vez que este ciclo básico funciona de forma predecible, recién entonces tiene sentido preguntarse si la tarea se beneficiaría de delegarse a un subagente o de dividirse entre varios miembros de un equipo de agentes.

• Verifica que el agente respeta allowed_tools incluso cuando el prompt lo tienta a salirse del guion.
• Comprueba que el ResultMessage incluye coste y duración, y guarda ese dato como referencia.
• Prueba el mismo flujo dos o tres veces: la variabilidad en el número de turnos te dice cuánto margen dejar en producción.

Cuándo delegar trabajo a subagentes o equipos de agentes

Escalar de un agente único a un sistema con subagentes o equipos completos es una decisión de arquitectura, no un ajuste de configuración. El criterio central es este: si la subtarea produce mucho ruido intermedio (logs largos, archivos completos, resultados de búsqueda extensos) que el agente principal no necesita ver en detalle, es candidata a subagente. Si el ruido es manejable pero el trabajo se beneficia de ejecutarse en paralelo sobre partes independientes del mismo problema, es candidato a equipo.

• Delega a un subagente cuando la tarea requiere leer muchos archivos para producir una conclusión corta (auditoría de dependencias, resumen de un módulo legacy).
• Delega a un equipo de agentes cuando varias partes del problema son independientes entre sí pero deben terminar coordinadas (revisar cuatro microservicios distintos antes de un despliegue conjunto).
• Mantén todo en un solo agente cuando la tarea es lineal y el contexto necesario cabe cómodamente en una sesión normal.

El patrón de delegación más eficiente sigue una estructura de encargo y recolección: el agente principal (o líder) define el objetivo, lo divide en subtareas concretas, las asigna a subagentes o miembros del equipo, y espera los resúmenes antes de sintetizar una respuesta conjunta. Este patrón es exactamente el que sostiene Agent-swarm, donde un agente líder delega a trabajadores especializados y compone el resultado final con memoria compartida entre ejecuciones.

El tamaño del equipo importa más de lo que parece. Un equipo de dos o tres agentes suele coordinarse bien con una lista de tareas compartida; a partir de cuatro o cinco, la comunicación entre compañeros empieza a generar overhead que compite con el trabajo real. Como referencia práctica: Agent Teams reproduce el trade off clásico entre un agente único y un equipo permanente, y ese trade off se paga en tokens de coordinación, no solo en tokens de trabajo.

Antes de escalar, calcula el coste esperado con una regla simple: multiplica el coste estimado de una tarea individual por el número de agentes que planeas activar en paralelo, y compáralo con el coste de resolverlo de forma secuencial con subagentes. Si la diferencia no se traduce en un ahorro real de tiempo, la paralelización probablemente no compensa. La comparación entre una flota de agentes y un enjambre coordinado ilustra bien esta tensión: más agentes no siempre significa más rendimiento, a veces solo significa más factura.

Controles de seguridad, coste y monitoreo antes de producción

Llevar un agente de prototipo a producción exige una checklist de controles que no son opcionales, por mucho que el prototipo haya funcionado bien en pruebas locales.

• Límite de herramientas permitidas. Revisa allowed_tools con la misma seriedad con la que revisarías permisos de una cuenta de servicio: cada herramienta habilitada es una superficie de ataque o de error.
• Límite de turnos por sesión. Un maxTurns explícito evita que un fallo de lógica se convierta en un bucle costoso que agota presupuesto sin producir valor.
• Presupuesto de tokens por tarea o por equipo. Define un tope razonable y una alerta cuando una sesión se acerque a él, en lugar de descubrirlo en la factura mensual.
• Hooks de auditoría. Intercepta llamadas a herramientas sensibles (especialmente Bash y cualquier escritura a sistemas externos) para registrar qué se ejecutó y por qué.

Definir estos límites desde la primera iteración, y no como una capa añadida después de un incidente, es lo que separa un despliegue estable de uno que sorprende a tu equipo de finanzas.

El monitoreo en producción se sostiene en tres tipos de señales. Las métricas de coste y duración por sesión (extraídas del ResultMessage) te dicen si el comportamiento del agente se está desviando de la línea base. Los logs de sesión completos permiten reconstruir qué herramientas se llamaron y en qué orden, algo imprescindible cuando algo sale mal y necesitas explicar por qué. Las alertas automáticas sobre umbrales de turnos o de coste evitan que un problema pase inadvertido hasta el cierre del mes.

Consejo profesional: Configura una alerta que se dispare no solo por coste total, sino por coste por sesión anómalo. Un agente que de repente necesita el triple de turnos para la misma tarea suele indicar un cambio en los datos de entrada o una herramienta que empezó a fallar silenciosamente, no un problema de presupuesto.

Vale la pena revisar también los anti-patrones organizativos que los sistemas multi-agente tienden a reproducir antes de escalar: muchos de los problemas que aparecen en producción no son técnicos, sino estructurales, y ya se han documentado con suficiente detalle como para evitarlos por anticipado.

Ejemplos reales de agentes con Claude Code en producción

Los casos más útiles para aprender no son los tutoriales de ejemplo, sino sesiones reales donde el agente tuvo que enfrentarse a ambigüedad, archivos inesperados o herramientas que fallaron a mitad de camino. Tres patrones se repiten con suficiente frecuencia como para servir de plantilla.

• Revisión de código automatizada: un agente (o un pequeño equipo) revisa un pull request completo, verificando estilo, cobertura de tests y coherencia con la arquitectura existente, y deja comentarios estructurados en lugar de un veredicto binario.
• Auditoría masiva de un repositorio: varios subagentes exploran módulos distintos en paralelo y devuelven resúmenes de riesgos o deuda técnica, que el agente principal consolida en un informe único.
• Generación de briefs de investigación: un subagente navega documentación o código externo y produce un resumen ejecutivo, evitando que el agente principal tenga que procesar cientos de páginas de contexto irrelevante.

Un ejemplo reproducible bien documentado necesita tres elementos mínimos: un objetivo claro y acotado, la lista exacta de herramientas habilitadas para esa tarea, y una métrica de éxito verificable (no «funcionó bien», sino «redujo el tiempo de revisión de X a Y» o «identificó N problemas reales sin falsos positivos relevantes»).

Combinar skills reutilizables con subagentes para investigaciones aisladas y equipos de agentes para auditorías masivas es el patrón que más se repite en sesiones reales bien documentadas: cada pieza hace una cosa concreta y devuelve un resumen, no un volcado completo de su trabajo.

Este patrón aparece de forma consistente en las Agent-swarm, donde un agente líder delega tareas a trabajadores especializados y la memoria compartida entre ejecuciones reduce el trabajo repetido en flujos recurrentes. Un ejemplo concreto de esta lógica aplicada a ingeniería son los agentes de revisión de código listos para integración continua, donde el chequeo de un pull request se reparte entre varios agentes especializados en lugar de depender de un único revisor sobrecargado.

La lección práctica que se repite en todos estos casos es la misma: cuanto más específico el objetivo y más restringido el conjunto de herramientas, más predecible el comportamiento del agente. La ambición amplia («mejora la calidad del código») produce sesiones erráticas; el objetivo concreto («detecta funciones sin tests en este módulo») produce resultados verificables.

Errores comunes y cómo depurarlos rápido

La mayoría de los problemas con agentes en Claude Code se agrupan en tres categorías, y cada una tiene un procedimiento de diagnóstico bastante directo.

1. Inundación de contexto. Si el agente empieza a responder de forma imprecisa o a «olvidar» instrucciones tempranas, revisa cuánto contenido bruto (archivos completos, logs extensos, resultados de búsqueda sin filtrar) está entrando en el historial. La solución casi siempre es mover esa subtarea a un subagente que devuelva solo un resumen, en lugar de intentar comprimir el prompt principal.
2. Bucles infinitos o casi infinitos. Cuando una sesión consume turnos sin converger a una respuesta, revisa el ResultMessage de sesiones anteriores similares para ver cuántos turnos son normales. Si el agente repite la misma llamada a herramienta con variaciones mínimas, suele indicar que el resultado de esa herramienta no le está dando la información que espera, y hay que ajustar el prompt o la herramienta misma, no simplemente subir maxTurns.
3. Llamadas a herramientas fallidas. Comprueba primero que la herramienta está realmente en allowed_tools; una llamada bloqueada por permisos puede parecer un fallo funcional. Si el permiso es correcto, revisa el formato de los parámetros que el agente está generando: errores de esquema son la causa más común de fallos silenciosos.

Para reproducir y depurar cualquiera de estos casos, baja deliberadamente maxTurns a un número pequeño (cinco o menos) y ejecuta la tarea problemática de nuevo. Un límite bajo fuerza al agente a fallar rápido y te da un log corto y legible, en lugar de tener que revisar cuarenta turnos para encontrar el punto exacto donde algo se torció.

Si el problema persiste incluso con herramientas mínimas y un límite de turnos bajo, el problema casi nunca está en la configuración: está en la claridad del objetivo que le diste al agente en el CLAUDE.md o en el prompt inicial.

Lo que la práctica enseña que la documentación no dice del todo

El anti-patrón más frecuente en sistemas multi-agente no es técnico, es organizativo: equipos que reproducen su propia jerarquía disfuncional dentro del diseño de agentes, con un «agente jefe» que microgestiona a subagentes que podrían haber trabajado con total autonomía. Si tu equipo humano tiene problemas de comunicación, tu sistema de agentes probablemente los va a heredar sin que nadie lo diseñe así a propósito.

El balance entre autonomía y control humano no es un punto fijo, es una decisión por tarea. Dar demasiada autonomía a un agente que toca infraestructura de producción es negligencia; exigir aprobación humana para cada línea que lee un subagente de investigación es desperdiciar la herramienta. La pregunta útil no es «¿cuánto control quiero?» sino «¿qué pasa si esto falla sin que nadie lo note a tiempo?».

Integrar agentes en un pipeline de ingeniería sin acumular deuda técnica exige tratar cada CLAUDE.md, cada configuración de herramientas y cada hook como código versionado, revisado y probado, no como configuración ad hoc que alguien ajustó una tarde para que funcionara.

agent-swarm.dev: coordinar agentes sin montar la infraestructura desde cero

Todo lo anterior (subagentes, equipos, hooks, límites de coste) es la capa técnica que necesitas dominar para crear agentes con Claude Code. Pero cuando el objetivo no es un agente aislado sino coordinar decenas de flujos recurrentes entre varios equipos (ingeniería, soporte, operaciones), montar esa orquestación desde cero implica construir tú mismo lo que agent-swarm.dev ya resuelve: memoria compartida entre ejecuciones, delegación desde un agente líder hacia trabajadores especializados, y aislamiento en contenedores para cada tarea.

agent-swarm.dev funciona como sistema operativo para ese trabajo: un agente principal descompone objetivos complejos en tareas, las asigna a trabajadores que pueden usar Claude Code, Codex, Devin AI u otros motores, cada uno en su propio contenedor Docker aislado, y conserva el contexto acumulado entre sesiones en lugar de empezar de cero cada vez. Se integra con cientos de plataformas (Slack, Linear, GitHub, Turso, OpenAI) para que la delegación ocurra dentro de las herramientas que tu equipo ya usa.

El estudio de caso de Capchase muestra el impacto de este enfoque en un equipo de ingeniería real, y la comparación entre un espacio de trabajo tradicional y un equipo operativo de agentes ayuda a decidir si tu caso pide una plataforma alojada o un enjambre propio.

Si ya tienes agentes funcionando con Claude Code y el siguiente paso es coordinarlos entre equipos sin perder contexto, Agent-swarm y prueba el despliegue autohospedado para ver cómo encaja con tu flujo actual.

Fuentes

• Crear subagentes personalizados - Claude Code Docs

Preguntas frecuentes

¿Qué son los agentes en Claude Code?

Son sesiones que siguen un bucle de recibir instrucciones, decidir si usar herramientas, ejecutarlas y repetir hasta producir una respuesta final, con capacidad de delegar subtareas a subagentes o equipos.

¿Cómo puedo crear agentes en Claude Code?

Instala el CLI o el Agent SDK, define un CLAUDE.md con el contexto del proyecto, restringe allowed_tools a lo mínimo necesario y fija un maxTurns conservador antes de probar con una tarea acotada.

¿Cuáles son los principales tipos de agentes que se pueden construir con Claude Code?

Los patrones principales son el agente único, los subagentes que aíslan subtareas y devuelven resúmenes, los equipos de agentes que colaboran en paralelo, y los agentes incrustados vía Agent SDK en aplicaciones propias; herramientas como agent-swarm.dev añaden un nivel adicional al coordinar varios de estos patrones entre equipos completos.

¿Qué es un agente de IA dentro del ecosistema de Claude?

Es un proceso que combina un modelo de lenguaje con acceso a herramientas (archivos, ejecución de comandos, búsqueda web, servidores MCP) para completar tareas de forma autónoma dentro de límites de turnos y permisos definidos por el desarrollador.

¿Cuándo conviene usar un equipo de agentes en lugar de subagentes?

Cuando la tarea se divide en partes verdaderamente independientes que se benefician de ejecutarse en paralelo, como auditar varios módulos a la vez; para tareas secuenciales que solo necesitan un resumen final, un subagente basta y cuesta menos tokens.

Recomendación

• Agent Swarm Blog: Technical Deep Dives & Architecture Notes
• Code Review Agents for Engineering Teams: CI-Ready, Multi-Agent PR Checks | agent-swarm.dev
• Your AI Workflow Has Too Many Agents | agent-swarm.dev
• Multi-Agent Systems Reproduce Every Organizational Anti-Pattern You Already Hate | agent-swarm.dev