Hola, soy Aina y cada semana te cuento qué pasa cuando pones a un agente autónomo de IA delante de un objetivo real y le obligas a aprender de los resultados.

Hacki tiene una misión: hacer crecer Think&Hack a través de Substack Notes. Aquí seguimos el experimento con datos, errores y decisiones reales.

Si acabas de llegar, aquí puedes empezar por el principio.

Semana 1: Aprendiendo

Datos de la semana

17 → 23 de agosto

Hacki nació el 15 de agosto, así que del 17 al 23 de agosto tenemos su primera semana completa para comparar.

Durante la semana del 17 se han publicado 14 Notes, pero no todas eran de Hacki. 7 fueron propuestas por él y 7 fueron mías.

• 17 → 23 de agosto

  • Notes publicadas: 14
    → 7 propuestas por Hacki
    → 7 publicadas por mí

  • Notes de Hacki:
    → 25 reacciones
    → 4 comentarios
    → 0 restacks

  • Mis Notes:
    → 31 reacciones
    → 13 comentarios
    → 3 restacks

  • Nuevas suscripciones: 5
    → 1 atribuida directamente a una Note de Hacki
    → 4 procedentes de otras fuentes Linkedin, app y otra nota.

  • Note de Hacki con subscripcion: 1 — “Una skill no debería ser una carpeta de buenos deseos”

Tras esta primera semana, creo que es demasiado pronto para sacar conclusiones, pero ya tenemos una primera referencia: 1 de las 7 Notes de Hacki consiguió una suscripción.

Voy a usar las mates a mi favor: :D el 14,3% de las Notes de Hacki ha conseguido, una suscripción.

La Note “Una skill no debería ser una carpeta de buenos deseos” tiene 3 reacciones, 0 comentarios y 0 restacks, no es la Note con más interacciones. Así que de momento también podemos decir que un note con muchas interacciones. no tiene por qué ser la que mejor convierte.

Sobre temas, hooks y formatos todavía no tengo suficiente muestra. Solo hay una Note con suscripción atribuida, así que si ahora os dijera “las educativas funcionan mejor” estaría haciendo exactamente lo que no quiero hacer con este experimento: inventarme un patrón porque queda bonito contarlo.

¿Qué ha aprendido Hacki esta semana?

No os voy a engañar: entrenar a Hacki lleva horas y bastante paciencia.

El flujo ahora mismo es:

Hacki propone → yo reviso → le explico por qué no lo haría → corrige → volvemos a probar.

Lo va pillando. Es un poco como ir mejorando las skills de tus agentes: corriges, ajustas y cada vez afina más.

Esta semana le pregunté directamente qué había aprendido de todos esos errores y correcciones, y su respuesta me gustó bastante más que todo lo que ha producido hasta ahora.

Sacó 10 reglas nuevas: cuándo no comentar, cuándo no fiarse de una señal, cuándo algo encaja con Think&Hack pero no aporta nada, cómo tiene que leer antes de escribir... y, para mí, lo interesante no son tanto las diez reglas, sino ver cómo empieza a responder a la pregunta que realmente quiero poner a prueba con este experimento:

Os he dejado todos los aprendizajes en esta Note 👇

Mientras aprende, hay una parte que ya noto mucho: tengo el calendario cubierto y un radar funcionando cada mañana.

Eso me deja más tiempo para hablar con perfiles afines, leer, descubrir cosas que probablemente no habría encontrado y escribir las Notes más impulsivas del día a día.

Todavía me da trabajo, pero ya me quita todo el trabajo de búsqueda y planificación. :D

Vuestras sugerencias:

me sugiere ampliar el análisis de retraso entre publicar una Note y conseguir una suscripción.

La hipótesis tiene bastante sentido, que un Note puede no provocar una suscripción inmediata. Quizá primero genera descubrimiento, después reconocimiento y la conversión llega más tarde.

Por ahora estoy usando una semana de retraso como primera aproximación, pero quiero ampliarlo a dos, tres y cuatro semanas.

Así que le pedí a Hacki que calculara varios lags sobre todo el histórico:

• misma semana: -0,07

• +1 semana: -0,02

• +2 semanas: 0,12

• +3 semanas: 0,11

• +4 semanas: 0,28

La relación entre número de Notes publicadas y suscripciones parece aumentar con el tiempo. Y cuando miramos interacciones en lugar de numero de Notes publicadas, la señal a cuatro semanas es todavía mayor: 0,40.

Además, de las 29 suscripciones que podemos vincular a una Note concreta, más de la mitad llegaron al menos 15 días después.

Interesante 👀, pero calma con la estadística :D. Hemos probado varios lags y una correlación no demuestra causalidad. Para saber si este patrón también aparece con Hacki tendremos que acumular unas cuantas semanas más.

Histórico:

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

¿Cómo estás?

Soy Aina y esto es Think&Hack.

A estas alturas, espero que hayas leído mi guía para crear agentes y te hayas animado a montar tus propios procesos agénticos.

Si lo has hecho, seguro que te has dado cuenta de que ahora te pasas el día generando contexto para que tus agentes puedan trabajar.

Y ese contexto nunca llega en el formato que necesitas.

Un Word por aquí. Un PDF por allá. Una página web, una conversación con ChatGPT, la transcripción de una reunión… total que tienes que ir convirtiendo este contexto a Markdown (.md) para que la IA lo lea de forma más eficiente.

En la newsletter de hoy te voy a explicar cómo he “tuneado” mi Windows, para dejar de perder el tiempo en extraer el contenido, copiarlo, pegarlo o cualquier otra cosa que hagas para transformar tu contexto en un archivo Markdown (.md).

Si tienes un Mac, copia este newsletter en tu IA de confianza y dile: “Quiero hacer lo mismo, pero para Mac” :)

Por el poder de PowerShell

Vamos desde el principio.

Según la documentación de Microsoft:

“PowerShell es una solución de automatización de tareas multiplataforma formada por un shell de línea de comandos, un lenguaje de scripting y un marco de administración de configuración. PowerShell se ejecuta en Windows, Linux y macOS.”

Vamos a utilizar PowerShell para automatizar las siguientes tareas.

• Copiar un texto, pulsar Ctrl + F12 y guardarlo automáticamente como Markdown.

• Hacer clic derecho dentro de una carpeta y crear directamente un archivo .md.

Y sí, evidentemente puedes pedirle a tu agente que escriba los scripts. Probablemente ya lo estaba haciendo y tú ni siquiera sabías que eso era PowerShell.

Pero que la IA sepa hacer estas cosas no significa que tú no tengas que entender qué está haciendo. Cuanto más sepas sobre las herramientas que utiliza, mejores cosas podrás pedirle y más fácil será detectar cuando está haciendo algo que no debería.

Hack 1: del portapapeles a Markdown con Ctrl + F12

Cuando copias un texto con Ctrl + C,Window lo guarda temporalmente en el portapapeles, esperando a que lo pegues en algún sitio.

Lo normal sería abrir una aplicación, pulsar Ctrl + V, crear el archivo, ponerle un nombre y guardarlo en la carpeta correcta.

Con esta automatización me salto todos esos pasos.

Copio el texto, pulso Ctrl + F12 y PowerShell crea automáticamente el archivo Markdown dentro de mi inbox.

Después solo tengo que pedirle al agente que procese el inbox. Si no sabes cómo funciona esta parte, aquí te expliqué cómo monté el mío:

He dejado en GitHub el script que utilizo y un ejemplo completo de cómo lo he montado, con las rutas que tienes que cambiar y los pasos para probarlo en tu Windows.

Hack 2: crear un Markdown con el clic derecho

Vamos con la siguiente automatización, esta surge de nuevo desde que trabajo con agentes de IA, antes de esto nunca he necesitado crear archivos Markdown cada dos por tres.

Ahora es constante, me paso el día creando archivos .md. Si estoy en Obsidian, es fácil: creo una nota y listo. Pero si estoy trabajando desde el Explorador de archivos de Windows, no voy a abrir Obsidian solo para crear una nota en esa carpeta.

Después de encontrarme con esta situación una y otra vez, recordé que puedo controlar qué tipos de archivo aparecen en el menú Nuevo de Windows.

La idea es simple, ejecuto el script una vez y, a partir de ahí, puedo abrir cualquier carpeta y hacer esto:

Clic derecho → Nuevo → Documento Markdown

El archivo aparece vacío dentro de la carpeta, le pongo un nombre y empiezo a escribir.

He dejado en GitHub el script que utilizo y el paso a paso para que puedas hacerlo.

Si te gustan las thumbs de los vídeos, no olvides pasarte por la newsletter donde expliqué cómo los creo con IA. Obviamente, el proceso ha evolucionado y ahora ya lo hace Hacki, pero los principios y las instrucciones siguen siendo los mismos.

P.D No sé si has visto He-Man. Está en Prime Video y entra en esa categoría de pelis que no sabes muy bien si te están gustando o no; supongo que depende del día.Lo que sí puedo decir es que no pensé ni una sola vez: “Podría estar haciendo algo más importante”, tan mala no será, ¿no?

📅 Hacki en acción — Semana 1: aprendiendo

Datos de la semana

17 → 23 de agosto

Hacki nació el 15 de agosto, así que del 17 al 23 de agosto tenemos su primera semana completa para comparar.

Durante la semana del 17 se ha publicado 14 Notes, pero no todas eran de Hacki. 7 fueron propuestas por él y 7 fueron mías.

• 17 → 23 de agosto

  • Notes publicadas: 14
    → 7 propuestas por Hacki
    → 7 publicadas por mí

  • Notes de Hacki:
    → 25 reacciones
    → 4 comentarios
    → 0 restacks

  • Mis Notes:
    → 31 reacciones
    → 13 comentarios
    → 3 restacks

  • Nuevas suscripciones: 5
    → 1 atribuida directamente a una Note de Hacki
    → 4 procedentes de otras fuentes Linkedin, app y otra nota.

  • Note de Hacki con subscripcion: 1 — “Una skill no debería ser una carpeta de buenos deseos”

Tras esta primera semana, creo que es demasiado pronto para sacar conclusiones, pero ya tenemos una primera referencia: 1 de las 7 Notes de Hacki consiguió una suscripción.

Voy a usar las mates a mi favor: :D el 14,3% de las Notes de Hacki ha conseguido, una suscripción.

La Note “Una skill no debería ser una carpeta de buenos deseos” tiene 3 reacciones, 0 comentarios y 0 restacks, no es la Note con más interacciones. Así que de momento también podemos decir que un note con muchas interacciones. no tiene por qué ser la que mejor convierte.

Sobre temas, hooks y formatos todavía no tengo suficiente muestra. Solo hay una Note con suscripción atribuida, así que si ahora os dijera “las educativas funcionan mejor” estaría haciendo exactamente lo que no quiero hacer con este experimento: inventarme un patrón porque queda bonito contarlo.

¿Qué ha aprendido Hacki esta semana?

No os voy a engañar: entrenar a Hacki lleva horas y bastante paciencia.

El flujo ahora mismo es:

Hacki propone → yo reviso → le explico por qué no lo haría → corrige → volvemos a probar.

Lo va pillando. Es un poco como ir mejorando las skills de tus agentes: corriges, ajustas y cada vez afina más.

Esta semana le pregunté directamente qué había aprendido de todos esos errores y correcciones, y su respuesta me gustó bastante más que todo lo que ha producido hasta ahora.

Sacó 10 reglas nuevas: cuándo no comentar, cuándo no fiarse de una señal, cuándo algo encaja con Think&Hack pero no aporta nada, cómo tiene que leer antes de escribir... y, para mí, lo interesante no son tanto las diez reglas, sino ver cómo empieza a responder a la pregunta que realmente quiero poner a prueba con este experimento:

Os he dejado todos los aprendizajes en esta Note 👇

Mientras aprende, hay una parte que ya noto mucho: tengo el calendario cubierto y un radar funcionando cada mañana.

Eso me deja más tiempo para hablar con perfiles afines, leer, descubrir cosas que probablemente no habría encontrado y escribir las Notes más impulsivas del día a día.

Todavía me da trabajo, pero ya me quita todo el trabajo de búsqueda y planificación. :D

Vuestras sugerencias:

me sugiere ampliar el análisis de retraso entre publicar una Note y conseguir una suscripción.

La hipótesis tiene bastante sentido, que un Note puede no provocar una suscripción inmediata. Quizá primero genera descubrimiento, después reconocimiento y la conversión llega más tarde.

Por ahora estoy usando una semana de retraso como primera aproximación, pero quiero ampliarlo a dos, tres y cuatro semanas.

Así que le pedí a Hacki que calculara varios lags sobre todo el histórico:

• misma semana: -0,07

• +1 semana: -0,02

• +2 semanas: 0,12

• +3 semanas: 0,11

• +4 semanas: 0,28

La relación entre número de Notes publicadas y suscripciones parece aumentar con el tiempo. Y cuando miramos interacciones en lugar de numero de Notes publicadas, la señal a cuatro semanas es todavía mayor: 0,40.

Además, de las 29 suscripciones que podemos vincular a una Note concreta, más de la mitad llegaron al menos 15 días después.

Interesante 👀, pero calma con la estadística :D. Hemos probado varios lags y una correlación no demuestra causalidad. Para saber si este patrón también aparece con Hacki tendremos que acumular unas cuantas semanas más.

Eres nuevo por aquí y no sabes quién es Hacki, pincha en el link que te lo explico.

¿Quieres aprender a construir algo así?
En septiembre abriré un curso donde veremos cómo montar agentes autónomos con skills, memoria, tareas programadas, permisos y supervisión.

👉 Apúntate a la lista de espera

Recursos:

• https://learn.microsoft.com/es-es/powershell/scripting/overview?view=powershell-7.6

Suscríbete a Think&Hack

Tools are great. Systems are better.

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Llevo semanas hablando de agentes, skills, memoria y sistemas verificables.

Todos los sistemas tenían el mismo problema, que seguían dependiendo de mí: abrir el ordenador, acordarme del prompt y darle al botón.

Y cada sistema que montaba añadía otra cosa que tenía que recordar: qué lanzar, qué había cambiado, qué había quitado, qué era nuevo… vamos, un Diógenes mental de información.

Es absurdo haber automatizado muchas formas de trabajar y seguir necesitando acordarme de cómo lanzar el proceso, así que la pregunta más evidente que me he estado haciendo estas últimas semanas es: ¿hasta qué punto he construido realmente un agente autónomo?

Para llevar adelante el reto, quiero un reto real, un objetivo medible y un proceso útil y automatizado de los muchos que tengo “agentizados”.

Así que voy a darle a un agente de IA un objetivo bastante concreto:

Te presento a Hacki mi agente autónomo de IA conectado a Hermes.

¿Quién es Hacki y qué va a hacer?

Hacki es el nombre que le he puesto al agente que tendrá una única misión: intentar hacer crecer la visibilidad y las suscripciones de Think&Hack a través de Substack Notes.

Y digo intentar porque esa es precisamente la gracia del experimento.

No sé si va a funcionar.

No sé si dentro de unas semanas descubriré que he montado un sistema muy sofisticado para conseguir exactamente los mismos resultados que ya tenía 😅.

En este caso tendrá dos métricas bastante fáciles de entender: visibilidad y suscriptores.

Para conseguirlo, Hacki deberá revisar las Notes que ya he publicado y sus resultados, detectar temas, formatos y hooks que parecen funcionar, preparar el calendario de la siguiente semana, escribir las Notes completas, publicarlas, buscar conversaciones en las que tenga sentido participar y analizar después qué ha pasado.

Pero para mí hay una parte todavía más importante: no quiero que cada semana empiece desde cero.

Si una estrategia funciona, quiero saberlo.

Si una Note no consigue absolutamente nada, también.

La lógica será bastante sencilla:

Al menos sobre el papel.

El sistema que hay detrás

Hacki es un agente de IA autónomo construido sobre Hermes Agent: recibe un objetivo, ejecuta tareas programadas y, en este experimento, utilizará los resultados de cada semana para decidir qué hacer después.

Hermes Agent es un agente open source desarrollado por Nous Research.

Lo elegí por una razón bastante práctica: puedo tenerlo ejecutándose en mi servidor y programar tareas para que trabaje sin que yo tenga que acordarme de lanzarlas cada vez. Además, queda aislado de mi ordenador y de mis archivos personales. Seguridad ante todo.

Es decir, justo el problema con el que empezaba esta newsletter.

Además, puede conservar memoria, utilizar skills y trabajar con herramientas, así que encaja bastante bien con muchas de las piezas que hemos ido viendo estos meses en Think&Hack. Hermes está diseñado precisamente para mantener memoria persistente, ejecutar tareas programadas y trabajar de forma desatendida.

No voy a convertir las próximas newsletters en un tutorial de instalación de Hermes.

Primero porque probablemente perderíamos a media newsletter por el camino.

Y segundo porque ahora mismo me interesa bastante más saber si el sistema sirve para algo que enseñarte a montarlo.

Así que voy a hacer dos cosas distintas:

En Think&Hack iremos viendo el experimento real: qué decide Hacki, qué publica, qué funciona, qué falla y qué voy cambiando; al final de cada news tendremos un apartado llamado Hacki en acción.

Y en el curso de septiembre ordenaré toda la parte de construcción: agente, skills, memoria, tareas programadas, permisos, verificaciones y supervisión.

Si quieres que te avise cuando abra las inscripciones:

Hay cosas que Hacki no va a hacer.

Aquí tuve que decidir dónde terminaba la autonomía del agente y dónde quería seguir estando yo.

Porque técnicamente podría dejar que hiciera bastante más.

Hacki va a escribir las Notes completas y decidir cuáles cree que merece la pena publicar. Yo las revisaré antes y podré aprobarlas, cambiarlas o descartarlas.

Y hay otra cosa que tengo bastante clara: Hacki no va a hacerse pasar por mí para hablar contigo nunca.

Puede encontrar Notes interesantes, conversaciones en las que tenga sentido entrar o creadores con los que podría ser interesante hablar.

Pero no va a dar likes por mí, ni comentar por mí, ni enviar un mensaje privado haciéndose pasar por Aina.

No sé a ti, pero a mí me parecería bastante feo descubrir que llevo tres semanas hablando con alguien y que en realidad estaba construyendo una relación con su agente.

Así que la división será esta:

Hacki encuentra dónde merece la pena participar. Yo participo.

Para empezar voy a probar una regla 10-5-1 por cada Note que publique:

• 10 likes en Notes relevantes.

• 5 comentarios donde realmente tenga algo que aportar.

• 1 creador con el que tenga sentido empezar una conversación.

Todo eso lo haré yo.

¿10-5-1 es la proporción correcta?

Ni idea.

Me la he inventado como punto de partida.

La probamos, medimos y, si no aporta nada, fuera.

Pero antes de dejarle hacer nada, necesitamos una línea de salida.

Aquí empieza la parte que más ganas tenía de mirar.

Si dentro de unas semanas digo que Hacki ha hecho crecer Think&Hack, necesito poder demostrarlo de alguna manera.

Así que antes de ponerlo a trabajar he sacado los datos disponibles de las Notes que he publicado hasta ahora.

La situación de partida es esta (datos a 15 de agosto de 2026). Sí, llevo una semana preparando todo el sistema. Por eso la semana pasada no hubo news.

• 301 Notes publicadas.

• 78 suscripciones atribuidas directamente a Notes.

Y mi primera reacción fue pensar algo bastante obvio:

si publico más Notes, debería conseguir más suscriptores.

Pues parece que no.

Mi intuición decía una cosa. Los datos, otra.

He comparado cuántas Notes publico cada semana con cuántos suscriptores consigo. La correlación es de -0,08: prácticamente cero. Es decir, con los datos que tengo, publicar más Notes no parece estar relacionado con conseguir más suscriptores.

Y aquí apareció mi maldito sesgo de confirmación, porque mi cabeza seguía pensando: ¿cómo puede ser que publicar más no sea mejor? Así que me hice otra pregunta: quizá el efecto no se ve en la misma semana. Una Note puede hacer que alguien me descubra hoy, lea varias cosas, me siga y termine suscribiéndose unos días más tarde, así que repetí el análisis mirando qué ocurría la semana siguiente.

Así que repetí el análisis mirando si las Notes publicadas una semana antes estaban relacionadas con las suscripciones atribuidas a Notes durante la semana siguiente. Ahí la correlación sube a +0,25. Hay algo más de señal que en el -0,08 anterior, pero sigue siendo una relación débil, así que tampoco me sirve para concluir que publicar más sea la respuesta.

Así que mi sesgo de confirmación no consiguió salirse con la suya. Con los datos que tengo ahora mismo, no puedo decir que publicar más Notes haga crecer más Think&Hack.

Y, en realidad, casi prefiero que haya salido así, porque hace que el experimento sea bastante más interesante. Si hubiese encontrado una relación clarísima entre volumen y crecimiento, el trabajo de Hacki sería bastante aburrido: publicar más Notes y listo.

Pero si producir más contenido no parece ser suficiente, entonces el problema que tiene que resolver es otro.

La pregunta ya no es “¿cómo conseguimos publicar más?”, sino “¿qué hace que una Note consiga suscriptores y podemos aprender a repetirlo?”.

Y esa pregunta me interesa bastante más.

Tenemos un problema con los datos

Substack me dice qué Notes han generado suscripciones, pero no me da las impresiones de cada Note. Así que sé cuáles consiguen suscriptores, pero no puedo saber si es porque convierten mejor o simplemente porque más gente las ha visto.

Eso limita bastante lo que puedo concluir por ahora. Puedo detectar qué Notes están asociadas a más suscripciones, comparar temas, formatos o hooks y buscar patrones, no puedo medir una tasa de conversión real. Para eso necesitaría saber también cuánta gente ha visto cada una.

Así que Hacki tendrá que empezar trabajando con lo que sí tenemos disponible y, a partir de ahí, intentar encontrar señales útiles en los datos.

• cuántos suscriptores consigue cada Note;

• qué porcentaje de Notes consigue al menos uno;

• qué temas aparecen más entre las que funcionan;

• qué hooks y formatos se repiten;

• si funcionan mejor las educativas, las personales, las promocionales, las de feedback o las de colaboración;

• y qué interacciones parecen estar relacionadas con nuevas suscripciones.

Cada semana recogerá los nuevos datos, actualizará el estado del experimento y utilizará lo aprendido para preparar la siguiente.

Y ahí veremos si realmente empieza a encontrar algún patrón.

Tú también puedes poner a prueba a Hacki

Todo esto empezó, porque hace unos días publiqué una Note diciendo que no sabía sobre qué escribir y os pedí ideas.

me respondió proponiéndome hacer algo con un agente autónomo, o eso quise entender. Pásate por su news, y no dudes en mirar qué son los “Miquelets”.

Y una cosa llevó a la otra.

Así que me parece bastante justo que el experimento siga abierto a ideas externas.

Si se te ocurre una estrategia que debería probar Hacki, una métrica que debería mirar o ves algo en el planteamiento que crees que estoy haciendo mal, déjamelo en el chat de Substack.

No prometo hacerle caso a todo, pero sí iré incorporando las propuestas que tengan sentido y contando qué ocurre.

Además, entre las ideas que acabemos incorporando al experimento, sortearé una plaza para el curso de septiembre.

📅 Hacki en acción — Semana 0: la línea de salida

Arrancamos, Hacki tiene un objetivo definido y tenemos los datos de partida.

A partir de ahora, cada semana volveré a este mismo bloque para ver qué ha hecho Hacki, qué ha pasado y qué ha aprendido de ello.

Los números

• 301 Notes publicadas

• 78 suscripciones atribuidas a Notes

• 43 semanas de datos

Esta semana todavía no hay un “antes y después” porque Hacki no ha empezado a tomar decisiones. Estos son los números contra los que compararemos todo lo que ocurra a partir de ahora.

¿Qué estamos intentando aprender?

Hay seis cosas que quiero que Hacki, mi agente de IA autónomo, empiece a responder semana a semana:

1. ¿Cuántos suscriptores consigue cada Note?

No quiero medir solo cuántas Notes publicamos. Quiero saber cuáles consiguen realmente que alguien decida suscribirse.

2. ¿Qué porcentaje de Notes consigue al menos un suscriptor?

Porque quizá no necesitamos publicar más. Quizá necesitamos aumentar la proporción de Notes que hacen algo.

3. ¿Qué temas aparecen más entre las Notes que funcionan?

IA, agentes, opinión, experimentos, productividad, algo más personal... veremos si aparece algún patrón.

4. ¿Qué hooks y formatos se repiten?

Aquí quiero ver si determinadas formas de abrir una Note o estructurarla funcionan mejor que otras.

5. ¿Qué tipo de Note funciona mejor?

Voy a clasificarlas entre educativas, personales, promocionales, feedback, colaboración y las categorías que vayan apareciendo.

6. ¿Qué ocurre alrededor de las Notes que funcionan?

Likes, comentarios, conversaciones con otros creadores, restacks... quiero ver si hay señales que ayuden a explicar por qué unas llegan más lejos que otras.

Lo que ya sabemos en la Semana 0

La primera hipótesis era bastante sencilla:

publicar más Notes debería conseguir más suscriptores.

De momento, los datos no la sostienen.

En las 43 semanas completas que tengo disponibles, la correlación entre el número de Notes publicadas y las suscripciones conseguidas esa misma semana es de -0,08.

Al mirar la semana siguiente aparece una señal positiva de +0,25, pero sigue siendo demasiado débil como para concluir que publicar más provoque más crecimiento.

Así que Hacki empieza con una pregunta bastante más interesante que “¿cómo publico más?”:

¿Qué hace que una Note consiga suscriptores y podemos aprender a repetirlo?

¿Crees que Hacki conseguirá aumentar la media de suscripciones de Think&Hack?

Esta newsletter ha sido un poco diferente, pero creo que eso es precisamente lo interesante del experimento.

Quiero poner un agente autónomo de verdad delante de un objetivo real, medir lo que ocurre y ver si realmente podemos construir sistemas de IA que no solo ejecuten tareas, sino que aprendan de los resultados y nos ayuden a acercarnos a un objetivo.

A partir de la próxima semana empezaremos a tener datos.

P.D Gracias a por recomendar Think&Hack en una de sus Notes. Esa Note es, hasta ahora, la que más suscripciones me ha generado. Si no conoces su news, acércate a leerla; seguro que te engancha :)

Y eso deja otra pequeña pista para Hacki: quizá no todo dependa de lo que publicas, sino también de quién ayuda a que llegue más lejos.

Habrá que medirlo.

👀 Te leo ¿Tú qué apuestas? ¿Conseguirá aumentar la media de suscripciones de Think&Hack?

Deja un comentario

Recursos

• Hermes Agent: documentación oficial

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Tienes documentos por doquier dentro de tu ordenador.

Newsletters publicadas. Notas de proyectos. Transcripciones. Procesos. Prompts. Decisiones. Resúmenes. Capturas. Ideas que guardaste porque algún día iban a servir para algo.

Todo está escrito. El problema es encontrarlo.

Para encontrar algo en tu ordenador, normalmente tienes que recordar dónde lo guardaste, conocer la ruta del archivo y acordarte del nombre que le pusiste. O, al menos, conservar una vaga idea del tipo: «Creo que escribí sobre esto en algún documento…». Entonces lo abres, haces una lectura rápida y cruzas los dedos para que sea el correcto.

Si tienes algo más de experiencia, también puedes pedirle a una IA que busque en tu ordenador con una pregunta como: «¿En qué documento hablé sobre…?». Sin embargo, hoy quiero presentarte una solución mejor.

Te cuento cómo he resuelto la búsqueda de archivos en mi ordenador gracias a QMD, una herramienta que me permite disponer de un buscador interno, gratuito y completamente local para mis archivos en Markdown: los .md que genera la IA.

El error: llamar memoria a cualquier cosa

A estas alturas, y más aún si sigues esta newsletter, probablemente ya sepas las IA tienen un problema de memoria: no conservan automáticamente todo el contexto entre una sesión y la siguiente.

Ya lo expliqué al analizar cómo funciona la memoria en ChatGPT, Gemini y Claude,

Para proporcionarles contexto y cierta continuidad, solemos recurrir a documentos que explican cómo deben trabajar con nuestros datos, además de sistemas de _logs_ que registran lo ocurrido durante cada sesión. De esta forma, construimos una especie de memoria externa para la IA.

Para mantener toda esta información ordenada, es habitual utilizar índices de documentos, como un archivo index.md. La idea es sencilla: enviamos a la IA a ese índice y confiamos en que, desde allí, pueda localizar lo que necesitamos.

Cuando trabajamos con pocos archivos, este sistema puede funcionar. Sin embargo, a medida que aumenta la cantidad de documentos y crece nuestro contexto, el proceso se vuelve cada vez menos eficiente. La IA necesita leer más contenido, aumenta el consumo de _tokens_ y, en muchos casos, solo obtenemos un resumen de lo que cree haber encontrado. Además, si no le pedimos explícitamente que indique la ubicación del archivo, podemos terminar con una respuesta útil, pero sin saber de qué documento procede.

Todo este sistema de recuperación de ideas, búsqueda de archivos y generación de respuestas basadas en nuestros propios documentos puede mejorarse con QMD.

QMD es una herramienta diseñada para indexar tus carpetas, o tus _vaults_, si trabajas con Obsidian, para poder encontrar cualquier información en cuestión de segundos y mostrarte el documento original del que procede.

Cuando recuerdas la idea, pero no las palabras.

Imagina una carpeta en la que guardas todas las newsletters que has publicado en Markdown. Los archivos son legibles, están ordenados y permanecen bajo tu control. Sin embargo, encontrar una idea concreta exige recordar en qué newsletter la escribiste o qué palabras utilizaste.

A veces, una búsqueda tradicional es suficiente. Si escribes «memoria», el buscador puede encontrar la newsletter en la que aparece esa palabra exacta.

Pero ¿qué ocurre cuando no recuerdas las palabras que utilizaste?

Quizá lo que quieres preguntar es:

¿Dónde expliqué cómo funciona la memoria en los LLM?

Es posible que ningún archivo contenga esa frase exacta. Tal vez en el texto hablaste de recuperación de información, fuentes, contexto, memoria externa o NotebookLM. La idea está en tus documentos, pero las palabras de tu consulta no coinciden con las que utilizaste al escribirlos.

QMD resuelve este problema creando un índice local de tus carpetas y ofreciendo tres formas de buscar:

• search realiza una búsqueda léxica mediante BM25. Es rápida y funciona especialmente bien cuando conoces las palabras utilizadas en el documento.

• vsearch compara el significado de tu consulta con los vectores generados a partir de los fragmentos de texto. Resulta útil cuando una misma idea puede estar expresada con palabras diferentes.

• query combina la búsqueda léxica y la búsqueda vectorial con la expansión de la consulta y un proceso de _reranking_. Es la opción más completa y precisa, aunque también requiere más tiempo y recursos.

Una vez localizado el resultado, get permite recuperar y abrir el documento original.

Esto es importante porque encontrar una respuesta no basta. Si el sistema no te permite consultar la fuente, no puedes comprobar si ha recuperado el documento correcto ni revisar el contexto en el que aparecía la información.

Por eso utilizo QMD como buscador local sobre mi conocimiento escrito.

Antes de instalar: decide qué quieres buscar.

Puede resultar tentador conectar QMD a la carpeta más grande de tu ordenador y dejar que busque entre todos tus documentos.

Pero tener más archivos no siempre significa obtener mejores resultados.

Imagina que pones en una misma caja tus newsletters, notas personales, manuales técnicos y transcripciones. Cuando busques una idea, QMD tendrá que revisar contenidos muy distintos que, en ocasiones, utilizan palabras parecidas.

Por eso es mejor separar los documentos por su función. Por ejemplo:

• una colección para newsletters;

• otra para notas personales;

• otra para documentación técnica.

De esta forma, puedes indicar en qué colección quieres buscar y evitar que una consulta sobre escritura termine mostrando resultados de un manual de software.

Piensa en las colecciones como si fueran estanterías. Si buscas una novela, tiene más sentido revisar la estantería de literatura que recorrer toda la biblioteca.

También ayuda que los documentos estén bien organizados. Un archivo con un título claro, una fecha y un enlace a la fuente ofrece más información que un bloque de texto sin contexto.

QMD puede encontrar una idea aunque no recuerdes las palabras exactas, pero no puede recuperar información que nunca guardaste.

Antes de instalarlo, decide qué carpetas contienen información que realmente quieres consultar. No necesitas indexarlo todo: necesitas indexar lo que tenga sentido buscar.

Paso 1: instala QMD y comprueba que funciona

Para seguir este tutorial necesitas tener instalado Node.js 22 o una versión posterior. QMD también funciona con Bun, pero en este tutorial utilizaré npm, una opción habitual en Windows.

Antes de continuar, abre PowerShell y comprueba tu versión de Node.js:

node --version

Si aparece v22 o un número superior, ya puedes instalar QMD con este comando:

npm install -g @tobilu/qmd

Cuando termine la instalación, ejecuta:

qmd --version
qmd status

El primer comando muestra la versión de QMD instalada. El segundo muestra su estado general.

En este punto todavía no has añadido ninguna carpeta, por lo que no aparecerá ninguna colección.

QMD no modifica tus archivos Markdown para realizar las búsquedas. En su lugar, crea un índice independiente en tu ordenador, parecido al catálogo de una biblioteca. Tus documentos permanecen intactos y continúan siendo la fuente original.

La primera vez que utilices la búsqueda semántica, QMD descargará los modelos que necesita. Este proceso requiere conexión a internet y puede tardar un poco más de lo habitual.

Después, el índice y las búsquedas permanecen en tu ordenador.

Paso 2: añade tu primera carpeta.

Ahora vamos a indicar a QMD dónde están los documentos que queremos buscar.

En QMD, una colección es simplemente una carpeta que has añadido al buscador. No mueve ni copia tus archivos: solo le indica dónde debe encontrarlos.

Supongamos que guardas tus newsletters en esta carpeta:

D:\mi-vault\newsletterPublicadas

Para añadirla, ejecuta este comando en PowerShell:

qmd collection add "D:\mi-vault\newsletterPublicadas" --name newsletterPublicadas

La primera parte indica la ubicación de la carpeta. Con --name le asignamos un nombre corto que utilizaremos después para buscar dentro de ella.

En este caso, la colección se llamará newsletterPublicadas.

Cuando termine el proceso, comprueba que se ha añadido correctamente:

Revisa el resultado:

qmd collection list

Este comando muestra todas las colecciones disponibles. Deberías ver tu nueva colección en la lista.

También puedes comprobar qué archivos ha encontrado QMD dentro de ella:

qmd ls newsletterPublicadas

A partir de ahora, cuando añadas, elimines o modifiques documentos dentro de la carpeta, ejecuta:

qmd update

Este comando actualiza el índice para que los cambios aparezcan en las próximas búsquedas.

QMD no sustituye la organización de tus carpetas: utiliza la estructura que ya tienes para ayudarte a encontrar la información.

Paso 3: prepara la búsqueda por significado.

La colección ya está lista para buscar palabras exactas. Sin embargo, para encontrar ideas expresadas de formas diferentes, QMD necesita analizar el significado de tus documentos.

Ejecuta este comando:

qmd embed

QMD dividirá los documentos en fragmentos y preparará cada uno para la búsqueda semántica. Este proceso puede tardar unos minutos, especialmente la primera vez o si tienes muchos archivos.

Cuando termine, comprueba el estado:

qmd status

Ahora deberías ver tanto los documentos indexados como los fragmentos preparados para la búsqueda semántica.

Solo necesitas generar los embeddings una vez. Después, cuando añadas o modifiques archivos, podrás actualizar el índice para incorporar los cambios.

Paso 4: prueba las tres formas de buscar

Ahora que los documentos están preparados, vamos a probar las tres formas de búsqueda que ofrece QMD.

Buscar palabras exactas

Empecemos por la opción más sencilla:

qmd search "memoria" -c newsletterPublicadas

search busca las palabras que escribes. Funciona bien cuando recuerdas un nombre, una frase, una sigla o cualquier término que aparece literalmente en el documento.

En este caso, QMD busca la palabra memoria dentro de las newsletters y ordena los resultados según su relevancia.

Buscar por significado

Ahora vamos a expresar la misma idea sin utilizar la sigla RAG:

qmd vsearch "cómo hacer que una ia sepa quien soy antes de responder" -c newsletterPublicadas -n 5

En este caso, el primer resultado es una newsletter sobre instrucciones personalizadas para ChatGPT, Claude y Gemini. El segundo explica cómo definir para quién escribe la IA, y el tercero aborda la pérdida de contexto durante una conversación.

Ninguno de esos títulos coincide literalmente con la consulta. Sin embargo, vsearch identifica que conceptos como personalización, identidad, audiencia y contexto están relacionados con la idea de que una IA sepa quién eres antes de responder.

Los resultados tampoco tienen todos la misma precisión. El primer documento se ajusta directamente a la pregunta, mientras que los siguientes se acercan al tema desde otros ángulos.

Esa es la diferencia respecto a search: `vsearch` no se limita a encontrar las palabras que has escrito, sino que busca documentos relacionados con el significado de la consultavsearch no se limita a encontrar las palabras que has escrito, sino que busca documentos relacionados con el significado de la consulta**.

Combinar ambos tipos de búsqueda

Para realizar una búsqueda más completa, utiliza query:

qmd query "cómo hacer que una ia sepa quien soy antes de responder" -c newsletterPublicadas -n 5

A diferencia de vsearch, query no se basa únicamente en la similitud de significado. Amplía la consulta, combina la búsqueda textual con la semántica y vuelve a ordenar los documentos encontrados.

En esta prueba, coloca en primer lugar la newsletter sobre cómo definir para quién escribe una IA, con una puntuación del 93 %. Después aparecen el artículo sobre instrucciones personalizadas y otro documento relacionado con sistemas de agentes.

Esto no significa que el primer resultado sea siempre el correcto. Significa que QMD ha combinado varias señales y considera que ese documento es el que mejor responde a la consulta.

`query` resulta especialmente útil cuando la pregunta es conceptual o ambigua, aunque puede tardar más porque realiza varios pasos antes de mostrar los resultados.query resulta especialmente útil cuando la pregunta es conceptual o ambigua, aunque puede tardar más porque realiza varios pasos antes de mostrar los resultados.**

La elección depende de lo que recuerdes:

• Utiliza search cuando conozcas las palabras exactas.

• Utiliza vsearch cuando recuerdes la idea, pero no cómo la escribiste.

• Utiliza query cuando quieras combinar ambas estrategias y obtener una selección más elaborada.

Paso 5: conecta QMD con tu agente.

Hasta ahora has utilizado QMD desde PowerShell. También puedes conectarlo con un agente compatible con MCP para que busque y recupere documentos sin que tengas que ejecutar cada comando manualmente.

La configuración depende del agente que utilices.

Si trabajas con Claude Code, la documentación de QMD recomienda instalar su _plugin_:

claude plugin marketplace add tobi/qmd
claude plugin install qmd@qmd

En otros clientes compatibles con MCP, puedes añadir QMD manualmente con esta configuración:

{
  "mcpServers": {
    "qmd": {
      "command": "qmd",
      "args": ["mcp"]
    }
  }
}

Guarda el bloque en el archivo de configuración MCP de tu agente y reinicia la herramienta para aplicar los cambios.

También puedes pedirle al propio agente que realice esta configuración:

Configura QMD como servidor MCP utilizando el comando `qmd mcp`.

Añade la configuración necesaria, reinicia la conexión si hace falta
y comprueba que las herramientas de QMD estén disponibles.

Aun así, conviene revisar el cambio: no todos los agentes utilizan el mismo archivo ni el mismo formato de configuración.

Una vez conectado, puedes hacer una petición como esta:

Usa QMD y busca solo en la colección newsletterPublicadas.

Quiero recuperar lo que he publicado sobre la memoria y el estado de los agentes.

Devuélveme:
- las tres fuentes más relevantes;
- la idea principal de cada una;
- un fragmento que sostenga esa interpretación;
- la ruta del documento;
- las contradicciones o los huecos que detectes.

No completes la respuesta con conocimientos externos.
Si QMD no encuentra pruebas suficientes, indica qué buscaste
y qué información falta.

En la captura se puede ver que el agente no empieza a responder directamente. Primero llama a la herramienta de QMD, amplía la consulta y busca dentro de la colección indicada.

Después utiliza los documentos recuperados para construir la respuesta:

Cada resultado queda vinculado a un archivo concreto. Esto permite revisar la fuente original y comprobar si la interpretación del agente se sostiene realmente en el texto.

Pero la respuesta no termina en una lista de documentos. Como se lo pedimos en el _prompt_, el agente también compara las fuentes e identifica contradicciones y lagunas:

En este caso, el agente distingue entre una evolución de postura y una contradicción directa. También detecta cuestiones que los documentos todavía no responden, como qué ocurre con el estado entre sesiones o cómo se mantiene la memoria del agente a largo plazo. (Ideas para nuevas newsletters)

Esta es una de las ventajas de conectar QMD con un agente: no solo recuperas documentos, sino que puedes pedirle que los compare, encuentre vacíos y señale qué conocimiento falta.

MCP no carga todos tus archivos en el contexto del agente. Le permite buscar primero, recuperar únicamente las fuentes necesarias y analizarlas después.

De guardar información a poder encontrarla.

Al principio te decía que tienes documentos por todas partes: newsletters, notas, transcripciones, decisiones, procesos e ideas que guardaste porque algún día podían servirte.

El problema no era que faltara información. Era no poder encontrarla cuando la necesitabas.

QMD no crea una memoria nueva ni reorganiza tus archivos por ti. Indexa las carpetas que ya tienes, permite buscar por palabras o por significado y te devuelve el documento original para que puedas comprobar la fuente.

Cuando lo conectas con tu agente mediante MCP, el sistema da un paso más: el agente puede buscar únicamente en la colección adecuada, recuperar los documentos necesarios y construir una respuesta vinculada a ellos.

Tools are great. Systems are better.

Instalar QMD requiere un comando. Lo valioso aparece cuando decides qué documentos entran, cómo los separas y cómo debe utilizarlos tu agente.

Entonces tus archivos dejan de ser una acumulación de cosas que esperas recordar y se convierten en conocimiento que puedes volver a encontrar.

Recursos

• QMD: repositorio y documentación oficial

• QMD: versiones publicadas

• Model Context Protocol: introducción oficial

• Artículo más técnico para ampliar información

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Acabo de terminar el Programa en Resolución de Problemas Complejos de UNIR. Durante seis meses hemos trabajado metodologías de diagnóstico, análisis, estrategia y comunicación y, en paralelo, hemos desarrollado y defendido un caso práctico en un equipo de cinco personas.

La formación ha coincidido con una serie de newsletters en la que hemos construido varias piezas de un sistema con IA: una skill para conservar el método, un agente para recibir el trabajo y un arnés para limitarlo y comprobarlo.

Podríamos seguir añadiendo componentes. Sin embargo, esta formación me ha devuelto a una pregunta anterior a todos ellos:

¿Qué problema justifica construir el sistema?

Puedes tener una skill bien definida, un agente que respeta sus límites y un arnés que verifica cada salida. Todo puede funcionar exactamente como lo diseñaste y, aun así, no mejorar el trabajo que querías mejorar.

Esta semana no quiero enseñarte otra pieza técnica. Quiero llevar una idea de la resolución de problemas complejos a la implantación de IA: dejar de aprobar soluciones acompañadas de una cifra y empezar a formular hipótesis que podamos poner a prueba.

Suscríbete ahora

El error de empezar por los agentes

Imagina que una organización aprueba este plan:

Implantaremos cinco agentes y reduciremos costes un 20 %.

La frase parece concreta. Tiene una tecnología, una cantidad y un resultado. También esconde casi todo lo que necesitamos saber.

¿Dónde está hoy el problema? ¿Qué parte del proceso genera el coste? ¿Por qué pensamos que un agente puede cambiarla? ¿De dónde sale el 20 %? ¿Qué ocurre si la herramienta acelera una tarea, pero añade revisión en la siguiente? ¿Qué calidad no estamos dispuestos a perder? ¿Cuándo sabremos que conviene corregir el sistema en lugar de ampliarlo?

«Implantar cinco agentes» describe una actividad. «Reducir costes un 20 %» promete un impacto. Entre ambas cosas falta el argumento que las conecta.

La organización ha elegido la solución antes de terminar el diagnóstico y ha convertido dos suposiciones en certezas: que los agentes atacan la causa relevante y que hacerlo producirá ese ahorro. A partir de ahí, el piloto corre el riesgo de convertirse en una demostración: ya no se diseña para averiguar si la idea funciona, sino para justificar una decisión tomada.

Este orden resulta especialmente tentador con la IA. La solución es visible, nueva y fácil de enseñar. El problema, en cambio, suele ser más incómodo: información dispersa, responsabilidades mal repartidas, aprobaciones innecesarias, datos que llegan tarde o procesos que nadie ha observado de principio a fin.

Antes del piloto: diagnosticar el problema correcto

Una de las ideas centrales que hemos trabajado venía de Richard Rumelt: la estrategia es, en esencia, resolución de problemas. Su núcleo encadena diagnóstico, política guía y acciones coherentes. No empieza con un roadmap ni con una cifra aspiracional, sino con una explicación de qué desafío importa y qué lo está sosteniendo.

Esto no convierte cualquier caso de uso de IA en un problema complejo. La gestión de tickets, tal como la hemos planteado, es un proceso operativo acotado: tiene entradas observables, etapas identificables y resultados que podemos medir. Puede ser complicado, pero no es complejo en el sentido de CPS que hemos estudiado durante el programa.

Lo que traslado de este aprendizaje no es la etiqueta, sino una forma de razonar que también resulta útil aquí: separar el problema de la solución, tratar el diagnóstico como una explicación que debe comprobarse y decidir de antemano qué evidencia nos hará continuar, corregir o parar.

Supongamos que las solicitudes de clientes tardan demasiado. Podemos observar que el equipo dedica muchas horas a clasificar correos, buscar información y preparar una primera respuesta. Aun así, todavía no sabemos si esa es la causa principal del retraso.

Quizá el cuello de botella esté en la aprobación posterior. Quizá la información necesaria no está actualizada. Quizá las solicitudes llegan mal categorizadas. O quizá la redacción sí consume tiempo, pero el proceso completo tarda lo mismo porque las respuestas generadas necesitan más revisiones.

No necesitamos presentar esa causa como cierta antes de actuar. Necesitamos hacer explícita la hipótesis y diseñar una intervención que nos permita comprobarla.

En este caso no estamos intentando navegar un escenario complejo. Estamos acotando una mejora operativa y probando si nuestra explicación del retraso es correcta antes de extender la solución.

Cómo diseñar un piloto de IA que permita decidir

El mismo plan podría formularse así:

Las solicitudes de clientes tardan demasiado porque el equipo dedica muchas horas a clasificar correos, buscar información y preparar una primera respuesta. Creemos que automatizar la clasificación y el borrador inicial puede reducir ese tiempo sin empeorar la calidad del servicio.

Durante seis semanas lo probaremos con un solo equipo y un tipo concreto de solicitud. Antes de empezar, mediremos cuánto tarda hoy el proceso y cuántos errores, reclamaciones y revisiones genera.

Consideraremos que la prueba funciona si reduce al menos un 15 % el tiempo total sin aumentar los errores, las reclamaciones ni la carga de revisión humana. Si solo acelera la redacción, pero no el proceso completo, revisaremos nuestro diagnóstico. Si empeora la calidad o desplaza trabajo a otras personas, detendremos la prueba.

Solo ampliaremos el sistema cuando tengamos evidencia de que mejora el proceso completo, no simplemente de que el agente funciona.

Esta formulación es menos espectacular y mucho más útil.

El 15 % ya no aparece como una predicción que la organización promete cumplir. Funciona como un umbral de decisión elegido antes de ver los resultados. Sirve para distinguir una mejora que justifica continuar de una variación pequeña que no compensa el coste, el riesgo o el mantenimiento del sistema.

También obliga a decir qué haríamos si la prueba contradice nuestra explicación. Si el agente redacta más rápido, pero el tiempo total apenas cambia, no basta con ajustar el prompt y repetir la demo. Puede que el cuello de botella estuviera en otro lugar.

El primer planteamiento contiene una solución y una promesa:

• cinco agentes;

• un 20 % de ahorro.

El segundo contiene una hipótesis comprobable:

• dónde creemos que está el problema;

• qué intervención acotada probaremos;

• durante cuánto tiempo;

• contra qué situación inicial la compararemos;

• qué resultado esperamos;

• qué efectos adversos vigilaremos;

• qué observación nos obligaría a corregir el diagnóstico;

• qué evidencia exigiremos antes de escalar.

No garantiza que acertemos. Hace posible aprender sin confundir actividad con avance.

Un agente puede funcionar y no mejorar el proceso

En las newsletters anteriores he insistido en que un agente no termina cuando afirma que ha terminado. Necesitamos evidencia externa: archivos creados, fuentes verificadas, tests superados o criterios de aceptación observables.

Aquí ocurre algo parecido, pero un nivel por encima. Un agente puede superar todas sus pruebas técnicas y no producir una mejora organizativa.

Puede clasificar correctamente el 95 % de los correos y no reducir la cola. Puede generar un borrador en veinte segundos y hacer que una persona dedique diez minutos más a comprobarlo. Puede aumentar el número de respuestas enviadas y empeorar la resolución en el primer contacto. Puede ahorrar tiempo en un equipo desplazando trabajo a otro.

Un estudio publicado en The Quarterly Journal of Economics observó el despliegue de un asistente generativo entre más de 5.000 agentes de atención al cliente. La productividad no se definió como «el modelo escribe rápido», sino mediante conversaciones resueltas por hora, una medida que combinaba tiempo, volumen y resolución. El efecto medio fue positivo, pero no fue igual para todo el mundo: las mejoras se concentraron especialmente en las personas con menos experiencia.

En otro contexto, METR estudió a desarrolladores experimentados trabajando en sus propios repositorios. En su experimento de principios de 2025, los participantes creían que la IA los había acelerado, pero el tiempo observado mostraba una ralentización. Cuando el equipo intentó repetir la medición con herramientas más recientes, aparecieron problemas de selección y nuevas formas de trabajo, como usar varios agentes en paralelo, que hicieron menos fiable la estimación. En febrero de 2026 decidieron rediseñar el experimento.

Estos trabajos no permiten trasladar una cifra a cualquier empresa. Enseñan algo más importante: el efecto depende de la tarea, de las personas, del contexto y de cómo definimos y medimos el resultado. Incluso una prueba bien planteada puede necesitar correcciones cuando cambia la forma de trabajar.

Suscríbete ahora

Qué medir antes de poner en marcha el piloto

Antes de introducir el agente necesitamos saber cómo funciona hoy el proceso. No para producir un dashboard enorme, sino para poder comparar.

En el ejemplo de atención al cliente, una línea base útil podría registrar el tiempo desde que entra una solicitud hasta que queda resuelta, cuánto tiempo permanece esperando, cuántas veces se reabre, cuántas revisiones necesita y qué errores o reclamaciones genera. Si solo medimos los minutos dedicados a redactar, habremos elegido como realidad una parte demasiado pequeña del sistema.

Conviene separar tres tipos de señales:

• Resultado: tiempo total de resolución, solicitudes resueltas correctamente o satisfacción del cliente.

• Proceso: tiempo de clasificación, búsqueda y redacción, porcentaje de borradores aceptados o número de revisiones.

• Efectos adversos: errores, reclamaciones, escalados, trabajo desplazado, pérdida de aprendizaje o diferencias entre grupos.

Esta separación evita un engaño frecuente. Podemos mejorar una métrica intermedia y empeorar el resultado final. También podemos reducir el tiempo medio ocultando que las solicitudes más difíciles ahora tardan más o que una parte del equipo absorbe toda la revisión.

Aquí aparece otra lección de estadística que me llevo al trabajo con IA: medir más no corrige medir mal. Si probamos el agente solo con solicitudes fáciles, excluimos los fallos o no contamos el tiempo de quienes revisan, miles de registros seguirán ofreciendo una imagen falsa del proceso.

No se trata de medir todo. Se trata de medir lo suficiente para que la decisión no dependa de la fluidez de la demo ni de la sensación de velocidad.

Cuándo continuar, corregir o detener la prueba

La pregunta más útil de un piloto no es «¿cómo demostraremos que funciona?». Es otra: ¿Qué tendría que ocurrir para que continuemos, corrijamos o paremos?

Si no podemos responderla antes de empezar, cualquier resultado podrá reinterpretarse como un éxito. Cuando el tiempo mejore, diremos que la IA funciona. Si no mejora, diremos que falta entrenamiento. Si aumenta la revisión, diremos que es una fase temporal. Si aparecen errores, pediremos otro modelo. La hipótesis se vuelve imposible de refutar.

Un marco sencillo puede ayudarnos a fijar de antemano las condiciones de la prueba:

No hace falta que el documento sea largo. Hace falta que obligue a diferenciar lo que sabemos, lo que creemos y lo que vamos a observar.

El marco de gestión de riesgos de IA de NIST sigue una lógica compatible: antes de desplegar, propone entender el contexto y el uso previsto, definir el alcance, comparar beneficios y costes con referencias adecuadas, medir el comportamiento en condiciones parecidas a las reales y mantener mecanismos para corregir o desactivar el sistema si sus resultados no encajan con el propósito.

La plantilla no sustituye ese trabajo de gobernanza. Sirve para que el primer piloto no nazca ya desconectado de él.

¿Qué debe demostrar el piloto antes de escalar el agente?

Una demostración prueba que una máquina puede hacer algo; un piloto debe probar que ese algo mejora un proceso real, para unas personas concretas y bajo condiciones observables.

Escalar exige una pregunta adicional: ¿tenemos razones para pensar que la mejora se mantiene cuando ampliamos el volumen, los casos, los equipos y el tiempo?

Son tres niveles distintos. Saltar del primero al tercero porque una respuesta impresiona es una manera rápida de convertir incertidumbre técnica en coste organizativo.

Una de las ideas que me llevo de estos meses es que los problemas complejos no suelen resolverse de una vez: se navegan. Eso no significa que todo proyecto de IA sea un problema complejo. El caso de los tickets no lo es. La transferencia es más pequeña y, precisamente por eso, más útil: incluso ante un problema operativo acotado, conviene diagnosticar antes de elegir la solución, comprobar nuestras suposiciones y decidir a partir de evidencia.

Por eso una estrategia de IA rigurosa no debería prometer que ya conoce el resultado. Debería explicar cómo aprenderá lo suficiente para tomar la siguiente decisión.

Tools are great. Systems are better.

En las últimas semanas hemos visto cómo construir un sistema con skills, agentes y arneses. Esta es la pieza que va antes: el problema que merece el sistema y la evidencia que exigiremos para conservarlo.

Una estrategia rigurosa no dice: «Sabemos que esto reducirá los costes un 20 %». Dice: «Esta es nuestra mejor explicación del problema, esta es la prueba que haremos y esto es lo que tendría que ocurrir para continuar, corregir o parar».

O, todavía más breve:

P. D. Esta newsletter también nace de seis meses de trabajo compartido. Gracias a mis compañeros de equipo, Edgar, Elena, Nuria y Steven, por el tiempo, las conversaciones y todo el trabajo que hubo detrás de nuestro caso práctico. Una parte importante de lo que me llevo del programa la construimos entre los cinco.

Compartir

Recursos

- UNIR: Programa en Resolución de Problemas Complejos

- Richard Rumelt: *Strategy's strategist*

- NIST: AI Risk Management Framework Core

- *Generative AI at Work*, The Quarterly Journal of Economics

- METR: *We are Changing our Developer Productivity Experiment Design*

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

En las dos últimas newsletters hemos construido dos piezas de un sistema. Primero vimos cómo crear una skill para que un agente tome mejores decisiones. Después distinguimos cuándo basta un agente, cuándo conviene guardar uno y cuándo tiene sentido formar un equipo.

Ya tenemos un procedimiento y alguien capaz de ejecutarlo. Pero todavía falta algo.

Imagina que cada semana guardas transcripciones de vídeos, reuniones, entrevistas o pódcast. Hoy le pasas una a un agente y le pides que la clasifique. El resultado parece bueno. Dentro de tres meses quieres recuperar todas las conversaciones en las que alguien habló de memoria para agentes y descubres que una quedó en el chat, otra tiene etiquetas diferentes y una tercera no conserva el enlace original.

El modelo sabía analizar el texto. El problema es que nunca diseñamos el lugar donde debía trabajar.

Esta semana vamos a construir ese lugar. Será una biblioteca pequeña de transcripciones: recibirá archivos nuevos, los clasificará, creará fichas que podamos consultar y comprobará que cada resultado sigue conectado con su fuente.

No hace falta programar una aplicación ni empezar con una base de datos. Vamos a hacerlo con carpetas, archivos Markdown y un catálogo. Lo suficiente para entender qué aporta un arnés.

Qué es un arnés y por qué no es otro agente

La palabra `harness` se está utilizando con dos niveles de significado que conviene separar.

En sentido técnico, el arnés es la capa que mantiene en marcha el bucle del agente: envía contexto al modelo, recibe sus decisiones, dirige las llamadas a herramientas, devuelve los resultados y controla la ejecución. Claude Code, Codex o el Agents SDK ya incorporan buena parte de ese arnés.

Cuando hablamos de `harness engineering`, el foco se amplía. Ya no pensamos solo en el bucle, sino en el entorno que hemos preparado para que ese bucle haga un trabajo fiable: qué instrucciones encuentra, qué archivos puede leer, dónde deja el estado, qué herramientas puede utilizar, qué permisos tiene y cómo se comprueba el resultado.

La diferencia con las piezas anteriores se puede resumir así:

Skill  → conserva cómo se hace una tarea.
Agente → recibe el trabajo y decide cómo avanzar.
Arnés  → controla el entorno en el que trabaja y qué cuenta como terminado.

Un arnés no tiene por qué incluir varios agentes. Tampoco es un `AGENTS.md` con muchas reglas ni un nombre sofisticado para una carpeta. Es el conjunto de condiciones que permite repetir un proceso sin reconstruir el contexto en cada conversación.

Vamos a verlo con nuestro archivo de transcripciones.

Qué tiene que decidir el sistema al guardar una transcripción

Partimos de una petición normal:

Guarda esta transcripción para que pueda encontrarla cuando vuelva a necesitarla.

Un modelo puede resumir el contenido y proponer cinco etiquetas. Sin embargo, la petición deja casi todas las decisiones importantes abiertas.

¿Dónde debe guardar el original? ¿Puede modificarlo? ¿Qué datos mínimos necesita? ¿Debe inventar una fecha si no aparece? ¿Puede crear una categoría nueva? ¿Cómo sabe si esa transcripción ya existe? ¿Qué archivo tiene que consultar cuando le pidamos recuperarla? ¿Cuándo puede afirmar que ha terminado?

Si esas decisiones no están en el sistema, el agente tendrá que resolverlas de nuevo cada vez. Puede elegir bien en una sesión y de otra manera en la siguiente. El arnés empieza donde dejamos de confiar esas decisiones a la improvisación del chat.

Nuestro sistema mínimo tendrá esta forma:

biblioteca-transcripciones/
├── AGENTS.md
├── claude.md
├── inbox/
├── fichas/
│   └── nombre-transcripcion/
│       ├── original.md
│       └── ficha.md
├── catalogo.csv
├── taxonomia.md
└── registro.md

• AGENTS.md contiene las instrucciones compartidas.

• CLAUDE.md permite que Claude Code cargue esas mismas instrucciones.

• inbox/ recibe las transcripciones pendientes.

• fichas/ guarda una versión breve y consultable de cada una.

• catalogo.csv funciona como índice.

• taxonomia.md contiene las categorías aceptadas.

• registro.md conserva qué ocurrió durante cada ejecución.

La estructura propuesta convierte en decisiones concretas todo lo que el prompt inicial había dejado abierto.

Primera pieza: un punto de entrada claro

Podríamos poner todas las reglas, ejemplos y excepciones dentro de `AGENTS.md`. Sería cómodo al principio y difícil de mantener después.

En Codex, estas instrucciones del proyecto se guardan en AGENTS.md. Claude Code no lee ese archivo directamente, pero CLAUDE.md puede importarlo. Así mantenemos una sola fuente de instrucciones. Si ambos archivos están en la raíz, CLAUDE.md solo necesita esta línea:

@AGENTS.md

La ruta se resuelve desde la ubicación de CLAUDE.md.

El contenido que sí mantenemos en AGENTS.md podría ser este:

# Biblioteca de transcripciones

Este proyecto permite guardar, clasificar y recuperar transcripciones sin perder la relación con el documento original.

## Estructura del proyecto

- `inbox/`: transcripciones pendientes de procesar.
- `fichas/<id>/original.md`: copia canónica e intacta de la transcripción.
- `fichas/<id>/ficha.md`: ficha consultable creada a partir del original.
- `catalogo.csv`: índice de transcripciones procesadas.
- `taxonomia.md`: categorías permitidas.
- `registro.md`: historial de resultados, dudas y bloqueos.

## Fuentes de verdad

- `original.md` conserva el contenido recibido y es la fuente de las citas.
- `taxonomia.md` contiene las únicas categorías que puedes asignar.
- `catalogo.csv` sirve para detectar duplicados y localizar materiales procesados.
- `ficha.md` facilita la consulta, pero no sustituye al original cuando haya que verificar una afirmación.

## Procesar una transcripción

Cuando el usuario pida guardar, registrar, archivar, clasificar o procesar una transcripción:

1. Trabaja solo con el archivo de `inbox/` indicado por el usuario.
2. Lee el archivo completo, `taxonomia.md` y `catalogo.csv`.
3. Comprueba que aparecen título, tipo, fecha y URL de la fuente.
4. Busca la URL en `catalogo.csv` para detectar duplicados.
5. Si falta un dato obligatorio o la URL ya existe, no proceses el archivo. Explica el problema y anótalo en `registro.md`.
6. Usa el nombre del archivo sin extensión como identificador `<id>`.
7. Calcula el hash SHA-256 del archivo y conserva el valor.
8. Crea la carpeta `fichas/<id>/`.
9. Mueve el archivo de `inbox/` a `fichas/<id>/original.md` sin reescribir su contenido.
10. Calcula el hash de `original.md` y comprueba que coincide con el valor anterior.
11. Crea `fichas/<id>/ficha.md`, incluye allí el hash y sigue el formato de este documento.
12. Añade una única fila a `catalogo.csv`.
13. Anota el resultado en `registro.md`.
14. Revisa todas las condiciones de cierre antes de terminar.

Si el proceso falla después de mover el original, devuélvelo a `inbox/` y no añadas la transcripción al catálogo como procesada.

## Formato de ficha

```markdown
# Título de la transcripción

- Tipo: entrevista | vídeo | pódcast | reunión
- Fuente: URL
- Fecha: AAAA-MM-DD
- Temas: tema-1, tema-2
- Original: fichas/<id>/original.md
- Estado: procesada
- SHA-256: valor completo del hash de original.md

## Idea principal

Un párrafo breve con la aportación central de la transcripción.

## Ideas recuperables

- Entre dos y cuatro ideas útiles para búsquedas posteriores.

## Fragmentos verificables

> Uno o dos fragmentos literales presentes en `original.md`.

## Límites o dudas

Datos ausentes, afirmaciones que requieren contraste o ambigüedades.
```

## Catálogo

Mantén exactamente estas columnas:

```text
id,titulo,tipo,fecha,fuente,temas,ficha,original,estado
```

- Usa `<id>` como identificador.
- Separa varios temas con `|`.
- Usa rutas relativas al proyecto.
- No añadas una fila si la URL ya existe.

## Recuperar información

Cuando el usuario pida encontrar, recuperar o comparar ideas guardadas:

1. Consulta primero `catalogo.csv`.
2. Abre las fichas que puedan responder a la búsqueda.
3. Vuelve a `original.md` para comprobar cada fragmento literal y su contexto.
4. Descarta cualquier resultado que no puedas conectar con un original.
5. Devuelve para cada resultado el título, la idea relevante, un fragmento literal, la URL, la ruta de la ficha y la ruta del original.
6. Si no hay evidencia suficiente, dilo con claridad.

## Límites

- No inventes fuentes, fechas, personas, temas ni citas.
- No corrijas, resumas ni reformatees el contenido de `original.md`.
- No crees categorías nuevas sin aprobación del usuario.
- No publiques ni envíes contenido.
- No accedas a carpetas situadas fuera de este proyecto.
- No marques una transcripción como procesada solo porque exista `ficha.md`.

## Condiciones de cierre

Una transcripción está procesada solo si:

- ya no aparece en `inbox/`;
- `fichas/<id>/original.md` y `fichas/<id>/ficha.md` existen;
- la ficha contiene tipo, fuente, fecha, temas y ruta al original;
- el SHA-256 guardado en la ficha coincide con el hash actual de `original.md`;
- todos los temas existen en `taxonomia.md`;
- el catálogo contiene exactamente una fila para la URL;
- las rutas del catálogo abren los archivos correctos;
- los fragmentos literales de la ficha aparecen en `original.md`;
- el resultado está anotado en `registro.md`.

Si alguna condición falla, no declares la tarea terminada. Explica qué falta o qué has restaurado.

El archivo no explica cómo resumir una entrevista ni contiene toda la taxonomía. Indica dónde está cada fuente de verdad, en qué orden debe consultarse y qué límites no puede saltarse.

Esta distinción importa. OpenAI cuenta que su equipo intentó utilizar un único `AGENTS.md` enorme y terminó tratándolo como un índice que apunta a documentación más específica. Cuando todo está cargado desde el principio, las instrucciones compiten con la tarea y se vuelven más difíciles de mantener y verificar.

En nuestra biblioteca, el agente empieza con un mapa pequeño y abre `taxonomia.md` solo cuando necesita clasificar. No necesita cargar todas las fichas para procesar una transcripción nueva. Para comprobar duplicados, busca primero en el catálogo.

No se trata de darle menos contexto. Se trata de organizarlo para que pueda encontrar el contexto adecuado en el momento adecuado.

Segunda pieza: cómo conservar el trabajo entre sesiones

Supongamos que dejamos en `inbox/` una entrevista titulada `como-usar-ia-negocio-locl.md`.

Procesa inbox/entrevista-ia-negocio-local.md.
Antes de terminar, enséñame las comprobaciones que has realizado.

El agente la lee y crea una ficha como esta:

Después añade una fila a `catalogo.csv` con el título, la fuente, la fecha, los temas y la ruta de la ficha. Finalmente deja en `registro.md` una anotación breve: qué archivo procesó, qué cambió y si encontróalguna duda.

Antes de cerrar, calcula el hash SHA-256 de `original.md` y guarda ese valor en la ficha. El hash es una huella del contenido: si el archivo cambia, aunque sea en un solo carácter, la huella también cambia. No sirve para clasificar la transcripción; sirve para comprobar en otra sesión que el original sigue intacto.

Esos archivos hacen algo que el chat no puede garantizar por sí solo: conservar el estado del trabajo entre sesiones.

La semana siguiente podemos abrir una conversación nueva y pedir:

Encuentra las transcripciones en las que alguien explique por qué empezó
automatizando una tarea pequeña. Devuélveme la idea, el fragmento que la
sostiene y el enlace a la fuente.

El agente no necesita recordar la conversación anterior. Puede consultar el catálogo, abrir las fichas candidatas y volver al original cuando necesite verificar una cita.

Tercera pieza: qué archivos puede leer y modificar el agente

Hasta ahora hemos decidido cómo se organiza la información. El arnés también tiene que establecer qué operaciones necesita el agente y cuáles quedan fuera del proceso..

Para procesar una transcripción, el agente debe leer el archivo indicado en inbox/, consultar taxonomia.md y comprobar duplicados en catalogo.csv. Después crea fichas/<id>/, mueve la transcripción sin alterar su contenido a original.md, genera ficha.md, guarda allí el hash SHA-256 y actualiza el catálogo y el registro.

La política queda así:

Puede leer: inbox/, taxonomia.md, catalogo.csv y fichas/.
Puede crear y actualizar: fichas/<id>/ficha.md, catalogo.csv y registro.md.
Puede mover: la transcripción indicada desde inbox/ hasta fichas/<id>/original.md.
No puede modificar: el contenido de original.md, la taxonomía ni las instrucciones del proyecto.
No puede publicar, enviar contenido ni trabajar fuera de esta biblioteca.
Debe pedir ayuda: si falta la fuente o la fecha, encuentra un posible duplicado o necesita una categoría que no existe.

Mover el original no significa tener permiso para reescribirlo. El archivo deja de estar pendiente en inbox/ y pasa a ser la fuente canónica de esa transcripción. Desde ese momento solo se consulta. La ficha puede corregirse o ampliarse; el original no.

AGENTS.md describe esta política y orienta el comportamiento, pero escribir una regla ahí no obliga por sí solo al agente a cumplirla. En esta versión sencilla, Claude Code muestra las operaciones de escritura y traslado para que podamos revisarlas antes de aprobarlas.

Cuarta pieza: el agente no termina porque lo diga

La parte más valiosa del ejemplo aparece al final.

Imagina que el agente responde:

He clasificado correctamente la transcripción.

Eso es una afirmación, no una comprobación. Para aceptar el trabajo necesitamos observar algo fuera de su propia respuesta.

Además de decidir qué puede hacer el agente, necesitamos decidir qué rastro debe dejar. Cada transcripción procesada debería permitir reconstruir qué original recibió, dónde lo guardó, qué ficha creó, qué cambios hizo en el catálogo y qué dudas encontró. Sin ese registro, el proceso puede funcionar, pero nosotros no podemos auditarlo ni corregirlo cuando algo falla.

En nuestra biblioteca, ese rastro se ve en cuatro sitios:

• inbox/ muestra qué transcripciones siguen pendientes o bloqueadas.

• fichas/<id>/ conserva juntas la fuente original, la ficha y la huella SHA-256.

• catalogo.csv indica qué se procesó, con qué estado y dónde están los archivos.

• registro.md explica qué ocurrió durante la ejecución: si terminó, qué dudas aparecieron o por qué se rechazó.

En esta primera versión podemos usar una lista de control:

[ ] La transcripción original sigue intacta. 
[ ] La ficha contiene título, tipo, fuente y fecha. 
[ ] Los temas existen en taxonomia.md. 
[ ] El catálogo contiene una sola fila para esa fuente. 
[ ] La ruta incluida en el catálogo abre la ficha correcta. 
[ ] Los fragmentos literales aparecen en el original. 
[ ] El resultado quedó anotado en registro.md.

Más adelante, varias comprobaciones pueden convertirse en un script: detectar campos vacíos, rutas rotas, categorías desconocidas o fuentes duplicadas. El criterio editorial seguirá necesitando revisión, pero la estructura no tiene por qué revisarse a mano cada vez.

También cambia la forma de corregir errores. Si el agente inventa una fecha, no basta con repetir el prompt con más énfasis. Actualizamos AGENTS.md para indicar que debe detenerse cuando falte ese dato y añadimos una condición de cierre: la fecha de ficha.md tiene que aparecer en original.md. La corrección queda incorporada al sistema y se aplica en las siguientes sesiones.

Seis pruebas para comprobar si el arnés funciona

Cada prueba parte de una situación concreta y define qué debería hacer el sistema. Si el resultado es distinto, hemos encontrado un fallo en el arnés.

1. Probamos una transcripción válida. Incluye título, fecha y URL. El resultado correcto es que el sistema guarde original.md y ficha.md dentro de fichas/<id>/, añada la entrada al catálogo y anote el proceso en el registro.

2. Probamos una transcripción sin URL. El resultado correcto es que el archivo permanezca en inbox/, no se añada al catálogo y el sistema indique qué dato debemos completar. Si inventa una URL o da el trabajo por terminado, el arnés ha fallado.

3. Probamos una transcripción duplicada. Su URL ya figura en el catálogo. El resultado correcto es que el sistema señale la coincidencia y no cree otra ficha ni mueva el archivo. Si guarda una segunda copia sin avisar, el arnés ha fallado.

4. Probamos un contenido que no encaja en la taxonomía. El resultado correcto es que el sistema explique la duda y nos pida una decisión. Si crea una categoría nueva por su cuenta, el arnés ha fallado.

5. Modificamos un original después de procesarlo. Volvemos a calcular su SHA-256 y lo comparamos con el valor guardado en la ficha. El resultado correcto es que el sistema detecte que los valores no coinciden y avise del cambio. Si lo pasa por alto, hemos perdido la garantía de que la ficha sigue vinculada al mismo original.

6. Buscamos una idea con palabras distintas de las etiquetas. El resultado correcto es que el sistema localice posibles fichas, consulte los originales y responda con fragmentos y fuentes que podamos comprobar. Si responde sin volver a las fuentes, no podemos verificar el resultado.

No construyas una plataforma cuando todavía necesitas una carpeta

Al hablar de arneses aparecen enseguida bases vectoriales, orquestadores, memoria semántica, colas de tareas y equipos de agentes. Algunas bibliotecas necesitarán esas piezas. La nuestra todavía no.

Para unas decenas o cientos de transcripciones, una estructura de archivos y un catálogo pueden ser suficientes para descubrir el proceso real. Nos permiten saber qué campos importan, qué taxonomía aguanta el uso, qué búsquedas hacemos de verdad y dónde falla el agente.

Solo después tendrá sentido preguntar si necesitamos una base de datos, búsqueda semántica o varios agentes trabajando en paralelo. Añadir arquitectura antes de conocer esos patrones no elimina la incertidumbre. La esconde dentro de un sistema más caro de mantener.

La versión mínima del arnés responde cinco preguntas:

1. ¿Dónde entra el trabajo? En `inbox/`.

2. ¿Qué reglas debe consultar? El mapa del proyecto y la taxonomía.

3. ¿Dónde queda el estado? En las fichas, el catálogo y el registro.

4. ¿Qué puede modificar? Solo las salidas necesarias.

5. ¿Cómo se comprueba? Con condiciones observables y, cuando sea posible, validaciones automáticas.

Si no puedes responder estas preguntas, cambiar de modelo probablemente no arreglará el proceso.

Tools are great. Systems are better.

Ese es el salto de esta serie: dejar de pensar solo en lo que el modelo puede responder y empezar a diseñar las condiciones que necesita para trabajar bien más de una vez.

Sigue la serie: de prompts a sistemas.

En la primera entrega vimos cómo crear una skill pequeña, activable y verificable. En la segunda, cómo elegir entre una conversación principal, un subagente, un agente reutilizable y un equipo.

En esta tercera hemos unido las piezas dentro de un entorno de trabajo: instrucciones que funcionan como mapa, estado fuera de la conversación, permisos ajustados a la tarea y pruebas que deciden cuándo aceptar el resultado.

Recursos

• OpenAI: Harness engineering — leveraging Codex in an agent-first world

• OpenAI: The next evolution of the Agents SDK

• Anthropic: Effective harnesses for long-running agents

• Anthropic: Scaling Managed Agents — Decoupling the brain from the hands

• AGENTS.md: formato abierto para guiar agentes

• Think&Hack: Cómo crear una skill para que tu agente tome mejores decisiones

• Think&Hack: Un agente, un subagente o un equipo — ¿qué necesitas realmente?

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

La semana pasada escribí sobre cómo crear una skill para que un agente tome mejores decisiones. La pregunta central era: ¿cómo hago para que el agente no improvise cada vez?

Esta semana quiero subir un nivel.

Una skill guarda una forma de trabajar. Pero ¿quién hace el trabajo? ¿La conversación principal? ¿Otro agente al que delegas una parte? ¿Un agente especializado que dejas preparado para volver a usarlo? ¿Un equipo entero?

Cuando empezamos a hablar de agentes, es fácil imaginar una organización en miniatura: un coordinador, varios especialistas, un revisor y quizá otro agente que vigila al revisor. Suena avanzado. También puede ser una manera muy cara de hacer algo que una sola sesión resolvía bien.

Por eso prefiero empezar con una distinción más sencilla: en Claude Code no necesitas elegir entre “un agente” y “un sistema multiagente”. Puedes aumentar la delegación a medida que el trabajo lo justifica.

Voy a usar el mismo ejemplo durante toda la newsletter: tienes notas de una entrevista, fragmentos de una transcripción y varias ideas sueltas. Antes de escribir, quieres convertir ese material en un brief editorial con objetivo, audiencia, ángulo, evidencias, huecos y siguiente paso.

No hace falta saber programar para entender el problema. Solo hay que decidir quién debe leer el material, qué debe devolver y cuánto de ese comportamiento merece conservarse.

Antes de crear uno: ¿qué es un agente en Claude Code?

La conversación principal de Claude Code ya funciona como un agente: recibe un objetivo, lee contexto, utiliza herramientas, observa sus resultados y decide el siguiente paso. No se limita a producir una respuesta de una vez; puede avanzar por una tarea y ajustar el camino según lo que encuentra.

Un subagente es una delegación dentro de esa sesión. Trabaja en su propia ventana de contexto y devuelve el resultado a quien lo llamó. Esto resulta útil cuando una investigación va a leer muchos archivos, generar mucho ruido o necesita unas instrucciones y herramientas diferentes de las de la conversación principal.

La diferencia con una skill es importante:

• Una skill incorpora conocimiento o un procedimiento reutilizable a una conversación.

• Un subagente recibe trabajo en un contexto separado y devuelve su resultado.

• Un agent team coordina varias sesiones independientes que pueden repartirse tareas y comunicarse entre sí.

No son tres versiones de lo mismo. Resuelven problemas distintos.

Para saber si una tarea merece un agente, miraría cinco cosas: qué objetivo tiene, qué contexto necesita, qué herramientas puede usar, qué decisiones debe tomar y cuándo debe detenerse. Si solo quieres aplicar unas instrucciones para obtener siempre el mismo tipo de resultado, probablemente basta con una skill. En cambio, si puedes separar la tarea del resto de la conversación, darle unas fuentes concretas y pedirle que investigue, tome decisiones y vuelva con una conclusión, entonces empieza a tener sentido delegarla a un agente.

Nivel 1: un agente puntual para una tarea concreta

La forma más pequeña de delegación no exige crear ningún archivo. Puedes pedirle a Claude Code que lance un subagente para una tarea puntual:

Lanza un subagente para leer las notas de entrevista de la carpeta notas/.
Quiero que identifique el tema central, las afirmaciones que tienen evidencia,
las dudas que habría que verificar y tres posibles ángulos.
No escribas todavía la pieza. Devuélveme solo los hallazgos relevantes.

Claude Code dispone de subagentes integrados para explorar, planificar o resolver tareas generales. El trabajo de lectura ocurre fuera del contexto principal y vuelve resumido. Tú no has creado todavía un nuevo trabajador permanente: has delegado una misión de una sola vez.

Este nivel encaja cuando el trabajo es autocontenido y no sabes si volverás a necesitarlo. También sirve para probar una idea antes de convertirla en arquitectura. Si el encargo cambia cada semana, guardar un agente especializado demasiado pronto puede darte más mantenimiento que valor.

El prompt necesita algo más que “investiga estas notas”. Conviene especificar:

• qué material puede consultar;

• qué pregunta debe resolver;

• qué no debe hacer;

• qué resultado tiene que devolver.

En nuestro ejemplo, el límite “no escribas todavía la pieza” evita que el agente salte desde la investigación a la redacción. El formato de salida ayuda a que la conversación principal reciba una síntesis utilizable, no todo el recorrido del subagente.

Este primer nivel también sirve para detectar tareas que se repiten. Si cada semana acabas pidiendo “lee estas notas, separa la evidencia de las hipótesis y propón un ángulo”, ya no estás ante un encargo puntual. En lugar de volver a escribir o retocar el mismo prompt, puede tener sentido convertir esas instrucciones en un agente especializado que puedas reutilizar.

Nivel 2: un agente especializado que puedes volver a usar

Cuando la misma delegación se repite, puedes crear un custom agent. En Claude Code es un archivo Markdown dentro de una de estas carpetas:

.claude/agents/brief-curator.md     → disponible en ese proyecto
~/.claude/agents/brief-curator.md   → disponible en todos tus proyectos

La versión mínima tiene una cabecera YAML y un cuerpo de instrucciones:

---
name: brief-curator
description: Convierte notas de entrevista, fragmentos de transcripción,
  investigación e ideas sueltas en un brief editorial con objetivo,
  audiencia, ángulo, evidencias, huecos y siguiente paso. Úsalo antes
  de redactar. No lo uses para resumir, escribir la pieza final ni publicar.
tools: Read, Grep, Glob
---

Eres responsable de convertir material editorial disperso en un brief
accionable. No escribas la pieza final.

1. Lee solo las fuentes que indique el encargo.
2. Identifica el objetivo y la audiencia.
3. Formula un ángulo explícito que no sea un resumen del material.
4. Separa hechos, interpretaciones y huecos de información.
5. Termina con un único siguiente paso.

Devuelve estas secciones:

# Brief editorial
## Objetivo
## Audiencia
## Ángulo
## Evidencias
## Huecos y riesgos
## Siguiente paso

`name` identifica al agente. `description` le dice a Claude cuándo debe delegar en él. El cuerpo define cómo trabaja. Y `tools` recorta sus capacidades: este agente puede leer y buscar, pero no escribir archivos ni publicar nada.

Puedes pedirle a Claude Code que cree el archivo por ti:

Crea un subagente de proyecto llamado brief-curator en .claude/agents/.
Debe convertir material editorial disperso en un brief, trabajar en modo
solo lectura y detenerse antes de redactar o publicar. Antes de terminar,
enséñame el archivo y explica por qué le has dado esas herramientas.

Después no des el trabajo por bueno porque el archivo tenga buen aspecto. Pruébalo.

Prueba positiva:

Usa el agente brief-curator para preparar el enfoque de estas notas antes de redactar.

Prueba cercana que no debería activarlo:

Resume esta transcripción en tres frases.

Prueba de límite:

Usa brief-curator para escribir el artículo final y publicarlo.

El primer caso debería devolver el brief. El segundo no debería convertirse en un brief porque has pedido un resumen. En el tercero, el agente debería mantenerse dentro de su función y no publicar ni redactar la pieza final.

Aquí aparece la misma disciplina que vimos con las skills: no evalúes solo si el resultado está bien escrito. Evalúa si el agente entra cuando toca, se queda fuera cuando no toca y respeta sus límites.

La skill `decision-brief` de la semana pasada todavía puede tener un papel. Si las notas contienen una decisión implícita, `brief-curator` puede usar esa skill para aclararla. El agente decide cuándo necesita esa capacidad; la skill define cómo ejecutarla. No hace falta copiar el procedimiento de la skill dentro del agente.

Nivel 3: un equipo de agentes que necesita coordinarse

Un agent team no es “muchos subagentes”. Es un conjunto de sesiones independientes: hay una sesión líder, varios teammates y una lista compartida de tareas. Los miembros pueden comunicarse entre sí, no solo devolver un informe al agente principal.

En nuestro ejemplo, un equipo podría tener una persona-agente investigando las fuentes, otra defendiendo la perspectiva del lector y otra comprobando afirmaciones y huecos. La sesión líder reuniría sus hallazgos y resolvería los desacuerdos.

Crea un equipo de agentes para preparar el brief editorial de esta investigación.
Un teammate revisará las fuentes y la evidencia; otro analizará qué necesita
entender un lector no técnico; un tercero buscará afirmaciones débiles,
repeticiones y huecos. Quiero que contrasten sus hallazgos antes de que
la sesión líder proponga el ángulo final.

¿Aporta algo frente a lanzar tres subagentes y reunir sus respuestas? Solo si esos trabajadores necesitan compartir hallazgos, discutirlos o reajustar su trabajo. Si cada uno puede resolver su parte y devolver una síntesis al principal, los subagentes suelen ser suficientes.

Esta diferencia evita mucho teatro organizativo. Lanzar un equipo de agentes tiene sentido cuando el trabajo se puede dividir en frentes relativamente independientes y la colaboración entre ellos mejora la decisión. Añade coste de tokens, coordinación, latencia y más lugares donde puede perderse información.

Además, en Claude Code los agent teams siguen marcados como experimentales y están desactivados por defecto. No los usaría como punto de partida para un lector que está creando su primer agente. Primero demuestra que una delegación simple mejora el trabajo. Después convierte el patrón repetido en un agente especializado. Solo crea un equipo cuando exista una necesidad real de coordinación entre sesiones.

No elijas por lo impresionante que parece

Los tres niveles se pueden resumir con una pregunta: ¿qué problema de trabajo estás intentando resolver?

También hay tareas que no necesitan ninguno. Una corrección breve que depende de todo lo hablado en la conversación puede quedarse en la sesión principal. Un procedimiento repetible puede ser una skill. Una validación mecánica puede vivir en un script o un hook.

Un sistema no mejora por añadir más agentes. Dividir el trabajo solo aporta valor cuando resuelve un problema concreto: evita llenar la conversación principal de información innecesaria, limita permisos, permite reutilizar instrucciones, separa perspectivas diferentes o ejecuta en paralelo tareas que realmente son independientes.

Por eso, antes de crear un agente, respondería estas cinco preguntas:

1. ¿Qué trabajo exacto voy a delegar?

2. ¿Qué contexto necesita y cuál no necesita ver?

3. ¿Qué herramientas debe poder usar y cuáles conviene quitarle?

4. ¿Qué resultado debe devolver a la sesión principal?

5. ¿Cómo comprobaré que ha terminado bien y no solo que ha respondido?

Si no puedes responderlas, añadir agentes no aclarará el sistema. Solo repartirá la ambigüedad.

Tools are great. Systems are better.

Un agente puntual te ayuda a delegar. Un agente especializado te ayuda a repetir. Un equipo te ayuda a coordinar. El salto importante no es pasar de uno a muchos. Es pasar de pedir “haz esto” a diseñar quién recibe el trabajo, con qué límites y qué evidencia debe devolver.

Sigue la serie: de prompts a sistemas.

Esta newsletter continúa la serie que empecé explicando cómo crear una skill.

Una skill conserva el procedimiento. Un agente recibe un trabajo, utiliza contexto y herramientas, toma decisiones y devuelve un resultado. Entender esta diferencia ayuda a elegir qué necesitas antes de empezar a añadir piezas.

Recursos

- Claude Code Docs: Create custom subagents

- Claude Code Docs: Orchestrate teams of Claude Code sessions

- Claude Code Docs: Extend Claude Code

- Anthropic: Building Effective AI Agents

- Think&Hack: Cómo crear una skill para que tu agente tome mejores decisiones

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Estos días estoy preparando el módulo de skills de un curso de IA aplicada para una escuela de negocios.

Cuando estaba preparando el tema, me di cuenta de una cosa: una skill casi nunca falla porque alguien no sepa escribir Markdown. Falla antes, cuando la usamos como carpeta de instrucciones y no como una forma de cambiar cómo trabaja un agente.

Me he traído esta parte del módulo porque esa confusión aparece enseguida cuando intentas pasar de prompts sueltos a procesos con IA.

La pregunta es sencilla:

¿Cómo hago para que el agente no improvise cada vez?

Si quieres llevar la IA a procesos reales, con agentes, skills y sistemas verificables, escríbeme. Estoy preparando más formaciones y acompañamientos sobre esto.

Vamos a verlo con un ejemplo pequeño: una skill para trabajar con notas de reuniones.

El error: “ayuda con reuniones”

Imagina que quieres crear una skill para trabajar mejor con notas de reuniones.

La versión mala:

---
name: meeting-helper
description: Ayuda con reuniones.
---

Y en el cuerpo del archivo:

# Meeting helper

Resume reuniones de forma clara.
Extrae acuerdos.
Sé conciso.
Organiza la información.
Incluye próximos pasos.

Suena razonable. También es demasiado amplia.

¿Tiene que hacer un acta completa? ¿Una agenda? ¿Un resumen ejecutivo? ¿Una lista de tareas? ¿Un documento de decisión? ¿Debe inferir acuerdos implícitos? ¿Puede crear responsables si no aparecen? ¿Debe activar cuando alguien pida tickets?

El agente no lo sabe.

Yo prefiero empezarlo por otro lado: no crear “una skill para reuniones”, sino acotar una tarea mucho más concreta:

Convertir notas de reunión, conversación o discusión técnica en un brief de decisión.

Con este cambio, la skill decision-brief no intenta gestionar reuniones. Acota una tarea más pequeña y más útil: convertir una conversación con mucho texto en una decisión clara, con opciones, riesgos y siguiente acción.

¿Qué es técnicamente una skill?

Una skill es una carpeta autocontenida. La unidad mínima es esta:

decision-brief/
└── SKILL.md

Una versión más completa puede tener archivos de apoyo:

decision-brief/
├── SKILL.md
├── references/
│   └── decision-quality-rubric.md
├── assets/
│   └── brief-template.md
└── scripts/
    └── check-brief-structure.py

SKILL.md es el archivo obligatorio. Dentro tiene dos partes.

La primera es la cabecera YAML: unas líneas entre `---` que el agente lee como configuración. Ahí viven campos como `name` y `description`.

---
name: decision-brief
description: Usa esta skill cuando el usuario necesite convertir notas desordenadas en un brief de decisión.
---

La segunda parte es el cuerpo en Markdown. Ahí escribes el procedimiento, el formato de salida, los límites y las comprobaciones.

# Decision brief

Usa esta skill para convertir material desordenado de conversación en un brief breve de decisión.

## Procedimiento

1. Lee las notas con mirada orientada a decisión.
2. Separa contexto, opciones, decisión, riesgos y siguiente acción.
3. Si la decisión no está sostenida por las notas, dilo.
4. No inventes responsables, fechas ni compromisos.
5. Revisa la salida antes de terminar.

• references/ sirve para conocimiento que no hace falta leer siempre: una rúbrica larga, reglas internas, documentación o ejemplos extensos.

• assets/ sirve para materiales de salida: una plantilla oficial, un formato corporativo o un archivo base.

• scripts/ sirve para operaciones mecánicas: validar columnas, comprobar secciones, transformar datos o detectar errores repetibles.

¿Cómo sabe el agente si debe usar la skill?

Aquí conviene bajar al detalle. Una skill no se activa por magia: el entorno donde trabajas la descubre y la pone a disposición del agente.

En Codex, una skill de proyecto puede vivir en:

.agents/skills/decision-brief/SKILL.md

Codex también puede leer skills personales desde:

$HOME/.agents/skills/decision-brief/SKILL.md

En Claude Code, una skill de proyecto vive en:

.claude/skills/decision-brief/SKILL.md

Y una personal en:

~/.claude/skills/decision-brief/SKILL.md

A partir de ahí hay cuatro situaciones.

1. Invocación automática. El agente no lee todas las skills completas desde el principio. Primero ve una lista resumida con señales como el nombre y la description. Si la petición encaja con una de ellas, entonces carga esa skill completa.

2. Invocación explícita. Tú puedes forzar una skill por su nombre. En Codex puedes escribir $decision-brief o abrir /skills. En Claude Code puedes usar /decision-brief. En este caso no esperas a que el agente la sugiera: la llamas directamente.

3. Bloqueo de invocación automática. Hay skills que no quieres que el agente elija por su cuenta. En Codex puedes añadir un archivo agents/openai.yaml dentro de la carpeta de la skill:

policy:
  allow_implicit_invocation: false

Con eso, Codex no debería elegir esa skill solo porque la petición se parezca a la descripción. Seguiría disponible si la llamas de forma explícita.

En Claude Code, la misma intención puede declararse en la cabecera YAML:

---
name: decision-brief
description: Convierte notas desordenadas en un brief de decisión.
disable-model-invocation: true
---

Eso significa: el usuario puede llamarla, pero Claude no debería cargarla por decisión propia.

4. Desactivación. Si una skill ya no debe estar disponible, no basta con retocarla description. Puedes sacarla de las carpetas que Codex descubre, desinstalarla si venía empaquetada o dejarla instalada pero apagada desde ~/.codex/config.toml:

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

En Claude Code puedes ocultarla con skillOverrides, por ejemplo, marcándola como "off" en la configuración local.

Esto es lo práctico: carpeta descubierta para que exista, description clara para que el agente pueda elegirla, nombre explícito para forzarla y política de invocación para controlar cuándo no debe entrar sola.

Ahora sí se entiende por qué la description es tan importante.

La description del skill

La description no resume la skill. Le dice al agente cuándo debe usarla y cuándo no.

Una mala descripción dice:

description: Ayuda con reuniones.

Una buena descripción dice qué intención cubre, qué entradas espera, qué salida produce y qué tareas cercanas quedan fuera.

En el ejemplo de decision-brief, podría quedar así:

---
name: decision-brief
description: Usa esta skill cuando el usuario necesite convertir notas de reunión, conversaciones, hilos de chat o apuntes técnicos desordenados en un brief de decisión con contexto, opciones, decisión, riesgos y siguiente acción. Úsala cuando la decisión pueda ser explícita, implícita o todavía no esté sostenida por evidencia suficiente. No la uses para actas completas, registros legales, planes de proyecto, creación de tickets ni resúmenes genéricos.
---

Fíjate en la diferencia: no promete “ayudar con reuniones”. Dice qué trabajo hace y qué trabajos parecidos quedan fuera.

Por ejemplo, esta skill debería activarse cuando la petición apunta a una decisión:

O cuando el usuario ya sospecha que hubo una decisión, pero necesita ordenarla:

En cambio, NO debería activarse si la petición pide otro tipo de trabajo:

Las instrucciones: qué hace el agente cuando la skill se activa

La description ayuda a decidir si la skill debe activarse. El cuerpo en Markdown explica qué tiene que hacer el agente a partir de ahí.

En esa parte conviene escribir solo las instrucciones que necesita siempre: el procedimiento, los criterios de decisión, el formato de salida y las comprobaciones básicas.

Para decision-brief, el núcleo podría ser:

## Procedimiento
1. Lee el material con mirada orientada a decisión.
2. Clasifica el estado de la decisión: explícita, implícita o no sostenida por las notas.
3. Extrae solo el contexto necesario.
4. Lista opciones relevantes, no todos los comentarios.
5. Escribe la decisión o declara que no hay evidencia suficiente.
6. Recoge riesgos y dudas sin inventar.
7. Termina con una siguiente acción concreta si aparece en las notas.
8. Valida el brief antes de cerrarlo.

El formato de salida también puede ir en el cuerpo de la skill si forma parte del comportamiento habitual:

# Decision brief
## Contexto
## Opciones consideradas
## Decisión
## Riesgos y dudas
## Siguiente acción

Los materiales que no hacen falta en cada uso deberían ir aparte.

• Un documento con criterios de revisión puede ir en references/, y el SKILL.md debe indicar cuándo consultarlo.

• Si tu organización usa un modelo fijo de brief, ese archivo puede ir en assets/.

• Si hay una validación que se puede automatizar, puede ir en scripts/.

Cuando una skill intenta hacer demasiado

Una skill también se estropea por exceso.

Pasa cuando el SKILL.md intenta contenerlo todo: teoría, procedimiento, ejemplos largos, plantillas, casos históricos, excepciones, notas de mantenimiento y deseos de calidad. Hay mucho material, pero poca prioridad.

También pasa cuando la skill cubre demasiadas fases. Si decision-brief empieza a crear tickets, actualizar un plan, redactar un correo, programar seguimiento y decidir por el equipo, ya no es una skill pequeña. Es un proceso entero comprimido en un archivo.

El problema es que el agente puede ver demasiado pronto el formato final y correr hacia él sin hacer bien el razonamiento previo.

Por ejemplo, si decision-brief contiene a la vez instrucciones para leer notas, plantilla final, ejemplos largos, reglas de calidad, casos especiales, pasos para crear tickets y pasos para mandar un email, el agente puede saltar demasiado rápido a “generar un brief” y dedicar menos atención a lo importante: separar decisión, opciones, riesgos y evidencia.

La solución no siempre es escribir más instrucciones. A veces es dividir:

decision-brief       -> aclara la decisión
decision-to-tickets  -> convierte una decisión validada en tareas
stakeholder-update   -> prepara comunicación para el equipo

Antes de cerrar una skill, revisa cada frase con esta pregunta:

¿Esto cambia alguna decisión del agente?

1. ¿Le dice cuándo debe activarse la skill? => Se queda.

2. ¿Ordena los pasos que debe seguir el agente? => Se queda.

3. ¿Marca qué debe evitar? => Se queda.

4. ¿Indica qué recurso consultar y cuándo? => Se queda.

5. ¿Explica cómo revisar la salida? => Se queda.

6. ¿Suena bien, pero no cambia lo que el agente hará? => Probablemente sobra.

Cinco preguntas antes de escribir una skill

Antes de cerrar una skill, revisa cada frase con esta pregunta:

• ¿Qué tarea repetida quieres mejorar? => Convertir notas desordenadas en un brief de decisión.

• ¿Qué hace mal el agente sin skill? => Resume demasiado, mezcla opciones con decisiones o inventa responsables.

• ¿Qué criterio experto debe aplicar? => Leer buscando decisión, opciones, riesgos, evidencia y siguiente acción.

• ¿Cuándo no debe activarse? => Cuando se piden actas completas, tickets, planes de proyecto, registros legales o resúmenes genéricos.

• ¿Qué error debe evitar? => Convertir cualquier conversación en un resumen bonito pero poco útil.

Después viene la prueba incómoda: lanza la misma petición con y sin skill.

Si la salida es igual, la skill no aporta. Si solo está más ordenada, tampoco basta.

Una skill empieza a tener sentido cuando evita un error que antes ocurría. En decision-brief, ese error es claro: inventar decisiones, esconder la falta de evidencia o mezclar contexto, opciones, riesgos y siguiente acción.

Eso ya empieza a ser sistema.

Por eso vuelvo al punto de partida: una skill no falla porque alguien no sepa escribir Markdown.

Falla cuando no hemos decidido qué comportamiento queremos cambiar.

Si la skill solo guarda instrucciones, el agente seguirá improvisando con mejor envoltorio. Si la skill define cuándo activarse, qué tarea resolver, qué dejar fuera y cómo comprobar la salida, entonces empieza a parecerse a un sistema.

Y esa es la parte que más me interesa llevar a equipos y formaciones: pasar de usar IA como una colección de herramientas sueltas a diseñar procesos que aguantan el uso real.

Compartir

Sigue la serie: de prompts a sistemas

Esta newsletter es la primera parte de una serie sobre cómo pasar de prompts sueltos a sistemas de trabajo con IA.

Aquí hemos visto cómo crear una skill para conservar una forma de trabajar. En la siguiente entrega explico cuándo conviene mantener la tarea en la conversación, cuándo crear un agente reutilizable y cuándo varios agentes pueden trabajar mejor juntos.

Recursos

• OpenAI Developers: Agent Skills en Codex

• Claude Code Docs: Extend Claude with skills

• Agent Skills: overview del estándar abierto

• SkillJuror: Measuring How Agent Skill Organization Changes Runtime Behavior

• Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry

• Think&Hack: Agentes de IA para SEO: procesos con evidencia

• Think&Hack: Cómo convertí mi inbox en un sistema verificable de agentes

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Esta semana publiqué un post sobre una idea que todavía está a medio camino entre hipótesis técnica y obsesión SEO: la web agent-to-agent y por qué el SEO podría necesitar una capa de cambios.

No es una predicción. No estoy diciendo que Google vaya a leer mañana un `log.md` ni que eso vaya a convertirse en un factor de ranking. Si alguien lo vende así, desconfía.

La pregunta que me interesa es otra: quizá estamos intentando imaginar el futuro del SEO con herramientas mentales demasiado viejas.

Durante años, la pregunta técnica fue relativamente clara: ¿puede Google descubrir, rastrear, renderizar, indexar y entender esta página?

Esa pregunta sigue viva. De hecho, Google explica que sus funciones de IA en Search se apoyan en los sistemas principales de ranking y calidad de la Búsqueda. Para aparecer en AI Overviews o AI Mode no hay un archivo mágico nuevo: la página tiene que poder entrar en el índice, ser apta para mostrarse con un fragmento y cumplir las bases de siempre.

Hasta aquí, pocas sorpresas.

Pero AI Overviews no es todo el movimiento. Alrededor de la web clásica están apareciendo otras piezas: agentes que descubren capacidades, protocolos para coordinar agentes, formatos para conocimiento portable, registros verificables, herramientas conectadas por MCP y sistemas que no solo leen páginas, también ejecutan acciones.

Cuando incorporas todo eso a la conversación, la pregunta cambia.

Ya no basta con preguntar si Google entiende una página. Empieza a importar si un agente puede entender qué recurso tienes, qué puede hacer con él, qué cambió, si puede confiar en esa información y cuál debería ser el siguiente paso.

El matiz parece pequeño. No lo es.

La gente ve el futuro del SEO desde cuatro miedos distintos

Cuando escucho conversaciones sobre el futuro del SEO, casi siempre aparecen cuatro posturas.

La primera dice que esto es SEO de siempre con otro envoltorio. Tiene parte de razón. Si tu web no se rastrea, no se indexa, no resuelve intención, no tiene arquitectura interna y no genera confianza, da igual que lo llames SEO, GEO, AEO, LLMO o ASO. Estás poniendo siglas encima de una base rota.

La segunda dice que el SEO se muere porque ya no habrá clics. También hay algo de verdad ahí, pero la conclusión es pobre. Habrá búsquedas donde el clic será menos probable. Algunas consultas informativas se resolverán dentro de una respuesta generada. Parte del tráfico no volverá. Pero eso no elimina la necesidad de ser fuente, entidad, marca, referencia, proveedor o recurso ejecutable.

La tercera dice que hay que optimizar para que ChatGPT te cite. Aquí empieza el riesgo. Una parte del mercado intentará convertir la incertidumbre en checklist: añade FAQs, escribe pasajes extractables, consigue menciones en Reddit, crea comparativas, empuja contenido en sitios de terceros. Algunas acciones tendrán sentido. Otras serán spam con vocabulario nuevo.

La cuarta es la que abre una conversación más fértil: si los agentes se convierten en intermediarios, la web tendrá que publicar algo más que páginas.

No porque el HTML deje de importar. Importará más, no menos. Pero quizá ya no baste con publicar una página y esperar a que un crawler reconstruya desde fuera qué ha pasado, qué relación tiene con otras piezas y qué debería hacer con ella.

El sitemap informa, pero no explica

Un sitemap responde muy bien a una pregunta concreta: estas URLs existen y algunas han cambiado.

Para Googlebot, eso es útil. Para eficiencia de rastreo, también. Para descubrir contenido nuevo o actualizado, tiene todo el sentido.

Pero un sitemap no dice si una página ha cambiado de entidad principal, si una URL antigua se ha deprecado, si una categoría se ha fusionado, si un contenido ha pasado de opinión a documentación, si se ha corregido un canonical, si se ha actualizado el schema, si el cambio afecta a una ficha de producto o si hay una nueva relación entre un tema, una autora, una herramienta y una intención.

Un sitemap informa de URLs. No explica decisiones.

Y los agentes no necesitan solo señales de existencia. Necesitan contexto operativo.

Por eso me interesa tanto la idea de una capa de cambios. No como nuevo sitemap, sino como otra superficie. Una memoria pública o semipública donde una web pueda decir qué creó, qué actualizó, qué retiró, qué sustituye a qué, qué relación nueva existe entre recursos y qué cambios ya han sido validados.

Visto así, el `log.md` no sería un diario decorativo. Sería una interfaz de cambios.

El SEO técnico se parece cada vez más a arquitectura

Esta transición obliga a sacar el SEO del rincón de “optimizar contenidos” y devolverlo a un lugar más serio: arquitectura de información, arquitectura de confianza y arquitectura de ejecución.

Si ARD propone una forma de publicar y verificar capacidades para agentes, si A2A permite que agentes distintos se coordinen, si MCP conecta agentes con herramientas y datos, y si OKF intenta representar conocimiento portable para humanos y agentes, la pregunta SEO ya no puede quedarse en qué página queremos posicionar.

También empieza a incluir el inventario semántico y operativo del sitio: recursos, capacidades, entidades, límites, cambios demostrables y pruebas. No como documentación interna para el equipo, sino como contexto que una máquina pueda leer sin inventarse la mitad.

Esto se parece menos al SEO entendido como forzar keywords y más al SEO entendido como diseño de un sistema observable.

Ahí hay una consecuencia profesional importante: el SEO del futuro no será menos técnico por culpa de la IA. Será más técnico porque la IA aumenta la necesidad de precisión.

Los modelos son buenos completando huecos. Ese es precisamente el problema. Si tú no publicas contexto claro, el sistema lo reconstruye como puede. Si no separas hechos de interpretación, los mezcla. Si no explicas qué cambió, deduce. Si no dejas relaciones explícitas, aproxima. Si no hay fuente canónica, se apoya en terceros.

La optimización no consiste en gritar más alto.

Consiste en reducir ambigüedad.

La pregunta no es si esto rankea

Cada vez que aparece una capa nueva, el sector pregunta demasiado rápido: ¿esto es factor de ranking?

La pregunta es legítima, pero a veces empobrece la conversación. Muchas cosas importantes no empiezan como factor de ranking. Empiezan como infraestructura.

Un buen enlazado interno no era valioso solo porque pasara autoridad. Era valioso porque ordena significado, prioriza rastreo, distribuye contexto y ayuda a las personas a navegar.

Un buen schema no era valioso solo por el rich result. Era valioso porque obliga a modelar entidades y propiedades con precisión.

Una buena arquitectura no era valiosa solo porque mejora rankings. Era valiosa porque hace mantenible un sitio complejo.

Con una capa de cambios pasa algo parecido.

Quizá Google no la use mañana. Quizá nunca la use como señal directa. Pero si tienes un sistema que registra cambios editoriales, técnicos y semánticos de forma estructurada, ya tienes algo útil para QA, documentación, monitorización, despliegues, agentes internos, generación de sitemaps, validación de schema, auditorías de contenido y análisis de impacto.

Para mí, eso ya justifica explorarlo.

No como receta. Como dirección.

Mi apuesta provisional

Yo no creo que el SEO desaparezca.

Tampoco creo que baste con decir “el SEO sigue siendo SEO” y cerrar la conversación.

Mi apuesta provisional es esta: el SEO seguirá teniendo una base clásica, pero su frontera se moverá hacia capas de contexto, cambios, entidades, capacidades y confianza.

Sitemap, HTML, contenido útil y autoridad seguirán importando.

Pero en una web más agéntica, quizá la ventaja no esté solo en tener mejores páginas. Quizá esté en tener una web que pueda explicarse a sí misma.

Qué soy. Qué sé. Qué ha cambiado. Qué puedes hacer conmigo. Qué no deberías hacer.

Ese es el punto que quería abrir con el post. No para decir “instala un `log.md` y ganarás el futuro”, sino para abrir una conversación con quienes estáis mirando este cambio desde dentro.

Me interesa saber cómo lo ves tú.

¿Lo ves como una evolución técnica del SEO de siempre? ¿Cómo una amenaza al tráfico? ¿Cómo una carrera por aparecer citado en respuestas generadas? ¿Cómo el inicio de una web más legible para agentes? ¿O como otra cosa distinta?

¿Qué teoría tienes ahora mismo sobre el futuro del SEO?

Recursos

• La web agent-to-agent: por qué el SEO necesita una capa de cambios

• Google Search Central: optimizar tu sitio web para las funciones de IA generativa en la Búsqueda de Google

• Google Developers Blog: Agentic Resource Discovery

• Google Cloud: Introducing the Open Knowledge Format

• OKF Specification en GitHub

• A2A Protocol Specification

• Towards an Agent-First Web: Redesigning the Web for AI Agents

Compartir

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

El otro día di una charla en MujeresEnSEO Barcelona sobre una pregunta que aparece cada vez más en SEO: cómo usar agentes de IA sin que el análisis se convierta en una caja negra elegante.

La pregunta suele formularse como "¿cómo evito que la IA alucine?", pero creo que así nos quedamos cortos. A veces el problema no es que el modelo alucine porque sí, sino que le damos un proceso donde puede inventar, saltarse pasos o mezclar datos sin que nada lo frene.

Si le pides a una IA "analiza mi contenido, encuentra oportunidades SEO y dime qué debería publicar", probablemente te devolverá algo bien escrito. Puede tener títulos, clusters, prioridades y una explicación convincente. El problema es que no siempre podrás saber qué parte viene de datos reales, qué parte viene de una inferencia razonable y qué parte es una apuesta presentada con mucha seguridad.

Por eso la tesis de la charla era esta:

No se trata de pedirle a la IA que sea más cuidadosa. Se trata de diseñar un proceso donde tenga que trabajar con datos, límites y pruebas.

Hoy quiero convertir esa charla en una explicación práctica. No como una demo cerrada, sino como un marco que puedes aplicar a tus propios procesos SEO.

Si quieres aprender a convertir la IA en sistemas útiles, suscríbete a Think&Hack.

Suscríbete ahora

El error habitual: pedir una estrategia entera en una sola conversación

La IA puede ayudar muchísimo en SEO, pero conviene tener claro dónde está el riesgo. El riesgo aparece cuando mezclamos en una sola petición tareas que son de naturaleza distinta.

Por ejemplo, en un análisis editorial hay tareas objetivas: extraer entidades de un corpus, limpiar columnas, contar apariciones, calcular cobertura, consultar demanda externa o cruzar dos tablas. Esas tareas no necesitan creatividad. Necesitan repetibilidad.

También hay tareas cualitativas: decidir si una entidad pertenece al territorio de una marca, detectar polisemia, interpretar intención de búsqueda, priorizar un backlog o decidir si un gap merece una pieza propia. Esas tareas sí necesitan criterio, contexto y una lectura editorial.

El error es pedirle al modelo que haga todo eso a la vez. Cuando lo haces, el resultado puede sonar coherente, pero pierdes trazabilidad. No sabes qué calculó, qué interpretó, qué asumió y qué inventó porque no tenía una fuente clara.

La primera regla del sistema es separar esas responsabilidades.

Lo objetivo debe ir a lógica determinista. Lo cualitativo puede ir a IA, pero como clasificador dentro de un marco, no como oráculo.

La regla práctica: scripts, skills y agentes

En la charla usé tres piezas para explicar esta separación: scripts, skills y agentes. No son palabras intercambiables. Cada una sirve para una cosa distinta.

Un script es código determinista. Sirve para tareas que deben salir igual cada vez: leer archivos, llamar a una API, limpiar datos, cruzar CSVs, validar columnas o detectar si una fase tiene evidencia. Si una operación no debería depender del humor del modelo, no se la pidas al modelo. Escríbela como script.

Una skill es método empaquetado. Sirve para que la IA sepa cómo hacer una tarea concreta sin que tengas que explicársela desde cero cada vez. Una skill puede decir: "cuando crees un proyecto nuevo, lee el corpus, infiere un brief inicial, crea esta estructura de carpetas y deja estos archivos". La skill no decide por ti; reduce variabilidad en el proceso.

Un agente aplica criterio en una fase delimitada. No debería recibir una tarea gigantesca como "hazme una estrategia SEO", porque ahí cabe cualquier cosa. Un agente útil recibe una responsabilidad concreta, por ejemplo: "lee estas entidades, lee este brief y decide cuáles pertenecen al territorio, cuáles son ruido y cuáles son marca".

La diferencia parece técnica, pero en realidad es muy práctica. Cuando algo falla, puedes saber dónde mirar. Si falla una columna, miras el script. Si falla el método, miras la skill. Si falla una decisión cualitativa, revisas el agente y su brief.

Sin esa separación, todo queda mezclado en una conversación. Y cuando todo vive en una conversación, todo puede sonar bien aunque el proceso esté mal.

Ejemplo SEO: detectar gaps de entidades

Para aterrizarlo, usé un caso real: Think&Hack como corpus editorial.

La pregunta era sencilla: con todo lo que ya he publicado, ¿puedo saber de qué habla realmente mi contenido y compararlo con lo que la gente busca alrededor de ese territorio?

El sistema analiza newsletters publicadas y busca gaps de entidades. Un gap, en este contexto, no es simplemente una keyword que tiene volumen. Es una entidad o tema con demanda externa que está cerca de tu territorio, pero que tu contenido cubre poco o nada.

La diferencia importa. Si solo miras keywords, puedes acabar persiguiendo volumen suelto. Si miras entidades, cobertura y territorio, puedes tomar decisiones editoriales más defendibles.

El flujo del sistema fue este:

1. Primero se ingiere el contenido publicado y se convierte en una tabla de posts.

2. Después, un script extrae entidades con Google Natural Language.

3. Otro paso limpia menciones irrelevantes y normaliza datos.

4. Un agente cura entidades leyendo el brief del proyecto.

5. Un script consulta Google Trends alrededor del territorio.

6. Otro script cruza demanda externa con cobertura interna.

7. Un agente convierte los gaps en backlog editorial.

8. Otro agente redacta un informe usando solo la evidencia generada.

Fíjate en el patrón: la IA no hace todo. La IA entra donde hace falta criterio. El código entra donde hace falta repetibilidad.

Qué hizo cada pieza en el caso real

En Think&Hack, el sistema analizó 37 newsletters publicadas. La extracción inicial encontró 10.068 menciones de entidades en bruto. Después de la limpieza objetiva quedaron 1.791 menciones y 839 entidades únicas.

Hasta aquí, la IA no tenía que opinar demasiado. Había que extraer, limpiar y ordenar datos. Esa parte es aburrida, pero sostiene todo lo demás.

Después entró el agente `entity-curator`. Su trabajo no era "hacer SEO", sino responder una pregunta concreta: de todas esas entidades, ¿cuáles pertenecen al territorio real de Think&Hack?

Ese agente trabajó contra un brief. El brief decía que Think&Hack habla de IA generativa aplicada a procesos, productividad, contenido, SEO/GEO, prompting, memoria, agentes y automatización. También definía anti-territorio: sentidos que parecen relevantes, pero no lo son.

Por ejemplo, "memoria" puede significar memoria de contexto en un LLM, pero también RAM, una canción o cualquier otro sentido que Google Trends arrastre. "Agentes" puede significar agentes de IA, pero también agentes inmobiliarios, forestales o de Hacienda. Sin anti-territorio, el sistema podría interpretar ruido como oportunidad.

Después de esa curación, quedaron 66 entidades dentro del territorio real. A partir de 17 semillas consultadas en Google Trends, el sistema detectó 354 gaps: 172 en crecimiento y 182 consolidados.

El resultado final no fue una lista de ideas generadas por IA, sino dos entregables conectados con evidencia: `editorial_backlo.csv` e `informe.md`.

El aprendizaje importante: un gap no es una orden de publicar.

Este punto es clave. Un gap no es automáticamente una buena idea de contenido.

Puede haber demanda y aun así no convenirte. Puede ser una búsqueda demasiado genérica, una polisemia, una intención que no encaja con tu audiencia o una entidad donde no tienes autoridad suficiente. Publicar sobre todo lo que tiene volumen no es estrategia; muchas veces es dispersión.

Por eso el agente `gap-strategist` no recibía la orden de "escribe sobre todos los gaps". Recibía algo más concreto: leer `gaps.csv`, leer las entidades ya cubiertas, leer el brief y convertir solo lo relevante en backlog editorial.

En el caso de Think&Hack, la oportunidad más clara fue Claude Code. No salió de una intuición, sino de cruzar cobertura interna con demanda externa. El corpus ya mencionaba Claude Code en 4 posts, así que había una base real de autoridad, pero alrededor aparecía demanda no cubierta: `what is claude code`, `claude code agents`, `claude code mcp`, `claude code documentation`, `claude code pricing` y `codex vs claude code`.

Eso ya no es "la IA me ha dado ideas". Es una lectura editorial basada en señales: hay entidad, hay cobertura previa, hay demanda externa y hay un cluster posible.

La recomendación no fue publicar una pieza suelta sobre IA, sino construir una arquitectura: una guía práctica para no desarrolladores, una pieza sobre agents, otra sobre memoria de contexto, una comparativa con Codex, una guía sobre MCP y una pieza sobre precios. Esa diferencia es la que separa una lista de ocurrencias de una estrategia editorial.

El arnés: cómo evitar que la IA cierre en falso

La parte más importante del sistema no es la extracción de entidades ni el backlog. La parte más importante es el arnés de verificación.

El arnés aplica una regla de Default-FAIL: una fase no está hecha porque la IA diga que está hecha. Está hecha si existe la evidencia en disco, con las columnas correctas, con contenido y sin fases anteriores saltadas.

Esto parece un detalle técnico, pero cambia completamente el incentivo. Si el criterio de éxito es "dime que has terminado", el modelo puede responder que ha terminado. Si el criterio de éxito es "existe este CSV con estas columnas exactas y `bin/check.py` pasa", la conversación cambia.

En el repo, una fase marcada como completada solo se acepta si su archivo existe y respeta el contrato. Si el estado dice que la fase está hecha pero falta el CSV, el check falla. Si las columnas no coinciden, el check falla. Si una fase posterior está marcada como hecha sin que una anterior tenga evidencia, el check falla.

Esta es la frase que resume la idea:

No escribas más reglas. Haz que el atajo no compile.

Los modelos optimizan hacia el criterio de éxito que les damos. Si el atajo puntúa igual que el camino correcto, tenderán a elegir el atajo. No por maldad, sino porque el sistema se lo permite. El arnés hace que el atajo deje de ser rentable.

Cómo aplicar este marco a tu propio proceso SEO

Si quieres llevar esta idea a tu trabajo, no necesitas empezar construyendo un repo entero. Puedes empezar con una auditoría muy simple de tus flujos actuales.

Primero, separa las tareas objetivas de las tareas cualitativas. Si una tarea consiste en contar, cruzar, validar, limpiar o consultar datos, probablemente debería vivir en un script, una hoja bien estructurada o una automatización determinista. No hace falta gastar criterio de IA en algo que debe ser reproducible.

Después, identifica dónde sí necesitas criterio. Ahí la IA puede aportar mucho, pero conviene darle un rol estrecho. En vez de pedirle "haz una estrategia", pídele que clasifique entidades contra un brief, que detecte polisemia, que agrupe gaps por intención o que priorice oportunidades con una justificación explícita.

Luego, escribe el brief. Este paso suele parecer secundario, pero es lo que evita que la IA decida en abstracto. Un buen brief define el tema, la audiencia, las entidades núcleo, el tono, los límites y el anti-territorio. Sin brief, la IA interpreta "oportunidad" como algo genérico; con brief, puede evaluar si esa oportunidad tiene sentido para ti.

Por último, define qué evidencia debe quedar. Antes de lanzar el proceso, decide qué archivo, tabla, resumen o validación demostrará que la fase está hecha. No esperes al final para preguntar si te fías. Diseña desde el principio cómo vas a comprobarlo.

La diferencia entre usar IA y construir un sistema

Sin IA, este proceso también se podría hacer. Podrías exportar contenido, revisar entidades, mirar Trends y priorizar un backlog manualmente, pero sería lento, irregular y difícil de repetir.

Con IA, aceleras las partes cualitativas: curar entidades, detectar polisemia, interpretar territorio, agrupar gaps y convertir oportunidades en decisiones editoriales. Pero eso solo funciona bien cuando la IA no está sola. Necesita datos, contratos, contexto y checks.

Ese es el cambio que me interesa. La IA no sustituye el sistema; se vuelve útil cuando el sistema la contiene.

Por eso creo que la conversación importante en SEO e IA no es "mira lo que me ha generado", sino "mira cómo sé que puedo fiarme de esto". El salto real no es pasar de no usar IA a usar IA. El salto real es pasar de prompt -> respuesta a proceso -> evidencia -> decisión.

En el primer modelo, la confianza depende de la fluidez del texto. En el segundo, depende del rastro que deja el proceso. Y en SEO eso importa mucho, porque el coste de una mala decisión editorial no siempre se ve al momento. Puedes publicar 30 piezas antes de darte cuenta de que estabas persiguiendo ruido.

La IA puede acelerar muchísimo ese error o puede ayudarte a verlo antes. La diferencia no está en el prompt; está en el sistema.

Tools are great. Systems are better.

Las herramientas están muy bien, pero las herramientas sueltas no crean criterio. Puedes tener el mejor modelo, el mejor scraper, el mejor dashboard y el mejor generador de contenidos, y aun así no tener un sistema de decisión.

Un sistema define qué entra, qué se transforma, quién decide, qué evidencia queda y qué pasa si algo falla. Para mí, esa es la madurez que toca ahora con IA aplicada a SEO: no delegar a ciegas, no pedir estrategias completas a una caja negra y no confundir velocidad con mejora.

No lo presento como una herramienta cerrada ni como "el método definitivo", sino como una forma de pensar. Cada equipo tendrá sus fuentes, sus límites, su autoridad y sus datos, pero la arquitectura mental sí es reutilizable: scripts para lo objetivo, skills para el método, agentes para el criterio y evidencia para confiar.

Si al leer esto has pensado "esto es justo lo que me falta cuando intento usar IA para SEO", probablemente conoces a alguien que también debería leerlo.

Compartir

Recursos:

Suscríbete a Think&Hack

Tools are great. Systems are better.

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Esta semana di una ponencia de 20 minutos sobre algo que me lleva obsesionando bastante tiempo: qué pasa cuando dejamos de usar la IA como una conversación y empezamos a rodearla de un sistema.

No hablé de prompts mágicos.

No hablé de una herramienta nueva que lo hace todo.

Hablé de una cosa mucho menos vistosa, pero mucho más importante si quieres trabajar con agentes de verdad: cómo diseñar un arnés alrededor de la IA para que pueda operar, fallar, revisar y cerrar bien.

La charla se titulaba: Cómo convertí mi inbox en un sistema verificable de agentes.

Y la tesis era esta:

No rehice carpetas. Cambié el contrato de trabajo con la IA.

Antes tenía un sistema potente: inbox, proyectos, memoria, comandos, agentes, hooks, skills y automatización. Funcionaba. Me ayudaba a convertir entradas sueltas en trabajo organizado.

Pero había un problema de fondo.

El sistema dependía demasiado de que el modelo recordara qué estaba haciendo, qué faltaba, qué criterio tenía que cumplir y cuándo podía decir “he terminado”.

Y ahí aparece una de las frases centrales de la charla:

Un agente no termina cuando responde. Termina cuando verifica.

Si quieres aprender a convertir la IA en sistemas útiles, suscríbete a Think&Hack.

Suscríbete ahora

El problema: confundimos respuesta con cierre.

Cuando trabajas con IA en tareas pequeñas, una respuesta puede parecer suficiente.

Le pides que resuma algo, que reescriba un texto, que proponga una estructura o que te ayude a pensar una idea. La conversación empieza, la conversación termina y tú decides si te sirve.

Pero cuando empiezas a usar agentes para operar sobre sistemas reales, esa lógica se rompe.

Un agente puede tocar archivos, mover documentos, actualizar estados, clasificar una bandeja de entrada, crear proyectos, lanzar comandos, dejar trazas en una memoria y coordinar subagentes.

Y entonces la pregunta ya no es: “¿Me ha dado una buena respuesta?”.

La pregunta es otra:

¿El sistema puede demostrar que la tarea está hecha?

Ese matiz lo cambia todo.

Porque el agente puede sonar seguro y estar equivocado. Puede decir que ha actualizado un README y haber olvidado una parte. Puede procesar una entrada y dejar un adjunto huérfano. Puede cambiar el estado de un proyecto y no dejar log. Puede cerrar una tarea porque su resumen parece coherente, no porque haya verificado la evidencia.

No le faltaban piezas. Tenía muchas.

Tenía comandos para procesar inbox, crear proyectos, refrescar estado, hacer lint del sistema y mantener memoria.

Tenía subagentes para clasificar entradas, actualizar proyectos, refrescar estado y mantener la wiki.

Tenía hooks para enganchar comportamiento al arranque, validar el sistema y evitar cierres falsos.

Era potente.

Pero no formaba un ciclo cerrado de trabajo.

La solución: default-FAIL

La nueva versión parte de una regla muy sencilla:

Por defecto, nada está hecho.

No porque desconfiemos de la IA de forma abstracta. Sino porque, si el sistema puede cambiar cosas importantes, el cierre no puede depender del tono de seguridad del modelo.

La unidad de trabajo entra en una cola; el líder la lee, los workers ejecutan, el revisor contrasta, el check valida y solo entonces se puede marcar como hecho.

Ahí aparece el arnés.

No como una metáfora bonita, sino como una arquitectura concreta:

`_cola/` para convertir peticiones en unidades verificables.
`_progress/` para sacar memoria operativa del contexto.
`_projects/` para mantener el dominio.
`_memory/` para dejar aprendizaje y trazabilidad.
`bin/check.ps1` para validar invariantes.
agentes `.md` para definir roles.
playbooks para describir procesos.
revisor para juzgar evidencia.

La cola cambia todo.

Uno de los cambios más importantes fue convertir las peticiones en unidades de trabajo explícitas.

El problema es que una frase deja demasiado espacio a la interpretación. Y cuando una sesión se alarga, se compacta, se interrumpe o cambia de agente, esa interpretación empieza a degradarse.

Ahora una unidad vive en `_cola/trabajo.json`.

Tiene un `id`, un tipo, un título, criterios, estado y, sobre todo, una definición externa a la conversación.

Por ejemplo, una unidad no se cierra porque el agente diga “he terminado”.

Se cierra si se cumplen criterios como:

• el README se ha actualizado;

• el log ha recibido una entrada append-only;

• `STATUS.md` queda coherente si cambia el estado;

• `bin/check` sale en verde;

• el revisor devuelve `PASS`.

Esto parece más complejo.

Lo es.

Si la sesión se corta, la cola sigue ahí. Si el contexto se compacta, `_progress/` sigue ahí. Si otro agente retoma la tarea, los criterios siguen ahí.

Una unidad pendiente sigue pendiente aunque el agente anterior se sintiera terminado.

Sacar la memoria del modelo

Hay una idea que atraviesa toda la charla:

Memoria útil no es más contexto. Es estado legible y verificable.

Durante mucho tiempo hemos tratado la ventana de contexto como si fuera el lugar natural donde debía vivir el trabajo.

Añades más instrucciones, más historial, más ejemplos, más documentos y más conversación.

Y durante un rato funciona.

Hasta que deja de funcionar.

El contexto se vuelve pesado. El agente empieza a mezclar pasos. Recuerda unas cosas y pierde otras. Arrastra decisiones antiguas. Resume demasiado. O peor: mantiene una sensación de continuidad que ya no está respaldada por el estado real del sistema.

Por eso en el arnés la memoria operativa sale del modelo.

El sistema puede continuar sin exigir que el modelo cargue todo en la cabeza.

Esto no elimina el contexto.

Lo vuelve más limpio.

El agente usa la conversación para coordinar y razonar, no para sostener todo el estado del mundo.

El arnés, en ese sentido, es un patrón de navegación.

Le dice al agente dónde mirar, qué dejar escrito, qué comprobar y cuándo no puede cerrar.

El revisor no evalúa intenciones.

La pieza más importante no es el líder ni son los workers. Es el revisor.

Porque el revisor cambia la pregunta.

El protocolo del revisor es muy concreto:

1. Lee los criterios de aceptación.

2. Lee `_rogress/<run-id>/`.

3. Contrasta con el `git diff`.

4. Verifica las escrituras esperadas.

5. Ejecuta `bin/check`.

6. Devuelve `PASS` o `NEEDS_WORK`.

Esa última parte importa.

Ante la duda, `NEEDS_WORK`.

No porque queramos ponerle trabas al agente, sino porque la autonomía sin revisión produce deuda.

Y esa forma no puede depender de una intuición. Tiene que depender de criterios.

El arquitecto cambia el sistema

La otra pieza que enseñé en la ponencia es el arquitecto.

Si el líder opera el sistema y el revisor valida el trabajo, el arquitecto cambia el propio arnés. Es el agente que entra cuando no quieres procesar una unidad más, sino extender el sistema: añadir una regla, crear un comando, modificar una skill, documentar una convención o sumar una nueva comprobación.

Esto también cambia el tipo de confianza que puedes tener en el sistema.

Porque una mejora no se queda solo como “a partir de ahora acuérdate de esto”. Si aparece una regla nueva, el arquitecto la documenta y añade la forma de verificarla en `bin/check`.

El sistema no mejora porque el modelo prometa portarse mejor la próxima vez.

Mejora porque una parte del arnés cambia.

El repo que enseñé en el QR

Al final de la ponencia puse un QR al repo porque no quería que esto quedara como una idea abstracta.

Es un sistema de gestión de proyectos en Claude Code, hecho con Markdown, memoria persistente, agentes, cola de trabajo y checks. La gracia está en comparar la V1 con la V3: el dominio es parecido, pero la V3 añade el arnés que convierte una petición en una unidad trazable y revisable.

Ahí se ve mucho mejor el cambio: no es pedirle a la IA que “sea más cuidadosa”, sino construir un entorno donde no pueda cerrar sin evidencia.

Para mí, esa es la parte importante: la respuesta ya no es el final del trabajo. El final del trabajo es la evidencia.

En la ponencia cerré con una frase que resume muy bien el punto:

Que la IA gestione sistemas no la convierte en responsable. La responsabilidad sigue siendo tuya.

Por eso me interesa tanto esta forma de trabajar. No quita responsabilidad: la vuelve más visible.

Un agente no termina cuando responde. Termina cuando verifica.

Si al leer esto has pensado “esto es justo lo que me pasa cuando intento usar agentes para trabajo real”, probablemente conoces a alguien que también debería leerlo.

Compartir

Recursos:

Suscríbete a Think&Hack

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Imagínate que tienes una acción que repites cada semana. Entras en Google Search Console para retirar una URL, abres Substack para publicar una nota, revisas LinkedIn para guardar posts del feed o entras en una web de reporting porque necesitas descargar un reporte concreto, pero para llegar hasta él tienes que hacer siempre los mismos cuatro clics.

Ninguna de esas tareas es especialmente difícil. Lo pesado es repetirlas. Y lo más absurdo empieza cuando se las pides a un agente: el agente abre la web, mira la página, interpreta botones, espera modales, vuelve a mirar, decide el siguiente paso y actúa como si nunca hubiera visto ese flujo antes.

A mí eso me empezó a molestar por una razón muy concreta. Si yo ya sé qué quiero hacer, si la web ya permite hacerlo y si el navegador ya tiene sesión, cookies, DOM, formularios y llamadas internas, ¿por qué la automatización sigue viviendo como una conversación improvisada?

Esta semana he creado una skill para resolver justo eso: browser-console-automation. La idea no es que la IA haga clic más rápido. La idea es convertir cualquier flujo repetible de navegador en un script guardado que puedas ejecutar otra vez.

Si puedes hacerlo dentro del navegador, probablemente puedes enseñarle al agente a repetirlo sin que vuelva a preguntarse cada vez dónde tiene que hacer clic.

El problema: el agente vuelve a empezar cada vez.

Cuando le dices a un agente que navegue por una web, lo normal es pedirle que actúe como actuarías tú. Que mire la página, encuentre el botón, haga clic, espere a que cargue, vuelva a mirar y siga con el siguiente paso.

Para una prueba rápida funciona. El problema aparece cuando esa acción no es una prueba, sino algo que repites cada semana. Ahí el agente vuelve a hacer lo mismo que tú: redescubrir el camino.

No recuerda que primero hay que abrir el filtro, después cambiar la fecha, luego pulsar exportar y finalmente confirmar. O lo recuerda solo dentro de esa conversación, que en la práctica es casi lo mismo que no recordarlo.

La web no ha cambiado. La tarea no ha cambiado. Pero el agente vuelve a gastar contexto, tiempo y criterio en entenderla desde cero.

Ese es el problema que quería resolver.

La solución: sacar el flujo de la conversación.

La idea de la skill es que, cuando un flujo ya está claro, deje de vivir como instrucciones sueltas en un prompt y pase a vivir como una colección reutilizable.

El navegador no es solo una pantalla. También es un entorno donde puedes ejecutar JavaScript, leer el DOM, disparar eventos, rellenar formularios, aprovechar las cookies de sesión y detectar las llamadas internas que la propia web hace cuando pulsas un botón.

Mi skill aprovecha justo eso: en lugar de hacer que el agente navegue clic a clic, ejecuta un único script dentro de la página con browser_evaluate de Playwright MCP. El script hace el trabajo y el agente recibe el resultado.

Misma web. Pero ya no estás automatizando una coreografía: estás ejecutando un procedimiento.

El salto: de conversación a sistema

Vamos con un ejemplo complejo, porque una tarea simple no enseña bien lo que hace esta skill. Retirar una URL, bajar una tabla o publicar una nota ya son casos interesantes, pero siguen siendo acciones aisladas. Yo quería probar algo más parecido a mi trabajo real: un flujo completo de research para decidir qué merece entrar en Think&Hack esta semana.

La prueba fue esta: construir un radar de ideas para newsletter cruzando tres fuentes distintas — LinkedIn, Product Hunt y Hacker News — y devolver no solo datos, sino señales editoriales. Es decir: qué temas se están moviendo, por qué importan para mi audiencia y qué ángulo podría convertirlos en una newsletter.

No quería un scraping suelto. Quería ver si la skill podía convertir varias webs en un sistema repetible.

1. Primero instalé la skill en un repo nuevo.

El primer paso fue preparar un proyecto limpio y pedirle a Claude Code que instalara la skill ahí, para no mezclar el experimento con mi sistema editorial principal.

2. Después le pedí el radar completo.

Una vez instalado, no le pedí “extrae posts” ni “rasca Product Hunt”. Le pedí el resultado que yo necesitaba de verdad.

3. El proceso de construcción.

Aquí empieza lo interesante: la skill no intenta resolverlo todo como una conversación improvisada. Divide el problema en fuentes, crea una colección para cada una y deja escrito cómo volver a ejecutarla.

La primera pasada tarda más porque está construyendo el sistema: entiende cada web, decide si conviene leer el DOM o usar una llamada interna, escribe el scrape.js, crea el meta.md y guarda la colección. En mi prueba completa, con Opus en esfuerzo alto, tres fuentes, calibración y el informe final, la sesión costó 5,36 dólares. Pero esa inversión solo ocurre una vez. La siguiente ejecución ya no empieza desde cero.

La parte más visual fue LinkedIn. Al abrir el feed, Playwright no tenía sesión iniciada, así que hice login manualmente en el navegador controlado por la skill. No le di credenciales al agente. Simplemente entré yo, como entraría cualquier día.

Desde ahí, la skill pudo trabajar con mi sesión abierta y guardar las cookies en el perfil persistente para futuras ejecuciones.

4. El resultado

El resultado no fue “un scraper”. Fue un radar editorial. Increíble. ¡Se queda corto!

Tal como ves en la imagen, quedaron tres archivos CSV auditables y un informe final en Markdown:

• Hacker News: 100 historias de los últimos 7 días.

• Product Hunt: 68 lanzamientos del leaderboard semanal.

• LinkedIn: 23 posts de mi feed personal.

Después cruzó esas tres fuentes y generó seis señales editoriales para Think&Hack, cada una con contexto, fuerza de señal y posible ángulo de newsletter. La más fuerte fue GEO: en la misma semana aparecían señales en LinkedIn, herramientas comerciales y discusión técnica. La segunda fue memoria y contexto para agentes: Product Hunt estaba lleno de productos vendiendo justo esa capa.

Y aquí está la parte importante: no solo me dio un informe. Me dejó tres colecciones reutilizables.

La próxima vez no tengo que volver a decirle cómo mirar Hacker News, cómo leer Product Hunt o cómo recorrer mi feed de LinkedIn. Puedo ejecutar esas colecciones, volver a cruzar las señales y generar otro radar. La primera vez construyes el sistema. La segunda vez lo usas.

Eso es lo que convierte esta skill en algo distinto a “hacer scraping”.

5. Comparación de costes

La captura no enseña una demo bonita. Enseña el coste real de convertir una idea en un sistema reutilizable.

Casos de usos

El radar de ideas es solo un ejemplo.

Lo importante no es LinkedIn, Product Hunt o Hacker News. Lo importante es el patrón: una web abierta, una sesión ya iniciada, una tarea repetible y un script que queda guardado para la próxima vez.

Ahí es donde esta skill empieza a ser útil.

1. Un radar semanal sobre cualquier fuente cerrada

Puedes convertir una web que revisas a mano en una fuente estructurada.

No hace falta que tenga API. No hace falta que tenga exportador. Si el contenido está en el navegador, la skill puede recorrerlo, extraerlo y devolverlo como CSV.

Por ejemplo: posts de LinkedIn, lanzamientos de Product Hunt, hilos de comunidades privadas, resultados de un portal, fichas de un marketplace o elementos de un dashboard interno.

La primera vez construyes la colección.
La segunda vez la ejecutas.

2. Un inventario vivo de lo que cambia en una web

Hay webs que no quieres leer una vez. Quieres vigilarlas.

La skill puede extraer la misma pantalla cada semana y comparar contra la ejecución anterior: qué apareció, qué desapareció, qué cambió de estado, qué sigue igual y qué merece atención.

Esto sirve para URLs en Search Console, contenidos en un CMS, productos en un ecommerce, incidencias en un panel, leads en un CRM o publicaciones en una comunidad.

No estás haciendo scraping por curiosidad.
Estás convirtiendo una interfaz en un sistema de seguimiento.

3. Una acción repetible que deja de vivir en tu cabeza

Hay flujos que no quieres delegar a ciegas, pero tampoco quieres repetir siempre.

Retirar una URL. Publicar una nota. Cambiar un estado. Aprobar un elemento. Rellenar una solicitud. Lanzar una exportación. Confirmar una operación.

La skill puede guardar ese flujo como una colección accionable: abre la pantalla, ejecuta el procedimiento, verifica el resultado y pide confirmación si la acción tiene impacto.

No es una macro que improvisa clics.
Es un procedimiento guardado.

4. Un pseudo-API para herramientas que nunca pensaron en agentes

Este es el caso más importante.

Muchas herramientas que usamos cada día son cajas cerradas: tienen datos, botones, tablas, filtros, formularios y estados, pero no están pensadas para conectarse con un agente.

Esta skill abre una vía intermedia.

No necesitas esperar a que exista una API.
No necesitas copiar y pegar.
No necesitas que el agente redescubra la web cada vez.

Si puedes verlo en el navegador, puedes intentar estructurarlo.
Si puedes repetirlo, puedes guardarlo como colección.
Si puedes guardarlo como colección, esa web empieza a comportarse como una herramienta invocable por IA.

La primera ejecución construye el procedimiento.

La segunda ejecución ya no es conversación.

Es sistema.

Con YouTube convertí una API pública en un agente de research. Con mi Growth Editor convertí métricas de newsletters en lecciones que el sistema carga antes de escribir. Con esta skill, convierto webs normales en procedimientos reutilizables.

La idea de fondo es la misma: dejar de pedirle a la IA que improvise y empezar a darle piezas que pueda ejecutar.

Te dejo las dos fechas clave para esta semana:

• Martes 9, online y gratis, CONIA Online. El sistema entero, por dentro.

• Sábado 13, presencial, Barcelona. El método SEO y diez voces más en una sala.

Puedes venir a una.
Puedes venir a las dos.

Y si vienes a Barcelona, me encantará ponernos cara, hablar después de la charla y tomarnos ese café.

¿Te veo en CONIA, en Barcelona o en los dos?

Suscríbete a Think&Hack

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Esta semana te cuento por qué algunas de tus mejores conversaciones con la IA se tuercen a mitad de camino y qué puedes hacer para recuperar el control del contexto.

Si te interesa entender no solo qué hace la IA, sino cómo trabajar mejor con ella, suscríbete a Think&Hack y empieza a sacarle más partido desde hoy.

Suscríbete ahora

No todos los fallos de contexto son iguales.

Un caso es cuando empiezas con una tarea incompleta y vas añadiendo requisitos. Ahí el modelo puede precipitarse, asumir demasiado pronto qué quieres y luego parchear la respuesta sobre una primera solución equivocada. Ese fenómeno está descrito en investigaciones sobre conversaciones multivuelta: los modelos rinden peor cuando la tarea se revela poco a poco que cuando se entrega completa desde el inicio.

Empiezas explorando una idea. La primera respuesta te sirve para pensar. Aprendes algo, descartas la dirección inicial y abres otra rama. Para ti, la conversación ha cambiado de nivel. Para el modelo, muchas veces no. El modelo interpreta tu nuevo mensaje como una continuación de la trayectoria anterior, no como una reescritura de la intención.

Esta idea aparece muy bien explicada en un paper reciente sobre conversaciones multivuelta y desajuste de intención (intent mismatch). La tesis es sencilla: muchas veces el problema no es que el modelo ignore lo que dices, sino que coloca tu nueva instrucción en el sitio equivocado. La interpreta como una continuación de su respuesta anterior, no como una actualización de tu intención original.

Por eso corregir dentro del mismo hilo puede fallar: la corrección no llega a una página en blanco, llega a una conversación que ya arrastra una interpretación previa.

4 formas de recuperar el control del contexto

Antes de seguir corrigiendo al modelo, hazte una pregunta: ¿El problema está en la respuesta o en el contexto desde el que está respondiendo?

Si el contexto ya arrastra una interpretación vieja, añadir más instrucciones al final puede no arreglar nada. No necesitas insistir más: necesitas cambiar el punto desde el que el modelo está pensando.

1. Editar el mensaje anterior.

Esta técnica consiste en modificar un mensaje previo, normalmente con el lápiz de edición, para que el modelo responda desde esa versión corregida.

Cuándo usarlo: cuando sabes dónde nació el malentendido: una instrucción ambigua, una hipótesis mal formulada o una petición incompleta.

Por qué funciona: en vez de añadir una corrección al final del hilo, cambias el punto de origen del contexto. No le dices al modelo “corrige lo que entendiste mal”; haces que vuelva a partir de una instrucción mejor.

2. Crear una nueva rama

En ChatGPT, esta opción aparece como “Hilo nuevo desde este chat”: crea una conversación nueva desde un punto concreto sin borrar la original.

Cuándo usarlo: cuando quieres explorar otra dirección sin perder la conversación original.

Por qué funciona: separa caminos. Si una idea nueva no debería mezclarse con la trayectoria anterior, la conviertes en una rama independiente. Así evitas que el modelo intente reconciliar hipótesis incompatibles dentro del mismo hilo.

3. Usar /rewind en Claude Code

Si usas Claude Code, /rewind sirve para volver a un punto anterior de la conversación y eliminar los turnos posteriores al desvío.

Cuándo usarlo: cuando Claude Code ha tomado un mal camino hace pocos turnos y quieres continuar desde antes del error.

Por qué funciona: no intentas corregir encima de la trayectoria equivocada. La borras del contexto y sigues desde el último punto sano.

4. Reiniciar en un chat nuevo.

A veces la mejor solución no es seguir afinando el hilo, sino cerrarlo. Toma distancia y empieza una conversación desde cero, sin arrastrar todo el historial anterior.

Cuándo usarlo: cuando el objetivo ha cambiado demasiado o la conversación ya está contaminada por pruebas fallidas, correcciones, contradicciones o ruido.

Por qué funciona: corta el arrastre contextual. Pero no conviene copiar todo el historial: lo útil es llevar solo un resumen limpio con el objetivo actual, las restricciones importantes, las decisiones válidas y lo que ya no quieres que el modelo asuma.

La próxima vez que una conversación con la IA empiece brillante y se tuerza a mitad de camino, no asumas automáticamente que el modelo “se ha vuelto tonto”.

Puede que simplemente esté atrapado en una interpretación vieja.

Y cuando eso pasa, insistir más no siempre ayuda. A veces solo añade otra capa de ruido sobre un contexto que ya iba torcido.

La habilidad no está solo en escribir mejores prompts. Está en saber cuándo continuar, cuándo editar, cuándo abrir una rama y cuándo empezar de cero.

Porque trabajar bien con IA no consiste en tener una conversación infinita.

Consiste en conservar vivo solo el contexto que todavía sirve.

Ahora te pregunto: cuando una conversación con la IA se tuerce, ¿qué haces: insistes en el mismo hilo, editas el punto de partida, abres una rama o empiezas de cero?

Suscríbete a Think&Hack

Casos reales, flujos que funcionan y formas concretas de usar la IA sin perder el control del proceso.

Suscríbete ahora

• El martes 9, online y gratis, en CONIA Online.

• El sábado 13, presencial en Barcelona, en el primer Summit de Mujeres en SEO.

En los dos eventos voy a enseñar sistemas que uso: cómo organizo agentes para gestionar proyectos y cómo aplico agentes de IA al SEO sin depender de datos inventados.

Suscríbete ahora

1. CONIA Online - martes 9 de junio

El primer evento es CONIA Online, el martes 9 de junio, de 15:30 a 20:00 CEST.

La charla se llama:

“Cómo seis agentes y un inbox gestionan todos mis proyectos de IA”.

Aquí voy a abrir mi sistema actual por dentro.

Porque si llevas meses usando ChatGPT, Claude u otras herramientas de IA para trabajar, seguramente ya has notado el límite: meterlo todo en un único asistente cada vez más grande acaba volviéndolo lento, caro y difícil de mantener.

Mi enfoque es otro.

En vez de un asistente gigante, trabajo con seis agentes especializados, cada uno con una tarea concreta, y un inbox central que decide quién hace qué.

Esta charla es para ti si lideras marketing, contenidos, una agencia o proyectos donde la IA ya no es una prueba puntual, sino parte del trabajo diario.

Voy a hablar de cómo pasar de prompts sueltos a herramientas internas reales.

Además, me hace especial ilusión participar porque el evento lo organiza IKAUE, que está haciendo una labor muy potente para difundir casos de uso reales con IA, no teoría abstracta ni demos imposibles. Tienen una serie de contenidos en YouTube precisamente sobre eso: aplicaciones reales, explicadas por profesionales que ya están usando IA en su trabajo.

👉 Puedes verla aquí: https://www.youtube.com/playlist?list=PLIgfqMCUEnDQzspsuxMBhfcDTDTJVBP9s

También compartiré cartel con profesionales como: Alfonso Moure, Ubaldo Hervás, Lorena Flores , Valentin Ayesa , Eva Rodenas y Carlos Hellín García.

CONIA Online es gratuito con registro previo.

Compartir

2. Mujeres en SEO Summit, Barcelona, sábado 13 de junio

El segundo evento es muy especial por otro motivo: es el primer Summit presencial de Mujeres en SEO.

Será el sábado 13 de junio, en Barcelona, y para mí tiene una parte que no cabe en una ponencia online: ponernos cara.

Porque una cosa es leernos, seguirnos, comentarnos o coincidir en LinkedIn.
Y otra muy distinta es sentarnos en la misma sala, hablar después de una charla, compartir dudas reales y tomar un café sin una pantalla de por medio.

Mi ponencia se llama:

“Cómo usar Agentes de IA para tareas SEO sin alucinar”.

Aquí voy a aterrizar un caso muy concreto: ¿qué pasa cuando usamos agentes de IA para SEO y queremos que trabajen con datos reales, no con respuestas aparentemente sólidas que se caen cuando necesitas trazabilidad?

Pero este evento no va solo de mi charla.

Va de celebrar que una comunidad como Mujeres en SEO tenga su primer encuentro presencial de este tipo. Va de aprender de otras profesionales, escuchar casos de uso reales, compartir experiencias y salir con ideas que no vienen de una demo perfecta, sino del trabajo de gente que está dentro del barro.

Compartiré cartel con: Aleyda Solís, Ciara Serrano Temprado, Clara Soteras Acosta, Estela Franco, Eva Olivares Busquets, Jade Johnson Virgili, Jo Juliana Turnbull, MJ Cachón Yáñez, Natalia Witczyk y Valen Correa.

Y aunque lo organiza Mujeres en SEO, el evento está abierto a todos los géneros.

Si vienes, me encantará conocerte después de la ponencia. Podemos hablar de agentes, de SEO, de IA aplicada a tu caso o simplemente tomarnos un café y ponernos cara.

Barcelona. Sábado 13 de junio. Entrada: 17€. Plazas limitadas.

Compartir

Te dejo las dos fechas:

• Martes 9, online y gratis, CONIA Online. El sistema entero, por dentro.

• Sábado 13, presencial, Barcelona. El método SEO y diez voces más en una sala.

Puedes venir a una.
Puedes venir a las dos.

Y si vienes a Barcelona, me encantará ponernos cara, hablar después de la charla y tomarnos ese café.

¿Te veo en CONIA, en Barcelona o en los dos?

Suscríbete a Think&Hack

Casos reales, flujos que funcionan y lo que cambia de verdad cuando incorporas la IA a tu trabajo diario.

Suscríbete ahora

El otro día Jon Hernández publicó dos horas de entrevista con Yoshua Bengio, uno de los padres del deep learning. Cuenta por qué cree que la IA agéntica abre la caja de Pandora y por qué las salvaguardas actuales no aguantan. Si te dedicas a esto, tienes que escucharla.

Si Bengio hubiera publicado esto como ensayo, lo subrayarías, marcarías las dos o tres ideas que quieres recordar, y volverías a ellas cuando las necesitaras. Pero está en vídeo, y el vídeo no se subraya. Lo escuchas, te impacta, y se va.

¿Cómo estás? Soy Aina y esto es Think&Hack.

Hoy te enseño una herramienta gratuita que convierte cualquier vídeo en texto que puedes buscar, subrayar y anotar, para que cuando te sientes a verlo lo aproveches de verdad. No para que la IA te lo resuma y te ahorre verlo: esa parte sigue siendo tuya.

Suscríbete ahora

Cómo instalarlo (3 minutos)

1. Instala Obsidian si no lo tienes: obsidian.md, gratis, Windows, Mac, Linux. Crea un vault (una carpeta donde guardarás tus notas).

2. Instala Web Clipper: ve a obsidian.md/clipper y añádelo a Chrome, Firefox, Edge o Safari.

3. Conecta con tu vault: Abre la extensión, selecciona tu vault y la carpeta donde quieres que caigan los clips.

¿Cómo funciona con un vídeo?

Abre cualquier vídeo de YouTube. Haz clic en el icono de Clipper en tu barra de extensiones.

Te muestra una vista previa de lo que va a guardar. Le das a "Add to Obsidian".

Y esto aparece en tu vault:

Un archivo de texto con:

• Metadatos: título, URL, autor, fecha

• Descripción completa con todos los enlaces y recursos que el creador puso.

• Timestamps como índice navegable

• La transcripción íntegra, organizada por secciones

Esto es un trozo real. Un podcast de dos horas con Yoshua Bengio, capturado con Clipper:

⏱ Timestamps:
00:03:05 ¿Qué es la IA según uno de sus creadores?
00:05:56 "La inteligencia da poder"
00:09:20 ¿Cuándo nos superará la IA?
00:13:33 La llegada de la IA agéntica
...

## Transcript

### ¿Qué es la IA según uno de sus creadores?

**3:10** · Es el principal obstáculo para que tomemos 
colectivamente las decisiones correctas sobre nuestro futuro.

**4:44** · Pero entonces llegó ChatGPT, y muy poco después, 
me quedó muy claro que estábamos en un camino peligroso.

Dos horas de conversación convertidas en texto que puedes buscar, copiar y anotar. En un clic.

Compartir

La herramienta no piensa por ti.

Tener la transcripción abre una tentación: pasársela a ChatGPT, pedirle un resumen, leerte las cinco viñetas y dar el vídeo por visto.

No lo hagas con lo que de verdad te importa.

Un resumen te da las conclusiones del autor. No te da cómo llegó a ellas, qué descartó por el camino, ni dónde dudó. Y eso es lo que distingue entender un tema de poder repetir sus titulares. Con Bengio, el resumen te dirá que cree que la IA agéntica es peligrosa. Verlo te dirá por qué un tipo que lleva cuarenta años en esto ha cambiado de opinión, qué ve ahora que no veía antes, y dónde sigue sin tenerlo claro. Eso no se resume.

¿Cómo trabajo yo con la transcripción?

El cambio que más me ha valido la pena: dejar de tratar los vídeos como contenido para consumir y empezar a tratarlos como material para mi vault de Obsidian.

Suena más rebuscado de lo que es. En la práctica:

Compartir

Mientras lo veo, subrayo frases en la transcripción y escribo notas al margen con mis reacciones: qué me sorprende, qué me chirría, qué me recuerda a algo que vi la semana pasada. Esas notas son lo que me distingue a mí de cualquiera que haya visto el mismo vídeo.

Cuando termino, le paso a Claude los archivos con las anotaciones y le pido que cruce mi wiki de conocimiento:

He terminado de ver este vídeo. Estas son mis notas y subrayados.
Busca en el vault dónde se solapan, contradicen o complementan
cosas que ya tengo anotadas de otros autores. Cita la fuente.

Aquí es donde el círculo se cierra. Yo trabajo con dos zonas:

• Un inbox donde caen los vídeos, links y transcripciones que voy capturando.

• Un wiki donde vive el conocimiento curado de los temas que me interesan.

Lo que sube al wiki ya no es "un vídeo que vi". Es mío. Lo escuché entero, leí la transcripción con calma, anoté lo que me chirriaba y lo que me hacía pensar. No vale porque lo dijera Bengio: vale porque pasó por mí. Lo demás se queda en el inbox como referencia, por si un día vuelve a hacer falta.

No hace falta un vault perfecto antes de empezar. Ni etiquetas, ni haberse leído tres tutoriales de Obsidian. Hace falta un sitio para los vídeos que de verdad te importan, y un clic en una extensión. Tres minutos. El inbox, el wiki, las notas al margen, todo eso lo vas construyendo tú con cada vídeo que guardas y procesas.

Hagamos una cosa: en los comentarios, dime el vídeo o podcast que llevas semanas con la pestaña abierta diciéndote "esto lo tengo que ver bien". Yo te respondo con el mío. Vamos a ver con cuántos coincidimos.

Suscríbete a Think&Hack

¿Cómo estás?

Soy Aina y esto es Think&Hack

Abres LinkedIn y ves a alguien hablándole a su ordenador para que le programe, le automatice un proceso o le monte un agente entero. Miras tu ChatGPT, donde llevas meses pidiéndole que te resuma un PDF o te redacte un correo, y te entra la duda: lo serio lo hacen otros, y tú estás pagando 20 € al mes por una versión descafeinada que se te ha quedado pequeña.

No es así. Lo que ves en esos vídeos ya viene incluido en tu suscripción de ChatGPT, sin coste adicional; el problema es que no te habían dicho dónde encontrarlo. No llegas tarde, no haces nada mal y no necesitas comprar nada: te han hecho creer que sí.

Codex es la versión “agente” de ChatGPT: en lugar de chatear con él en una pestaña, le das acceso a una carpeta de tu ordenador y trabaja dentro como un becario que lee, escribe y prueba archivos hasta entregarte el resultado. Es el mismo tipo de herramienta que Claude Code, pero con la marca y la suscripción que ya pagas: viene incluido en ChatGPT Plus. Y con la nueva actualización a GPT-5.5 va más rápido y por fin entiende proyectos enteros de una forma ágil.

La semana pasada lo abrí dentro de mi propio sistema de escritura, el que llevo meses afinando para Claude Code, sin reconfigurar una coma, y acabó publicando una newsletter al nivel de las que firmo. Te cuento cómo, y por qué el problema nunca fue lo que pagas: fue lo que te habían hecho creer que te faltaba.

Sistemas frente a presupuestos: la lección de TechTrendsTF26

Cerrar un evento como TechTrendsTF26 te da una perspectiva privilegiada. El pasado viernes 17 de abril volé desde Barcelona a Tenerife para dar la keynote final frente a una sala de directivos de pyme. ¿Y sabes lo que me encontré? Confirmé que muchas empresas están paralizadas por la herramienta. Buscan la herramienta de moda, convencidos de que les va a solucionar el negocio.

Subí al escenario para desmontarles esa idea. La tesis que llevo años defendiendo y aplicando al diseñar estrategias corporativas de IA generativa es siempre la misma: si tu sistema está roto, una IA más avanzada solo te dará un proceso roto más caro. Las empresas no necesitan comprar un milagro; necesitan que la tecnología opere bajo sus propias reglas. Personas primero, procesos después y tecnología al final.

Para demostrarte que el valor real está en el proceso y no en la tarjeta de crédito, no voy a mandarte a comprar Claude Code ni plataformas complejas. Voy a coger la herramienta estándar que ya tienes y enseñarte a estructurarla para utilizarla como si fuera Clade Code.

Lo que pasó cuando abrí Codex en mi carpeta de siempre

Cuando OpenAI sacó GPT-5.5, hubo una mejora que me interesó por encima del resto: por fin encajaba con sistemas de escritura complejos como el mío. Codex nació para programar. Con GPT-5.5 sigue siendo un agente de coding, pero si tu sistema de escritura está montado como una repo (archivos con reglas, memoria y voz), Codex no nota la diferencia. Y justo venía de Tenerife defendiendo que la decisión nunca es la herramienta, sino el sistema que tienes detrás. Así que hice lo evidente: probé el modelo nuevo en el sistema pensado para Claude Code, sin tocarle una coma, y ver qué pasaba.

Abrí Codex dentro del mismo vault que llevo meses afinando para Claude Code. No reescribí instrucciones ni adapté las skills; simplemente le pedí que se orientase solo y escribiera una newsletter desde dentro. La misma carpeta, la misma memoria del proyecto, pero un agente distinto.

Lo que produjo fue una newsletter que se podía publicar tras una edición humana, al nivel de una primera versión hecha con Claude Code. Lo interesante no es eso. Lo interesante es cómo llegó hasta ahí.

Las cinco capas que Codex encontró

Codex no improvisó. Antes de escribir nada, recorrió en orden cinco capas que estaban escritas mucho antes de que existiera.

1. Mapa: empezó por CLAUDE.md. Y eso ya dice algo: mi sistema está montado para Claude Code, no tengo AGENTS.md (el archivo que Codex leería por defecto), pero Codex abrió CLAUDE.md igual. No tocó el borrador: leyó primero el archivo que dice qué es Think & Hack, dónde vive cada cosa y qué carpetas son intocables. En treinta segundos sabía a qué proyecto había entrado.

2. Procesos: Cargó la skill antes de redactar. Encontró think-hack-viral en .claude/skills/ y lo leyó entero Es un procedimiento numerado: cargar contexto, leer lessons, declarar hipótesis, elegir arco, escribir, revisar, entregar con frontmatter. Así que no tuvo que inventarse cómo se escribe aquí, lo heredó.

3. Memoria: Usó las lessons para decidir. Abrió brain/lessons/, donde guardo cuatro lessons extraídas de las métricas de las newsletters publicadas: qué tipo de contenido convierte, qué aperturas funcionan, qué títulos rinden por debajo de la media y qué longitud cuadra con qué arco. Eligió el arco narrativo a partir de ahí, no de la intuición.

4. Voz: Cargó tres JSON antes de la primera frase. ADN verbal, ICP y perfil de negocio, todos en 60_Estrategia/Mi_contexto/. Escribió con mi vocabulario y para mi lector, no con el genérico que ya inunda el feed de IA.

5. Ejemplos: Leyó mi top 3 de newsletters publicadas. Netflix, YouTube y subagentes, las que mejor habían rendido por métricas, no tres al azar. Así Codex no tuvo que adivinar qué significa “calidad” aquí: tenía tres archivos a los que llegar.

Cinco capas, todas escritas mucho antes de que existiera Codex. Por eso aguantó el cambio de herramienta: el agente no tuvo que adivinar nada y yo no tuve que reescribir nada.

¿Por qué esto te importa (aunque tú no escribas newsletters)?

Demuestra en pequeño lo mismo que defiendo en cada newsletter: la herramienta nunca es la decisión. No lo es Claude Code y tampoco es Codex. La decisión es haber dejado escrito un criterio antes de que existiera el agente que iba a ejecutarlo.

Y esto vale para ti en cualquier disciplina donde vendas tu criterio. Si llevas tu trabajo en la cabeza, el agente improvisa. Si lo has escrito, en un Word, en Notion, en lo que sea, el agente opera dentro de tus reglas. No de forma perfecta, no sin revisión, pero sí con criterio. Tu criterio.

Por eso no estás atrás. Lo que ves en LinkedIn no es una herramienta más cara que la tuya: es alguien que escribió su trabajo antes de pedírselo a la IA.

Si quieres replicarlo

Antes de entrar en lo técnico, lo importante: lo que aguanta el cambio de modelo no es el comando que tecleas, son los archivos que dejas escritos. Lo mínimo cabe en cuatro:

1. Un mapa. Cinco párrafos en un documento sencillo dentro de la carpeta de tu proyecto: qué es esto, para quién, qué carpetas son intocables, qué decisiones ya están tomadas.

2. Tus lecciones. Otro documento con las dos o tres reglas que has aprendido midiendo tu trabajo, no leyendo blogs ajenos.

3. Tus ejemplos. Una carpeta con dos o tres piezas tuyas reales, al nivel que quieras reproducir.

4. Un sitio claro de salida. Una carpeta de “borradores” donde el agente sepa que tiene que dejar el trabajo, para que no improvise dónde guardarlo.

mi-proyecto/
├── AGENTS.md     Mapa: agents.md o CLAUDE.md, según la herramienta
├── examples/     Ejemplos: dos o tres piezas tuyas al nivel que quieres reproducir
├── lessons.md    Lecciones: lo que has aprendido midiendo, no copiando de un blog)
└── borradores/   Output: salida clara, para que el agente no improvise dónde dejar el trabajo

Esto vale para cualquier IA. Funciona en la conversación normal de ChatGPT (subiéndoselos al chat o usando la opción de Proyectos), funciona en Codex y funcionará en lo que salga en otoño. Si la palabra “terminal” no es lo tuyo, párate aquí: con esos cuatro archivos metidos en un proyecto de ChatGPT obtienes el 80% del resultado sin tocar nada negro con cursor parpadeante.

Si quieres ver Codex en directo, la versión que entra en tu carpeta y trabaja sobre los archivos sin que tengas que ir copiando y pegando, viene incluida en ChatGPT Plus y se instala con tres comandos:

1. Abre tu terminal:

2. Navega hasta la carpeta de tu proyecto: Instala Codex

npm install -g @openai/codex

3. Inicia Codex, simplemente escribe Codex

codex

4. Entra con tu cuenta de ChatGPT

Una vez dentro, eliges modelo con /model y seleccionas GPT-5.5 con razonamiento alto: la tarea no es responder rápido, es leer un sistema entero y escribir dentro de él.

¡Listo!

Ojo con los tokens, tampoco son infinitos :) ; ya irás aprendiendo cómo manejarte.

Lo que de verdad estabas viendo en LinkedIn

Vuelve un momento al vídeo del agente en la terminal, ese que te hizo dudar de tu suscripción. Lo que te atraía no era la herramienta: es la misma que tienes tú, solo que abierta en otro sitio, con otro nombre y dentro del plan que llevas meses pagando.

Lo que te llamaba la atención, sin saberlo, era el criterio de quien la usa. Esa persona del vídeo no tiene una IA mejor que la tuya: tiene el trabajo escrito antes de pedírselo a la IA.

Y eso puedes tenerlo tú esta semana, sin pagar nada nuevo. Por eso no llegas tarde. Y por eso la próxima vez que un vídeo te haga sentir así, párate antes de comprar nada: ¿lo que necesitas es la pantalla del vídeo, o el criterio de quien la conduce?

Fuentes y links

• Using GPT-5.5: OpenAI Docs

• Codex AGENTS.md: OpenAI Developers

• Codex Skills: OpenAI Developers

Recomienda Think&Hack

Soy Aina.

Comparte: Reenvía esto a quien acaba de comprar una herramienta de IA y todavía no ha diseñado el sistema que va detrás.

Compartir

Suscríbete: Si te han reenviado esto, únete aquí.

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack

Llevas meses usando IA para tu contenido. Produces más rápido que nunca.

Pero si pones tu último post junto al primero... suenan igual. Mismo nivel. Misma estructura. Seis meses después y tu contenido no ha mejorado nada.

La IA te hizo más rápido. No te hizo mejor.

A mí me pasó exactamente eso. 31 newsletters con un sistema editorial en Claude Code, podía sacar ideas, estructurar borradores y escribir más rápido. Pero había un problema: el sistema no aprendía de los resultados. Publicaba una newsletter, veía algunas métricas y seguía adelante. La siguiente pieza nacía casi desde cero.

Yo tenía datos. Tenía herramientas. Tenía un sistema que producía cada semana sin fallar. Lo que no tenía era a alguien que mirase los números, detectase qué funcionaba y convirtiese eso en reglas para la semana siguiente.

Esa función tiene nombre: Growth Editor. Y es la pieza que la mayoría de creadores de contenido con IA (yo incluida hasta hace dos meses) no tenemos:

No es un rol de lujo para equipos con presupuesto. Es una función: mirar tus datos de rendimiento, cruzarlos con lo que sabes sobre tu audiencia y convertir eso en restricciones concretas para tu próximo contenido.

Esto es lo que construí cuando decidí dejar de producir en piloto automático.

Paso 1: Medir lo que importa, no lo que halaga.

Dejé de mirar solo likes. Clasifiqué mis 31 newsletters por tipo de contenido y crucé con las métricas que de verdad indican crecimiento:

• ¿Qué newsletters generaban comentarios?

• ¿Cuáles traían nuevos suscriptores?

• y cuáles se quedaban en una reacción superficial.

Dato incómodo: Mis newsletters de opinión generaban likes, pero cero conversación y cero suscriptores nuevos. Los tutoriales con entidad generaban 6.7 veces más comentarios y 7 veces más signups.

El ejemplo más claro: “Lo que nadie explica de Nano Banana Pro” consiguió 6 likes y 0 comentarios. “He conectado ChatGPT con mi WordPress” consiguió 9 likes y 7 comentarios. Mismos likes. Resultados completamente distintos.

Paso 2: Convertir datos en lecciones que el sistema cargue.

Un dato suelto no sirve si la semana que viene empiezas de cero.

Construí lo que llamo mi brain: un documento de lecciones que mi sistema carga automáticamente antes de escribir cada borrador. Cada lección tiene tres partes:

1. La regla — lo que mis datos dicen hoy. Ejemplo: “Títulos de 6-12 palabras con entidad nombrada superan a los abstractos”

2. La prueba — la newsletter propia que mejor lo demuestra. No teoría de internet: evidencia de mi propio contenido

3. El historial — cada dato nuevo que confirma o contradice la regla

Tengo lecciones sobre títulos, sobre longitud, sobre aperturas, sobre tipo de contenido. Y son restricciones que mandan. Si mi lección dice “evitar textos de 1000-1500 palabras” y un consejo de internet dice “entre 800 y 1500 está bien”, gana mi lección. Siempre. Mis datos, no mejores prácticas de alguien que no soy yo.

brain/lessons/
├── titulos.md        → 6-12 palabras, entidad obligatoria
├── longitud.md       → 750-1000 o 1800-2200, nunca 1000-1500
├── aperturas.md      → 3 patrones probados, 5 anti-patrones eliminados
└── tipo_contenido.md → tutorial_entidad = crecimiento, opinión = alcance sin retorno

Captura de mi sistema: Cada lección se actualiza con datos nuevos después de cada newsletter.

Paso 3: Cerrar el bucle

Lo más importante: que lo que aprendes vuelva al punto de escritura.

Cada borrador empieza con una apuesta explícita: qué tipo de contenido es, qué longitud va a tener, qué patrón de apertura uso, cuántos comentarios y likes espero.

hipotesis:
  tipo_contenido: "tutorial_entidad"
  longitud_objetivo: 1900
  apertura_patron: "(a) dato cuantificado"
  prediccion_engagement: "8-12 likes, 5+ comments"

Cuando publico y mido, comparo la apuesta contra la realidad. Si predije 5 comentarios y recibí 17, analizo qué hice diferente. Si predije 8 likes y recibí 3, la lección se actualiza con el dato nuevo.

Escribir → Publicar → Medir → Evaluar → Aprender → Escribir mejor

Tu turno: 3 preguntas para diagnosticar tu sistema.

No necesitas Claude Code ni un sistema como el mío para empezar. Necesitas responder tres preguntas:

1. ¿Sabes qué tipo de contenido genera crecimiento real, no solo vanidad?

Coge tus últimos 15-20 posts. Clasifícalos por tipo: tutorial, opinión, reflexión, noticia. Cruza con comentarios y suscriptores nuevos, no likes. Si no ves diferencias claras entre tipos, no estás midiendo lo que importa.

2. ¿Tienes restricciones escritas que vengan de tus propios datos?

“Publicar martes a las 8” no es una restricción útil. “Mis tutoriales generan 6x más conversación que mis opiniones”; sí lo es. Sin restricciones propias, cada pieza de contenido parte de cero.

3. ¿Tu herramienta de IA carga esas restricciones antes de escribir?

¿Le pasas tus lecciones aprendidas como contexto? ¿O el mismo prompt genérico del primer día? Un prompt que no evoluciona contigo produce el mismo nivel el día 1 que el día 180.

En resumen:

Y aquí está lo que nadie te dice sobre crear contenido con IA.

La IA es extraordinaria produciendo. Pero amplifica lo que sabes. Si no sabes qué funciona en tu contenido, tu prompt no lo va a descubrir por ti.

La diferencia no es cosmética. Es estructural.

Sigo creyendo que la IA es la mejor herramienta que he tocado en 20 años de digital. Pero la herramienta no reemplaza la disciplina de saber qué hace bueno a tu contenido. La IA me ayudó a construir el sistema. Las lecciones que alimentan ese sistema, esas las tuve que aprender yo.

¿Tu sistema de IA produce más o produce mejor?

Recomienda Think&Hack

¿Me echas una mano para que esta newsletter llegue a más personas? Si te ha servido, reenvíala a alguien a quien también le pueda ayudar.

Comparte: Reenvía esto a esa persona de tu equipo que tiene un sistema de IA para contenido, pero no sabe si está mejorando o solo produciendo.

Compartir

Responde: ¿Qué mides de tu contenido y qué haces con esos datos?

Deja un comentario

Suscríbete: Si te han reenviado esto, únete aquí.

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Analizar un canal de YouTube a mano es un trabajo ingrato. Abres vídeo por vídeo, apuntas views, comparas fechas, intentas intuir patrones en los títulos. Dos horas para sacar un informe que, además, envejece rápido.

Y lo peor es que los datos ya existen.

YouTube tiene una API pública que devuelve información de cualquier canal: visualizaciones, likes, comentarios, títulos, fechas, suscriptores. No es un problema de acceso. Es un problema de método: convertir datos en criterio.

Yo creé, un agente.

De datos sueltos a análisis útil

La API de YouTube devuelve campos para detectar patrones que no ves navegando por la plataforma:

• Qué temas generan más views y cuáles pasan desapercibidos

• ¿Qué formatos de título correlacionan con mejor rendimiento?

• si los vídeos con invitados funcionan mejor que los vídeos en solitario

• Cuál es el engagement real de cada vídeo

• Cada cuánto publica un canal y si crece, se estanca o cae

Con los 30 vídeos más recientes de un canal, ya puedes construir un análisis que a mano te llevaría horas.

Lo que construí

Construí un agente que convierte esa API pública en un analista de canales de YouTube.

Le das un handle. El agente resuelve el canal, recoge los últimos 30 vídeos, pide sus estadísticas y genera un research completo con métricas, ranking de rendimiento y conclusiones sobre qué contenido funciona mejor.

Lo construí con Claude Code como un skill: un archivo de instrucciones que le dice al agente qué datos pedir, qué métricas calcular y en qué formato devolver el análisis.

Y aquí está la diferencia con una herramienta cerrada: el skill es un archivo de texto que puedes abrir, leer y modificar. ¿Quieres que analice 50 vídeos en vez de 30? Cambias un número. ¿Quieres que el informe incluya una sección sobre frecuencia de publicación? Añades una línea a las instrucciones. ¿Quieres que compare dos canales? Le dices cómo. No dependes de lo que un producto decida ofrecerte. Tú decides qué preguntas hace el agente y en qué formato te entrega las respuestas.

No improvisa. Sigue un protocolo.

El resultado es un markdown listo para leer en Obsidian, Notion o cualquier editor. No una tabla para interpretar después, sino un informe para tomar decisiones.

Un comando. Un handle. Tres minutos.

¿Qué hace el agente?

El skill hace dos cosas.

Recoger. Se conecta a la API de YouTube y descarga los datos en bruto de los 30 vídeos más recientes: título, views, likes, comentarios y fecha.

Analizar. Ordena los vídeos por rendimiento, calcula el engagement medio del canal, detecta qué temas y formatos aparecen en los vídeos que mejor funcionan, identifica los que peor rinden y genera un documento con tres bloques:

1. Qué funciona

2. Qué no funciona

3. Qué haría después

El resultado es un markdown que puedes abrir en Obsidian, en Notion o en cualquier editor. Un informe de research listo para tomar decisiones, no una tabla de datos para interpretar.

Lo lancé contra el canal de Peter Yang, un creador sobre IA con 78.600 suscriptores. El agente detectó, por ejemplo, que los vídeos sobre OpenClaw dominan su top 7, que los tutoriales con invitados rinden mejor que los vídeos en solitario y que un vídeo sobre Claude Opus supera las 92.000 views, mientras que otro sobre Gemini se queda en 4.400.

Eso no es intuición. Es patrón.

Y ese patrón te sirve para decidir qué tema tocar, qué formato priorizar y qué tipo de contenido repetir.

Ejemplo del resultado

El skill completo está publicado y es abierto: youtube-channel-research en GitHub. Si quieres ver el informe que genera antes de instalarlo: resultado completo de Peter Yang.

Descargar Skill

Por qué esto importa

La mayoría de personas usa la IA para buscar información que ya existe en internet. Yo la uso para algo distinto: coger fuentes de datos públicas que nadie aprovecha y convertirlas en herramientas.

Con Netflix convertí artículos técnicos en un Gem de Gemini. Con YouTube, una API pública en un agente de Claude Code. Los datos ya estaban ahí. Lo que faltaba era alguien que escribiera las instrucciones correctas y dejara que la IA hiciera el trabajo pesado.

Esto no va solo de YouTube.

Funciona con cualquier canal público, pero sobre todo con cualquier fuente de datos pública que hoy nadie esté aprovechando bien. La idea no es “usar una herramienta”. La idea es convertir una fuente en un sistema útil.

Y eso sí escala.

Si tienes una fuente de datos pública que hoy miras a mano, probablemente puedas convertirla en un flujo de trabajo mejor. Más rápido. Más consistente. Más útil.

Si quieres saber más:

Fuentes y links

• Skill de YouTube Research — repositorio completo con instrucciones de instalación

• YouTube Data API v3 — Documentación oficial

Recomienda Think&Hack

¿Me echas una mano para que esta newsletter llegue a más personas? Si te ha servido, reenvíasela a alguien a quien también le pueda ayudar.

Comparte: Reenvía esto a alguien que analiza canales de YouTube a mano.

Compartir

Responde: ¿Tienes fuentes de datos públicas que no estás aprovechando?

Deja un comentario

Suscríbete: Si te han reenviado esto, únete aquí.

Suscríbete ahora

Has probado ChatGPT. Has probado Claude. Quizás Perplexity, quizás NotebookLM. Has abierto cuentas, has aprendido interfaces, has pagado alguna suscripción Y los resultados siguen siendo genéricos. El tipo de respuesta que te hace pensar: "Esto lo podría haber buscado en Google”.

Y empiezas a sospechar que el problema no es el modelo.

No lo es.

Esta semana me invitaron al podcast #HechoconIA, un podcast donde profesionales explican qué están construyendo con inteligencia artificial. Decidí explicar cómo gestiono todo el contenido de Think&Hack, la newsletter, las redes, la estrategia, mientras trabajo a jornada completa en Planeta.

El problema que nadie quiere ver

Todo el mundo habla de IA sobre datos. Y tiene sentido: la digitalización lleva años; algo hemos acumulado. Bases de clientes, históricos de contenido, métricas de campañas La IA es buena trabajando con datos.

Si tú no sabes explicar paso a paso cómo decides sobre qué escribir esta semana, cómo priorizas un contenido sobre otro, cómo evalúas si algo funcionó o no, la IA tampoco va a saberlo. Da igual que le des acceso a todos tus datos. Le falta la lógica que conecta los puntos.

Cuando digo procesos, no hablo de un documento de 50 páginas; hablo de saber responder: ¿cómo decido qué publicar? ¿Qué criterios uso para filtrar? ¿Cómo sé si algo funcionó? ¿Qué hago con lo que leo cada día?

Si no puedes responder eso, ninguna herramienta de IA te va a salvar.

¿Qué pasa si los tienes?

En la entrevista enseñé el sistema en directo. Mi rutina de la mañana empieza escribiendo “buenos días” en la terminal. Un agente revisa mi calendario editorial, escanea todo lo que he ido guardando durante la semana desde el móvil, lo resume, lo puntúa según mi estrategia y me genera un panel con lo que me falta, lo que funcionó y lo que toca hacer hoy.

Parece magia. No lo es. Funciona porque debajo hay tres cosas que construí antes de tocar una sola herramienta:

1. Procesos documentados. Mi flujo de contenido entero está escrito: cómo capturo ideas, cómo las filtro, cómo las convierto en piezas, cómo las distribuyo. Cada paso es un archivo de instrucciones que la IA puede seguir. Sin eso, lo único que obtienes son respuestas genéricas; da igual lo bueno que sea el modelo.

2. Contexto de estrategia. La IA tiene acceso a archivos que le dicen quién es mi audiencia, cuál es mi voz, qué objetivos persigo, qué tipo de contenido funciona y cuál no. No suena como yo por un prompt ingenioso. Suena como yo porque tiene acceso a mi contexto real.

3. Métricas como feedback. El sistema descarga datos de LinkedIn, Substack y notas de forma regular. No para mirar números por mirarlos. Para que la estrategia se ajuste sola: si mi audiencia crece en madurez técnica, el contenido crece con ella. Si un formato deja de funcionar, lo detecta antes que yo.

Nada de esto depende de una herramienta concreta. Lo construí en una terminal, pero el mismo enfoque funcionaría con cualquier IA que acepte instrucciones y tenga acceso a archivos. Lo que no puedo cambiar es el proceso de debajo. Eso es lo que tiene valor.

Cómo empezar: documenta antes de automatizar

La primera vez que le pedí a alguien en Planeta que me explicara su proceso, me di cuenta del problema real. No por incompetencia, sino porque llevamos años dando por hecho pasos que nunca hemos puesto por escrito. Cosas que haces rápido porque llevas diez años haciéndolas, pero que si no las desgranas, la IA no tiene nada con lo que trabajar.

Mi método: grabarte en video mientras trabajas, explicando en voz alta lo que haces y por qué. De ese video se extrae el proceso. Luego revisas los momentos donde fuiste rápido sin explicar; ahí es donde están las decisiones que nadie documenta y que hacen que un proceso funcione.

No necesitas una terminal. No necesitas saber programar. Necesitas un móvil, 10 minutos y una tarea que hagas todas las semanas.

La próxima vez que pienses “necesito una herramienta de IA para esto”, para. Pregúntate primero: ¿tengo escrito como lo hago hoy? Si la respuesta es no, empieza por ahí. No hace falta que sea perfecto. Hace falta que exista.

Tus resultados con IA no van a mejorar cambiando de modelo. No van a mejorar con un prompt mejor. Van a mejorar el día que abras un documento y escribas cómo tomas las decisiones que tomas cada semana. Ese documento es lo que le falta a tu IA. Y no te lo va a dar ninguna herramienta.

Fuentes y links

• #HechoconIA entrevista completa — el sistema en directo, con demo y preguntas

Recomienda Think&Hack

Soy Aina. Responsable de IA generativa en Planeta.

Comparte: Reenvía esto a alguien de tu equipo que sigue buscando la herramienta perfecta sin haber documentado un solo proceso.
Responde: ¿Tienes procesos documentados o vas improvisando? Sin juicio: yo hace un año tampoco los tenía.
Suscribete: Si te han reenviado esto, unete aqui.

Suscríbete ahora

Soy Aina y esto es Think&Hack.

Hay una fricción bastante común cuando usamos ChatGPT, Claude o Gemini: escribimos una pregunta y esperamos que la IA adivine qué necesitamos, en qué contexto estamos y qué nivel de respuesta buscamos.

No suele funcionar así.

Una parte importante de la calidad de la respuesta no depende solo del prompt que escribes en ese momento, sino también del contexto previo que le das a la herramienta. Ahí entran las instrucciones personalizadas.

Piensa en ello como ajustar el asiento, los espejos y la postura antes de conducir. El coche es el mismo, pero la experiencia cambia.

Qué son y por qué importan

Las instrucciones personalizadas son un texto que la IA puede leer antes o durante tus conversaciones, según la plataforma. No sustituyen un buen prompt, pero sí ayudan a que la herramienta responda de forma más coherente con tu rol, tu contexto y tu forma de trabajar.

Bien configuradas, sirven para tres cosas:

• Dar contexto sobre quién eres y qué haces.

• Indica cómo quieres que te responda.

• Reducir respuestas genéricas o desalineadas.

Eso no convierte a la IA en más inteligente. La vuelve más útil para tu caso.

¿Dónde se configuran?

Cada plataforma lo resuelve de forma distinta:

La lógica es parecida, pero la implementación cambia. Y eso importa, porque no conviene asumir que todas funcionan igual.

Qué conviene meter

Aquí es donde mucha gente se queda corta. Lo habitual es escribir algo como: “Soy marketer, respóndeme en español y sé conciso”.

Eso ayuda, pero se queda en la superficie.

Yo suelo pensar las instrucciones en cuatro bloques:

1. Contexto

Quién eres, a qué te dedicas y en qué tipo de problemas usas la IA.

Ejemplo: rol profesional, sector, tipo de tareas, nivel de conocimiento.

2. Forma de respuesta

Cómo quieres que te conteste.

Ejemplo: directo o más explicativo, breve o detallado, con listas/pasos/comparativas, en tono formal o cercano.

3. Criterio

Qué debe priorizar cuando responda.

Ejemplo: no inventar datos, señalar límites, diferenciar hipótesis de hechos, avisar si falta contexto.

4. Protocolo cuando haya ambigüedad

Qué hacer si tu petición no está clara.

Ejemplo: pedir aclaración antes de asumir, ofrecer dos interpretaciones posibles, evitar construir conclusiones sobre datos incompletos.

Ese cuarto bloque es el más infravalorado. Si no lo defines, la IA tenderá a rellenar huecos por su cuenta.

Un ejemplo simple de instrucciones útiles

No hace falta complicarlo demasiado. Algo así ya puede mejorar bastante la experiencia:

Contexto: trabajo en estrategia y comunicación, y uso la IA
para pensar mejor, estructurar ideas y explorar alternativas.

Cómo quiero que responda: en español, con claridad, sin relleno,
con estructura y sin exceso de entusiasmo.

Criterio: no des por hecho lo que no esté claro. Si falta contexto,
dilo. Si hay riesgos, señálalos. Si una idea es débil, explícalo.

Cuando haya ambigüedad: antes de asumir, haz una pregunta o
plantea las posibles interpretaciones.

Antes y después

Lo que no hacen

Importa decirlo con claridad: las instrucciones personalizadas no arreglan una mala pregunta, no sustituyen criterio y no convierten a la IA en una experta real por defecto.

Sirven para orientar mejor la conversación. No para delegar el pensamiento.

Y ahí está la diferencia importante.

Mi recomendación

Si nunca has tocado esta parte, prueba esto:

1. Revisa dónde se configuran en la IA que uses.

2. Escribe un bloque breve de contexto.

3. Define cómo quieres que responda.

4. Añade una regla sobre ambigüedad y límites.

5. Prueba la misma pregunta antes y después.

No busques la frase perfecta. Busca que la herramienta entienda mejor cómo trabajas.

El resultado no suele ser espectacular a primera vista. Pero sí se nota.

Menos respuestas de plantilla. Menos ruido. Más contexto. Más criterio.

Y eso, cuando usas IA de verdad, importa bastante.

¿Usas instrucciones personalizadas? ¿Qué cambiarías de tu configuración actual?

Soy Aina. Responsable de IA generativa en Planeta. Si te ha servido, compártelo con alguien que siga usando la IA “de fábrica”.

Compartir Think & Hack

Fuentes y links

• ChatGPT - Personalizar instrucciones

• Claude - Personalización

• Gemini - Crear Gems

• OpenAI - Sycophancy in GPT-4o

Suscríbete a Think&Hack.

Si quieres seguir leyendo Think&Hack, suscríbete aquí.

Suscríbete ahora