Cómo monté mi equipo de agentes de contenido IA con Claude Code

Hoy me ha dado por empezar a montar cinco agentes que escriben y editan mis posts, ya sean los del blog o los de redes sociales. Con esto, lo único que tengo que hacer cuando funcione es revisar para modificar y/o publicar.

Que una IA escriba por ti a día de hoy ya no sorprende a nadie. Según un análisis de Graphite que recogió Axios, más o menos la mitad de los artículos nuevos que se publican en inglés los escribe ya la IA, pero lo peor de todo, al menos para mí, es que ya no se molestan en adaptar siquiera el tono de voz y se nota a leguas cuando escribe al 100% la IA.

Diría que lo complicado es montar algo que produzca y optimice sin que pierdas el control de qué se publica, de dónde sale cada dato y cuánto se gasta por el camino.

Así que por si te sirve, esta es la estructura de mis agentes de contenido, qué es lo que tuve en cuenta, qué descarté y por qué, y en qué dos puntos intervengo.

Y por cierto, un detalle: este artículo es la primera publicación de este equipo de contenido. Para bajar las expectativas, el primer borrador que sacó el equipo no sonaba a mí, así que tuve que hacer unos cuantos cambios en tres agentes y lo reescribí. Lo que aprendí, te lo cuento en la parte 2. Si algo chirría, la culpa es mía, que soy quien firma.

Mi eterno problema

Siempre he tenido problemas para ser constante publicando: primero, porque es algo que no me gusta y segundo, porque siempre encontraba una excusa perfecta para darle prioridad a otra cosa que me divierte más. Así que vamos al grano.

Tengo reglas para todo lo que publico. Cada post lleva un bloque de metadatos completo (marca, voz, idioma, estado…), se escribe con una voz concreta (la mía o un intento de la mía), al final del post tiene que haber algo que se pueda hacer, replicar, una lista… lo que viene siendo, algo que hacer y nunca pisa un post de otra ejecución ni uno ya publicado: si hay que rehacerlo, se crea una versión nueva, al menos de momento para poder comparar y que la IA aprenda. En caso de que no haya acción, valoraré si se publica o no aunque la IA me avisará de ello, más que nada porque ya que estás aquí leyendo, al menos que sea un artículo útil (más o menos).

Ser constante y cumplir todo esto con cada post me llevaba horas y horas, así que me acababa aburriendo y lo dejaba de lado. También me venía el síndrome de la impostora a dar por saco, pero bueno, ahora con la ayuda de los agentes, espero tardar menos y publicar más.

Lo que hace este equipo de agentes es sacar un post de principio a fin siguiendo esas reglas. Es decir:

EstrategaPropone un brief.
La Humana (yo) (paso humano)Apruebo o corrijo el brief.
RedactoraEscribe el borrador.
EditoraCorrige forma y voz.
Abogada del diabloDa feedback, un veredicto y hasta 10 hallazgos.
La Humana (yo) (paso humano)Elijo qué hallazgos se aplican.
EditoraHace una segunda pasada solo con lo aceptado.
SocialSaca los derivados por canal.
Tracker y registroSe apunta todo automáticamente.

paso humano

Todo esto dentro de Claude Code, lanzado con un comando desde el directorio de mi vault donde tengo el contenido, ideas, braindumps, etc.

¿Por qué subagentes de Claude Code?

Por alternativas no será, que tenemos 12398529384 opciones sobre la mesa y elegir a veces se hace complicado, pero finalmente me decanté por los subagentes de Claude Code por tres motivos.

Coste -> No quería incrementar mis gastos de herramientas, así que el primer motivo es que con subagentes no pago nada aparte de mi plan de Claude.
Trabajan donde ya está todo -> leen y escriben directamente en mi vault de Obsidian y usan las skills de voz que tengo escritas. No tengo que copiar nada a otra plataforma ni reescribir mis guías de estilo en otro formato. Además, tampoco lo tengo que subir a un VPS ni nada similar y añadir otra capa de seguridad que vigilar.
Se pueden parar a mitad -> el proceso se detiene, me enseña lo que tiene y no sigue hasta que respondo.

Descarté otras opciones como Ollama, porque quiero que la redacción tenga calidad y que use mi tono de voz lo más fiel posible (aunque todavía le queda mucho por aprender), y creo que ahora mismo un modelo local no está en ese punto. También descarté CrewAI que es un framework de Python: tendría que programar y mantener el flujo en código, y yo quería poder cambiar un agente editando un .md para no complicarme la vida.

Lo que les falta a los subagentes frente a herramientas como Paperclip por ejemplo, es un panel donde ver a los agentes trabajando y cuántos tokens gasta cada uno, pero lo cubrí con un panel simple en local que te cuento más abajo.

Mi lado racional: “¿y si esto lo tienes que hacer en n8n, que es lo tuyo?” Mi lado oscuro: “¿para qué montar horarios y webhooks si de momento quiero estar delante en cada post?”

Ganó el segundo, por ahora. n8n sería la siguiente fase si esto funciona. Como de momento esto es un MVP, quiero mirar cada brief con calma y no aprobar y publicar cosas con las que no me siento cómoda.

Ojo con dónde pones a los agentes

Hay una parte de seguridad que se pasa mucho por alto cuando la gente monta agentes en un servidor.

Por eso, de momento, descarté subir los agentes a un servidor. En local el riesgo no desaparece, porque mi ordenador también tiene cosas que proteger, pero lo tengo delante, apruebo cada paso y el único agente que sale a internet no puede ejecutar nada. Igualmente, cuando empiece a funcionar como tiene que ser, ya escalaremos. De momento baby steps.

Los cinco papeles del equipo

Cada agente es un archivo .md en .claude/agents/. Lo hice así, porque así lo explica la documentación de subagentes de Claude Code. Arriba lleva un frontmatter con su nombre, una descripción, las herramientas que puede usar (tools) y el modelo (model). Debajo, sus instrucciones y para cambiar un agente, editas su archivo y listo.

Agente	Modelo	Qué hace	Qué puede tocar	Qué entrega
Estratega	Sonnet	Elige ángulo, voz e id; propone hook, estructura y acción concreta	Solo leer (Read, Glob, Grep)	Un brief, en la conversación
Redactora	Opus	Carga la voz del brief y escribe el pilar	Leer, crear archivos, usar skills (Read, Glob, Grep, Write, Skill)	Un borrador nuevo en `drafts/`
Editora	Sonnet	Voz, reglas, relleno, hook. No cambia el fondo ni el estado	Leer, editar, usar skills (Read, Glob, Grep, Edit, Skill)	Una revisión con lo que ha corregido y lo que decido yo
Abogada del diablo	Opus	Verifica datos en el vault y en la web, busca contradicciones y lee el texto desde otros puntos de vista	Solo leer y buscar en la web (Read, Glob, Grep, WebSearch, WebFetch)	Veredicto + hasta 10 hallazgos (bloqueante, importante, sugerencia)
Social	Sonnet	Derivados por canal, con la misma voz e id	Leer, crear archivos, usar skills (Read, Glob, Grep, Write, Skill)	Un archivo por derivado en `drafts/`

Por encima de los cinco hay un orquestador, que es una skill (/equipo-de-contenido). Reparte el trabajo, pasa el contexto de uno a otro y se para donde toca. Es el único que cambia el estado de un post y solo con mi ok.

Directorio.claude/
- Directorioagents/
  - estratega.md
  - redactor.md
  - editor.md
  - abogada-del-diablo.md
  - social.md
- Directorioskills/
  - Directorioequipo-de-contenido/
    SKILL.md el orquestador

Cada uno tiene los permisos mínimos

Cada agente puede hacer lo que necesita y nada más.

La estratega solo lee porque su trabajo es pensar, no producir. La redactora puede crear archivos y sobrescribir uno que ya existe. Técnicamente puede; lo que se lo impide es una línea en sus instrucciones. Veremos si aguanta. La editora puede editar pero no crear. Y la abogada del diablo, que es la única que sale a internet, no puede escribir ni ejecutar nada. El riesgo no es cero, porque lee mis notas y consulta webs, pero lo que trae pasa por mí antes de que se aplique nada.

Para los modelos, la regla es cuánto cuesta un error: Opus donde un error sale caro (escribir el post y criticarlo en serio) y Sonnet para el resto, que es trabajo con criterio pero más acotado.

Los dos puntos donde está la parte humana

El equipo de contenido hace que un post pase por todas las fases como si de una fábrica se tratara y para en dos puntos de control de calidad.

Uno: aprobar o corregir el brief. El brief decide el fondo: de qué va el post, para quién, con qué ángulo, qué estructura y qué tiene que poder hacer la persona que lee al terminar. Si el brief está mal, todo el trabajo que hagan después será una pérdida de tiempo, tokens y dinero. Tal cual pasa con un equipo de humanos cuando se idean cosas y se cambia de opinión como de ropa interior porque la brisa le da a alguien la inspiración.

Dos: elegir qué hallazgos de la abogada del diablo se aplican. La abogada del diablo puede tener razón o no. Puede pedir un cambio que mejora el texto o uno que lo vuelve más correcto pero más soso. Si los cambios se aplicaran solos, quien decidiría qué crítica vale sería otro modelo y de eso todavía no me fío. Puedo responder “todos”, “solo los bloqueantes”, números sueltos o mis propias indicaciones, y si rechazo alguno, el motivo queda apuntado.

En este post el brief que me propuso la estratega no era el que yo quería publicar, y lo tuve que corregir antes de que empezaran a trabajar los demás agentes: el ángulo se lo había inventado, el objetivo también, y un par de afirmaciones eran erróneas y tuve que quitarlas. Si no llego a parar ahí, la redactora habría escrito con mucha seguridad un artículo que luego me tocaría rehacer.

El registro: qué pasó en cada ejecución

Cada vez que se ejecuta el trabajo en equipo, el orquestador (el skill) añade un bloque al final de una nota de registro, sin editar los anteriores. Cada bloque lleva:

el brief resumido y los cambios que hice;
el veredicto de la abogada del diablo;
los hallazgos aceptados y los rechazados, con mi motivo (o “sin motivo” si no lo di);
los datos verificados, cada uno con su fuente;
lo que no se pudo verificar y queda pendiente;
los derivados que salieron.

Este registro me sirve para tres cosas:

No rehacer la estrategia -> si dentro de dos meses quiero sacar otro derivado o reescribir el post, el brief está ahí.
Saber de dónde sale cada dato -> cuando alguien me pregunte “¿esto de dónde lo has sacado?”, tengo la respuesta sin tener que rebuscar.
Detectar fallos que se repiten -> si la abogada del diablo me marca lo mismo en cinco artículos seguidos, el problema es el agente que lo escribió. Entonces tocaría corregir sus instrucciones.

Lo tercero es lo que más me interesa: si un sistema de agentes no aprende de sus errores, al final hay que corregirlo todo, y en vez de ahorrar tiempo lo pierdes. Que al principio, siempre será así, hasta que optimice el proceso.

El panel de tokens

Lo que más echaba de menos de herramientas como Paperclip era ver qué está pasando. Así que monté un panel local.

Panel de agentes: cinco encargos terminados, con los tokens, la duración y el modelo de cada agente

Se lanza con un comando de Python y se abre en el navegador. Se actualiza cada 4 segundos y enseña:

quién está trabajando ahora y cuántos encargos hay;
por sesión, cada agente con su estado (trabajando, terminado, parado o error), lo que está haciendo, sus tokens, su duración y su modelo;
si haces clic en un agente, su encargo, su resultado, los archivos que ha escrito, las herramientas que ha usado y sus pasos uno a uno;
filtros por proyecto y por periodo (1, 7 o 30 días).

Cómo funciona: lee los registros que Claude Code guarda de cada subagente. No hay que configurar nada ni instalar nada porque solo lee y escucha en 127.0.0.1 (o sea, solo se ve desde mi ordenador) y solo usa la biblioteca estándar de Python, sin dependencias externas.

Punto importante: el panel enseña tokens, porque con el plan de Claude no se factura por token (salvo que actives el uso extra de pago, que cobra aparte cuando agotas los límites del plan). El objetivo es poder ver qué agente consume más y si algo se dispara. También distingue la “caché leída”, que es contexto reutilizado y sale mucho más barato que la entrada nueva.

Qué viene en la parte 2 del post

En la parte 2, dentro de un mes, te contaré cuántos posts han salido, cuánto tiempo y cuántos tokens han costado, qué problemas han aparecido, qué he cambiado en los agentes y si me quedo con subagentes o paso a n8n. No prometo que salga bien, pero sí prometo contarlo tal cual.

Cómo puedes empezar tú

No lo montes todo de golpe, sino agente a agente.

Crea un archivo .md en .claude/agents/ dentro de tu proyecto, con este esqueleto:

---
name: revisor
description: Lee un borrador y devuelve una lista de correcciones. No edita nada.
tools: Read, Glob, Grep
model: sonnet
---

Eres el revisor de mis borradores. Lees el archivo que te indiquen
y devuelves una lista de problemas con el fragmento y una propuesta.
No modificas ningún archivo.

Dale los permisos mínimos para su papel. Si solo tiene que opinar, que solo lea. Si tiene que crear, ten en cuenta que también podrá sobrescribir lo que ya existe, así que déjale claro en sus instrucciones lo que quieres que haga.
Y antes de añadir un segundo agente, decide tus dos puntos de parada: dónde se decide el fondo y dónde se decide qué crítica se acepta. Ahí paras tú y si necesitas que pare más veces, que lo haga.

Y si dudas entre subagentes, n8n u otra cosa, hazte tres preguntas:

¿Necesito que corra solo, con horario y sin mí delante?
¿Necesito aprobar a mitad del proceso?
¿Voy a pagar por API o ya tengo un plan que lo cubre?

Si la primera es que sí, mira n8n. Si la segunda es que sí y la tercera es “plan”, los subagentes te van a dar mucho juego.

Si estás montando algo parecido en tu equipo, o te estás peleando con agentes que sacan volumen sin control de calidad, escríbeme por DM en LinkedIn y lo hablamos.

Nos leemos en la parte 2, dentro de un mes.