Hace unas semanas me senté delante del terminal con una idea en la cabeza. Llevaba tiempo usando OpenCode como asistente personal, de esos que te ayudan con código, te responden preguntas, te echan una mano con tareas concretas. Pero me estaba encontrando con un problema que cada vez se hacía más evidente: cuando le pedía a un solo agente que hiciera algo complejo, algo que requería varios pasos, el resultado se iba degradando según avanzaba. Las primeras instrucciones las seguía al pie de la letra, pero según se alargaba la conversación, el modelo empezaba a perder el foco, a mezclar conceptos, a olvidarse de lo que le había dicho al principio. Como cuando le pides a un becario que haga cinco cosas a la vez y al final hace mal las cinco.
Y entonces pensé: si en una obra de construcción no le pides al albañil que también haga de fontanero y de electricista, ¿por qué le pido a un solo agente que investigue, escriba, optimice para SEO y revise? No tiene ningún sentido. Necesitaba un equipo, no un único asistente. Necesitaba un jefe de obra que coordinara a especialistas, cada uno con su herramienta, su modelo y su temperatura. Y lo mejor de todo es que OpenCode ya tiene todo lo necesario para montar esto sin instalar nada más.
Así que me puse manos a la obra, y el resultado es lo que te voy a contar en este episodio. Te adelanto que este artículo que estás leyendo no lo he escrito yo solo. Bueno, sí, la idea es mía, la estructura la he definido yo, las correcciones las he hecho yo. Pero la redacción, la investigación, la optimización SEO y la revisión las ha hecho un equipo de cuatro agentes de IA coordinados por un supervisor. Y todo desde la terminal, sin salir de OpenCode.
Si te perdiste los episodios anteriores, te recomiendo que le eches un vistazo al episodio 795 donde hablé de OpenCode por primera vez, al 796 sobre skills y al 797 sobre OpenRouter y Go. Pero si vienes directamente aquí, no te preocupes, te pongo en contexto.
De asistente personal a equipo de agentes
Hasta ahora, la forma de trabajar con modelos de lenguaje era bastante sencilla. Te conectabas a ChatGPT, a Gemini o a Claude, le preguntabas algo y te respondía. Luego, con el tiempo, los modelos fueron ganando capacidades: empezaron a poder ejecutar código, a buscar en internet, a leer archivos. Aparecieron las herramientas, los MCP (Model Context Protocol), los skills. De repente, tu asistente ya no solo hablaba, sino que podía hacer cosas.
Pero hay un salto cualitativo que va más allá de darle herramientas a un solo agente. Y es pasar de tener un asistente a tener un equipo de asistentes. Cada uno especializado en una tarea, cada uno con su propio contexto, su propio modelo, su propia temperatura. Y un coordinador que se encarga de orquestarlos.
¿Por qué harías algo así? Pues por una razón muy sencilla: la especialización. Cuando le pides a un solo agente que haga todo, ocurre lo que yo llamo la degeneración del contexto. El modelo empieza bien, pero según avanza la conversación, el contexto se va llenando de información que no es relevante para lo que está haciendo en ese momento. El redactor tiene en su cabeza los datos de la investigación, las instrucciones del SEO, las reglas de revisión… y al final, escribe peor porque está saturado.
En cambio, si separas las responsabilidades, cada agente recibe solo la información que necesita. El investigador recibe la pregunta y vuelve con datos. El redactor recibe los datos y vuelve con un borrador. El SEO recibe el borrador y vuelve con los metadatos optimizados. El revisor lo examina todo y dice si está bien o si hay que repetir alguna fase. Y el coordinador, que no hace nada de todo esto, se limita a orquestar.
El patrón supervisor: el jefe de obra que no pone ladrillos
Vamos a lo fundamental. El patrón supervisor no es ni más ni menos que un agente que actúa como jefe de obra. Y el jefe de obra, ya sabes, no hace nada. No pone ladrillos, no pinta paredes, no instala tuberías. Su trabajo es planificar la obra, establecer los pasos, delegar en cada especialista y luego revisar que todo esté correcto.
┌──────────────────────────────────────────────────┐
│ SUPERVISOR (Coordinador) │
│ Rol: Planificar, delegar, NO ejecutar │
│ Modelo: Grande (razonamiento complejo) │
│ Permisos: Solo task (delegación) │
├──────────┬──────────┬──────────┬──────────────────┤
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌──────────┐
│ Inves- │ │ Redac- │ │ SEO │ │ Revi- │ │(Opcional)│
│ tigador│ │ tor │ │ Optim. │ │ sor │ │ Public. │
│Solo │ │Escribir│ │Solo SEO│ │Solo │ │ │
│leer │ │ │ │ │ │leer │ │ │
│Modelo │ │Modelo │ │Modelo │ │Modelo │ │ │
│pequeño │ │medio │ │pequeño │ │pequeño │ │ │
└────────┘ └────────┘ └────────┘ └────────┘ └──────────┘Este esquema es la base de todo. Y ojo, que no te estoy hablando de programación. Esto no es un sistema para escribir código, es un sistema para escribir artículos. O para hacer presentaciones. O para lo que se te ocurra. El patrón supervisor es agnóstico al dominio: lo que cambia son los agentes especializados que pongas debajo.
En mi caso, he creado un sistema para la redacción de artículos del blog. Pero perfectamente podrías tener un equipo que te prepare presentaciones: un agente que busque imágenes, otro que redacte las diapositivas, otro que genere gráficos, otro que revise la coherencia. Las posibilidades son enormes.
El pipeline de cinco fases
El flujo de trabajo que he implementado se divide en cinco fases. Cada fase tiene un agente especializado, aunque algunas las puede hacer el propio coordinador si son lo suficientemente simples.
F1: Planificación. El coordinador (o un agente de planes) define la estructura del artículo, las secciones que va a tener, el tono, la extensión aproximada. Es el momento de decidir qué se va a hacer y cómo. En esta fase, el coordinador puede hacer preguntas para afinar el enfoque. De hecho, una de las cosas que he incorporado es un skill llamado grill me que hace que el agente te pregunte antes de empezar. Así no se lanza a escribir sin tener claro lo que quieres.
F2: Investigación. Aquí entra el investigador o bibliotecario. Su única misión es buscar información. No escribe, no opina, no redacta. Solo trae datos. Busca documentación oficial, repositorios de GitHub, ejemplos reales, artículos relacionados. Todo con sus fuentes. Usa un modelo pequeño y barato, porque no necesita ser creativo, necesita ser preciso.
F3: Redacción. El redactor o periodista recibe los datos del investigador y escribe el artículo. Usa el tono de la casa, estructura en secciones con Markdown, incluye ejemplos prácticos. No sabe nada de SEO, no investiga, solo escribe. Aquí sí que necesitas un modelo con cierta calidad de escritura, algo como Claude Sonnet o GPT-4o.
F4: SEO. El comercial o SEO optimizer recibe el borrador y lo optimiza para buscadores. Pone un título que la gente busque en Google, escribe la meta descripción con menos de 160 caracteres, añade etiquetas y palabras clave, asegura que la keyword principal esté donde tiene que estar. Pero no cambia el fondo del artículo. Solo los metadatos.
F5: Revisión. El revisor o editor examina el artículo completo. Verifica que el título tenga la palabra clave, que la descripción no se pase de caracteres, que los tags sean relevantes, que la estructura sea correcta, que el tono sea el adecuado. Y lo más importante: no edita nada. Simplemente devuelve un informe. Si algo no cumple, se lo dice al coordinador, y el coordinador decide si repetir la fase que ha fallado.
Coordinador → Investigador → Redactor → SEO → Revisor
│
┌──────────┴──────────┐
▼ ▼
¿OK? = Sí ¿OK? = No
│ │
▼ ▼
Entrega Repite fase fallida
│
▼
Vuelve al coordinadorEste bucle de retroalimentación es lo que diferencia un sistema multi-agente bien hecho de cualquier otra cosa. No es un pipeline lineal donde todo sale bien a la primera. Es un proceso iterativo donde el revisor puede devolver el artículo al redactor si encuentra problemas, y el redactor lo corrige y lo vuelve a pasar por SEO y revisión.
La herramienta Task: el corazón de la delegación
Todo esto funciona gracias a la herramienta Task de OpenCode. Task es el mecanismo de delegación: permite que un agente (normalmente el coordinador) lance subagentes con su propio contexto, su propio modelo y sus propias herramientas.
Cada subagente se ejecuta en su propia sesión hija. Tiene su contexto aislado, no comparte nada con el padre. Puede usar un modelo diferente al del agente que lo invoca. Y puede ejecutarse en paralelo usando el modo background, de manera que puedes lanzar varias tareas a la vez y esperar a que todas terminen.
La configuración de permisos para Task es muy granular. Puedes controlar exactamente qué subagentes puede invocar cada agente:
{
"agent": {
"coordinador": {
"mode": "primary",
"permission": {
"task": {
"*": "deny",
"investigador": "allow",
"redactor": "allow",
"seo-optimizer": "allow",
"revisor": "allow"
}
}
}
}
}Fíjate en la clave de todo esto: el coordinador tiene edit: deny, bash: deny, write: deny. No puede hacer nada más que delegar. Y los subagentes no tienen permiso para usar Task, con lo que no pueden invocar a otros subagentes. Esto evita el caos de que el investigador llame al revisor, el revisor llame al SEO, y se monte un follón de mucho cuidado.
Los agentes especializados al detalle
Cada agente es, al final, un archivo Markdown. Un archivo Markdown con un frontmatter que define su descripción, su modo, su modelo, su temperatura y sus permisos. Y luego un prompt que le dice exactamente qué tiene que hacer. Si sabes escribir Markdown, sabes crear agentes.
El investigador o bibliotecario
El investigador no escribe nada. Su único trabajo es buscar información. Le dices investiga sobre el cangrejo azul de aguas profundas y él vuelve con datos: cómo se reproduce, dónde vive, de qué se alimenta, con fuentes verificadas. No opina, no redacta, no hace valoraciones. Solo trae datos.
---
description: >
Busca información en internet y documentación oficial.
NO escribe, NO opina. Solo investiga y devuelve datos
con fuentes verificadas.
mode: subagent
model: anthropic/claude-haiku-4-20250514
temperature: 0.1
permission:
webfetch: allow
edit: deny
bash: deny
write: deny
---
Eres un investigador. Tu única misión es buscar información veraz.
Devuelve los datos en bruto con sus fuentes. No redactes, no opines.La temperatura es bajísima, 0.1, porque no queremos creatividad. Queremos datos precisos. El modelo es pequeño y barato, un Haiku o un GPT-4o-mini. Los permisos son mínimos: solo puede hacer peticiones web y leer archivos. Nada de editar, nada de ejecutar comandos.
La gran ventaja de tener un investigador separado es que no contamina la redacción. Si usaras el mismo agente para investigar y escribir, acabarías con un opinólogo, alguien que mezcla los datos con su interpretación subjetiva. El bibliotecario trae los datos en bruto, y luego el redactor los interpreta.
El redactor o periodista
El redactor recibe los datos del investigador y escribe el artículo. Usa el tono de atareao.es, que hemos entrenado para que conozca nuestro estilo. Estructura en secciones con Markdown, incluye ejemplos prácticos, usa negritas y cursivas donde corresponde.
---
description: >
Escribe artículos en Markdown con el tono de atareao.es.
NO investiga, NO hace SEO. Solo escribe.
mode: subagent
model: anthropic/claude-sonnet-4-20250514
temperature: 0.7
permission:
edit: allow
write: allow
bash: deny
---
Eres un escritor profesional. Usa el tono conversacional de atareao.es.
Estructura el artículo en secciones con Markdown. Incluye ejemplos prácticos.Aquí la temperatura es más alta, 0.7, porque necesitamos creatividad en la escritura. El modelo es de gama media-alta, porque la calidad de la redacción importa. Y tiene permisos para editar y escribir archivos, porque necesita crear el artículo.
Una cosa importante: el redactor no sabe nada de SEO. Si le pidieras que también optimizara para buscadores, lo haría, pero mal. Porque no es su especialidad. Por eso tenemos un agente separado para eso.
El SEO o comercial
El agente de SEO recibe el borrador y lo optimiza para buscadores. No cambia el contenido del artículo, solo los metadatos. Pone un título que la gente busque en Google, escribe la meta descripción con menos de 160 caracteres, añade etiquetas y palabras clave relevantes.
---
description: >
Optimiza artículos para buscadores. Añade frontmatter,
meta description y tags. NO cambia el contenido del artículo.
mode: subagent
model: anthropic/claude-haiku-4-20250514
temperature: 0.2
permission:
edit: allow
bash: deny
---
Eres un experto en SEO. Añade title SEO, meta description (<160 chars),
tags relevantes y asegura que la keyword principal esté bien posicionada.La temperatura es baja, 0.2, porque las reglas del SEO son fijas y no queremos inventos. El modelo es pequeño y barato. Y el permiso de edición está limitado a lo justo para modificar el frontmatter.
Fíjate en un detalle importante: el título que vende no lo escribe el periodista, lo escribe el comercial. El periodista escribe un título descriptivo, y luego el SEO lo convierte en un título que la gente busque en Google. Son dos habilidades distintas.
El revisor o editor
El revisor es, para mí, el agente más importante de todos. Porque es el que asegura la calidad. Y lo hace sin editar nada, simplemente leyendo y devolviendo un informe.
---
description: >
Revisa la calidad del artículo. Verifica estructura, tono y SEO.
NO edita, solo informa de problemas.
mode: subagent
model: anthropic/claude-haiku-4-20250514
temperature: 0.1
permission:
edit: deny
bash: deny
write: deny
---
Eres un editor. Revisa el artículo y devuelve un informe de calidad.
Si hay errores, indica qué fase debe repetirse. No corrijas tú mismo.Temperatura bajísima, 0.1. Modelo pequeño y barato. Permisos mínimos: solo leer. No puede editar, no puede ejecutar, no puede escribir. Su única misión es examinar y reportar.
¿Y qué verifica? Pues cosas como que el título tenga la palabra clave principal, que la descripción no exceda los 160 caracteres, que los tags sean relevantes, que el artículo tenga la estructura correcta, que el tono sea el adecuado, que no haya errores de formato. Si algo no cumple, el editor lo devuelve al coordinador con un informe detallado de lo que hay que corregir.
Y aquí entra el bucle de retroalimentación. El coordinador recibe el informe, lanza de nuevo al redactor con las correcciones indicadas, el redactor corrige, pasa por SEO otra vez, y vuelve a revisión. Este ciclo se repite hasta que el revisor da el visto bueno.
El coordinador: la no ejecución como clave del éxito
Llegamos al agente más importante y, paradójicamente, el que menos hace. El coordinador no escribe, no investiga, no optimiza, no revisa. Solo coordina. Su descripción es clave:
---
description: >
Coordinador de artículos. Tu trabajo es coordinar, NO escribir.
NO HAGAS EL TRABAJO TÚ MISMO. Descompón la tarea y asigna
cada parte al agente especializado.
mode: primary
model: anthropic/claude-sonnet-4-20250514
temperature: 0.3
permission:
task:
"*": "allow"
edit: deny
bash: deny
write: deny
---
Eres el jefe de obra. Planifica, delega y supervisa. No ejecutes.
NO PUEDES HACER NADA. SOLO PUEDES DELEGAR.
NO ESCRIBAS ARTÍCULOS TÚ MISMO.
NO INVESTIGUES TÚ MISMO.
NO REVISES TÚ MISMO.
SOLO PLANIFICA, DELEGA Y SUPERVISA.Fíjate en las exclusiones en mayúsculas. Esto no es casual. Es una de las lecciones más importantes que he aprendido montando este sistema: los modelos de lenguaje tienden a hacer en lugar de delegar. Si no le pones barreras muy claras, el coordinador se pondrá a investigar él mismo, a escribir él mismo, a hacer SEO él mismo. Y el resultado será nefasto, porque el coordinador no es especialista en nada.
Por eso le he puesto edit: deny, bash: deny, write: deny. No puede hacer nada. Literalmente, nada. Su única herramienta es Task, que le permite delegar en los subagentes. Y punto.
Errores comunes y cómo evitarlos
Después de varias semanas usando este sistema, te puedo asegurar que me he encontrado con todos los errores imaginables. Te los cuento para que no pases por los mismos apuros.
El coordinador no delega
Este es el error más común con diferencia. Configuras al coordinador, le pides algo, y en lugar de llamar al investigador, investiga él. En lugar de llamar al redactor, escribe él. El resultado es lo peor de ambos mundos: el coordinador no es especialista en nada, así que hace todo mal.
La solución es triple. Primero, la descripción tiene que ser muy explícita, con exclusiones en mayúsculas. Segundo, los permisos tienen que estar restringidos al máximo: solo Task. Tercero, y esto es importante, la descripción del coordinador debe decir claramente NO HAGAS EL TRABAJO TÚ MISMO.
Descripciones pobres en los subagentes
Cada subagente tiene una descripción en su frontmatter. Esta descripción es la puerta de entrada: es lo que ve el coordinador para decidir cuándo usar cada subagente. Si le pones busca cosas, el coordinador no va a saber exactamente para qué sirve.
La descripción tiene que ser específica: Úsalo cuando necesites buscar información actualizada en internet. No escribe, no opina. Devuelve datos con fuentes verificadas. Tiene que incluir negativas, para que el coordinador sepa cuándo no usarlo. Y tiene que describir el output, para que el coordinador sepa qué esperar.
Permisos excesivos
Si le das a todos los agentes permiso para usar Task, cualquier agente puede invocar a cualquier otro. El investigador llama al revisor, el revisor llama al SEO, el SEO llama al redactor, y al final se monta un caos absoluto.
La solución es simple: solo el coordinador tiene permisos de Task. Los subagentes no pueden tener subagentes. Y los permisos de Task del coordinador están limitados a los subagentes que realmente necesita.
El mito del coste multiplicado
Hay quien dice que cuatro subagentes son cuatro veces más caros que un solo agente. Y no es así. Puede ser incluso más barato, por varias razones.
Primero, cada subagente recibe solo el contexto que necesita, no todo el contexto acumulado de la sesión. Esto significa que los tokens de entrada son muchos menos. Segundo, puedes usar modelos pequeños y baratos para los subagentes que hacen tareas simples. El investigador, el SEO y el revisor pueden usar modelos como Haiku o GPT-4o-mini, que son muy económicos. Solo el coordinador y el redactor necesitan modelos grandes. Tercero, el contexto aislado evita la degeneración del modelo en sesiones largas, lo que significa que no tienes que repetir instrucciones constantemente.
Los subagentes como caja negra
Cuando lanzas un subagente, se ejecuta en su propia sesión. No ves lo que está haciendo a menos que tengas la sesión en primer plano. Esto puede ser un problema si algo sale mal y no sabes por qué.
La solución es usar la navegación entre sesiones que ofrece OpenCode. Puedes entrar en la sesión hija para ver lo que está haciendo el subagente, y volver a la sesión padre cuando termine. También puedes activar logging detallado para revisar lo que ha ocurrido.
Cuándo merece la pena usar multi-agente
No todo necesita un sistema multi-agente. De hecho, la mayoría de las cosas no lo necesitan. Si lo que quieres es traducir un texto, créate un agente que traduzca y ya está. No necesitas un equipo de cinco agentes para eso.
Usa multi-agente cuando:
- El contexto en una sola sesión se va a saturar por la cantidad de información
- Necesitas descomponer un problema complejo en partes más manejables
- Diferentes partes del proceso requieren diferentes especialidades
- Quieres un pipeline de calidad con revisión y retroalimentación
Para cambiar una bombilla no necesitas un equipo de cinco personas. Necesitas un electricista. Pero para construir una casa, necesitas un arquitecto, un albañil, un fontanero, un electricista y un jefe de obra que los coordine.
La demo en vivo: creando un artículo sobre FD
Para que veas cómo funciona todo esto en la práctica, te cuento la demo que hice en el episodio. Le pedí al coordinador que creara un artículo sobre fd, una herramienta en Rust que sustituye a find. Pero no le dije que escribiera un artículo de 2000 palabras directamente. Le dije que hiciera una demo rápida, de unas 300 palabras, con una investigación ligera.
El coordinador empezó haciéndome preguntas usando el skill grill me. ¿Sobre qué tema quieres hacer el artículo? le dije que sobre fd. Y a partir de ahí, él solo se puso a trabajar.
Lo primero que hizo fue trazar un plan. Definió las secciones del artículo, la estructura, el tono. Luego lanzó al investigador, que buscó información sobre fd en GitHub, en la documentación oficial, en ejemplos de uso. El investigador volvió con datos: qué es fd, cómo se instala, cómo se usa, qué ventajas tiene sobre find.
Luego lanzó al redactor, que con esos datos escribió un borrador del artículo. El redactor usó el tono de atareao.es, estructuró el artículo en secciones, incluyó ejemplos de uso. Después lanzó al SEO, que puso un título optimizado para buscadores (FD, el sustituto moderno de find en Rust), una meta descripción, etiquetas y palabras clave.
Finalmente, lanzó al revisor, que examinó el artículo completo y dio el visto bueno en la primera iteración. Todo el proceso, desde que le di el tema hasta que tuvo el artículo terminado, llevó apenas unos minutos. Y el resultado era un artículo perfectamente estructurado, con su frontmatter, sus secciones, sus ejemplos y sus metadatos SEO.
Lo más alucinante de todo es que yo no estuve mirando cómo lo hacía. Simplemente le di el tema, le fui guiando con pequeñas indicaciones — añade ejemplos, refuerza las cabeceras, incluye una comparativa con find — y él fue haciendo todo el trabajo pesado.
Porque aquí está el truco de todo esto: la parte del becario la hace la IA. La parte de la mente la pongo yo. Yo soy el que guía, el que decide el enfoque, el que dice por dónde tiene que ir el artículo. La IA ejecuta, pero la dirección la marco yo. Y eso es lo que hace que este sistema tenga tanto potencial.
OpenCode no es solo para programar
Una de las cosas que más me gusta de OpenCode es que no es exclusivamente para programar. La gente tiende a pensar que los asistentes de IA en terminal son solo para desarrolladores, pero no es así. OpenCode puede usarse para redactar artículos, para generar presentaciones, para hacer investigación, para cualquier tarea que requiera un flujo de trabajo estructurado.
Y con el sistema multi-agente que te he contado, las posibilidades se multiplican. Puedes tener un equipo de agentes que te prepare una presentación: uno que busque imágenes, otro que redacte las diapositivas, otro que genere gráficos, otro que revise la coherencia. O un equipo que investigue un tema técnico: uno que busque documentación, otro que extraiga los puntos clave, otro que los resuma, otro que verifique las fuentes.
El límite no está en la herramienta, está en tu imaginación. Y en tu capacidad para definir bien los agentes, sus descripciones, sus permisos y sus prompts.
Conclusión
Llegados a este punto, creo que ha quedado claro que el sistema multi-agente con OpenCode no es ciencia ficción. Es algo que puedes montar hoy mismo en tu terminal, con unos pocos archivos Markdown y un puñado de comandos.
No necesitas ser un experto en IA. No necesitas saber Python ni montar infraestructuras complejas. Solo necesitas OpenCode, ganas de experimentar y un poco de paciencia para definir bien cada agente.
Eso sí, te aviso de una cosa: una vez que empieces a usar este sistema, no hay vuelta atrás. Cuando ves a un equipo de agentes trabajando coordinados, cada uno haciendo lo que mejor sabe hacer, y el resultado es un artículo perfectamente estructurado, optimizado y revisado en cuestión de minutos… es difícil volver a hacerlo todo a mano.
Así que ya sabes, abre tu terminal, instala OpenCode, crea tu primer coordinador, define tus agentes especializados, y empieza a lanzar cosas como si no hubiera un mañana. Y si te surge alguna duda, ya sabes dónde encontrarme.
Más información
- Documentación oficial de OpenCode — guía completa de instalación, configuración y uso
- Agentes en OpenCode — documentación sobre agentes primarios, subagentes y permisos Task
- Repositorio de OpenCode (anomalyco) — código fuente del proyecto con ~198k estrellas
- Skills en OpenCode — cómo crear y usar habilidades reutilizables en formato SKILL.md
- Herramientas y permisos en OpenCode — referencia de herramientas disponibles y sistema de permisos granular
- CrewAI — Documentación de agentes — framework Python para sistemas multi-agente, alternativa a OpenCode
- AutoGen (Microsoft) — framework multi-agente conversacional para investigación y automatización
- Crush (Charmbracelet) — sucesor del OpenCode original, escrito en Go
- Model Context Protocol (MCP) — protocolo estándar para conectar modelos de lenguaje con herramientas externas
- OpenRouter — proveedor multi-modelo para acceder a diferentes LLMs desde una sola API