Media company unipersonal con bots de Hermes: el blueprint completo

El sistema con el que una sola persona arma un equipo de seis bots de Hermes: investigación, redacción y distribución de una media company entera.

2026-08-28

Una media company es un loop

La parte valiosa de una media company no es la cantidad de borradores que produce. Es el loop que conecta atención, research, criterio editorial, distribución y feedback.

El loop completo se ve así:

idea → research → ángulo → long-form → distribución → review → performance → playbooks actualizados

Si se rompe cualquier conexión, la calidad cae. Si la research nunca llega al estratega, el ángulo se vuelve genérico. Si el escritor nunca ve el paquete de fuentes, las afirmaciones se desvían. Si la distribución arranca desde un artículo terminado sin entender su argumento, cada plataforma recibe una versión acortada de lo mismo. Si el performance nunca actualiza los playbooks, el equipo repite los mismos errores para siempre.

Por eso seis chatbots independientes no son una media company. Necesitan ownership claro, contexto compartido, handoffs estructurados y un solo feedback loop.

Construí el cerebro compartido primero

Arrancá por el conocimiento que los seis roles necesitan para tomar decisiones compatibles. Una vez que esa base existe, cada bot trabaja desde los mismos estándares editoriales.

Obsidian le da a ese conocimiento una forma útil. Cada archivo markdown contiene una parte del sistema, y los links muestran cómo se relacionan voz, audiencia, hooks, plataformas y performance.

Ese grafo se vuelve el cerebro compartido del equipo. Estructura dentro de tu vault:

media-company/

  • index
  • brand: voz, audiencia, ofertas, pruebas
  • discovery: señales, preguntas de clientes, clips de autoridad
  • engine: ángulos, hooks, repurposing, review, performance
  • platforms: x, linkedin, newsletter, video, carousel
  • campaigns: una carpeta por campaña activa

El archivo index es el punto de entrada que todo bot lee primero. Define:

sobre qué publicamos

  • sistemas de IA aplicados para operadores
  • builds de agentes prácticos
  • herramientas nuevas con un uso de negocio específico

para quién publicamos

  • founders
  • marketers
  • operadores de IA

qué debe contener toda campaña

  • un resultado claro para el lector
  • una afirmación central
  • evidencia directa para las afirmaciones importantes
  • un framework, workflow o regla de decisión reutilizable
  • distribución nativa por plataforma

routing

  • señales nuevas → signal scout
  • señales aprobadas → researcher
  • paquetes de fuentes completos → content strategist
  • briefs de ángulo aprobados → long-form writer
  • piezas principales aprobadas → distribution bot
  • todo asset externo pasa por editor

aprobación humana

  • requerida antes de publicar
  • requerida antes de cambiar voz, audiencia, oferta o reglas de evidencia
  • requerida antes de que una lección de performance se vuelva regla permanente de playbook

No conviertas el vault en un archivo de cada pensamiento que producen los bots. Guardá conocimiento aceptado, reglas vigentes, ejemplos reutilizables y links al material fuente. Los borradores de campaña viven en la carpeta campaigns, donde se pueden revisar o descartar sin contaminar la memoria de largo plazo del equipo.

El cerebro compartido debe volverse más selectivo a medida que crece.

Seis bots, seis trabajos distintos

La forma más rápida de arruinar un flujo multi-agente es darle a cada bot la misma instrucción amplia: hacé buen contenido.

Cada bot necesita una decisión que le pertenezca, un entregable que devolver y un punto claro donde debe detenerse. Usá este contrato para cada perfil:

  • owns: la decisión de la que es responsable
  • reads: los archivos y campos de handoff que puede usar
  • returns: el artefacto exacto que recibe el siguiente bot
  • must not: decisiones que pertenecen a otro bot o al humano
  • done when: condiciones observables que completan el handoff

1. Signal scout: encuentra ideas con razón de existir ahora

Vigila lanzamientos de productos, research, preguntas de clientes, objeciones recurrentes, clips de autoridad fuertes y conversaciones que ya atraen atención. No decide la tesis final ni empieza a redactar.

Para cada candidato devuelve: qué pasó; por qué la audiencia podría importarle; la fuente original; el clip de autoridad o prueba más fuerte; la pregunta que la pieza terminada podría responder; qué tan rápido decae la oportunidad; y una razón corta para rechazarlo cuando la señal es débil.

Este bot debería descartar muchas más ideas de las que aprueba. Su trabajo es proteger al resto del equipo de pulir horas un tema que nadie necesitaba.

2. Researcher: construye el paquete de evidencia

Recibe una señal aprobada y la convierte en un paquete de evidencia atado a fuentes. Verifica la afirmación original, encuentra fuentes primarias, chequea el contexto, registra números útiles y separa hechos verificados de inferencias.

Su handoff incluye: el evento o fuente actual que crea urgencia; tres a siete afirmaciones verificadas; URLs directas para cada afirmación importante; citas relevantes o clips con timestamp; contradicciones y evidencia faltante; lo que las fuentes no prueban; y dos o tres mecanismos que vale la pena explicar.

Researcher no elige un titular sensacional y después busca evidencia que lo respalde. Le entrega al estratega un conjunto acotado de hechos lo bastante fuerte para sostener un argumento original.

3. Content strategist: encuentra la historia dentro de la research

Convierte el paquete de evidencia en una sola decisión editorial. Elige: el lector; el resultado; la tensión central; la tesis; el formato más útil; el titular principal; el objeto reutilizable con el que el lector se queda; y los ángulos de distribución que después podrían funcionar solos.

El output es un brief de ángulo, no un borrador: lector; resultado para el lector; fuente actual; tensión central; tesis; qué se vuelve posible; formato principal; objeto reutilizable; prueba requerida; secciones; y puertas de entrada de distribución (prueba, mecanismo, workflow, riesgo y resultado).

Un ángulo completo vale más que diez ideas intercambiables. El estratega devuelve una recomendación y explica por qué los caminos rechazados son más débiles.

4. Long-form writer: crea la pieza principal

Recibe el brief de ángulo aprobado, el paquete de evidencia, el archivo de voz y los patrones de artículo relevantes del vault. Su trabajo es crear la versión más profunda y reutilizable de la idea: un X article, newsletter, guía o video ensayo.

La pieza principal debe contener: titular orientado a resultado; primera pantalla que haga tangible el resultado; arquitectura visible; afirmaciones respaldadas por fuentes; un workflow o framework completo; ejemplos en los momentos donde el lector podría trabarse; y un cierre comprimido que haga la idea fácil de recordar.

El escritor no crea todos los assets de plataforma. Produce el material fuente del que el distribution bot desarrolla varias historias distintas.

5. Distribution bot: reconstruye la idea para cada plataforma

El repurposing falla cuando el sistema trata el formato como distribución. Un artículo no se vuelve un post de X porque perdió 1.500 palabras. Una newsletter no se vuelve un carrusel porque sus párrafos se pusieron en slides.

Distribution bot vuelve al brief de ángulo y pregunta qué parte de la idea encaja con el patrón de consumo de cada plataforma. Para X puede aislar la afirmación más filosa, un dato sorprendente, una secuencia de build o un clip de autoridad. Para LinkedIn, la lección de operador, la decisión interna o el workflow antes/después. Para un carrusel, el framework que se vuelve más claro visualmente. Para video, una narrativa hablada alrededor de la tensión, la demostración y el resultado. Para la newsletter, el matiz, los ejemplos y el contexto personal que sobrecargarían un post corto.

El requisito es simple: cada asset debe darle a alguien una razón para consumirlo aunque ya haya visto otra parte de la campaña.

6. Editor: protege toda la operación

El editor recibe todos los assets juntos, no uno por uno. Eso le permite detectar problemas que una revisión por plataforma no vería: cinco hooks haciendo la misma afirmación; la misma historia de apertura repetida en todos lados; hechos sin soporte introducidos durante el repurposing; tono que deriva entre plataformas; un carrusel que no agrega valor más allá del artículo; un CTA que no coincide con la etapa del lector; una plataforma que recibe mucho menos contenido útil que las otras.

El editor puede aprobar, pedir una revisión o rechazar un asset. No puede publicar. La cola de revisión humana debería mostrar el copy final, la fuente de soporte, la plataforma prevista, el media y la decisión requerida. No deberías tener que reconstruir cómo llegó el equipo al output antes de aprobarlo.

Hacé cada handoff inspeccionable

Un equipo multi-bot falla cuando un bot devuelve prosa y el siguiente tiene que adivinar qué partes importan.

Dale a cada campaña un único registro que viaja por el sistema: campaign (nombre); status (etapa); signal (evento, fuente, urgencia, pregunta de audiencia); research (afirmaciones verificadas, fuentes, clips de autoridad, contradicciones, incógnitas); angle (lector, resultado, tensión, tesis, objeto reutilizable); flagship (formato, path, estado de aprobación); distribution (assets por plataforma); review (issues y decisión final); performance (observaciones y cambios de regla propuestos).

El registro hace dos trabajos: le da al siguiente bot un input predecible, y te permite inspeccionar la historia de la campaña sin reabrir seis conversaciones. Si falta un campo requerido, el bot devuelve la tarea a la etapa anterior. No llena el vacío con una suposición plausible.

Armá el equipo en Hermes

Creá un perfil aislado para cada rol y cloná la misma configuración base en los seis para que compartan modelo y capacidades centrales manteniendo sesiones y memoria separadas. Poné el contrato de cada rol en el archivo de identidad de ese perfil y apuntá el working directory de cada uno al mismo vault de media-company, restringiendo los archivos que cada rol puede modificar.

Después activá bot mode y agregá los seis perfiles al roster con nombres reconocibles. Mantené una sala persistente para la media company donde puedas ver preguntas e intervenciones sin mezclarlas en el registro durable de campaña.

Usá conversación para coordinación. Usá archivos y kanban para estado.

Creá un board de kanban para la media company, arrancá el dispatcher y asigná la primera campaña al signal scout. El board se vuelve el camino de producción visible desde discovery hasta review final. Kanban guarda tareas y handoffs en un board durable: una tarea puede esperar dependencias, moverse a review, sobrevivir reinicios, llevar comentarios y volver al perfil correcto cuando se requieren cambios. Es una mejor mesa de producción que pedirle a un bot que le escriba al siguiente esperando que el contexto sobreviva.

La primera campaña: usá el sistema para construir el sistema

El primer assignment perfecto es el sistema mismo. Señal: bot mode de Hermes como evento, y la media company unipersonal como workflow candidato. Researcher chequea la documentación oficial y los tests de la comunidad, y registra qué hacen realmente bot mode, profiles y kanban, además de la distinción entre colaboración visible y ejecución durable de tareas. El estratega toma esa evidencia y hace la decisión editorial: lector (creator o operador que publica en varias plataformas); resultado (armar una operación de contenido de seis bots alrededor de un cerebro compartido); tensión (escribir más rápido no resuelve ideas débiles, distribución duplicada ni aprendizaje perdido); tesis (una media company unipersonal es posible cuando bots especializados comparten conocimiento aceptado y pasan trabajo estructurado por un solo feedback loop); objeto reutilizable (modelo operativo de seis roles, grafo de Obsidian y registro de handoff).

El writer construye la guía. Distribution bot crea varias puertas de entrada distintas: la capacidad (bot mode convierte seis perfiles aislados en un equipo de medios visible); la arquitectura (los bots son las personas, Obsidian es el cerebro de la empresa, kanban es la mesa de producción); el crecimiento en X (una idea principal puede sostener una semana de posts sin repetir el mismo hook); la research (signal scout y researcher frenan temas débiles antes de escribir); y el compounding (el performance actualiza los playbooks compartidos en vez de desaparecer en analytics).

El editor revisa el paquete completo, compara los hooks, chequea cada afirmación contra el paquete de fuentes y crea la cola de aprobación. Una idea recorrió el mismo sistema que la pieza terminada enseña.

Convertí la media company en un motor de crecimiento en X

No le pidas al distribution bot que resuma la pieza principal siete veces. Dale a cada post una razón separada de existir. Esta secuencia semanal funciona:

Día 1: publicá el argumento principal. Liderá con el mayor resultado y adjuntá la guía completa.

Día 2: enseñá la arquitectura. Explicá una distinción útil por completo: los bots son las personas. Obsidian es el cerebro de la empresa. Kanban es la mesa de producción. Después mostrá qué se rompe cuando esas responsabilidades se mezclan.

Día 3: usá un clip de autoridad. Adjuntá una demostración relevante y desarrollá un mecanismo que revele. El post debe ser útil sin requerir abrir la guía.

Día 4: publicá el build práctico. Compartí los seis roles, el árbol de Obsidian o el contrato de handoff como post de implementación standalone.

Día 5: desafiá el workflow común. Explicá por qué un solo chat de IA escribiendo todos los formatos crea distribución repetitiva, aunque cada borrador individual suene pulido.

Día 6: mostrá el feedback loop. Desglosá qué señales de performance deberían actualizar hooks, ángulos, reglas de plataforma o supuestos de audiencia.

Día 7: comprimí el sistema. Convertí todo el workflow en un solo visual: idea → research → ángulo → long-form → distribución → review → performance → playbooks actualizados.

El resultado es una semana de distribución conectada con siete puertas de entrada distintas. Alguien puede descubrir el sistema por el titular, la arquitectura, el clip, el build, la crítica, el feedback loop o el visual. Eso es mucho más fuerte que publicar el mismo link siete veces.

Mantené al humano en la frontera editorial

La primera versión debe preparar todo y no publicar nada. Todavía aprobás: el ángulo central; el borrador principal; cada afirmación fáctica con consecuencias reales; cada post público; cambios de voz, audiencia, oferta o política editorial; y las lecciones de performance que se vuelven reglas permanentes.

Esto te da una forma rápida de entrenar al sistema: cada aprobación, revisión y rechazo se convierte en un ejemplo concreto de tu criterio. Cuando la misma decisión se vuelve predecible, movela antes en el playbook. El editor puede aprender que siempre rechazás superlativos sin soporte, hooks duplicados, CTAs genéricos o carruseles que solo citan la pieza principal.

Mantené la aprobación de publicación en humanos hasta que el costo de un error sea genuinamente bajo y la cola de review sea consistentemente aburrida. La autonomía debe eliminar decisiones repetidas, no sacar tu gusto de la operación.

Hacé que el performance mejore la próxima corrida

La mayoría de los analytics de contenido se detienen en reportar números. Un sistema de aprendizaje útil cambia cómo se construye la próxima campaña.

Después de cada campaña registrá: la señal y el tema; el resultado para el lector; el ángulo central; el tipo de hook; el formato; la plataforma; impresiones o alcance; interacción significativa; clics, follows, respuestas o conversiones atadas al objetivo; qué aprobó o revisó el editor; y qué debería probarse de nuevo.

No hace falta un séptimo rol permanente de performance. Dale al editor una tarea semanal de review que compare campañas recientes y proponga cambios a los playbooks de hooks, ángulos y plataforma. Exigí que la propuesta nombre los posts que la respaldan: un resultado fuerte crea una hipótesis, no una regla universal.

El review semanal devuelve tres listas cortas: keep (patrones que funcionaron repetidamente y siguen alineados con la estrategia); test (patrones prometedores que necesitan otro intento controlado); stop (patrones débiles repetidos, formatos duplicados o trabajo caro sin resultado útil).

Vos aprobás los cambios antes de que el cerebro compartido se actualice. Esto cierra el loop: el equipo ya no arranca cada campaña desde el mismo prompt genérico. Arranca con el criterio acumulado de todo lo que elegiste conservar.

Armá la versión mínima esta semana

No necesitás seis bots totalmente autónomos el primer día. Construí en este orden:

  1. Creá el cerebro de contenido en Obsidian con los archivos mínimos de voz, audiencia, prueba y plataforma.
  2. Creá signal scout, researcher y editor primero.
  3. Pasá tres ideas reales por señal, research y review.
  4. Agregá content strategist cuando los paquetes de evidencia sean consistentemente útiles.
  5. Agregá long-form writer cuando los briefs de ángulo sean lo bastante fuertes para limitar un borrador.
  6. Agregá distribution bot cuando un formato principal esté funcionando.
  7. Empezá a registrar performance y actualizá los playbooks una vez por semana.
  8. Mantené la aprobación humana mientras el equipo aprende tus estándares.

La primera versión útil puede simplemente devolver una oportunidad investigada, un brief de ángulo y un post de X listo para aprobar. Después agregá la pieza principal. Después el paquete de plataformas. Después el loop de performance.

El destino es una media company unipersonal. El build todavía empieza con una pieza de trabajo que puedas juzgar. Hermes aporta el equipo. Obsidian aporta el cerebro compartido. Tus decisiones les enseñan a ambos qué merece acumularse.

— Ariel Di Stefano
Preguntas Frecuentes

Sobre la media company con bots

¿Qué es una media company unipersonal?

Un sistema donde una sola persona opera la capacidad de investigación, redacción y distribución de una media company completa, usando agentes especializados con roles separados y un cerebro de conocimiento compartido.

¿Por qué seis bots en vez de uno solo?

Porque cada rol necesita una decisión que le pertenezca, un entregable definido y un punto donde detenerse. Un solo bot con instrucciones amplias produce contenido genérico; seis roles con handoffs estructurados producen un loop editorial completo.

¿Qué rol cumple Obsidian en el sistema?

Es el cerebro compartido: un vault markdown con voz, audiencia, ofertas, pruebas, hooks y playbooks que todos los bots leen. Asegura que los seis roles tomen decisiones compatibles desde los mismos estándares editoriales.

¿Cuánto tiempo lleva armar la versión mínima?

Una semana de trabajo real: crear el vault mínimo, levantar tres roles (signal scout, researcher y editor), pasar tres ideas reales por el flujo y empezar a registrar performance. Los otros tres roles se agregan cuando cada etapa produce output consistente.

¿El humano deja de aprobar contenido?

No. La regla es mantener la aprobación humana hasta que el costo de un error sea bajo y la cola de review sea consistentemente aburrida. La autonomía elimina decisiones repetidas, no el criterio editorial.

Te puede interesar