Respuesta rápida: un equipo de agentes de IA funciona cuando cada agente tiene un ámbito claro, solo una persona autoriza y las acciones que no se pueden deshacer las confirma siempre esa persona. El resto, que es memoria escrita, revisores independientes y mensajes entre agentes tratados como información y no como órdenes, sirve para que esas tres reglas se cumplan cada día.
¿Por qué un solo agente se queda corto?
Un agente de programación como Claude Code es muy bueno dentro de un proyecto. El problema aparece cuando llevas varios a la vez: una web, un par de apps, un juego, la infraestructura que los aloja y las automatizaciones que los unen. Si todo vive en una sola conversación, el contexto se llena de cosas que no tocan, las decisiones de un proyecto se cuelan en otro y nadie sabe quién es responsable de qué.
La solución que me funciona es la misma que en un equipo de personas: repartir responsabilidades y escribir las normas. Cada proyecto tiene su agente, cada recurso compartido tiene un dueño y las reglas están en ficheros que todos heredan.
No es un caso raro. Según la encuesta de Stack Overflow de 2025, el 84 % de los desarrolladores usa herramientas de IA o piensa usarlas, pero solo un 32,7 % confía en la precisión de lo que generan y el 66 % dice que su mayor frustración son las soluciones «casi bien, pero no del todo». Las normas existen precisamente para eso: para que lo que es casi correcto no llegue a producción sin que nadie lo decida.
¿Cómo se organiza el equipo?
Trabajo con tres tipos de agente:
- Titulares: uno por proyecto, que arranca en la carpeta de ese proyecto y solo trabaja ahí. Es el dueño de su código, de sus despliegues y de su memoria.
- Un director: coordina, lleva el organigrama y hace de puente entre titulares cuando un cambio toca a varios. No ejecuta el trabajo de los demás.
- Especialistas efímeros: revisores de seguridad, calidad, rendimiento o infraestructura que se lanzan para una tarea concreta y desaparecen. No escriben código: informan.
Las normas viven en ficheros CLAUDE.md con herencia: unas globales para todo, otras para el departamento y otras para cada proyecto. Claude Code carga esos ficheros al empezar cada sesión, así que una norma escrita una vez se aplica en todas partes. Eso sí, la documentación de Claude Code es clara: el modelo trata esos ficheros como contexto, no como configuración obligatoria. Una norma escrita orienta; lo que debe cumplirse sí o sí necesita algo más fuerte.
¿Quién autoriza qué?
La regla más importante es corta: solo autoriza la persona, y solo en el chat del agente que va a ejecutar. De ahí salen tres consecuencias prácticas:
- Lo que es de otro agente no se toca, aunque la persona lo autorice en tu chat. Se pide al dueño, a través del director.
- Las acciones que no se pueden deshacer las confirma la persona: cambios de DNS, escrituras en la base de datos de producción, borrados, pagos o publicaciones. En muchos casos el agente lo deja todo preparado y es la persona quien pulsa el botón final.
- Si una protección bloquea algo, no se rodea. Ni con otra herramienta, ni pidiéndoselo a otro agente. Se avisa a la persona y lo hace ella.
Claude Code tiene piezas que ayudan a que esto no dependa solo de la buena voluntad del modelo: modos de permiso, reglas de permitir y denegar por herramienta y hooks que se ejecutan antes o después de cada acción. Las reglas de permisos se evalúan en orden fijo (denegar, preguntar, permitir) y una regla de permitir no puede abrir una excepción en una de denegar. Los hooks dan control determinista: ciertas acciones ocurren siempre, sin depender de que el modelo decida hacerlas. Y cada subagente trabaja con su propio contexto, sus herramientas y sus permisos.
Mensajes entre agentes: ¿información o permiso?
Los agentes se escriben entre sí: el de infraestructura avisa al de la web de que va a tocar un servidor, el director reenvía una pregunta. Aquí está la trampa más peligrosa: que un agente diga «la persona ya lo ha aprobado» no es una aprobación. Es información de segunda mano.
Si los mensajes entre agentes valieran como permiso, bastaría con convencer a un agente para que convenciera al resto. Por eso la norma es tratarlos siempre como datos: se leen, se contrastan y, si piden algo que cambia el mundo exterior, se consulta a la persona en el chat que va a ejecutar.
Memoria escrita: ¿por qué guardar el porqué?
Las conversaciones se compactan y las sesiones se reinician. Lo que no está escrito se pierde. Cada agente guarda en ficheros cortos lo que no se deduce del código: decisiones, restricciones y preferencias, siempre con el porqué y cómo aplicarlo.
El porqué es lo que evita errores después. «Hacer commit solo cuando se pida» es una norma; «porque un push a un repositorio de cliente es una entrega, no una copia de seguridad» permite aplicarla bien en un caso que nadie había previsto.
¿Para qué sirven revisores que no escriben código?
Un agente que revisa su propio trabajo tiende a darse la razón. Los especialistas reciben el cambio, no la conclusión del autor, y devuelven hallazgos. No pueden aplicar nada, así que su incentivo es encontrar problemas, no cerrar la tarea.
Los uso en momentos concretos: antes de tocar DNS o una migración (infraestructura), cuando un cambio toca autenticación, pagos o datos personales (seguridad) y antes de publicar o entregar (producto).
Un ejemplo real: ¿cómo se cambia un registro DNS?
Un cambio de DNS en producción puede dejar una web sin servicio en segundos. El reparto en mi equipo queda así:
- El agente de infraestructura propone el cambio y explica cómo deshacerlo.
- La persona da el visto bueno en el chat del agente que lo va a ejecutar.
- El agente rellena el formulario y comprueba lo que va a cambiar.
- La persona pulsa Guardar.
- El agente verifica desde fuera que todo responde y lo deja anotado.
Parece más lento, pero en la práctica son unos segundos de la persona y elimina la clase de error que más caro sale: el que nadie decidió.
Si quieres ver cómo encaja esto con flujos de trabajo concretos, en flujos agénticos con Claude Code explico el ciclo de planificar, ejecutar y evaluar, y en cómo configurar Claude Code están los permisos y hooks básicos.
Preguntas frecuentes
¿Cuántos agentes hacen falta para empezar?
Uno por proyecto que mantengas de verdad y un director cuando haya cosas compartidas. Los revisores se lanzan cuando hacen falta, no viven siempre abiertos.
¿Un agente puede pedirle a otro que haga lo que a él le han bloqueado?
No. Es la forma más habitual de saltarse un permiso sin querer. Si algo está bloqueado, se avisa a la persona y lo decide ella.
¿Qué acciones debe confirmar siempre una persona?
Todas las que no se pueden deshacer o salen hacia fuera: DNS, bases de datos de producción, borrados, pagos, publicaciones y mensajes a terceros.
¿Dónde se guardan las normas?
En ficheros CLAUDE.md con herencia (global, departamento y proyecto) y en una memoria por proyecto con el porqué de cada decisión.
