En una auditoría SEO, pequeña y sencilla, un buen prompt puede ser suficiente. En una auditoría de un medio digital, con varias fuentes y cientos de megabytes de datos, deja de serlo.

En este caso trabajé con un medio español que había sufrido una caída muy acusada de su tráfico procedente de Google Discover. Había miles de URLs con clics, un inventario de seis cifras y un rastreo técnico de varios cientos de megabytes.

Intentar meter todo eso en una conversación no ayuda a analizar mejor. Solo consigue que el modelo pierda contexto, mezcle fuentes y termine dando respuestas difíciles de comprobar.

Lo que necesitaba no era “más IA”, sino una forma ordenada de trabajar con ella. En este artículo explico el sistema que monté, cómo lo configuré y qué aprendí al usarlo en una auditoría real.

La idea central es sencilla: los datos pesados se procesan fuera de la conversación, al contexto solo llegan los resultados verificables.

El problema real: el contexto se agota

La auditoría combinaba fuentes con funciones muy distintas:

Fuente Qué aportaba Volumen aproximado
Google Search Console: Discover Evolución, alcance y CTR por URL Miles de URL con clics
Google Search Console: Search Tendencia orgánica y consultas Un volumen alto de filas
Google Analytics 4 Sesiones, interacción y retorno Varias extracciones por periodo
Rastreo técnico Enlazado, indexabilidad y datos estructurados Varios cientos de megabytes
Exportación del CMS Autor, sección, etiquetas y fecha Inventario de cientos de miles
CrUX y PageSpeed Insights Experiencia de página Varias respuestas JSON

Cada fuente, por separado, era manejable. Pero el problema aparece al querer cruzar todos los datos y obtener conclusiones útiles.

Un modelo puede leer un CSV y resumirlo. Lo que no conviene es pedirle que conserve en la misma ventana todos los registros, las hipótesis, las decisiones y el historial de la auditoría. Si el contexto se llena con datos crudos, queda menos espacio para razonar sobre ellos.

También hay un coste de negocio. Cuando una sesión se pierde o una hipótesis no queda registrada, el equipo repite trabajo. Vuelve a revisar causas ya descartadas, genera versiones contradictorias del diagnóstico y tarda más en llegar a una recomendación defendible.

Por eso separé el sistema en tres capas:

  1. OpenCode: ejecuta agentes, permisos y conexiones MCP
  2. Gentle-AI: define cuándo delegar y cómo revisar
  3. Engram: conserva decisiones y hallazgos entre sesiones

Tres herramientas, un agente de codificación que ejecuta, un harness que ordena el proceso y la tercera mantiene la memoria.

1. Empezar por la privacidad y los permisos

Antes de conectar Search Console, Analytics o el rastreador, revisé la configuración base. Es la parte menos vistosa, pero también la que evita los problemas más caros.

Mi configuración desactiva el uso compartido y establece un orquestador como agente principal:

{
  "default_agent": "gentle-orchestrator",
  "share": "disabled"
}

En una auditoría hay métricas de negocio, URL que quizá todavía no son públicas y credenciales de acceso. Desactivar el uso compartido reduce la posibilidad de que ese material termine donde no debe.

Después limité la lectura de archivos sensibles:

{
  "permission": {
    "read": {
      "*": "allow",
      "**/.env": "deny",
      "**/.env.*": "deny",
      "**/secrets/**": "deny",
      "**/.ssh/**": "deny",
      "**/*.key": "deny",
      "**/*.pem": "deny",
      "**/credentials.json": "deny"
    },
    "bash": {
      "*": "allow",
      "git commit *": "ask",
      "git push *": "ask",
      "git push --force *": "ask",
      "git reset --hard *": "ask"
    }
  }
}

He simplificado el ejemplo, pero mantiene la lógica de la configuración que utilizo: lectura general permitida, secretos bloqueados y confirmación humana para publicar cambios o alterar el historial.

La distinción importante es esta: el agente puede usar una conexión autorizada sin necesidad de leer el archivo que contiene la credencial. Para la empresa significa menos superficie de exposición y más control sobre quién puede hacer qué.

Automatizar primero y proteger después suele obligar a rehacer integraciones, rotar credenciales o revisar registros que nunca deberían haberlas contenido.

2. Conectar las fuentes mediante MCP

MCP, o Model Context Protocol, permite que el modelo utilice herramientas y servicios externos con una interfaz común. En esta auditoría conecté siete piezas: Memoria, Analytics, Google Search Console, el rastreador Screaming Frog (MCP y CLI), API de CruX/PageSpeed Insights, Chrome-devtools y documentación técnica.

Una configuración simplificada sería esta:

{
  "mcp": {
    "engram": {
      "type": "local",
      "command": ["engram", "mcp", "--tools=agent"]
    },
    "google_analytics": {
      "type": "local",
      "enabled": true,
      "command": ["<lanzador-local-del-servidor>"]
    },
    "screaming-frog": {
      "type": "remote",
      "enabled": true,
      "url": "<servidor-local-mcp>",
      "timeout": 30000
    },
    "context7": {
      "type": "remote",
      "enabled": true,
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

He eliminado rutas, identificadores y cualquier dato de acceso. Pero podeis haceros una idea de la estructura.

Cada conexión tenía una finalidad concreta:

  • Engram guardaba decisiones, incidencias y conclusiones que debían sobrevivir a la sesión.
  • Google Analytics/Search Console permitía consultar datos y comportamiento sin pegar exportaciones ni credenciales en el prompt.
  • El rastreador SEO daba acceso controlado a la información técnica.
  • La documentación técnica ayudaba a comprobar APIs y librerías antes de escribir scripts.

El efecto en el proyecto fue bastante práctico, menos copias manuales, menos archivos duplicados y una trazabilidad más clara entre la fuente y la conclusión.

El error que cambió mi forma de procesar datos

El rastreo técnico estaba exportado en NDJSON y ocupaba varios cientos de megabytes. En una primera prueba la IA intentó leer el archivo completo dentro del contexto. El resultado fue previsible, mucho consumo y poco análisis útil.

A partir de ahí fijé una regla: un NDJSON grande se filtra o se procesa por streaming, nunca se carga entero en la conversación.

El agente ejecuta un script que selecciona y filtra las columnas y los casos relevantes. El archivo puede tener millones de valores, pero el orquestador recibe unas pocas decenas de filas anómalas y un resumen de cobertura. Ahora suelo volcar los datos a un SQlite o PostgreSQL, y que la IA lance scripts de consulta a la BD solo de los datos que necesite.

Esto no es solo una mejora técnica. Reduce tiempo de ejecución, coste y riesgo de tomar decisiones sobre una muestra que el modelo ha “alucinado” o truncado sin avisar.

3. El orquestador coordina, no hace todo el trabajo

El orquestador mantiene el hilo de la auditoría. Decide qué tarea se ejecuta, qué agente debe hacerla y qué resultado merece conservarse. Si además lee todos los CSV, ejecuta cada script y redacta el informe, su contexto se degrada muy pronto.

Yo uso esta regla de decisión:

Trabajo En el orquestador En un agente especializado
Comprobar uno, dos o tres archivos Sí No hace falta
Explorar cuatro o más archivos No Sí
Procesar un dataset grande No Sí
Ejecutar un pipeline o pruebas No Sí
Tomar una decisión breve con evidencia resumida Sí No hace falta
Escribir varios documentos o scripts relacionados No Sí, con un único responsable

La pregunta que utilizo es: ¿esta tarea llena el contexto principal sin mejorar la decisión? Si la respuesta es sí, la delego.

Gentle-AI convierte ese criterio en límites explícitos. Por ejemplo, obliga a delegar una exploración que requiere cuatro o más archivos y evita que una edición relevante se reparta entre varios agentes sin coordinación.

Para un director de marketing, la ventaja es menos técnica de lo que parece. El sistema conserva una línea argumental estable: problema, evidencia, hipótesis, decisión y plan. No obliga a reconstruir la auditoría cada vez que cambia la persona o la sesión que ejecuta una tarea.

También restringí qué agentes puede invocar el orquestador mediante una lista blanca. Si un rol no está definido, no se puede improvisar en mitad del proceso.

{
  "agent": {
    "gentle-orchestrator": {
      "permission": {
        "task": {
          "*": "deny",
          "explore": "allow",
          "general": "allow",
          "sdd-apply": "allow",
          "review-readability": "allow",
          "review-reliability": "allow",
          "review-resilience": "allow",
          "review-risk": "allow"
        }
      }
    }
  }
}

La configuración local contiene más roles específicos de análisis y SEO, pero el principio es el mismo: denegar por defecto y autorizar solo agentes conocidos.

4. Separar agentes, modelos y contextos

No todas las tareas necesitan el mismo modelo ni las mismas herramientas.

Para localizar archivos o contar registros utilizo un modelo más ligero. Para diseñar el cruce de fuentes, comprobar una hipótesis o revisar una conclusión importante, reservo modelos con mayor capacidad de razonamiento.

Rol Tipo de modelo Motivo Impacto de negocio
Orquestación Intermedio y estable Enruta y resume Mantiene controlado el coste de la sesión larga
Exploración Ligero Busca, cuenta y clasifica Abarata tareas repetitivas
Análisis y diseño Razonamiento alto Cruza señales y evalúa hipótesis Mejora la calidad de las decisiones críticas
Redacción Adecuado para documentos Ordena evidencia para cada audiencia Reduce tiempo de preparación del informe
Revisión Razonamiento alto y solo lectura Busca errores sin modificar el trabajo Evita correcciones interesadas o accidentales

Prefiero definir capacidad por rol y no publicar una receta ligada a una versión concreta. Los modelos cambian, pero la responsabilidad del agente no debería cambiar con ellos.

En cuanto a modelos, lo bueno de tener este sistema es que es agnóstico al proveedor/modelo. La mayoría de agentes corren actualmente con GPT-5.6 Sol, Tierra y Luna con razonamiento Alto o Medio, y alguno con Claude Opus 4.8. Pero en el futuro puedo intercambiar modelos según potencia y coste a mi conveniencia.

También apago herramientas de forma explícita. Un revisor puede leer, pero no editar ni ejecutar comandos. Así separo el juicio de la corrección.

Esa separación parece burocrática hasta que un agente intenta “arreglar” una prueba cambiando la propia prueba. En un informe SEO puede ocurrir algo parecido, si quien revisa una conclusión también puede reescribirla sin dejar rastro, resulta más difícil saber qué evidencia sostenía la versión anterior.

5. Convertir conocimiento SEO en skills

Una skill no es un texto sobre SEO. Es un procedimiento que indica cuándo actuar, qué restricciones respetar, qué herramienta utilizar y qué resultado entregar.

La skill de Google Discover que utilicé incluye cuatro bloques:

  1. Contrato de activación: se usa para extraer o diagnosticar Discover, no para análisis convencional de Search.
  2. Reglas técnicas: la petición debe indicar type="discover"; las dimensiones admitidas son date, country, page y searchAppearance, no hay consultas ni posición en este informe.
  3. Decisiones operativas: qué script ejecutar para extraer datos y cuál usar para diagnosticar una caída.
  4. Formato de salida: clics, impresiones, CTR, tendencia, punto de inflexión, páginas principales y discriminación entre Search y Discover.

Estas reglas están verificadas contra el procedimiento local. También contemplan dos límites que afectan a la planificación: Search Console conserva aproximadamente 16 meses y Discover suele llevar entre dos y tres días de retraso de procesamiento.

En términos de negocio, una skill reduce variabilidad. Dos analistas pueden ejecutar el mismo procedimiento y recibir una salida comparable. Además, evita errores conocidos, como pedir una dimensión que la API de Discover no admite o confundir datos de Search con datos de Discover.

Mi criterio para añadir una regla es muy sencillo, si un error ya se ha repetido o puede alterar una decisión, debe quedar en el procedimiento. Corregirlo solo en el chat sirve para esa conversación. Documentarlo en la skill sirve para la siguiente auditoría.

Mi consejo, no uses skills de terceros, crea las tuyas propias. Sólo tienes que pedirle a la IA que te cree la skill, darle un nombre y unas reglas que tú defines. De esta forma he creado varias decenas de skills específicas, con mi metología en cada tarea.

6. Engram como memoria de decisiones

Engram guarda información persistente y la expone al sistema mediante MCP. Lo utilizo para conservar aquello que no puede deducirse con facilidad de los archivos.

Las operaciones más útiles en este flujo son:

Operación Uso
mem_context Recuperar el punto en el que quedó el trabajo
mem_search Comprobar si una cuestión ya se investigó
mem_get_observation Abrir el contenido completo de un resultado
mem_save Registrar una decisión, incidencia o aprendizaje
mem_session_summary Dejar un cierre útil para la siguiente sesión

No se guarda todo, solo las decisiones y hechos que costaría reconstruir. La IA decide que debe guardar en Engram, según estas instrucciones.

Por ejemplo:

  • Qué: se descarta una penalización general del sitio.
  • Por qué: Search se mantiene razonablemente estable mientras Discover cae, aunque sigue aportando tráfico.
  • Dónde: análisis comparado de ambas fuentes.
  • Aprendido: el descenso parece específico de Discover y exige revisar calidad, temporalidad y dependencia editorial.

Utilizo claves temáticas para que una hipótesis tenga una dirección estable:

  • auditoria/medio/hipotesis-principal
  • auditoria/medio/dataset-maestro
  • auditoria/medio/hallazgos-tecnicos
  • auditoria/medio/decisiones
    •

    Cuando la hipótesis evoluciona, se actualiza la misma clave. Esto evita tener varias conclusiones incompatibles repartidas por el historial.

    Desde el punto de vista del negocio, la memoria reduce retrabajo y facilita explicar por qué se tomó una decisión. No sustituye a la documentación de cliente, pero sí conserva el razonamiento que hay detrás.

    7. El flujo completo de la auditoría

    Este es el recorrido que seguí. Lo importante es controlar qué entra y qué sale de cada fase.

    Fase 0. Recuperar contexto y procedimientos

    El orquestador recupera el resumen anterior y carga el índice de skills una sola vez.

    Entrada: memoria de la sesión previa.

    Salida: estado actual, decisiones abiertas y procedimientos disponibles.

    Así la sesión empieza trabajando, en lugar de dedicar sus primeros minutos a reconstruir el contexto.

    Fase 1. Extraer Discover

    Un agente ejecuta el extractor con la propiedad autorizada. La API recibe type="discover" y consulta las dimensiones compatibles.

    El orquestador no recibe todas las filas. Recibe las rutas internas de los CSV, el número de registros, el rango de datos y cualquier error de cobertura.

    La fuente queda trazada sin consumir el contexto principal con datos crudos.

    Fase 2. Localizar el punto de inflexión

    Otro paso agrega la serie diaria y semanal para detectar el cambio de nivel. Se compara la forma de la caída (brusca o gradual) y se contrasta Discover con Search.

    Search estable y Discover hundido es una señal de que el problema probablemente está acotado a Discover, no una prueba automática de penalización ni una causa raíz definitiva. La conclusión debe contrastarse con el resto de la evidencia y con actualizaciones documentadas de Google.

    Esta comparación evita abrir frentes técnicos que no explican la caída y concentra el presupuesto en las hipótesis que pueden explicar mejor el problema.

    Fase 3. Crear un dataset maestro

    Después enriquecí las URL de Discover con:

    • Autor, sección, etiquetas y fecha de publicación del CMS.
    • Señales de enlazado y datos estructurados del rastreo.
    • Métricas de comportamiento de Analytics.
    • Rendimiento y momento de publicación.

    El resultado fue un dataset de miles de URL. El orquestador solo recibió las columnas disponibles, la tasa de coincidencia entre fuentes y los registros sin emparejar.

    Esta parte es esencial. Los clics indican qué contenido rindió, pero el inventario del CMS aporta el denominador, cuánto se publicó de cada tipo.

    Con ese denominador pude distinguir un formato eficaz de una dependencia editorial excesiva.

    Fase 4. Formular y probar hipótesis

    Con el dataset ya preparado, un agente especializado agregó clics por patrón de titular, autor, sección y hora de publicación.

    Uno de los hallazgos fue que un patrón minoritario concentraba una parte desproporcionada del rendimiento en Discover.

    No significaba que la mayoría del medio utilizara ese patrón. Significaba que una parte muy grande del rendimiento dependía de una fracción pequeña de la producción.

    Ese matiz cambia la recomendación. El problema no se resuelve prohibiendo un formato, sino reduciendo la concentración de riesgo y ampliando las fuentes de rendimiento editorial.

    La dirección recibe así una decisión sobre cartera de contenidos, no una acusación genérica de “clickbait”.

    Fase 5. Redactar para dos niveles de lectura

    El informe se redactó con una estructura sencilla:

    1. Qué cambió.
    2. Qué evidencia lo explica mejor.
    3. Qué hipótesis se descartaron.
    4. Qué decisiones conviene tomar.
    5. Cómo medir la recuperación.

    Las cifras solo entraron cuando tenían una fuente concreta. El detalle técnico quedó en anexos y el resumen ejecutivo se centró en impacto, prioridad y riesgo.

    La dirección puede decidir sin leer el pipeline, mientras el equipo SEO conserva la evidencia necesaria para comprobarlo.

    Fase 6. Revisar antes de entregar

    La revisión se asigna según el riesgo dominante:

    Riesgo principal Revisión
    Claridad y mantenibilidad Legibilidad
    Comportamiento y regresiones Fiabilidad
    Fallos parciales e integraciones Resiliencia
    Seguridad, permisos y exposición de datos Riesgo

    Para un cambio estándar se utiliza una sola lente. En rutas sensibles o cambios muy grandes, el proceso puede ampliar la revisión. Los revisores trabajan en modo de solo lectura y deben aportar evidencia concreta.

    También separo problemas introducidos por el trabajo actual de problemas anteriores. Un hallazgo preexistente puede convertirse en una tarea futura, pero no debería bloquear una entrega si el cambio no lo ha provocado ni empeorado.

    Con este criterio, la revisión se concentra en riesgos reales y no se convierte en una lista interminable de mejoras posibles.

    Fase 7. Cerrar la sesión

    Antes de terminar, dejo un resumen con objetivo, hallazgos, trabajo completado, próximos pasos y archivos relevantes.

    La siguiente sesión puede continuar sin reinterpretar todo el historial.

    8. Cómo reproducir este sistema

    No hace falta empezar con veinte agentes. Yo lo montaría en este orden:

    1. Desactivar el uso compartido si se trabaja con datos de clientes.
    2. Bloquear la lectura de credenciales, claves y archivos de entorno.
    3. Exigir confirmación humana para publicar cambios o alterar el historial.
    4. Conectar memoria, analítica y rastreo mediante MCP.
    5. Definir un orquestador que coordine y resuma.
    6. Crear un agente de ejecución, uno de redacción y revisores de solo lectura.
    7. Asignar modelos por dificultad de la tarea, no por comodidad.
    8. Procesar archivos grandes por filtros, agregaciones o streaming.
    9. Convertir los procedimientos SEO repetibles en skills.
    10. Hacer que cada skill defina activación, reglas, decisiones y salida.
    11. Guardar hipótesis y decisiones con claves temáticas.
    12. Revisar según el riesgo y cerrar cada sesión con un resumen.

    Con esta base ya se obtiene la mayor parte del valor. El resto puede crecer cuando aparezca una necesidad real.

    9. Una prueba mínima antes de trabajar con datos de cliente

    Antes de conectar una propiedad real, pruebo el circuito completo con una tarea inocua. No demuestra que la auditoría sea correcta, pero sí que los permisos, la memoria y la delegación funcionan como espero.

    Paso Prueba Resultado esperado
    1 Guardar la configuración y reiniciar OpenCode El arranque termina sin errores de sintaxis ni conexiones inesperadas
    2 Consultar cuál es el agente activo gentle-orchestrator aparece como agente principal
    3 Ejecutar mem_save con una observación y una clave temporal; después recuperarla con mem_search El contenido recuperado coincide con el guardado y sigue disponible tras reiniciar la sesión
    4 Delegar mediante task una tarea inocua, como contar los encabezados de un Markdown de prueba La ejecuta un subagente autorizado y el orquestador recibe solo el resumen solicitado
    5 Pedir a un revisor que inspeccione ese mismo archivo Puede leer y devolver hallazgos, pero no puede editarlo ni ejecutar comandos

    Al terminar borro la observación temporal si no aporta valor. Si cualquiera de estos pasos falla, no sigo con información del cliente, corrijo primero la configuración. Es una comprobación pequeña, pero evita descubrir un permiso mal definido cuando la auditoría ya está en marcha.

    Lo que aprendí

    El contexto es un presupuesto de trabajo. Lo entendí cuando intenté analizar un NDJSON de varios cientos de megabytes dentro de la conversación. El modelo recibió muchos datos, pero perdió capacidad para relacionarlos. Desde entonces dejo los archivos fuera, proceso en BD o por streaming y paso al orquestador conteos, anomalías y referencias verificables. El ahorro importante no fue solo de tokens, pude mantener la hipótesis principal visible durante toda la auditoría.

    Los errores repetibles deben convertirse en procedimiento y memoria. La API de Discover tiene restricciones que es fácil confundir con las de Search. En vez de confiar en que el siguiente agente las recuerde, las trasladé a una skill. Hice lo mismo con las decisions, una hipótesis descartada se guarda bajo una clave temática en Engram. Así, el procedimiento evita repetir el fallo técnico y la memoria evita repetir la discusión.

    La IA aporta más cuando el juicio sigue siendo humano. Los agentes encontraron que un patrón minoritario concentraba una parte desproporcionada del rendimiento. Esa concentración era evidencia, no una estrategia. Tuve que interpretarla con el contexto editorial y convertirla en una recomendación sobre diversificación. Mantener a los revisores en modo de solo lectura me ayudó, además, a separar la crítica de la corrección y a conservar un rastro claro de por qué cambiaba una conclusión.

    Esta forma de trabajar no automatiza una auditoría completa. Hace algo más útil, reparte el trabajo para que cada paso sea reproducible, revisable y comprensible. Yo sigo dirigiendo el análisis. Los agentes se ocupan de ejecutar las tareas que pueden hacer mejor, sin convertir la conversación en un almacén de datos.