Mi Marketing OS: el sistema que construí con Claude Code sin saber programar

Un martes sin sorpresas

El día se va en lo operativo y las decisiones que mueven el negocio se hacen entre hueco y hueco.

Llevas años con la misma sensación. El día se va en lo operativo. Coordinar el calendario, revisar borradores, montar el research, perseguir métricas, preparar la presentación. Y las decisiones que de verdad mueven el negocio, las que justifican que estés en la mesa, se hacen entre hueco y hueco, casi siempre con prisa. Compras una herramienta más para ganar tiempo. A los tres meses tienes una herramienta más y el mismo problema. El stack creció. Tu capacidad de decidir, no.

A eso me refiero con un Marketing OS. No es un robot que ocupa mi silla. Es un sistema que ejecuta el trabajo predecible para que yo dedique mis horas a lo que define el resultado: el juicio, el ángulo, la decisión final. Esa es la diferencia entre lo que la IA hace de verdad en una operación de marketing real y el hype. El dolor de partida, el operativo que se come el día, tiene solución. Y no es comprar la herramienta número once.

Para que se entienda la escala antes de seguir: lo que corre detrás son 12 agentes especializados, 82 skills, 28 pipelines y 4 clientes activos. Lo construyó alguien que no sabe programar. Yo.

Qué es un Marketing OS, y qué no es

Ninguna plataforma de software sabe cómo piensa un CMO específico. Ese conocimiento no se exporta a un SaaS.

Si buscas “Marketing OS” en Google ahora mismo, encontrarás plataformas SaaS que prometen “reunir toda tu función de marketing bajo un sistema inteligente unificado”. Algunos son buenos productos. Pero eso no es lo que construí.

Lo que construí es diferente por una razón práctica: ninguna plataforma de software sabe cómo piensa un CMO específico. No sabe qué mensajes ha aprobado para un cliente concreto. No sabe qué tono funciona con su audiencia. No sabe qué evitar porque lo probaste hace seis meses y no funcionó. Ese conocimiento vive en ti, y no se exporta a un SaaS.

Un sistema que construyes tú sí puede cargarlo. Porque tú escribes las instrucciones. Tú defines qué es una buena pieza de contenido y qué no. Tú documentas las decisiones. Y cuando el sistema aprende de tu feedback, aprende tu forma de trabajar, no una genérica.

La barrera para construir un Marketing OS nunca fue técnica. Es convertir años de criterio de marketing en instrucciones que un sistema pueda ejecutar. — Reyes Brusola, CMO

Cómo llegué aquí sin saber programar

Cuando empecé no tenía ni idea de cómo construir algo así. Invertí semanas en aprender antes de tener nada que funcionara.

La teoría suena bien. El problema es que cuando empecé no tenía ni idea de cómo construir algo así. Nada de Claude Code. Nada de agentes. Nada de APIs. Invertí tiempo, semanas, en aprender a construir antes de tener nada que funcionara.

Fui aprendiendo sobre lo que encontré en fuentes públicas. Rubén Hassid me abrió la puerta al mundo de Claude y las herramientas de IA. Ryan Doser me enseñó a arrancar con Claude Code desde cero, y algunas cosas de sistemas magníficas. Vi a The Viable Edge construir marketing systems y me inspiró a crear el mío sin tener ningún conocimiento técnico. Simon Scrapes me tradujo lo técnico a algo que podía aplicar al día siguiente. Rananjay Raj comparte skills de marketing en LinkedIn que me ayudaron a estructurar los míos. Álvaro Morales me ayudó a entender cómo funciona la IA por dentro, no solo a usarla.

Mi método no es inventar desde cero. Es observar a quien sabe, tomar lo que tiene sentido para mi forma de trabajar y adaptarlo. No copiar literal. Adaptar.

Sigo siendo principiante comparada con los expertos que sigo. Eso no ha cambiado. Lo que cambió es que ese tiempo invertido se convirtió en un sistema que hoy me cambia el trabajo de verdad.

Lo que falló de verdad (y lo que aprendí de cada fallo)

Construir un sistema así sin ser desarrolladora tiene un coste: aprendes de los fallos.

Estos son los reales, documentados. Te explico antes tres palabras que voy a usar, para no repetirlas luego. Un skill es un procedimiento escrito para que el sistema lo ejecute. Un agente es un especialista que ejecuta esos procedimientos. Un hook es una instrucción automática que salta después de cada acción del sistema.

Los sub-agentes que se cerraban solos a los 6 minutos

Le asignas una tarea a un agente y esperas a que termine. El problema que descubrí: hay un límite de tiempo duro en el sistema, alrededor de 6 minutos. Cuando se alcanza, el agente termina y suelta lo que tiene, sin avisar, sin error visible.

Por qué importa: si tiene que escribir cinco documentos y lo corta a mitad del tercero, te quedas con trabajo a medias sin saber que está a medias. La solución fue partir las tareas en lotes más pequeños con una verificación al final. Tener un sistema y no diseñarlo para sus propios límites significa que los límites trabajan contra ti.

El hook que cerraba el turno en silencio

Uno de mis hooks hacía una llamada a la IA tras cada vez que se escribía un fichero, para verificar calidad. El problema: si esa verificación devolvía “no”, el sistema terminaba el turno sin decir nada. El agente cerraba habiendo escrito un fichero de cinco, sin ningún mensaje de error.

Por qué importa: la automatización falla de formas que no ves hasta que cuentas los resultados. El fix fue cambiar esa verificación por un script determinista, que comprueba patrones en el texto en lugar de preguntar a la IA. Más rápido y más predecible. Lo que aprendí: comprobar cómo se comporta de verdad tu automatización, no dar por hecho que se porta como crees.

Diseñar un skill que ya existía

En cierto momento diseñé uno nuevo con detalle y empecé a construirlo. Ya existía. Un documento de planificación decía “pendiente”. El disco decía “hecho”.

Por qué importa: cuando planificas mucho por escrito, y en este sistema se planifica mucho, es fácil creer que lo que querías hacer es lo que hiciste. El fix fue simple: comprobar siempre contra el sistema real antes de actuar. Las notas describen la intención. El disco describe los hechos.

Lanzar en segundo plano tareas que tienen que entregar algo concreto

Algunas tareas pueden correr en segundo plano, sin que yo esté mirando. Otras tienen un compromiso de entrega: estos ficheros deben existir al final. Si lanzas las segundas en segundo plano, te puedes encontrar con que el agente cerró satisfecho, “ahora escribo los ficheros”, antes de escribirlos.

Por qué importa: el segundo plano sirve para explorar, no para entregar. Lo que tiene que entregar algo concreto se queda donde yo lo veo. Parece obvio. No lo era cuando lo descubrí.

Una semana normal del sistema

Lanzo el pipeline y corre solo, salvo en los puntos donde quiero decidir yo. Esa frontera la marco yo, a propósito, en cada flujo.

Lo abstracto se entiende mejor con la película de una semana. Esto es lo que pasa, en la práctica, con mi supervisión en los puntos marcados.

• Research de cliente y competencia. Lanzo un pipeline y corre solo: analiza el mercado, mapea a la competencia, perfila la audiencia. Antes esto eran uno o dos días de un analista juntando fuentes a mano. Ahora reviso el brief que me deja y decido qué entra. Esa parte, la decisión, sigue siendo mía.
• Un blog post bilingüe. Research, borrador en español, reescritura al inglés, SEO con datos reales de búsqueda y maquetación. El montaje completo de una pieza así llevaba varios días entre redactor y SEO. El sistema lo deja listo en horas. Yo apruebo el ángulo, corrijo la voz y firmo cada versión.
• El diseño de una newsletter. Estructura, copy, plantilla. El sistema la monta. Yo decido qué historia abre y qué se queda fuera.
• El calendario de LinkedIn. Propuesta de temas, redacción, imagen, programación. Reviso antes de que nada salga.

El patrón es siempre el mismo. Lanzo el pipeline y corre solo, salvo en los puntos donde quiero decidir yo. Esa frontera, dónde el sistema avanza solo y dónde se para a esperarme, es la parte importante. La marco yo, a propósito, en cada flujo.

Lo que cambió no es que trabaje más rápido. Es que recuperé las horas que se iban en juntar, montar y maquetar, y las puse donde aporto: analizar a un cliente, leer a la competencia, decidir el ángulo. El trabajo que justifica que un CMO esté en la mesa.

Por qué el conocimiento operativo no se vende empaquetado

Las plataformas estandarizan lo que funciona igual para cualquier empresa. Lo que un CMO senior sabe no está escrito en ningún sitio.

Las plataformas de IA para marketing son buenas en lo que pueden estandarizar: las operaciones que funcionan igual para cualquier empresa del sector. La creación de contenido genérico. Los flujos de aprobación estándar. Los informes de métricas comunes.

Lo que no pueden estandarizar es lo que un CMO senior sabe y que no está escrito en ningún sitio: que este mensaje funciona mejor con esta audiencia, que esta semana no es buen momento para publicar esto, que este cliente prefiere verlo antes de que salga aunque no esté en el proceso formal, que la voz de esta marca suena diferente en LinkedIn que en email y que la diferencia importa.

Ese conocimiento no se exporta a un SaaS. Se codifica en las instrucciones del sistema que tú construyes.

El “Marketing OS” del mercado te da una plataforma. Lo que yo construí es un sistema que sabe cómo trabajo, qué priorizo, qué no voy a aprobar y por qué. Esa diferencia es de criterio acumulado, no de tecnología.

Lo difícil no aparece en la lista de agentes y skills. Lo difícil es decidir qué construir primero, qué automatizar después y dónde poner los puntos de revisión para que la calidad no dependa de que yo esté encima de cada tarea.

Y empieza por una tarea, no por el sistema completo. Yo empecé con el calendario de LinkedIn. El sistema completo llegó después.

Sin conclusión

Si llevas 15 años tomando decisiones de marketing, ya tienes el conocimiento más difícil.

El que no se aprende en un curso ni se compra en un SaaS.

La barrera para construir un sistema así nunca fue técnica. Es de criterio: saber qué automatizar, qué dejar en tus manos y en qué orden construirlo. Eso lo tiene un operador senior y un producto de software genérico no puede replicarlo.

Empieza por una tarea. Documenta cómo la haces. Escribe las instrucciones para que el sistema la ejecute. Comprueba que funciona. Repite.

Nadie construye un Marketing OS de golpe. Construyes una tarea útil. Luego otra. Y un día descubres que tienes un sistema. El que corre este blog empezó con una. Las otras 81 llegaron después.