Primero las reglas, la IA después

Cada equipo de contenido con el que he trabajado tiene una versión del mismo problema. Con el paso de los años, un CMS se llena de cosas que nadie recuerda haber creado: la misma imagen hero subida cuatro veces con cuatro nombres distintos, entradas a las que ya nada enlaza, referencias que apuntan a contenido eliminado o que se remiten a sí mismas, entradas de "prueba-no-publicar" que de todas formas fueron publicadas, y campos de esquema que alguien añadió para una campaña de hace dos temporadas. Nada de esto rompe nada por sí solo, así que rara vez se le da prioridad. Simplemente hace que el stack sea más lento para trabajar y más difícil de confiar, hasta que alguien finalmente reserva una semana para una auditoría manual.

Cuando nuestro equipo se inscribió en el hackathon de socios de Contentstack este verano, ese era el problema que queríamos abordar. Muchas de las ideas agénticas más evidentes en el espacio de los CMS giran en torno a la generación de contenido, pero nosotros queríamos explorar un agente capaz de cuidar el contenido que una empresa ya tiene, porque en los stacks de gran escala con los que trabajamos, la deuda crece más rápido de lo que cualquiera puede limpiarla. El resultado fue Curator, un agente de gobernanza para Contentstack. Lo presentamos en vivo en el área de patrocinadores de ContentCon US 2026 en Chicago, donde ganó la edición norteamericana del hackathon.

Curator rastrea un stack de Contentstack y le asigna una puntuación de salud del 0 al 100. La puntuación se construye a partir de seis áreas:

• Activos duplicados
• Referencias, incluyendo entradas huérfanas y enlaces rotos o circulares
• Contenido obsoleto y de prueba
• Campos de esquema sin uso
• Publicación
• Personalización, que abarca audiencias vacías, variantes duplicadas y contenido de variantes huérfanas en Contentstack Personalize

Curator funciona mediante un ciclo continuo. Analiza el contenido del stack, propone correcciones, las ejecuta una vez que una persona las aprueba y verifica el resultado mediante una nueva auditoría y puntuación. Los editores pueden ver todo esto en un panel de pantalla completa que se ejecuta dentro de Contentstack como una aplicación del Marketplace, por lo que nunca tienen que salir de la herramienta con la que ya trabajan.

El panel está diseñado para hacer visible la deuda invisible. Incluye un muro de clústeres de activos duplicados, un gráfico de las relaciones entre referencias que muestra huérfanos y bucles, y un mapa de calor de los campos que están siendo utilizados. Verlo todo organizado suele cambiar la conversación, porque "algún día deberíamos limpiar el CMS" se convierte en una lista concreta de tareas con una puntuación asociada.

La decisión más importante que tomamos desde el principio fue determinar hasta qué punto debíamos permitir que Curator actuara por cuenta propia.

La mayoría de la deuda de contenido tiene una definición precisa. Las imágenes duplicadas, las entradas huérfanas, las referencias rotas o circulares, los campos sin uso y los problemas de publicación pueden identificarse mediante reglas, por lo que Curator los detecta con código determinista. Los corrige de la misma manera, a través de la API de gestión de contenido. El archivado de entradas, la cuarentena de recursos y la eliminación de campos se ejecutan de forma idéntica en cada ocasión, de una manera que podemos probar y auditar. Cuando algo parece incorrecto, hay un único lugar donde buscar, y nadie tiene que explicarle a un cliente que un modelo de lenguaje editó su contenido en producción por iniciativa propia.

Parte del trabajo sí requiere criterio. Determinar si una entrada llamada "Banner de Navidad v2 FINAL" es contenido activo o datos de prueba residuales implica leerla en contexto, y las reglas no lo manejan de forma perfecta. Actualmente, Curator marca esos casos y deja la decisión en manos de un editor. Ese es el único lugar donde vemos un rol para la IA: un modelo que clasifica los casos ambiguos y explica su razonamiento, mientras que las correcciones continúan ejecutándose con el mismo código determinista.

La detección de duplicados sigue el mismo enfoque. Para comparar imágenes, Curator descarga cada una en la memoria del motor, que en el despliegue actual es una función serverless de Vercel. Allí, sharp reduce la imagen a una cuadrícula en escala de grises de 9×8 y conserva dos huellas digitales de 64 bits, tras lo cual los bytes de la imagen se descartan. No se escribe nada en disco, y las imágenes nunca se envían a un servicio de IA de terceros ni a ningún otro servicio. Los ciclos de referencias y los elementos huérfanos se obtienen mediante análisis de grafos con graphology.

Un agente que modifica contenido en vivo debe ser seguro por diseño, por eso incorporamos varias capas de protección en Curator:

• Protección de ramas. De forma predeterminada, las correcciones se envían a una rama que eliges en la aplicación, y las ramas main y production están protegidas. El motor admite una anulación para los equipos que deseen modificar esta configuración.
• Vista previa y simulación en seco. Antes de realizar cualquier cambio, Curator muestra exactamente lo que tiene previsto hacer y simula el resultado.
• Aprobación humana con un solo clic. Nada se ejecuta hasta que una persona da su visto bueno.
• Reversión para la mayoría de los cambios. La mayoría de las correcciones se pueden deshacer, y la reauditoría muestra si la puntuación realmente mejoró. Eliminar un campo borra sus datos de forma permanente, por lo que ese paso requiere una confirmación adicional.

Para el hackathon, ejecutamos Curator contra un stack inicializado con un desorden realista al estilo minorista. Un seeder de un solo comando inyecta clústeres de activos duplicados, huérfanos, bucles de referencias, referencias rotas, entradas obsoletas y de prueba, borradores y campos muertos; además, puede restablecerse para que la demo se ejecute de la misma manera cada vez. Obtuvimos acceso a la API de Personalize después de que el evento comenzó, a tiempo para incluir la personalización en la demo de ContentCon. En el evento, Curator se conectó al stack, lo puntuó en las seis áreas, procesó un conjunto de correcciones previsualizadas y volvió a puntuar el stack para mostrar la mejora.

Los equipos que desarrollan agentes para actuar en sistemas empresariales se enfrentan a la misma pregunta que nosotros: cuánto permitirle decidir al sistema por su cuenta. Comenzar con reglas para todo lo que puede definirse con precisión, incorporar un modelo solo para las decisiones que requieren criterio, contar con una persona que apruebe los cambios y tener lista una reversión siempre que sea posible, es un patrón que aplica a catálogos de comercio, gestión de pedidos y cualquier otro sistema donde los errores de un agente llegan a los clientes. Si tu equipo está evaluando cuánta autonomía otorgarles a los agentes en tu propio stack, con gusto podemos intercambiar experiencias.