Módulo 06

Un agente es un compañero. Varios agentes son un equipo.

Entender esta diferencia es lo que convierte Claude Code en una herramienta de equipo — no solo personal. La mayoría de flujos empiezan con un agente. Saber cuándo y cómo añadir más es lo que los hace escalar.

Qué es un agente

Un agente es Claude Code ejecutando una tarea con un objetivo claro, acceso a tus archivos y un conjunto de instrucciones sobre cómo trabajar en tu proyecto.

Piénsalo como un diseñador júnior al que le das un briefing completo: tiene el contexto del proyecto, sabe qué herramientas usar, conoce las restricciones. Si el briefing es bueno, trabaja solo. Si es vago, improvisa.

La diferencia con usar Claude.ai es que este diseñador júnior tiene acceso real a los archivos del proyecto — puede leer, editar y generar entregables, no solo responder en un chat.

Claude.ai

  • Responde en el chat
  • Contexto solo en el prompt
  • Sin instrucciones persistentes
  • Sin acceso a archivos del proyecto
  • Sin entregables directos

Claude.ai + Proyecto

  • Responde en el chat
  • Instrucciones persistentes en el proyecto
  • Archivos subidos disponibles en cada conversación
  • Contexto limitado al tamaño de los archivos subidos — no lee el repositorio completo
  • Sin entregables directos

El contexto está configurado una vez. Pero sigues trabajando en un chat — no ejecutas tareas en el proyecto real.

Agente en Claude Code

  • Lee y escribe archivos del proyecto
  • Instrucciones persistentes (CLAUDE.md + skills)
  • Acceso al repositorio completo en tiempo real
  • Genera entregables reales — specs, docs, código
  • Sigue procesos definidos por el equipo (skills)

Qué puede hacer un agente solo

Un solo agente bien configurado resuelve la mayoría de tareas de un equipo de diseño. La regla: si la tarea tiene un input claro, un proceso definido y un output concreto — un agente solo es suficiente.

Auditar un componente contra el design system

Generar una spec de entrega completa

Revisar un flujo desde la perspectiva de un arquetipo

Detectar tokens hardcoded en código

Escribir user stories cruzadas con los arquetipos

Cuándo plantearse más de un agente

Tres señales de que un solo agente no es suficiente.

La tarea es demasiado larga

01

El agente acumula contexto a lo largo de la sesión. Como un diseñador que lleva 8 horas seguidas en el mismo proyecto — empieza a cometer errores que no cometería con la cabeza fresca.

Divide en agentes más cortos y focalizados

Dos partes del trabajo son independientes

02

Si puedes hacer la auditoría de tokens y la revisión de flujo UX al mismo tiempo, un segundo agente en paralelo reduce el tiempo a la mitad. Como dos diseñadores en piezas distintas del mismo sprint.

Agentes en paralelo, merge al final

Una parte debe revisar a la otra

03

A veces necesitas que alguien externo valide el trabajo. Un agente genera la spec, otro la audita con ojos frescos. Igual que en un proceso de diseño real: quien diseña no es quien hace el QA.

Agentes en cadena: genera → revisa → aprueba

Inputs y outputs: el punto crítico

El punto más frágil en arquitecturas multi-agente es la transferencia entre agentes. Si el output del agente A no está bien definido, el agente B no tiene con qué trabajar.

Input — qué necesita cada agente

  • El archivo o contexto específico que debe procesar — no todo el proyecto
  • Instrucciones claras de qué hacer con ese input
  • Solo los documentos de referencia relevantes para esa tarea

Output — qué debe producir cada agente

  • Un formato definido y predecible — tabla, markdown o JSON
  • Solo lo que el siguiente agente necesita — nada más
  • Sin ambigüedad — el agente B no interpreta, ejecuta

Los tres patrones más comunes

Tres formas probadas de coordinar agentes, de la más simple a la más compleja.

01 — Secuencial

A genera, B revisa

Input → A (Genera) → B (Revisa) → Output

El más simple y el más útil. Ideal para flujos de entrega donde la calidad importa más que la velocidad.

Ejemplo en diseño

  • A — Genera la spec del componente
  • B — Audita la spec contra el DS
  • C — Añade criterios de accesibilidad

02 — Paralelo

A y B trabajan a la vez

Input → [A + B + C] → Merge → Output

Para tareas independientes que pueden ejecutarse al mismo tiempo. Reduce la duración total sin añadir complejidad de revisión.

Ejemplo en diseño

  • A — Audita tokens del componente
  • B — Revisa estados y variantes
  • C — Verifica accesibilidad
  • M — Consolida los tres reportes

03 — Orquestado

Un coordinador, varios ejecutores

Input → O (Orquestador) → [W + W + W] → O → Output

El más potente y el más frágil. Solo tiene sentido cuando el trabajo es genuinamente complejo y las partes están bien definidas antes de empezar.

Ejemplo en diseño

  • O — Recibe “audita el sprint completo”
  • W — Delega un worker por componente
  • O — Consolida y genera el informe

Glosario

  • O — Orquestador: el agente que recibe la tarea del usuario, la descompone y delega en otros agentes.
  • W — Worker: un agente como cualquier otro — se llama así porque recibe instrucciones de otro agente, no del usuario.

Cuándo no dividir

Más agentes no es siempre mejor. Añadir agentes añade complejidad de coordinación real.

Si la tarea dura menos de 5 minutos

El overhead de coordinar dos agentes supera el beneficio. Un agente único es suficiente.

Si los agentes necesitan compartir mucho contexto

Si el agente B necesita leer todo lo que hizo el agente A, el beneficio del aislamiento desaparece. Mejor mantenerlos juntos.

Si el equipo aún está aprendiendo

Empieza siempre con un agente. La arquitectura multi-agente se gana — no se asume desde el día uno.

Regla de oro

Empieza con un agente y un buen CLAUDE.md. Añade un segundo solo cuando tengas un problema concreto que no puedes resolver de otra forma.

Recursos para ir más lejos

Documentación oficial, artículos y tutoriales sobre agentes.