Cómo usamos un agente para preparar borradores, y por qué no publica nada

El primer borrador de los posts de LinkedIn de cada semana lo escribe un agente. Una persona del equipo lo lee, lo cambia y decide si sale o no. Lo contamos porque es un ejemplo pequeño y honesto de lo que llevamos tiempo defendiendo en proyectos de inteligencia artificial: automatizar procesos concretos, no sustituir el criterio de nadie.

Cuando se habla de IA y contenido suele haber dos relatos, y ninguno se parece a lo que hacemos. Uno dice que la IA escribe y el humano sobra. El otro dice que usarla es hacer trampa. Lo nuestro es más aburrido y más útil: una tarea repetitiva (preparar borradores cada semana) se automatiza, y las decisiones que importan siguen siendo nuestras.

Qué hace el sistema, paso a paso

Cada semana se ejecuta una tarea programada. Esa tarea:

1. Lee una nota de nuestro Obsidian donde está escrito el procedimiento: el objetivo, los pasos, los criterios de calidad y qué no se puede publicar.
2. Lee el calendario editorial.
3. Lee otra nota con nuestra voz y nuestros ejemplos reales.
4. Con todo eso escribe los borradores de la semana y los guarda.
5. Avisa por Slack con la lista de lo que ha dejado preparado.

Es la misma lógica de otros flujos que tenemos montados, como el briefing diario que llega a Slack: el agente lee de herramientas donde ya vive la información (por eso importa documentarlo todo) y entrega el resultado donde el equipo ya está mirando.

La decisión importante: las instrucciones no viven en el código

Si tuviéramos que quedarnos con una sola decisión de diseño, sería esta: el procedimiento está escrito en una nota de Obsidian y no dentro del código del programa.

La consecuencia práctica es que cualquiera del equipo puede abrir esa nota, cambiar un criterio y el comportamiento de la semana siguiente cambia. Sin desplegar nada, sin abrir una tarea a nadie, sin esperar a que alguien con conocimientos técnicos toque un script. Si decidimos que un tipo de post ya no nos interesa, o que hay un tema que no queremos tocar, se escribe en la nota.

Esto no es específico de los posts. Es un patrón útil en cualquier automatización con IA en una empresa pequeña: cuando las reglas de negocio son texto que entienden las personas del equipo, el sistema deja de depender de quien lo montó. Y la gente que mejor sabe qué criterios aplicar rara vez es la que mejor sabe programar.

Lo que no hace: publicar

Ningún borrador sale sin que una persona lo lea, lo corrija y decida. No es una formalidad. Es la parte del proceso que no queremos automatizar, porque es donde está el criterio: si lo que se dice es cierto, si suena a nosotros, si aporta algo, si hay algo que no deberíamos contar.

Y los borradores se editan, la mayoría bastante. Lo decimos sin rodeos porque es lo que ocurre: el agente nos ahorra el folio en blanco y una parte del trabajo de estructurar, pero el resultado final lo pone quien lo revisa. Si alguien espera que un sistema así produzca textos listos para publicar sin tocarlos, no es lo que tenemos ni lo que buscamos.

El agente es tan bueno como el contexto que le das

Lo que más hemos aprendido es dónde buscar cuando algo falla. En algún momento los borradores empezaron a salir genéricos, y la tentación natural era pensar que el problema era el modelo. No lo era. El problema era que la nota de contexto, la que recoge nuestra voz y nuestros ejemplos reales, estaba desactualizada.

Desde entonces, cuando un borrador no convence, lo primero que revisamos es lo que le hemos dado para trabajar. Es una lección que se traslada a cualquier proyecto con IA: un modelo bien instruido sobre una empresa mal descrita produce resultados que podrían ser de cualquier empresa. Mantener el contexto al día es parte del trabajo, igual que mantener actualizado cualquier otro documento del que depende algo.

Qué puedes llevarte a tu empresa

No hace falta publicar contenido para aprovechar la idea. Sirve para cualquier tarea que se repita con una estructura estable y que hoy consuma tiempo de alguien: informes periódicos, resúmenes, respuestas tipo. Lo que recomendamos, a partir de lo que nos ha funcionado:

• Escribir el procedimiento en un sitio que cualquiera del equipo pueda abrir y editar.
• Dar al agente ejemplos reales de cómo queréis que suene o se presente el resultado.
• Dejar siempre a una persona en el paso en el que hay una decisión.
• Revisar el contexto antes que el modelo cuando los resultados empeoran.

Si en tu empresa hay una tarea así y quieres valorar si compensa automatizarla, puedes escribirnos desde contacto.