Cómo convertí el sistema de contenidos de Stavia Models en un workflow con Cursor Cloud Automation

Hace poco llevé el sistema de contenidos de Stavia Models a su siguiente etapa: de producir cada artículo con ayuda de IA a un flujo con agente en la nube que prepara páginas según un calendario.

Hoy configurar un agente en la nube ya no es la parte más difícil. Cursor Cloud Automation puede correr en horario, leer archivos, trabajar dentro del repositorio y dejar un resultado listo para revisar. La pregunta más exigente es qué le pides hacer exactamente.

Claro, puedes bajar el estándar del contenido y delegar todo al agente en la nube, desde la planificación hasta la publicación. Ese setup genera mucho contenido rápido y lo publica en páginas pulidas. No creo que eso entregue trabajo con valor comercial o reputacional real para un negocio, un producto o una marca personal.

Para Stavia Models, la instrucción a la IA no podía ser «escribe un artículo». El agente necesitaba un sistema de contenidos alrededor: lógica de producto, artículos de referencia, reglas editoriales, expectativas de fuentes, ítems de cola, patrones de diseño, chequeos de QA y un límite claro de revisión editorial.

Este caso trata de esa capa detrás de la automatización. Muestra cómo el flujo de contenidos de Stavia Models pasó de la producción asistida por IA a un workflow controlado con agente en la nube de Cursor Cloud — y por qué la calidad vino del sistema, no de un prompt ingenioso.

Funcionó porque Stavia ya tenía algo real sobre lo que trabajar.

Stavia Models tiene su propia lógica de modelado financiero: pricing, adquisición, churn, estructura de costos, costos de IA y API, nómina, cash flow, runway, financiamiento, unit economics y preparación para inversores. El sitio ya tenía un blog code-first, donde los artículos viven dentro del producto y no como archivos de texto sueltos.

Antes de crear la automatización, ya había publicado unas 20 artículos a mano o semi manualmente. No eran solo piezas de contenido. También eran material de entrenamiento para el workflow. Mostraban qué debe explicar un artículo de Stavia, qué tan práctico debe ser, cómo aparece la lógica de producto, qué patrones visuales funcionan y dónde el consejo genérico para startups se queda corto.

Si hubiera empezado con un blog vacío y le pidiera a un agente en la nube contenido SEO, probablemente habría recibido más contenido genérico, más rápido. La automatización útil empezó solo porque ya había un sistema que valía la pena automatizar.

Cuando arranqué la automatización, el blog de Stavia ya tenía un formato reconocible.

Cada artículo debía partir de una decisión real de un founder, no de un tema financiero general. La idea era mostrar cómo una decisión cambia el modelo: ingresos, costos, burn, runway, necesidad de financiamiento, unit economics o la historia para inversores.

La estructura también se aclaró con la repetición. Un buen artículo de Stavia necesita una respuesta rápida al inicio, secciones prácticas, enlaces internos que lleven al lector por una cadena de decisiones y bloques visuales que aclaren el modelo. Un bloque visual no es decoración. Ayuda a entender cómo funciona una decisión.

Lo mismo pasaba con el diseño. Mapas de modelo, diagramas de flujo, timelines, tarjetas compactas y estructuras de supuesto a resultado solían funcionar bien. Tarjetas enormes, layouts vacíos y bloques genéricos lado a lado, no.

Eso le dio al agente una referencia. No tenía que adivinar qué significaba «bueno» para Stavia. El proyecto ya tenía ejemplos.

Gran parte del sistema editorial vino de conversaciones previas en ChatGPT, donde trabajé unas 20 artículos.

Parte de mi feedback era sobre la voz. A menudo rechazaba texto que sonaba demasiado promocional, demasiado genérico o demasiado parecido a contenido de startups generado por IA. No quería que los artículos de Stavia describieran a los founders como ingenuos, repitieran las mismas estructuras, abusaran del marco «no X, sino Y» o sonaran como pitch de producto.

Pero el estilo era solo una parte. Muchos comentarios iban al fondo del artículo.

A veces pedía contexto de mercado porque el tema debía reflejar lo que pasa alrededor de startups de IA, fundraising, apps de suscripción o expectativas de inversores. A veces hacían falta benchmarks: retención, rangos de precio, patrones de conversión, lógica de costos de IA o métricas de suscripción para que los supuestos se sintieran más realistas.

En otros casos faltaba la capa de modelado. Un párrafo podía explicar la idea, pero el artículo se fortalecía con números: un escenario pequeño, una comparación simplificada o un mini modelo que mostrara cómo un supuesto cambiaba runway, margen, burn o necesidad de financiamiento. Para algunos temas también necesitábamos ejemplos reales de empresas o casos de mercado para que el material no se sintiera abstracto.

Ese feedback se volvió política editorial. La pregunta ya no era solo «¿suena a Stavia?». También era: ¿este artículo necesita fuentes frescas, benchmarks, un ejemplo de modelado, contexto para inversores, un caso de empresa o una conexión más fuerte con la metodología del producto?

Ahí ChatGPT fue útil más allá del borrador. Ayudó a convertir la revisión experta repetida en reglas reutilizables, campos de cola, checklists e instrucciones para el agente de Cursor.

El siguiente paso fue mover el flujo de las conversaciones al repositorio.

Un agente en la nube no debería depender de un prompt enorme pegado en un campo de automatización. Debería poder leer las reglas del proyecto donde ocurre el trabajo. Por eso movimos el workflow de artículos a documentación del repo: reglas editoriales, pasos de producción, formato de cola, chequeos SEO, enlaces internos, estándares visuales, lógica de routing, guía de referencias e instrucciones de automatización.

Eso cambió el proyecto. El workflow ya no vivía solo en mi cabeza ni disperso en chats de ChatGPT. Pasó a ser parte del repositorio.

Ahora el agente podía abrir los archivos relevantes, entender el sistema de artículos, trabajar dentro de la estructura de páginas existente y saber dónde detenerse.

La cola de artículos se volvió el puente entre estrategia y automatización.

Un calendario de contenido simple no alcanzaba. El agente necesitaba más que un título y una keyword. Cada ítem debía funcionar como un brief de producción: ángulo, lector objetivo, diferenciación frente a artículos existentes, puntos obligatorios, reglas de qué evitar, flags de chequeo de fuentes, chequeos de metodología de producto, prioridades de enlaces internos y ruta de la portada.

Dos campos fueron especialmente útiles: «por qué este artículo ahora» y «valor nuevo más allá del chat de IA».

Obligaban a cada tema a demostrar que merecía existir. La idea era sumar algo útil al sistema de contenidos de Stavia —una decisión de modelado nueva, un problema de negocio actual de la era IA, una discusión de benchmarks, un ejemplo práctico o una explicación más fuerte de la lógica para inversores— y no publicar más solo porque la automatización lo permitiera.

Antes de crear la automatización diaria, probé el workflow a mano en modo Cursor Agent.

El primer artículo de prueba trataba sobre use of funds en startups. Al inicio, el tema corría el riesgo de solaparse con artículos existentes de Stavia sobre proyecciones para inversores, financiamiento, runway y milestones. Un artículo genérico de use of funds habría repetido demasiado.

Por eso agregamos un paso de diferenciación en el cluster. El artículo nuevo debía tener un ángulo más claro: use of funds como capa de traducción entre el fundraising ask y el operating model.

Eso hizo el material más específico. Podía enfocarse en allocation vs sequencing, committed vs flexible spend, learning budget vs scaling budget, milestone evidence, monthly burn, impacto en runway y escenarios de trade-off.

Cursor leyó el ítem de cola, la documentación editorial, el production workflow, la guía de diseño, las reglas de enlaces internos y el registro de artículos. Luego creó la página, eligió artículos relacionados, usó la ruta de la portada, actualizó el route, corrió chequeos y preparó la rama.

El primer resultado fue mejor de lo que esperaba, pero no perfecto. La apertura tenía demasiados enlaces internos y algunos bloques visuales eran débiles. Refinamos la página, actualizamos la documentación y llevamos la corrección a la siguiente corrida. Con el segundo artículo, quedé conforme con el primer resultado del agente y lo publiqué sin cambios.

Aunque el resultado fue mejor de lo esperado, no planeaba publicar sin preview. La revisión editorial sigue haciendo la página más precisa y mejora el sistema para el siguiente artículo.

El esquema de revisión es una de las partes más útiles de este workflow: planificación de contenido, cola estructurada, ramas de GitHub, previews de Vercel y publicación final.

El proceso sigue empezando con estrategia y criterio editorial. No dejo que el agente en la nube elija al azar el siguiente tema. Primero preparo el plan de contenido con ayuda de IA: temas, ángulos, lector objetivo, diferenciación frente a artículos existentes, necesidad de fuentes, ejemplos de modelado, puntos obligatorios, puntos a evitar, prioridades de enlaces internos y assets de portada.

Ese plan se convierte en un archivo de cola estructurada en el repositorio. El agente de Cursor Cloud revisa la cola cada día, toma el siguiente ítem aprobado, lee la documentación del repo y crea una página de artículo en una rama.

Antes de la automatización, la producción avanzaba por etapas. Primero trabajábamos el texto: lógica del artículo, estructura, ejemplos, fuentes, tono y valor práctico. Luego Cursor convertía el borrador aprobado en una página code-first. Después revisaba la página otra vez, porque un texto que funciona en un documento también tiene que funcionar dentro del layout real del sitio.

En el nuevo workflow, gran parte del feedback editorial y de diseño vive en la documentación. El agente lee la cola, las reglas de artículos, los patrones de diseño, la guía de enlaces internos, las expectativas de chequeo de fuentes y el production workflow antes de crear la página. Aplica la versión documentada de mi lógica de revisión mientras arma la página, no solo mientras redacta el artículo.

Técnicamente, el setup es simple. Cursor crea el artículo en una rama separada de GitHub, y esa rama dispara un preview de despliegue en Vercel. En lugar de publicar directo en el sitio en vivo, el sistema me da un enlace de preview donde leo el artículo casi como si ya estuviera publicado.

Puedo abrir ese preview desde la laptop o el teléfono y revisar una página casi lista para publicar: estructura, texto, visuales, enlaces internos, ritmo de página y comportamiento en móvil. Ya no parto de un borrador temprano imaginando cómo se sentirá la página después.

Si todo funciona, fusiono la rama con main y el artículo queda en vivo. Si veo un ángulo más fuerte, un ejemplo faltante, un bloque visual débil o un lugar donde el artículo puede ser más preciso, comento y lo mando a otra iteración.

Ese es el límite de revisión que quería: sigo siendo dueña de la estrategia, la dirección del contenido y el juicio final, mientras el agente prepara la siguiente página aprobada y la lleva al punto donde revisar es práctico.

Después de que la primera prueba funcionó, moví el proceso a Cursor Cloud Automation.

La automatización diaria tiene un trabajo acotado: leer la cola de artículos y la documentación del repo, procesar un ítem aprobado, crear la página en una rama, validar el trabajo, actualizar el estado de la cola y detenerse para revisión editorial. Si otro artículo ya espera revisión, no crea uno nuevo.

La regla de «un artículo activo a la vez» mantiene el sistema útil en lugar de ruidoso. No quiero diez ramas de IA sin terminar. Quiero una página revisable en el momento correcto.

Aquí el lado técnico resultó menos dramático de lo que suena. Crear una automatización en la nube ya no es la parte difícil. El setup necesita un horario, un repositorio, un bloque de instrucciones y acceso a los archivos correctos.

Lo más exigente es decidir qué debe leer el agente, qué debe cambiar, qué nunca debe decidir solo y dónde debe detenerse. Cuando esos límites quedaron claros, el prompt de automatización pudo mantenerse relativamente corto porque el workflow real ya vivía en el repositorio.

Cuando la producción diaria funcionó, la siguiente pregunta fue el mantenimiento.

Un sistema de contenidos en crecimiento no solo necesita artículos nuevos. Los artículos antiguos necesitan mejores enlaces hacia piezas nuevas, y las afirmaciones basadas en fuentes requieren chequeos periódicos.

El primer workflow de mantenimiento fue el de enlaces internos semanales. Puede ser de riesgo relativamente bajo si el alcance es estricto: actualizar solo enlaces internos útiles o referencias a artículos relacionados, sin reescribir el artículo, sin cambiar metadata, sin tocar código de producto.

El segundo workflow es un freshness watch. Es más sensible porque trata benchmarks, contexto de mercado, precios de API, condiciones de financiamiento y afirmaciones basadas en fuentes. Por eso debería crear un reporte o un PR revisable en lugar de cambiar contenido publicado en silencio.

La regla es simple: el nivel de riesgo de la tarea define el modelo de revisión.

Cuando el workflow empezó a correr, algunas cosas me sorprendieron.

La IA ya puede producir texto, páginas y assets más rápido que el trabajo manual. Esa no es la parte interesante de este caso.

La lección más útil es que la automatización de contenido con IA solo se vuelve valiosa cuando el trabajo detrás se hace legible para el sistema.

Para Stavia, el agente en la nube pudo trabajar porque el sistema de contenidos ya tenía metodología de producto, experiencia de consultoría, artículos anteriores, criterio editorial, estándares de diseño, lógica de enlaces internos, expectativas de benchmarks, ejemplos de modelado, chequeos de fuentes y revisión editorial.

El agente no creó esa expertise. Hizo repetibles partes del flujo de producción de artículos.

Eso es lo que otros expertos pueden adaptar. Un consultor, educador, founder o equipo no necesita empezar con una automatización perfecta. La pregunta práctica de inicio es más simple: ¿qué trabajo repito seguido y qué necesitaría saber un agente de IA para preparar la siguiente versión con responsabilidad?

Normalmente la respuesta es una base de fuentes, un resultado de referencia, reglas documentadas, una cola estructurada de tareas, un artefacto revisable y un ciclo claro de aprobación humana —no solo un mejor prompt.