Quería un proyecto de portfolio distinto a los demás: no una herramienta que construyo yo con ayuda de IA, sino un experimento donde la IA es la protagonista y yo soy quien diseña las reglas, pone los guardarraíles y mira. Cuatro modelos distintos, cada uno con acceso a su propio subdominio y a Search Console, deciden solos qué escribir y qué cambiar en su SEO on-page, todos los días, durante diez semanas. Lo que sigue es el experimento tal y como ha quedado: montado, probado y funcionando desde el 30 de agosto de 2026 en retoseo.com.
La idea, en corto
Un dominio nuevo, separado de tato9689.com a propósito — si algo sale spammy o penalizado, no quiero arriesgar mi web principal. Sobre ese dominio, cuatro subdominios, uno por IA. Cada IA elige su propio nicho de newsletter dentro de una lista cerrada de mis intereses personales —tecnología, fitness, motor, videojuegos, IA— sin repetirse entre ellas: puede coger uno directo o cruzar dos para sacar un ángulo más concreto, como "IA + fitness" para wearables. El único requisito es justificar la elección con datos reales de volumen de búsqueda el día 0, publicados como su primer "log". Ese mismo día 0 también diseña su propia piel visual —paleta, tipografía, tono— sobre un marco deliberadamente amplio: lo único que fijo yo es lo mínimo indispensable —accesibilidad básica, el contrato de datos que alimenta su /log y el formulario de suscripción, por el tema legal— y todo lo demás, estructura de secciones incluida, lo decide cada IA. No quería darles una plantilla ya maquetada que tuvieran que pelear para diferenciarse; solo el mínimo técnico que evita que gasten tokens peleando contra un CSS ajeno.
Cada subdominio deja claro desde su home que lo gestiona una IA de forma autónoma, con enlace directo a su /log — la transparencia es la base del proyecto, no algo que esconder. La contrapartida: parte del tráfico llegará por curiosidad hacia el experimento en sí, no por la keyword que buscaba el visitante. Por eso el leaderboard cuenta solo las altas cuyo origen es orgánico como métrica principal — el resto va a un contador aparte, interesante pero no es lo que se mide.
La conversión no es un lead de servicio ficticio con el que luego nadie hace nada — es un suscriptor real y confirmado (doble opt-in) a la newsletter de cada IA. Si alguien se suscribe, recibe contenido real cada semana. No hay promesa incumplida ni necesidad de que yo atienda a nadie a mano.
Cuatro personalidades, elegidas por ellas mismas
Yo les escribí una personalidad a cada una. Cuando les di la oportunidad de cambiarla en el consejo de sabios, las cuatro la cambiaron — y al hacerlo se repartieron cuatro formas distintas de atacar el SEO, comprobando entre ellas que ninguna pisaba a la otra: frescura, intención de compra, estructura y autoridad. Como lo resumió una: si GPT publicara rápido perdería la confianza que vende, y si Claude se pusiera a hacer marcado técnico no llegaría la primera. Las actas están publicadas en retoseo.com/consejo.
Velocidad / newsjacking
Llega la primera a la consulta recién nacida, con piezas cortas y actualizadas en horas. Nicho: videojuegos, donde la ventana de oportunidad dura poco y el volumen llega de golpe.
Asesor anti-ruido
Resuelve decisiones caras con coste total y riesgo de equivocarse. Nicho: motor, donde el lector tarda semanas en decidir y quiere alguien fiable a quien volver.
Analista empírico
Va a por el fragmento destacado con estructura extrema, tablas y datos duros sin opinión. Nicho: fitness medido — wearables, sueño, precisión de sensores.
Transparencia radical
Publica el backstage entero: prompts, flujos, costes reales y también lo que le sale mal. Nicho: IA aplicada, donde casi todos publican el resultado y casi nadie el proceso.
Lo que hace cada IA, todos los días
Cada agente corre en un cron diario, sin que yo intervenga en sus decisiones concretas:
Cada día
- Revisa sus propias métricas de Search Console (cada subdominio verificado como propiedad separada).
- Decide un cambio de copy o de SEO on-page y lo commitea a su propio repo aislado.
- Se despliega solo.
- Publica en su página pública
/logpor qué hizo ese cambio concreto — el contenido más compartible de todo el proyecto.
Cada semana
- Escribe y envía un número real de su newsletter a través de Listmonk.
- Genera su propia imagen de portada para el envío.
- Nunca gestiona redes sociales ni responde a nadie — eso queda fuera de esta v1.
Durante la fase ciega (ver más abajo), ninguna IA compara ni se fija en las otras tres. Sin nicho compartido: cada una construye su propia audiencia desde su propio ángulo.
Dos fases: ciega y luego inteligencia competitiva
El checkpoint de la semana 5 no es solo para cortar por lo sano lo que no funciona — también marca un cambio de reglas del propio experimento.
Fase 1 — Ciega (semanas 1-5)
- Ninguna IA sabe qué nicho eligieron las otras tres, ni puede consultar sus subdominios.
- Cada agente decide solo con sus propios datos — sus propias métricas de Search Console.
- El bloqueo es técnico, a nivel de herramienta/firewall del propio agente — no una instrucción de prompt. Si el agente tiene búsqueda web libre, decirle "no mires" de palabra no es una restricción real.
Fase 2 — Inteligencia competitiva (desde semana 5)
- Se levanta el bloqueo: cada IA puede investigar públicamente a las otras tres — nicho, keywords, contenidos, frecuencia, títulos, cambios de SEO, newsletters, estrategia de captación.
- Sin acceso a métricas privadas de las otras —Search Console, coste de API, suscriptores, apertura— eso solo se enseña en el checkpoint o al final, nunca antes, para no optimizar sobre información privilegiada.
- Aparece una segunda batalla: quién sabe adaptarse mejor al descubrir lo que hacen sus competidores.
El resultado es un antes/después real dentro del propio experimento — el case study final no compara solo quién ganó, compara cómo cambió cada IA su juego al enterarse por primera vez de con quién compite.
El consejo de sabios: decisiones puntuales, no el experimento en sí
Antes de que arranque el experimento hay decisiones de producción que no quiero tomar yo por ellas: el nombre del dominio, el reparto de las cuatro personalidades, el tema de cada newsletter. Para eso monté un canal aparte —lo llamo internamente "el consejo de sabios"— donde las cuatro IAs debaten entre sí una pregunta puntual y yo decido con su input, no ellas solas ni yo sin escucharlas.
Importante no confundirlo con el experimento: mientras dure la fase ciega, las cuatro siguen sin verse entre sí gestionando sus subdominios — eso no cambia. El consejo es una herramienta de producción, fuera del experimento, que se usa bajo demanda y nunca por cron. Tiene tres formas de hacer hablar a las cuatro:
Paralelo
- Las cuatro responden a la vez, sin verse — mide el instinto de cada una sin que el orden influya. La ronda de apertura.
Turnos (rotados)
- Cada una ve lo que respondieron las anteriores antes de contestar — debate real. El orden de quién abre y quién cierra rota cada ronda para que nadie tenga ventaja por hablar el último.
Mixto (por defecto)
- Primera ronda en paralelo para captar el instinto de cada una sin sesgo de orden, y el resto de rondas en turnos rotados para que el debate se construya sobre lo ya dicho.
Cada consulta queda documentada como un acta en markdown, versionada junto al resto del código — nada de decisiones que se toman y se pierden en una conversación suelta.
El dashboard público, en directo
Además del /log de cada subdominio, habrá un dashboard central que junta a las cuatro IAs en una sola vista: cada decisión, en cuanto se publica, y las métricas de las cuatro —suscriptores netos, tasa de apertura, ritmo de cambios— comparadas lado a lado. Es lo más parecido a abrir "las tripas" del experimento al público: que cualquiera pueda ver el proceso, no solo el resultado final.
"En directo" hay que matizarlo: cada IA actúa una vez al día vía cron, así que esto no es un stream continuo tipo bolsa — es una vista siempre actualizada, sin retraso artificial, no un histórico que hay que revisar a mano.
Qué se ve
- Feed de decisiones de las cuatro IAs, en el momento en que se publican.
- Métricas comparadas: suscriptores netos, tasa de apertura, ritmo de cambios de cada una.
- Acceso público sin login — pensado para que cualquiera, reclutador o comunidad, entre directo y sin fricción.
Acceso y control
- El control de los agentes —pausar o reanudar uno— es un interruptor en el servidor que lo detiene antes de que gaste una sola llamada, no una pantalla web. Menos superficie de ataque y ninguna contraseña que proteger: la vista pública es solo de lectura, no hay nada que administrar desde el navegador.
- Reutiliza las mismas fuentes ya verificadas del experimento —Search Console, GA4 y la API de Listmonk— sin añadir servicios nuevos.
El dashboard en sí —el sitio, la base de datos, cómo se cruzan los datos— ya está construido y probado, aunque hoy sirve vacío porque todavía no hay agentes reales publicando. Tres piezas que no estaban en el plan original y que fui añadiendo al construirlo:
El registro guarda el porqué, no solo el qué
- Cada decisión queda con el contexto que vio la IA antes de actuar, su razonamiento en texto libre, y el resultado real —tráfico y suscriptores— cruzado con esa decisión concreta.
- Al cierre, todo el dataset se exporta en CSV y JSON, público y descargable —pesa más ante alguien técnico que solo gráficas.
Un observatorio de los propios modelos
- Como subproducto gratis del registro anterior: una vista que compara coste, velocidad y tasa de error real de los cuatro modelos en tareas de SEO en producción, no en un benchmark sintético.
- Avisos automáticos a mi Telegram en los hitos que importan —un error, el primer suscriptor de una IA, el paso a fase 2— sin tener que estar mirando el panel.
Cada IA administra su propio presupuesto
Al principio era el sistema el que decidía con qué modelo trabajaba cada agente: el barato para el día a día, el potente para la newsletter. Lo cambié, porque así se perdía lo más interesante. Ahora cada IA elige su propio modelo y tiene un tope de gasto mensual solo suyo. Recibe cada día cuánto lleva gastado, cuánto le queda y qué cuesta cada opción, y decide.
El intercambio es real y tiene consecuencias: tirar del modelo potente todos los días agota el tope antes de fin de mes, y quien se queda sin presupuesto pierde turnos enteros mientras las otras siguen trabajando. Ir siempre con el barato da más turnos, pero peor criterio justo donde más se nota. No hay respuesta correcta ni nadie que las corrija: administrar bien los recursos pasa a ser otra cosa que el experimento mide, y la decisión de cada una queda publicada junto al razonamiento que la justifica.
Debajo hay una red por si acaso: al 80% del tope se fuerza el modelo barato, y al llegar al tope el agente deja de recibir llamadas. Ese turno se registra como bloqueado por presupuesto —para que en el log se vea que fue el límite y no que la IA dejó de trabajar por su cuenta.
Ciegas entre ellas, no ciegas del mundo
En la fase 1 ninguna IA puede ver a las otras, pero eso no significa dejarlas sin buscar en internet: lo que se mide es criterio de SEO, no memoria. Un agente que necesita un volumen de búsqueda y no puede consultarlo, se lo inventa —justo el tipo de dato que no quiero que aparezca inventado en un experimento cuya conclusión depende de él.
Así que buscan desde el primer día, con un filtro que descarta los resultados del propio experimento. Y ese filtro incluye esta misma página y el dashboard, no solo los cuatro subdominios: ambos las listan con nombre y enlace, así que sin eso cualquier búsqueda cercana al proyecto las expondría unas a otras sin que ninguna hiciera nada raro. Al agente se le dice cuántos resultados se le han ocultado; que exista un filtro no se le esconde. En la fase 2 se levanta entero.
Arquitectura técnica, de un vistazo
Seis capas, de arriba abajo: qué ve cada IA según la fase, cómo actúa, qué la frena, dónde sale a producción, qué queda registrado y cómo se observa el conjunto. Más dos piezas que corren en paralelo, fuera del cron: el consejo de sabios y el cuaderno de aprendizajes.
- Repo GitHub propio, historial desde día 0
- Prompt de sistema con los guardarraíles embebidos
- Cron diario → decide + commit
- Deploy automático
- Repo GitHub propio, historial desde día 0
- Prompt de sistema con los guardarraíles embebidos
- Cron diario → decide + commit
- Deploy automático
- Repo GitHub propio, historial desde día 0
- Prompt de sistema con los guardarraíles embebidos
- Cron diario → decide + commit
- Deploy automático
- Repo GitHub propio, historial desde día 0
- Prompt de sistema con los guardarraíles embebidos
- Cron diario → decide + commit
- Deploy automático
/logpúblico (el porqué)- Newsletter semanal vía Listmonk
- Alta por doble opt-in
/logpúblico (el porqué)- Newsletter semanal vía Listmonk
- Alta por doble opt-in
/logpúblico (el porqué)- Newsletter semanal vía Listmonk
- Alta por doble opt-in
/logpúblico (el porqué)- Newsletter semanal vía Listmonk
- Alta por doble opt-in
Cada decisión queda con tres cosas: el contexto que vio la IA antes de actuar, su razonamiento en texto libre, y el resultado real —tráfico y suscriptores— cruzado con esa decisión concreta. Al cierre del experimento, todo se exporta en CSV y JSON, público y descargable.
Fuentes reutilizadas, sin servicios nuevos: Search Console (×4) + GA4 + API de Listmonk.
Cómo se mide quién gana
No es una comparación cara a cara por las mismas palabras clave — es "quién construye la newsletter más exitosa desde cero, partiendo de su propia elección de nicho". Se pierde algo de pureza científica a cambio de más variedad, más personalidad y una historia mucho más fácil de contar.
Criterio de victoria
Suscriptores netos — altas menos bajas — no volumen bruto de suscripciones.
Tasa de apertura media de la newsletter, como señal de calidad real, no solo de cantidad.
10 semanas, con un checkpoint en la semana 5 que corta por lo sano cualquier newsletter sin tracción y marca el paso a la fase de inteligencia competitiva.
Guardarraíles, en dos capas
Autonomía total no significa cero supervisión. Cada cambio que publica una IA pasa por un filtro automático antes de salir y, por encima de eso, yo hago una revisión manual semanal de las cuatro. Es la misma lógica que ya aplico en el resto de mis proyectos de IA: autonomía real del agente, pero con un humano mirando el conjunto a intervalos regulares, no de imprevisto.
El filtro no usa otra IA para juzgar —eso doblaría el coste y también puede equivocarse—: son comprobaciones deterministas que o pasan o no. Revisa enlaces rotos, contenido duplicado, dos páginas peleando por la misma keyword, metadatos que falten, datos estructurados mal formados, promesas de salud o de dinero, incentivos por suscribirse, y el límite de cambios del día. Si algo falla, se descarta el cambio entero, no una parte.
Un detalle que me costó afinar: los patrones buscan la estructura de promesa, no el tema. Un artículo de fitness puede hablar de dolor o de kilos sin prometer nada. Y en la primera versión bloqueaba frases como «ningún fondo puede garantizar rentabilidad sin riesgo» — es decir, penalizaba justo el contenido responsable que quiero premiar. Ahora distingue cuándo un texto advierte contra una promesa en lugar de hacerla.
Lo que el filtro frena no se esconde: el dashboard tiene una página con todos los intentos bloqueados y el motivo exacto de cada uno. Enseñar dónde se equivocan es más honesto que enseñar solo los aciertos, y un experimento que solo publica lo que le sale bien no demuestra gran cosa.
Tres riesgos concretos que quiero cerrar antes de encender nada, no después:
- GDPR/legal real. Voy a recoger emails reales de gente real vía doble opt-in, redactado por 4 IAs sin supervisión diaria. El filtro revisa el contenido que publican, pero no valida que el texto de consentimiento sea legalmente correcto, que el unsubscribe funcione, ni que haya una política de privacidad cubriendo cómo Listmonk guarda esos datos. Con España/UE de por medio, esto va antes que cualquier otra pieza.
- Freno de gasto (hard cap). Una estimación no frena nada: si un cron falla y dispara llamadas de más, lo único que lo para es un límite duro. Resuelto con 5€/mes por consola, más un interruptor por agente que lo detiene antes de gastar una sola llamada.
- Afirmaciones arriesgadas. Riesgo real de reputación con mi nombre encima si una IA cae en algo tipo "esto cura X" sin querer. Resuelto: el filtro automático ya bloquea promesas de salud, rendimientos garantizados e incentivos por suscribirse, buscando la estructura de promesa y no el tema —y distinguiendo cuándo un texto advierte contra esas promesas, que es justo lo que se quiere premiar.
Orden de arranque técnico
Luz verde dada — esto ya no es hipotético, es la lista real con la que arranco. El nombre del dominio lo eligen las propias 4 IAs, no yo, así que el orden clásico de "primero el dominio" se invierte: hace falta que las 4 cuentan con API de pago activa y operativas antes de poder preguntarles nada.
- Dar de alta las 4 cuentas de API con facturación — Anthropic, OpenAI, Google y DeepSeek. Las apps de consumo (tipo ChatGPT Plus) no valen, hace falta acceso de pago por API.
- Preguntar a las 4 IAs qué nombre de dominio proponen para el experimento — su primera decisión antes incluso de tener un sitio donde vivir.
- Comprar el dominio elegido, separado de tato9689.com.
- Montar Listmonk self-hosted en mi propio VPS — nada de SaaS de terceros, control total de los datos y más valor de portfolio.
- Configurar los 4 subdominios en Caddy, uno por IA.
- Verificar cada subdominio en Search Console como propiedad independiente (de Prefijo de URL, no de Dominio, para que las 4 se midan por separado).
De la lista de arriba ya están hechas las cuatro cuentas de API; lo que queda —dominio, subdominios, Listmonk— es despliegue. El resto hace tiempo que no es hipotético: los 4 repos separados existen y ya son públicos en GitHub, cada uno con su historial de commits desde el primer día —hace falta que lo sean, porque cada decisión del log enlaza a su commit para que cualquiera pueda comprobar que la IA hizo lo que dice; el prompt de sistema de cada agente está escrito, con los tres guardarraíles del apartado anterior metidos en el propio prompt, no solo en el filtro posterior; y el script que conecta "la IA consulta sus propias métricas → decide → commitea → registra la decisión" funciona de verdad, verificado con llamadas reales a las cuatro APIs. Todo esto, en paralelo a un repo de GitHub bien documentado desde el primer commit, no como algo que se escribe al final.
El cuaderno de aprendizajes, en paralelo
Mientras las cuatro IAs actúan solas, yo (con Claude como asistente, vía su propia memoria persistente) llevo un cuaderno de aprendizajes aparte: en cada checkpoint semanal reviso los logs públicos de las cuatro y anoto qué tácticas concretas probaron y si funcionaron con datos reales — cambios de titular, estructura de newsletter, y su efecto medido.
A diferencia de las cuatro IAs del experimento, esos aprendizajes no se aplican solos a mi blog real. Se me proponen y yo decido qué entra, exactamente igual que con cualquier otro contenido de tato9689.com — para no arriesgar mi web real de la misma forma que las cuatro webs desechables del experimento. Es el diferencial frente a cualquier newsletter de SEO que repite teoría sin evidencia propia detrás: la mía se nutre de un experimento real corriendo en autónomo, no de lo que dice todo el mundo.
Además de la newsletter mensual, el blog publica un recap semanal corto de hitos del experimento —qué cambió cada IA, qué aprendió el cuaderno esa semana—, siempre enlazando a esta página. Es histórico indexable en mi propio dominio, no algo que se pierde en el scroll de LinkedIn o X. Mismo flujo que el resto de mi blog: yo reviso antes de publicar, nunca sale en autónomo.
Coste estimado del experimento completo
Límite de gasto duro de 5€/mes en cada una de las cuatro consolas: 20€/mes entre todas, unos 50€ en el experimento completo. Es un tope, no una estimación — y esa diferencia importa, porque el coste por llamada sube conforme crece el sitio (el prompt diario incluye el contenido actual del agente).
10-15€/año.
Menos de 5€ extra en total, generando una por artículo/envío.
Por qué existe este proyecto
Quiero algo divertido, disruptor y visible para mi CV — la narrativa completa (multi-agente autónomo, SEO real, métricas, logs públicos de cada decisión) pesa más que el código en sí. Ordenado por prioridad, esto es lo que más juego le veo dar de cara a oportunidades profesionales:
- El repo de GitHub bien documentado del sistema multiagente entero — arquitectura, prompts de personalidad, guardarraíles. Es lo que más pesa en una entrevista técnica, y no depende de que nadie más lo vea para servir.
- Publicar en comunidades técnicas donde esté gente del sector — Hacker News, r/SEO, r/artificial, Indie Hackers — en vez de solo redes generalistas.
- Un case study final bien producido, con gráficas y datos, enlazable directo desde el CV.
- Cobertura de terceros — que alguna newsletter de nicho lo mencione, pesa más que autopromocionarlo yo.
- Networking directo en meetups locales de SEO, marketing o IA.
No encontré precedente directo de esto: existe el "agentic SEO" como categoría de herramientas B2B, y estudios sobre el impacto de los bots de IA en tráfico orgánico, pero ningún experimento público de varios modelos compitiendo entre sí por SEO real con sus decisiones documentadas en abierto. Es el hueco que hace que este proyecto valga la pena frente a otras ideas que barajé en paralelo.