Cómo trabajo con agentes de IA en Claude Code de verdad

Cómo trabajo de verdad con agentes de IA en Claude Code: subagentes, orquestador y sesiones que nacen, hacen su tarea y mueren.

Te dejo el vídeo arriba, pero aquí lo tienes escrito y con los enlaces por si prefieres leerlo.

Una de las dudas que más me llega cuando enseño lo que hago con Claude Code es la misma: "Rubén, ¿cómo narices trabajas tú con los agentes?" Hablo mucho de subagentes, de agent teams, de sesiones de trabajo, pero por lo visto no queda claro cómo encaja todo eso. Así que vamos a ello.

Lo primero que tengo que decirte es que yo no trabajo con agentes de la forma que te está enseñando casi todo el mundo. Y no es por llevar la contraria: es que para mí la forma habitual no tiene ningún sentido.

¿Qué es un agente para mí exactamente?

Te lo explico desde el caso de Claude Code, que es lo que uso.

Para mí un agente es lanzar una skill de forma asíncrona. Se levanta como si abrieras una terminal nueva o una ventana nueva, con su propio contexto, y cuando acaba lo que tiene que hacer se muere. Punto. Se mantiene vivo hasta que termina su tarea y en ese momento se cierra, hasta que lo vuelvas a lanzar para otra cosa con el contexto que toque en ese momento.

Eso es lo que la mayoría no está haciendo. Lo que muchos llaman "agentes" no dejan de ser automatizaciones normales que por alguna razón usan un poco de IA y ya está. Si quieres profundizar en dónde está esa frontera, lo conté a fondo en agentes o automatizaciones no es lo mismo.

¿Por qué no tengo agentes corriendo 24 horas?

Porque no le veo el sentido en mi caso. Tener todos los agentes lanzados en todo momento, haciendo cosas sin mi permiso y sin mi supervisión, es la forma más fácil de que algo se te escape de las manos y acabe haciendo lo que no quieres.

Y hay un motivo técnico igual de importante. Si dejas agentes vivos sin más, saturas ventanas de contexto. La mayoría de las peticiones que les vas a hacer tienen partes de contexto distintas, así que es mucho mejor que se levanten cuando los necesitas y se mueran en cuanto terminan. Un agente que se queda ahí "dormido" esperando tareas sigue arrastrando su ventana de contexto, y al final lo revientas: empieza a alucinar, empieza a hacer cosas que no debe y se lía parda.

Por eso para mí importan más los patrones de diseño agénticos que el hecho de construir agentes sin más. Entender que tienes un agente principal, un orquestador, que es el que llama a los demás. Ahí está la mayoría de los problemas de la gente que no termina de usar esto bien.

¿Y cómo responderías tú a los comentarios de YouTube?

Te lo pongo con un ejemplo, porque es el caso típico donde alguien diría "ahí sí necesitas un agente vivo".

Imagina que quieres algo que conteste tus comentarios de YouTube. Lo primero, yo no lo dejaría decidir solo qué responder: es demasiado abstracto. Siempre va a hacer falta una mínima supervisión, porque llega un hater, o alguien malinterpreta algo, y ahí la puede liar.

Pero aunque quisiera automatizarlo, no tendría un agente corriendo continuamente. Prepararía un proceso que se lanza cada cierto tiempo (un cron) y que revisa con la API si hay comentarios nuevos. Eso es un script, no un agente. Solo cuando hay algo nuevo, en ese momento, se llama a la IA para generar la respuesta. Ni siquiera eso lo considero un agente como tal.

Orquestador y subagentes: cómo se levantan solos

Mi día a día normal es lanzar una skill de Claude Code, trabajar con ella, y cuando termino cierro la ventana: se acabó el contexto, se acabó la conversación. Cuando quiero otra cosa, lanzo otra skill. Eso ni siquiera lo llamo un agente, es trabajar con una terminal hasta que acabas.

Lo que pasa es que muchas veces esa skill necesita lanzar otras skills, a veces en paralelo. Ahí es cuando se levantan los subagentes, y esos sí son agentes de verdad: se levantan instancias de Claude que adoptan un rol según la skill que se está lanzando, hacen su trabajo y se cierran. Ese es el uso lógico y normal de un agente. Si quieres verlo con detalle, lo desarrollé en subagentes de Claude Code: para qué sirven y cómo se usan, y el mapa completo del tema está en la guía de automatización y agentes con IA.

¿Qué es una sesión de trabajo con Agent Teams?

De vez en cuando tengo que hacer algo con muchos trabajos en paralelo, y entonces abro lo que llamo una sesión de trabajo.

La idea es tener una conversación principal (el "main") que funciona como una reunión donde están todos los agentes que necesito, cada uno una skill levantada. En el main hablo, gestiono y apruebo. Pero cada agente tiene su propia conversación abierta en paralelo, su propia terminal, con su propia ventana de contexto. Eso es lo más óptimo: solo gastas la ventana de contexto de cada cosa donde de verdad sucede.

Y aquí está la clave: con Agent Teams, un agente puede mandarle un mensaje directo a otro sin pasar por la conversación principal. Cuando uno necesita algo de otro, se lo pide directamente, agarra lo que necesita y sigue. Solo suben al main cuando hace falta mi aprobación. Se autogestionan, porque cada uno tiene sus skills y sabe cuál es su función y qué necesita de los demás.

Te lo cuento con algo real que estaba haciendo: el relanzamiento de una de mis formaciones con un bonus. Ahí hay que coordinar varias cosas. Hablo con el CEO, que decide qué "trabajadores" entran y los lanza como agentes. El de planificar emails necesita métricas del director de redes sociales para saber qué campaña funcionó mejor. El director de producto tiene que dar contexto de lo que se ha creado. Y servidor web gestiona la plataforma donde se suben los bonus, la migración de alumnos de la plataforma antigua a la nueva, la landing con su contador y sus módulos. Se hablan entre ellos, se piden cosas entre ellos, y yo solo entro cuando quiero decirle algo concreto a uno.

Cuando un agente no tiene nada que hacer se queda en gris, dormido, esperando instrucciones. Y cuando termino todo el trabajo del lanzamiento, la sesión se cierra y se documenta: un acta con lo que se ha hecho, las decisiones, las fechas. Cada agente documenta además su propio trabajo. Y se acabó, sin dejar bichos vivos gastando recursos.

¿Cómo se implementa todo esto?

Te va a decepcionar, porque es ultra simple. Son skills de Claude Code. No hay nada del otro mundo.

No es el típico prompt de "actúa como no sé qué". Están bastante más currado: cada skill tiene su documentación y tira de ella para saber qué hacer. Cada una tiene acceso a sus documentos, sabe qué puede tocar y qué no, y si necesita algo que depende de otra skill, llama a esa skill y le pide que lo toque. El CLAUDE.md lo que hace es gestionar eso: cuando se habla de esto, lanza esta skill; cuando se habla de lo otro, esta otra. Ya está. Te conté cómo montar ese archivo en cómo escribir tu CLAUDE.md.

Y aquí viene lo único que de verdad importa: la documentación es la clave de todo. Sin documentación las skills no funcionan como tienen que funcionar. Con ella, cada agente entiende las decisiones que se han tomado y todo lo que se está haciendo, así que la gestión de errores es mínima. No repite cosas que ya estaban hechas. Por eso escribo la documentación antes que el código: no es burocracia, es la instrucción principal del trabajo.

De hecho, la mayoría de las veces le digo a Claude que tome él las decisiones y que no me pregunte. "Tienes las transcripciones, haz lo que quieras, no me preguntes, necesito que venda, no me vuelvas loco." Se lo digo tal cual. Gracias a la documentación, él sabe qué hacer.

Herramientas que salen en el vídeo

  • Claude Code: el agente con el que monto todo el sistema. Skills, subagentes, orquestador y sesiones de trabajo viven aquí.
  • Codex y Gemini: los nombro como alternativas. Mi mensaje es justo ese: da un poco igual cuál uses. Hoy casi todo hace lo mismo, así que usa el que más cómodo te resulte y déjate de discusiones técnicas.

Lo que de verdad tienes que sacar de aquí

Lo más difícil de esto no es la parte técnica. Es entender qué problemas reales tienes para aplicarles soluciones reales. Si no entiendes tus propios problemas, da igual que tengas la mejor tecnología del mundo: no vas a sacarle partido.

Por eso enseño ejemplos de cosas que hago yo. Lo que no es obvio es a qué narices aplicar esto, y tener algo en lo que inspirarte es lo que vale. Y si no sabes cómo hacer algo, abres tu IA, le explicas lo que quieres y le preguntas cómo. Tienes la mayor base de conocimiento del mundo delante y un ayudante que la busca por ti.

Si yo puedo, no tienes excusa.

Si quieres ver cómo tengo montado todo este sistema de documentación por dentro (el orden que le doy a las cosas, cómo se coordina cada pieza), eso es justo lo que explico en la formación Yo S.A.. Aquí en YouTube te enseño el qué; ahí te cuento el cómo.

Relacionado

Sigue leyendo