¿Cómo estás?
Soy Aina y esto es Think&Hack.

Tengo una wiki creada con inteligencia artificial. Bueno, tengo varias: una sobre IA, otra sobre resolución de problemas complejos, otra de estadística, otra con mis newsletters y otra para ideas.

Hay fuentes, conceptos, etiquetas y enlaces entre páginas. También he creado un buscador basado en QMD y lo he conectado a un modelo de lenguaje para poder hacer preguntas sobre lo que guardo. Todo desde Obsidian, la aplicación donde abro y consulto mis wikis.

Lo curioso es que el sistema funciona. Puedo guardar información, relacionarla y recuperarla cuando la necesito. El problema es que, en la práctica, casi nunca voy a buscarla.

Y esto me ha hecho replantearme algo: ¿de qué sirve tener todo ese conocimiento organizado si después no lo utilizamos para trabajar?

Así que he cambiado el enfoque. He creado /piezas, una skill que permite a mis agentes buscar soluciones que ya hemos construido en otros proyectos y comprobar si pueden reutilizarlas antes de empezar algo nuevo.

La diferencia está en cuándo y para qué utilizamos la información que guardamos.

Y eso es precisamente lo que quiero enseñarte hoy.

Guardar todo lo interesante y poder recuperarlo después.

Un segundo cerebro con IA consiste en poder guardar todo lo que vas leyendo, aprendiendo y, cuando necesitas algo, encontrarlo sin tener que recordar dónde está.

Así que me puse a crear mi LLM Wiki: un sistema donde una IA organiza lo que guardo, relaciona mis ideas con otras y me permite hacer preguntas sobre toda esa información. Así no tengo que ir buscando entre documentos cada vez que quiero recuperar algo.

Para construir mi wiki elegí como referencia la idea de Andrej Karpathy, en la cual propone utilizar agentes de IA para mantener la base de conocimiento que se va actualizando con la información que incorporo. Por ejemplo, si añades un artículo sobre un tema que ya tienes documentado, el agente puede actualizar la página correspondiente, relacionar las ideas nuevas con las anteriores y señalar si encuentra información contradictoria.

Ahora puedo enviar un artículo desde Telegram para incorporarlo a la wiki del tema correspondiente y, después, hacer preguntas sobre ese contenido desde Obsidian.

¿Por qué no estaba utilizando mis wikis?

Después de montar todo el sistema, me he dado cuenta de que apenas lo utilizo. Tengo un montón de información guardada y ordenada, pero cuando empiezo un proyecto nuevo, no recurro a ella para consultar lo que he guardado.

Esta situación me ha recordado algo de lo que ya he hablado: “Datos sin procesos no sirven”. No basta con tener la información disponible. También necesitamos definir cuándo y para qué vamos a utilizarla.

Así que he añadido piezas a mi arnés agéntico, el conjunto de instrucciones, herramientas y archivos con el que organizo el trabajo de mis agentes.

Una pieza es algo que ya he construido, que resuelve un problema concreto y que puedo volver a usar en otro proyecto sin rehacerlo. Puede ser un script, un conector, una skill, una pantalla o un método documentado.

¿Cómo consigo que mis agentes reutilicen lo que ya he construido?

Para que mis agentes puedan aprovechar lo que ya he construido, necesitan saber qué soluciones tengo disponibles en cada proyecto.

Por eso, en cada proyecto tengo un archivo llamado piezas.json, donde registro las soluciones que puedo reutilizar. De cada una guardo qué problema resuelve, cómo funciona, dónde están sus archivos y qué necesita para utilizarla.

Pero claro, de poco sirve tener ese catálogo si los agentes no lo consultan.

Dentro del AGENTS.md, les explico cómo tienen que trabajar, he añadido una instrucción: antes de construir algo nuevo, deben comprobar si ya existe alguna solución que pueda servir. Y cuando crean, modifican o dejan de utilizar una pieza, también tienen que actualizar el catálogo.

¿Y qué pasa si la solución está en otro proyecto?

Ahí entra Tardis, la aplicación que utilizo para gestionar mis proyectos. Tardis lee los archivos piezas.json de todos mis proyectos y permite buscar entre todos ellos. Así, el agente puede buscar por el problema que necesita resolver, sin que yo tenga que recordar en qué proyecto está cada solución.

Por último, tengo la skill instalada a nivel global , /piezas, que explica a los agentes cómo hacer esa búsqueda y qué pasos seguir cuando encuentran una posible solución.

Porque encontrar algo parecido no significa que podamos reutilizarlo directamente. Primero tienen que consultar sus archivos, comprobar qué necesita para funcionar y valorar si encaja con lo que les he pedido.

Y si no encaja, seguimos construyendo. Pero al menos comprobamos antes si ya tenemos parte del trabajo realizado.

Lo que he aprendido construyendo estos sistemas

Después de todo este trabajo, hay algo que tengo bastante claro: antes de montar otro sistema para guardar conocimiento, quiero saber cuándo y para qué voy a utilizar esa información.

Mis wikis funcionan. Puedo guardar documentos, relacionar conceptos y hacer preguntas sobre lo que he aprendido. Pero, en la práctica, apenas las consulto.

Con /piezas es diferente. Mis agentes tienen instrucciones para buscar soluciones anteriores antes de construir algo nuevo. Y si encuentran alguna que pueda servir, tienen que comprobar si podemos reutilizarla.

No significa que vaya a abandonar mis wikis. Quizá encuentre otras formas de incorporarlas a mis procesos. Pero ahora tengo mucho más claro qué necesito resolver para que me resulten útiles.

Porque me encanta seguir experimentando y construyendo cosas con IA, pero también quiero aprovechar todo el trabajo que ya tengo hecho. :)

Y ahora te pregunto: ¿tienes alguna carpeta, wiki o colección de enlaces que se haya convertido en tu propio Diógenes organizado? ¿Qué haces para aprovechar lo que guardas?

Cuéntamelo. Siempre leo todo.
Nos leemos,
Aina

Deja un comentario

Suscríbete a Think&Hack

Tools are great. Systems are better.

Si te gusta probar la IA y entender cómo puedes aprovecharla en tu trabajo, suscríbete a Think&Hack. Por aquí comparto lo que voy aprendiendo, mis experimentos y cómo puedes probarlos tú. :)

Suscríbete ahora

¿Cómo estás?
Soy Aina y esto es Think&Hack.

Si llevas un tiempo construyendo cosas con agentes de IA, quizá te esté pasando algo parecido. Empiezas con una aplicación, añades unas cuantas funciones, se te ocurre otra herramienta… y llega un momento en que cuesta acordarse de qué habías decidido en cada proyecto.

¿Esto lo habíamos terminado? ¿Aquello era una idea que propuso el agente o le había dicho que lo hiciera? ¿Por qué decidimos montarlo así?

Estamos construyendo a un ritmo que hace muy difícil llevar todo eso en la cabeza. Y, aunque la conversación siga guardada, ponerse a buscar dónde acordamos cada cosa tampoco es un plan demasiado apetecible. :)

En la última newsletter te enseñé cómo había preparado un sistema de diseño y dos agentes para construir y revisar componentes. Una parte del trabajo consistía en dejar las decisiones por escrito para que una conversación nueva pudiera recuperarlas.

En la newsletter de hoy voy a profundizar un poco más en cómo estoy construyendo mi arnés: las instrucciones, herramientas y procedimientos con los que hago trabajar al agente. Además de indicarle cómo trabajar, necesito un lugar donde guardar qué estamos haciendo, qué hemos decidido y qué hemos aprendido.

Para eso he preparado una carpeta llamada memorias, con tres registros y sus plantillas.

Vamos desde el principio. :)

Volver a un proyecto sin tener que reconstruir toda la historia.

Cuando vuelvo a un proyecto, necesito entender en qué punto está antes de pedirle nada nuevo al agente. Para eso he separado la información en tres archivos:

memorias/
├── backlog.json
├── decisiones.json
└── aprendizajes.json

Son archivos de texto en formato JSON. En lugar de escribir un párrafo distinto cada vez, la información se guarda en campos con nombres definidos: el título, el estado, la fecha… Así podemos leerla nosotros y también puede utilizarla un programa.

No hace falta rellenarlos a mano. El agente se encarga de escribirlos siguiendo las plantillas. Pero sí conviene entender qué tiene que guardar en cada uno, porque después vamos a trabajar a partir de esa información.

1. El backlog: distinguir lo que hemos pedido de lo que el agente ha propuesto.

El backlog es la lista de tareas y propuestas del proyecto. Cada entrada explica qué se quiere hacer, por qué y qué consideraríamos terminado.

Imagina que estoy construyendo una aplicación para gestionar solicitudes. Cada solicitud tiene un estado, como «pendiente» o «resuelta», y quiero poder verlas por separado. Le pido al agente que añada un filtro por estado y, mientras trabaja, me propone incorporar también una opción para exportar la lista a Excel.

Las dos pueden quedar apuntadas en el backlog, pero tienen una diferencia: el filtro se lo he pedido yo; la exportación es una sugerencia suya que todavía no he aceptado.

En mi backlog, una propuesta del agente nace como propuesto. Puedo aceptarla o descartarla. Que haya tenido una buena idea no significa que tenga permiso para ponerse a construirla.

Una tarea aceptada pasa a en_curso cuando empieza el trabajo y a hecho cuando se ha completado siguiendo el procedimiento del proyecto. También conservamos las entradas descartadas, para que quede constancia de que se valoraron y se decidió no hacerlas.

Esta distinción me permite conservar mi criterio sobre cómo avanza el proyecto. El agente puede proponer mejoras, pero soy yo quien decide cuáles tienen sentido, cuándo hacerlas y cuáles descartar. Así, una sugerencia suya no se convierte en un encargo sin que yo la haya aceptado.

2. Las decisiones: no tener que volver a explicar por qué lo he hecho así.

Mientras trabajo con el agente, vamos decidiendo qué solución utilizar, qué dejar para más adelante y qué puede hacer sin pedirme permiso. Si solo lo hablamos en el chat, al abrir una conversación nueva, el agente no sabrá qué habíamos acordado ni por qué. Puede volver a proponer una solución que ya descartamos o ponerse a trabajar en algo que habíamos dejado para más adelante, y me tocará explicárselo otra vez.

En decisiones.json guardamos qué problema necesitábamos resolver, qué hemos decidido y qué alternativas hemos descartado y por qué. Así el agente puede consultar los acuerdos antes de continuar y yo puedo recordar los motivos sin releer varios chats.

También puedo cambiar de opinión. En ese caso, registramos una decisión nueva y marcamos la anterior como sustituida. Así queda claro cuál se aplica ahora, pero conservamos lo que habíamos decidido antes y sus motivos.

3. Los aprendizajes: no tener que resolver el mismo problema dos veces.

Mientras trabajo con el agente, vamos descubriendo errores, soluciones y limitaciones que no conocíamos al empezar. Parte de lo que aprendemos puede servirnos en otras tareas, pero si se queda en la conversación, otro agente puede volver a tropezar con el mismo problema.

En aprendizajes.json guardamos qué ocurrió, qué aprendimos y en qué situaciones conviene tenerlo en cuenta. Así, cuando el agente se encuentre con un problema parecido, puede consultar lo que ya descubrimos antes de volver a investigarlo desde cero.

Las plantillas: cambiar de agente sin que cada uno organice la información a su manera.

Ya tengo dónde guardar las tareas, las decisiones y los aprendizajes. Pero si le digo a un agente «apunta esta decisión», puede escribir solo lo que hemos elegido y dejar fuera el motivo. Otro puede organizarlo de otra manera. Al cambiar de conversación, acabaría teniendo registros distintos y tendría que revisar qué falta en cada uno.

Para evitarlo, cada registro tiene una plantilla en la carpeta plantillas. Ahí explico qué información debe guardar el agente, qué significa cada campo y qué valores puede utilizar.

Por ejemplo, la plantilla de decisiones pide el problema que necesitábamos resolver, lo que hemos decidido y las alternativas descartadas. La del backlog explica los estados de una tarea y pide que su descripción indique qué quiero hacer, por qué y qué consideraré terminado.

En la carpeta memorias queda guardado lo que vamos haciendo y decidiendo. En plantillas explico qué debe incluir cada registro para que no falte información importante.

Para que el agente sepa dónde encontrar esas plantillas, las enlazo desde AGENTS.md, el archivo donde dejo las instrucciones de trabajo del proyecto. Ahí le indico que consulte la plantilla correspondiente antes de crear o modificar un registro.

Así, aunque cambie de agente, todos tienen las mismas instrucciones para guardar la información y yo puedo encontrarla organizada de la misma manera.

El recorrido es bastante sencillo: antes de empezar, leer las tareas y los aprendizajes; durante el trabajo, respetar lo aceptado; y al terminar, dejar registrado qué ha pasado y qué sigue pendiente. Si hemos tomado una decisión o aprendido algo que merece conservarse, se guarda en su sitio.

Ver cómo van todos mis proyectos sin tener que abrirlos uno por uno.

Guardar la información de la misma manera en todos mis proyectos me permite dar un paso más: reunirla en una sola pantalla y consultar cómo van, sin tener que abrir cada proyecto por separado.

Si en uno utiliza una carpeta llamada memorias, en otro logs y en otro tareas, cada proyecto acaba teniendo su propia organización. Por eso, en cada proyecto tengo una carpeta llamada memorias, con los mismos nombres de archivo y la misma estructura:

• backlog.json

• decisiones.json

• aprendizajes.json

Cada proyecto guarda su propia información, pero siempre en el mismo sitio y con el mismo formato. Así puedo leer esos archivos y reunir la información de varios proyectos en una sola pantalla.

Esto también me permite reunir esa información en Tardis, la aplicación que estoy construyendo para gestionar mis proyectos.

En Tardis puedo entrar en un proyecto y consultar su backlog, con sus tareas y propuestas. Pero también tengo un backlog general que reúne las entradas de todos los proyectos. Desde ahí puedo filtrar por proyecto, estado o prioridad y ver qué está en curso o qué propuestas esperan mi decisión.

Para mostrarlo, Tardis lee el archivo memorias/backlog.json de cada proyecto y conserva a cuál pertenece cada entrada. La misma información que utiliza el agente para trabajar me sirve a mí para ver el detalle de un proyecto o consultar cómo van todos desde una sola pantalla.

Claro que esto depende de que los registros estén al día. Si el agente termina una tarea y no actualiza su estado, Tardis seguirá mostrándola como pendiente. Tendré la información desactualizada, pero muy bien presentada. :)

Saber dónde lo dejamos para decidir cómo seguimos

Al principio os hablaba de esas preguntas que me hago al volver a un proyecto: qué estaba terminado, qué había aceptado y por qué habíamos decidido hacerlo así.

Guardar esa información me permite recuperar el hilo y conservar mi criterio sobre cómo avanza el trabajo. El agente puede consultar lo acordado y yo puedo revisar qué queda pendiente, valorar sus propuestas y decidir por dónde seguir.

Además, al utilizar la misma estructura en cada proyecto, puedo reunir sus registros y ver cómo van todos desde un mismo lugar.

Pero esa vista solo me sirve si la información está al día. ¿Cómo consigo que el agente deje registrado lo que ha hecho? ¿Y qué tiene que comprobar antes de marcar una tarea como terminada? De eso os hablaré la semana que viene.

¿Y tú? ¿Cómo llevas el seguimiento de lo que haces con tus agentes? ¿Lo dejas en las conversaciones o tienes alguna forma de recuperarlo después?

Cuéntamelo. Siempre leo todo.
Nos leemos,
Aina

Deja un comentario

Suscríbete a Think&Hack

Tools are great. Systems are better.

Si te gusta probar la IA y entender cómo puedes aprovecharla en tu trabajo, suscríbete a Think&Hack. Por aquí comparto lo que voy aprendiendo, mis experimentos y cómo puedes probarlos tú. :)

Suscríbete ahora

¿Cómo estás?
Soy Aina y esto es Think&Hack.

Si has probado a crear una aplicación con IA, quizá te haya pasado algo parecido. Consigues una pantalla que te gusta, le pides que añada otra y empiezan las sorpresas. Los botones ya no tienen el mismo aspecto, los espacios cambian y aparece un formulario que parece sacado de otra aplicación.

Así que empiezas a corregir. Que utilice los mismos colores, que recupere aquel botón que ya habíais preparado, que mantenga el estilo de la primera pantalla… Y cuando abres una conversación nueva, vuelta a empezar. :)

El problema es que estamos tomando decisiones de diseño que después no quedan recogidas en ningún sitio que la IA pueda consultar y reutilizar. Y cuanto más crece la aplicación, más cosas tenemos que recordar y revisar.

Esta semana vamos a ponerle solución construyendo nuestro propio sistema de diseño con nuestra IA agéntica preferida (Codex, Claude Code…). Tendremos colores, reglas visuales y componentes reutilizables, además de un catálogo donde podremos verlos, probarlos y consultar cómo utilizarlos.

Pero también vamos a preparar algo que me parece especialmente interesante: un arnés de trabajo con instrucciones, skills y dos agentes especializados. Uno se encargará de construir los componentes y otro de revisar lo que ha hecho. Así, cuando pidamos una pantalla nueva, Codex tendrá un procedimiento para aprovechar lo que ya existe, crear lo que falta y comprobar el resultado.

Y lo vamos a probar construyendo una pantalla real a partir de nuestros componentes.

Vamos desde el principio. :)

Antes de empezar: ¿qué vamos a construir?

Vamos a preparar un sistema de diseño que podamos reutilizar en nuestras aplicaciones. Ahí guardaremos los colores, las reglas visuales y los componentes que vayamos creando, como botones, formularios o tablas.

También construiremos un catálogo para ver esos componentes, probar cómo se comportan y consultar cómo utilizarlos. Y lo interesante es que no serán ejemplos independientes: los componentes que veamos en el catálogo serán los mismos que después utilizaremos en nuestras aplicaciones.

Pero tener los componentes guardados es solo una parte. También necesitamos que Codex sepa dónde encontrarlos, cuándo reutilizarlos y qué hacer cuando necesitemos uno nuevo.

Para eso prepararemos nuestro arnés de trabajo: un conjunto de instrucciones, skills y agentes que guiarán el proceso. Tendremos un agente encargado de construir componentes y otro que revisará el resultado antes de incorporarlo al sistema.

Empezaremos con algo pequeño: nuestros colores, un catálogo básico y un botón Button con dos variantes. Cuando lo tengamos funcionando, daremos el siguiente paso y construiremos una pantalla más completa para comprobar cómo se reutiliza todo lo anterior.

1. Prepara una carpeta que puedas abrir y probar.

En este ejemplo utilizamos React para construir la interfaz, TypeScript para describir los datos que aceptan los componentes y Vite para crear el proyecto y verlo en el navegador. Node.js y npm permiten ejecutar esas herramientas e instalar sus dependencias. Trabajaremos desde Visual Studio Code con Codex.

Instala VS Code y una versión LTS de Node.js compatible con la versión de Vite que vayas a utilizar. Abre una carpeta vacía, por ejemplo mi-design-system, y entra en Terminal → Nuevo terminal. Comprueba la instalación ejecutando cada consulta por separado:

node -v
npm -v

Ambas deben devolver un número de versión. Si alguna no se reconoce, revisa la instalación y vuelve a abrir el editor antes de continuar.

Dentro de esa carpeta, crea la plantilla de React con TypeScript:

npm create vite@latest . -- --template react-ts

El punto indica que los archivos se crearán en la carpeta actual. Este paso se hace una sola vez.

Al terminar, verás los archivos en el explorador de VS Code. src contiene el código de la aplicación; package.json, las dependencias y los comandos disponibles.

Si el asistente de instalación no lo ha hecho ya, instala las dependencias y arranca el servidor, en ese orden:

npm install
npm run dev

Abre la dirección indicada en la terminal, normalmente http://localhost:5173/. Debería aparecer la página de ejemplo. Mantén esa terminal abierta mientras trabajas; puedes detener el servidor con Ctrl+C y arrancarlo otro día con npm run dev.

Ahora instala la extensión oficial de Codex, publicada por OpenAI, desde Extensiones de VS Code, abre su panel e inicia sesión. Mantén abierta la carpeta completa del ejercicio.

Antes de seguir: comprueba que ves los archivos, que la página carga en el navegador y que Codex puede inspeccionar ese mismo proyecto. Más adelante integraremos shadcn/ui como base de componentes; crear la plantilla no realiza esa integración.

2. Define el proyecto antes de pedir pantallas

El primer encargo a Codex consiste en concretar qué vamos a construir. Dale el objetivo, quién lo utilizará y uno o dos ejemplos de aplicaciones en las que quieras reutilizar el sistema. Adjunta también la paleta y la referencia visual: nombrarlas en el chat no permite consultarlas.

Pídele que inspeccione lo que ya existe, distinga tus decisiones de sus recomendaciones y resuelva las dudas en pequeñas rondas. En esta fase queremos una propuesta, así que delimita el trabajo a leer, preguntar y documentar.

En nuestro ejemplo aparecen preguntas sobre los usuarios, la tecnología y las referencias. A partir de ahí concretamos la primera entrega con Button y dejamos para después otras ampliaciones. También aclaramos el orden: preparar el arnés antes de construir.

Revisa que la propuesta incluya objetivo, tecnología, organización de archivos, identidad visual, alcance inicial y criterios de aceptación. Las decisiones provisionales deben seguir marcadas como provisionales: una sugerencia de tipografía o de color no se convierte en una decisión tuya por aparecer en la respuesta.

Cuando estés conforme, pide que guarde lo aprobado en docs/project-definition.md y abre el archivo para revisarlo.

La salida de esta etapa es un documento que puedas volver a consultar. Ahí debe quedar claro qué se construirá primero y qué condiciones tendrá que cumplir.

3. Haz que una conversación nueva pueda orientarse

La definición recoge qué queremos construir. Ahora vamos a documentar cómo trabajar en ese proyecto.

Encarga a Codex que lea la definición, revise las instrucciones existentes y prepare AGENTS.md en la raíz. Este archivo debe señalar dónde está la definición y recoger reglas breves: respetar el alcance, reutilizar componentes y tokens, conservar los cambios existentes y comprobar cada entrega según su naturaleza.

Los tokens son valores compartidos, como colores, espacios o radios de borde. Tenerlos centralizados permite aplicar un mismo criterio a todas las piezas.

Comprueba que los comandos citados coinciden con los disponibles en package.json. Evita copiar toda la definición dentro de las instrucciones: mantener dos versiones de la misma decisión acaba generando contradicciones.

Para probarlo, abre una conversación nueva de Codex en la misma carpeta. Sin pegar el historial, pide una lectura del contexto: qué instrucciones tiene activas, cuál es la primera entrega aprobada y qué decisiones siguen pendientes. Limita esa prueba a consultar y resumir.

Compara la respuesta con los documentos. En nuestro caso debía reconocer Button, sus dos variantes, el catálogo mínimo y los pendientes visuales. Si el resumen no encaja, revisa la carpeta abierta, el nombre exacto de AGENTS.md y si existen otras instrucciones que lo sustituyan.

Lo que estamos comprobando es que puede recuperar el contexto guardado. Conviene repetir esa comprobación cuando cambien de forma relevante las reglas del proyecto.

4. Convierte la construcción en un procedimiento repetible

Ya tenemos reglas generales. La siguiente pieza será una skill: un procedimiento para una tarea concreta. En este caso, añadir o modificar componentes del sistema y sus ejemplos en el catálogo.

La llamamos design-system-component y la guardamos en .agents/skills/design-system-component/SKILL.md. Su descripción debe explicar cuándo utilizarla; el cuerpo, qué consultar, qué pasos seguir y qué entregar.

Al encargarla, incluye este recorrido:

1. Leer la definición y delimitar el componente solicitado.

2. Inspeccionar la infraestructura y distinguir lo instalado de lo previsto.

3. Reutilizar tokens y componentes existentes.

4. Implementar únicamente el alcance encargado y preparar ejemplos reales.

5. Comprobar variantes y estados afectados, y registrar resultados para la revisión.

La primera prueba puede ser de planificación: pide que aplique la skill a Button, identifique requisitos previos, proponga los archivos que tocaría y describa las comprobaciones. Todavía sin modificar nada.

Debería detectar si faltan shadcn/ui, los estilos, los tokens, las exportaciones o la estructura del catálogo. También debe conservar las dos variantes aprobadas y señalar las decisiones visuales pendientes.

Revisa el plan y resuelve esas decisiones. Después encarga la preparación técnica necesaria: integrar la base elegida, configurar los estilos y organizar el sistema y el catálogo. Comprueba que el proyecto sigue arrancando antes de pedir la implementación de Button.

Al construirlo, pide una única implementación reutilizable y ejemplos que la consuman. El catálogo inicial del ejercicio quedó así:

La separación también se ve en los archivos: el componente vive dentro del sistema de diseño y el catálogo se encarga de mostrarlo.

En su página podemos comparar las variantes principal y secundaria, activar el botón y revisar sus estados normal, hover, foco, pulsado y deshabilitado.

Compruébalo también con el teclado: llega al botón con Tab, verifica que el foco sea visible y pruébalo con Enter o Espacio. Al deshabilitarlo, no debería ejecutar la acción. Acompaña la revisión visual con las comprobaciones técnicas que el proyecto tenga disponibles.

5. Prepara una revisión separada

Con el primer componente construido, necesitamos contrastarlo con lo que habíamos definido. Para ello creamos design-system-review en .agents/skills/design-system-review/SKILL.md.

Esta skill debe guiar la inspección del código, el comportamiento del catálogo y la accesibilidad dentro del alcance del encargo. Cada incidencia tiene que explicar el problema, su impacto, dónde ocurre y qué evidencia lo demuestra. Conviene distinguir errores, mejoras opcionales y comprobaciones pendientes.

Prueba la revisión en una sesión nueva, separada de la construcción. Puedes pedir que evalúe Button y el catálogo sin mencionar la skill, y observar si la selecciona. Si no lo hace, revisa la descripción de activación y repite la prueba.

El revisor debe obtener sus propias evidencias. Guarda el informe separado de la entrega del constructor, lee los hallazgos y encarga después las correcciones necesarias. Una skill describe un procedimiento; para una revisión independiente también hace falta separar quién construye de quién revisa.

La decisión visual final sigue siendo tuya: que algo compile no confirma que respete la identidad que querías.

6. Conecta las piezas y pide una pantalla completa

El siguiente paso es que el agente principal pueda coordinar ese recorrido cuando le pidas una pantalla. Primero consulta el sistema, identifica qué puede reutilizar y encarga al constructor las piezas que faltan. Después pasa la entrega a un revisor separado, gestiona las correcciones e integra el resultado.

En el proyecto del ejemplo documentamos dos roles en .codex/agents/: ds-component-builder.toml y ds-component-reviewer.toml. Cada uno referencia su skill. Las reglas de coordinación quedan en AGENTS.md.

Esas reglas delimitan los encargos, evitan que dos agentes escriban en los mismos archivos a la vez y establecen la secuencia construcción → revisión → corrección → integración. En nuestro ejercicio fijamos hasta dos rondas de corrección; si queda un problema, el principal debe explicarlo con evidencia y proponer el siguiente paso.

Crear los archivos no demuestra que la delegación funcione. Abre una sesión nueva, comprueba que el cliente reconoce los roles y prueba el recorrido con un encargo pequeño pero completo.

El nuestro fue una pantalla de solicitudes con búsqueda por asunto, filtro por estado y tabla, usando datos ficticios locales. Debía aparecer como ejemplo del catálogo, con su propio enlace. Al pedirla, no mencionamos las skills ni repartimos manualmente el trabajo: queríamos observar cómo se aplicaban las reglas guardadas.

A continuación entra el revisor. En la captura explica que obtendrá evidencias propias y que está comprobando filtros, navegación, foco y presentación móvil.

El seguimiento permite ver la intervención de ambos roles y las comprobaciones que se van comunicando. Para dar la entrega por buena, contrasta ese informe con la pantalla y con las evidencias guardadas.

El catálogo crece con las piezas necesarias para esa pantalla. En el resultado aparecen Input, NativeSelect y Table, además de Button.

La pantalla de solicitudes combina esas piezas. El botón de limpiar filtros reutiliza el botón secundario que ya habíamos definido.

Para comprobar la entrega, busca un asunto, combina la búsqueda con un estado y limpia los filtros. Prueba también una combinación sin resultados, recorre los controles con el teclado y revisa una pantalla estrecha. La tabla debe poder desplazarse sin ensanchar toda la página. Finalmente, comprueba que el ejemplo tenga enlace y que su dirección abra correctamente.

7. Comprueba que podrás reutilizarlo de verdad

La reutilización debe verse también en el código. En este proyecto, el sistema concentra tokens y componentes en src/design-system/ y los expone desde un punto de entrada común. El catálogo los importa; los datos y la lógica de solicitudes quedan en la aplicación.

Cuando añadas otra pantalla, empieza por consultar lo que ya existe. Si necesita una pieza nueva, repite el circuito: requisitos, construcción, revisión, integración y comprobación. Si cambia una pieza compartida, revisa también los lugares que la utilizan.

Para llevarlo a otro proyecto, conserva los componentes, sus estilos, tokens y dependencias, y adapta las instrucciones a la nueva aplicación. La publicación como paquete o la sincronización entre repositorios será una decisión posterior; este ejercicio deja preparada la separación que permitirá abordarla.

Al terminar tienes un catálogo que puedes abrir, componentes que puedes probar y decisiones que una nueva sesión puede consultar. La siguiente pantalla ya tendrá una base sobre la que trabajar.

🛠️ ¿Quieres crear tu propio sistema de diseño?

Si te apetece montar algo parecido para tus aplicaciones, he preparado un curso paso a paso para crear tu sistema de diseño con Codex, acompañado de los prompts que necesitas en cada fase.

Empezaremos definiendo el proyecto y preparando las instrucciones para Codex. Después construiremos los componentes y su catálogo, crearemos las skills de construcción y revisión y configuraremos los dos agentes para que puedan trabajar de forma coordinada.

Además de los prompts, tendrás las explicaciones para utilizarlos, qué resultados esperar y cómo comprobar que cada parte funciona. También encontrarás un ejemplo resuelto y una plantilla para preparar el contexto de tu proyecto.

La idea es que puedas seguir el proceso con tu propia aplicación, sin tener que preparar todas las instrucciones desde cero.

¿Y tú, cómo estás trabajando con tus agentes?

Yo he empezado por un sistema de diseño porque quería dejar de corregir los mismos detalles visuales cada vez que añadía una pantalla. Pero preparar este pequeño equipo también me ha servido para pensar en qué tareas quiero que intervenga cada agente y qué necesito comprobar antes de dar algo por terminado.

Suscríbete a Think&Hack

Tools are great. Systems are better.

Si te gusta probar la IA y entender cómo puedes aprovecharla en tu trabajo, suscríbete a Think&Hack. Por aquí comparto lo que voy aprendiendo, mis experimentos y cómo puedes probarlos tú. :)

Suscríbete ahora

¿Cómo estás?
Soy Aina y esto es Think&Hack.

Hace unos días vimos cómo montar un proceso dentro de Work mediante skills como dejarlo programado para que se ejecute solo una vez a la semana. Hoy quiero seguir por ahí y enseñarte a crear una skill con algo que seguramente tienes de sobra: contenido de otras personas que te has guardado para aprender a hacer algo.

Un vídeo, una guía, un PDF… Ese tipo de cosas que ves y piensas: “Esto me vendría muy bien para mi trabajo”, pero que se queda ahí, en tu wiki, en tu pc, en tus marcadores… vete a saber dónde.

Pues vamos a coger uno de esos recursos, pedirle a Work que lo analice y convertir lo que nos interese en unas instrucciones que podamos utilizar en otros chats, sin tener que pasarle el material y explicarle lo mismo cada vez.

En mi caso, he elegido un vídeo sobre cómo preparar anuncios y he creado una skill para aplicar ese método a mi curso sobre agentes de IA. Ahora te enseño cómo.

🚨 ChatGPT avisa: toca migrar tus GPT personalizados

Si tienes GPT personalizados en ChatGPT, esos asistentes que configurábamos para repetir tareas sin escribir cada vez las mismas instrucciones, puede que ya te haya saltado este aviso:

Los GPT personalizados dejarán de estar disponibles el 11 de diciembre de 2026. OpenAI ofrece migrarlos a complementos para conservar sus instrucciones y los documentos que habíamos subido.

Puedes empezar desde «Migrar a un complemento». Las instrucciones de tu GPT se convierten en una skill y los documentos pasan a ser archivos de referencia.

Pero ojo: migrarlo no garantiza que funcione exactamente igual. Después toca probarlo y revisar cómo compartirlo de nuevo, si otras personas lo utilizaban. Si tenía acciones personalizadas para conectarse a otros servicios, esas conexiones hay que reconstruirlas. Aquí tienes la guía de OpenAI.

Y aquí viene el lío: ¿una skill y un complemento son lo mismo?

Skills/habilidades, complementos… ¿Estamos hablando de lo mismo?

Skill significa habilidad. Plugin significa complemento. Pero una habilidad y un complemento son cosas distintas.

Una skill guarda las instrucciones para hacer una tarea: qué información necesita, qué pasos debe seguir y cómo queremos que entregue el resultado. También puede incluir ejemplos, plantillas, scripts y otros archivos que utilice para trabajar.

Un complemento es un paquete que puedes instalar y compartir. Dentro puede haber una o varias skills y conexiones con herramientas externas.

Piensa en el proceso de la semana pasada: teníamos una skill para recuperar las newsletters, otra para sacar ideas, otra para redactar Notes y una que coordinaba los pasos. Podríamos reunirlas en un complemento para que otra persona las instalara juntas, en lugar de tener que crear cada una por separado.

Y si el proceso necesitara consultar o guardar información en otro servicio, el complemento también podría incluir esa conexión.

Hoy vamos a coger un vídeo que explica cómo preparar anuncios y convertir ese método en una skill. Así, cuando quieras promocionar algo, podrás pedirle que lo aplique sin tener que volver a pasarle el vídeo ni explicárselo todo otra vez. :)

Cómo convertir un tutorial en una habilidad.

El vídeo que he elegido explica cómo preparar anuncios por piezas: los hooks, esos arranques que intentan captar la atención; el cuerpo, donde desarrollas lo que quieres contar; y la llamada a la acción.

La propuesta es preparar 50 arranques, entre 3 y 5 cuerpos y entre 1 y 3 llamadas a la acción. Después grabas las piezas y combinas las que tengan sentido juntas.

No se trata de grabar cientos de anuncios completos. Ni de mezclarlo todo porque sí: el cuerpo tiene que desarrollar lo que promete el arranque, y el cierre tiene que encajar.

Eso es lo que quiero convertir en una skill.

*🎬 Este vídeo forma parte de un proyecto de edición con IA que estoy probando. La voz está optimizada con IA y los cortes y el montaje también se han generado con ella. Son las primeras pruebas: hay algunas incoherencias y cortes un poco raros. Te lo comparto tal como va saliendo. :)

En el vídeo puedes ver el proceso. Te dejo también los pasos y unos prompts más ordenados que mis peticiones dictadas, para que puedas probarlo con tu propio material. :)

1. Primero, que entienda el material.

Abro un chat en Work, adjunto el vídeo y le pido que analice tanto lo que se dice como lo que aparece en pantalla:

Analiza este vídeo para extraer su método. Revisa la voz, los textos en pantalla y los ejemplos. Guarda unas notas con los pasos importantes y separa lo que muestra el vídeo de tus interpretaciones. Dime qué partes no has podido revisar.

2. Ahora, que lo convierta en una habilidad.

En el mismo chat le explico para qué quiero reutilizar ese método:

La habilidad que salió se llama Anuncios modulares 50–5–3.

No estamos entrenando un modelo nuevo: estamos guardando un procedimiento. Por eso le pido que incluya el material que necesita. No doy por hecho que todo lo hablado en este chat estará disponible cuando la use en otro.

3. Vamos a probarla en otro chat

Abro una conversación nueva en Work, escribo @ y selecciono Anuncios modulares 50–5–3.

Esta vez voy a utilizarla para preparar anuncios de mi curso sobre agentes autónomos de IA. Adjunto el contenido que explica la idea del curso y le pido:

Me devuelve los arranques, los cuerpos, las llamadas a la acción y propuestas para combinarlos. También señala qué información falta y qué promesas no podemos hacer con lo que le he dado.

En el vídeo te enseño el resultado para que veas cómo ha aplicado el método a mi contenido.

4. ¿Y si quiero cambiar algo?

Antes de seguir utilizándola, quiero revisar qué instrucciones ha guardado. Entro en logo de complementos, voy a Habilidades, selecciono la skill y pulso Editar.

Aquí puedo cambiar el nombre, la descripción y las instrucciones. Pero lo que me interesa comprobar es si ha recogido bien el método del vídeo: qué pasos debe seguir, qué información necesita y qué tiene que preguntarme si no se la doy.

Ahora te toca a ti rescatar algo de tus marcadores :)

Seguro que tienes algún vídeo o alguna guía guardada porque explica muy bien algo que te gustaría hacer. Pues ahora puedes probar a convertir ese método en una skill y utilizarla con tu propio trabajo.

Eso sí, mira qué instrucciones ha guardado y qué hace cuando le pasas tu contenido. Igual hay que ajustar cosas. En mi caso, ya tengo una primera propuesta de anuncios para el curso; ahora me toca revisarlos y decidir cuáles quiero probar. :)

Suscríbete a Think&Hack

Tools are great. Systems are better.

Si te gusta probar la IA y entender cómo puedes aprovecharla en tu trabajo, suscríbete a Think&Hack. Por aquí comparto lo que voy aprendiendo, mis experimentos y cómo puedes probarlos tú. :)

Suscríbete ahora

¿Cómo estás?

Soy Aina y esto es Think&Hack.

Ayer me tiré de cabeza a probar un modelo de IA y acabé pensando qué características tiene que tener una comida para considerarse un sándwich.

Sí, ese fue mi rato de investigación del día. :)

Este nuevo modelo es Jev, de TypeSafe, y está pensado para clasificar y evaluar información. Curioso, ¿no?, pero, ¿qué tiene esto de interesante si ya lo puedes hacer con cualquier modelo?

Básicamente, porque lo presentan como un LLM con el cual NO puedes chatear, es muy rápido y muy, muy barato.

Con esa promesa de ahorrar tiempo y dinero, me puse a leer su documentación y a trastear con su playground. Uno de los ejercicios era decidir si algo es un sándwich o no. Parece fácil, pero ¿tú considerarías un perrito caliente un sándwich?

Vale, pero ¿qué estamos llamando sándwich?

En el playground de Jev, la página donde puedes probar el modelo, hay un ejercicio que consiste en decidir si una comida es un sándwich. Parece fácil, ¿no? Pan, algo de relleno… Pero entonces aparece un perrito caliente. ¿Lo consideramos como sándwich? ¿O el pan tiene que estar separado en dos piezas para ser un sándwich? 😥

Aquí es donde el trabajo se complica si queremos tener buenos resultados a la hora de clasificar: si al definir qué es un sándwich decimos que tiene que llevar un relleno entre dos trozos de pan separados, el hot dog quedaría fuera. En cambio, si aceptamos que el pan siga unido por un lado, entonces sí lo consideraríamos un sándwich.

Con la documentación leída y el ejemplo elegido, quise ir un poco más allá: ¿merece la pena pararse a pensar qué consideramos un sándwich y describir los alimentos que le damos al modelo?

¿Notará Jev que me he currado el contexto?

Elegí cuatro alimentos para poner a prueba a Jev: un perrito caliente, un taco, un burrito y un calzone.

De cada uno preparé dos versiones:

• Solo el nombre: «hot dog».

• El nombre y una descripción: «hot dog: una salchicha dentro de un pan parcialmente cortado, cuyos lados siguen unidos».

Quiero comprobar si Jev responde lo mismo cuando le pongo «hot dog» que cuando le cuento cómo está hecho.

En ambos casos le doy la misma definición de sándwich. Así comparo las respuestas sin cambiar también las reglas a mitad de la prueba.

Cuando solo le pongo “hot dog”, Jev da un 55 % de probabilidad de que sea un sándwich, lo que viene siendo un: puede que sí, puede que no. Pero cuando le defino qué es un perrito caliente, esa probabilidad sube al 84 %: con esa información, el modelo se inclina mucho más por decir que sí, que es un sándwich.

Con el perrito caliente y el calzone hay más dudas: uno lleva el relleno dentro de un pan abierto por un lado y el otro dentro de una masa cerrada. Según cómo definamos un sándwich, podemos considerarlos sándwiches o no. Al describir cómo están hechos, además de explicarle qué entendemos por sándwich, le damos más información para aplicar ese criterio sin depender tanto de lo que el modelo interprete solo por el nombre.

Y esto me lleva a algo de lo que hemos hablado varias veces: le pedimos a la IA que haga un trabajo dando por hecho que entiende lo mismo que nosotros. Pero una cosa es que conozca la palabra y otra que sepa qué queremos decir con ella en nuestro caso, en qué detalles nos fijamos y por qué tomamos una decisión y no otra.

Todo eso lo tenemos en la cabeza, pero ¿se lo hemos explicado?

Y por eso me he acordado de Juan y de todo lo que sabía después de quince años en la empresa, pero nunca había escrito. Lo que para él era obvio por experiencia, había que documentarlo para que otros pudieran utilizarlo. Con la IA nos toca hacer ese mismo esfuerzo, aunque empecemos por algo tan sencillo como explicar qué entendemos por sándwich.

Y todo esto, ¿es tan rápido y barato como prometen?

Que me haya puesto a pensar en sándwiches no significa que me haya olvidado de por qué entré a probarlo. Jev promete hacer estas tareas rápido y barato.

Para comprobarlo, he pasado el mismo ejercicio a Jev y a GPT-5.5, con las mismas preguntas y criterios. Vamos a ver qué pasa con nuestro ejemplo.

La diferencia se ve enseguida:

En esta ejecución, GPT-5.5 ha tardado casi 19 veces más y el coste estimado ha sido unas 354 veces mayor. Lo he utilizado con razonamiento medio, así que estos números corresponden a esa configuración y a esta prueba.

Para hacernos una idea del coste: repetir mil veces esta misma consulta, con el mismo consumo, supondría unos 0,06 dólares con Jev frente a 22,68 dólares con GPT-5.5.

Pero para aprovecharlo tenemos que hacer el trabajo que hemos visto antes: tener claro qué queremos clasificar, definir las categorías y describir los elementos que le vamos a pasar. Qué significa cada categoría, qué condiciones debe cumplir algo para pertenecer a ella y qué información necesita el modelo para distinguir unas de otras.

Pero además del tiempo y el coste, fíjate en cómo cambia la respuesta según lo que le contamos. Solo con el nombre, Jev da un 54 % de probabilidad de que el perrito caliente sea un sándwich; cuando le explicamos cómo está hecho, sube al 81 %. No significa que haya acertado más, pero sí que un detalle que nosotros damos por supuesto puede cambiar su valoración.

Si queremos que clasifique según nuestro criterio, tenemos que explicar tanto las categorías como lo que le estamos pidiendo que clasifique. Aunque a nosotros nos parezca obvio.

¿Y para qué utilizaría algo así?

No solo he estado probando cómo clasifica Jev en diferentes casos de uso, sino que también he recorrido medio YouTube y Reddit para ver qué está haciendo la gente con él. Lleva apenas una semana en el mercado, así que lo que he encontrado son experimentos y primeras pruebas como estas:

• Ponerlo a comprar y vender. Hay quien ha conectado Jev a datos de precios para que decida si comprar o vender. Y yo ya estoy pensando en llevarlo a la segunda mano… Wallapop, calienta que sales. :) 💵💵

• Que elija dónde hacer clic en una web. Le dan información sobre la página y una lista de elementos con los que puede interactuar. Jev elige el botón o el campo y el programa hace el clic o escribe. Si la respuesta no es suficientemente clara, le pasan el trabajo a otro modelo. ¿Útil?

• Revisar lo que otro agente quiere ejecutar en la terminal. Antes de ejecutar un comando, Jev comprueba si podría hacer algo peligroso o necesitar autorización. Me interesa esta prueba porque, cuando un agente encadena muchas acciones, también importa cuánto tarda en revisar cada una. ¡Todo es probar!

• Recurrir al modelo caro solo cuando haga falta. Primero responde Jev y, cuando su nivel de confianza es bajo, se utiliza la respuesta de un modelo más potente. Hay que hacer algún test para ver si funciona y así reducir costes. Interesante.

• Ponerlo a jugar a Doom. Le pasan el estado del juego convertido a datos y Jev elige qué hacer unas diez veces por segundo. No está viendo la pantalla: alguien ha preparado la información que recibe para que pueda decidir su siguiente movimiento. El otro día, mi compi de trabajo me comentó que hay gente que paga para que sigan jugando en sus cuentas mientras ellos curran .. Esto da para otro post).

Yo, de momento, ya tengo unas cuantas ideas para seguir probando. Quiero ver si puedo aprovechar Jev en alguno de los procesos que ya tengo montados y si lo que ahorro en tiempo y coste compensa lo que tenga que revisar después. Ya te contaré.

P.D. En noviembre vuelvo a dar clase en The Bridge, esta vez dentro del Máster de IA Generativa Avanzada.

Y me apetecía contarlo porque no es una colaboración que haya aceptado “porque sí”.

Antes de verano di con ellos dos sesiones sobre Claude Code y salí bastante sorprendida. Dar clase online muchas veces tiene una barrera rara: tú hablas, ves cámaras apagadas y cuesta saber si al otro lado realmente está pasando algo.

Aquí fue distinto.

La propia dinámica de la escuela hacía que la gente participara, preguntara y se metiera de verdad en la clase. Y, sobre todo, noté que los alumnos ya tenían suficiente base como para que no sonara a chino hablar de cosas como agentes, memoria, contexto, verificación o cómo llevar IA a procesos reales.

Eso, como profesora, se agradece muchísimo.

Así que cuando me propusieron volver para esta nueva edición, me hizo bastante ilusión.

Esta vez voy a trabajar precisamente en la parte que más me interesa: cómo pasar de usar herramientas de IA a diseñar sistemas de trabajo con criterio, control y capacidad real de llevarlos a producción.

Si te apetece profundizar por ahí, te dejo el programa:

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.

Llevo meses hablando de agentes de IA.

Que si Claude Code por aquí, que si Codex por allá. Que si ahora le doy acceso a una carpeta, le preparo unas instrucciones y dejo que haga el trabajo.

Y sé que muchos me leéis y pensáis: «Esto tiene buena pinta», y ahí se queda la cosa.

Porque una cosa es utilizar ChatGPT y otra bastante distinta abrir una terminal y empezar a trabajar con archivos que se llaman SKILL.md.

Por mucho que me empeñe en decirte que no hace falta ser programador, la terminal sigue pareciendo la terminal y dar el salto cuesta.

Con ChatGPT Work podemos empezar a trabajar con un agente desde la interfaz de ChatGPT. En la práctica de hoy utilizaremos la aplicación de escritorio y una carpeta donde podrá leer y guardar los archivos del ejercicio.

Y para que no tengas que pensar qué demonios hacer con Work la primera vez que lo abras, he preparado un caso con mis newsletters. Vamos a pedirle que recupere la última, encuentre ideas y escriba borradores para Notes, las publicaciones cortas de Substack.

Si no tienes una newsletter, puedes seguir igualmente el ejercicio con la mía. Lo que vamos a aprender te servirá para pensar cómo organizar otros trabajos con tus propios documentos.

Vamos desde el principio. :)

¿Qué cambia cuando utilizas Work?

Cuando utilizas ChatGPT, le pides ideas, le pasas un texto para que lo revise, le preguntas algo… y vais iterando en la conversación.

Pero muchas veces eres tú quien va llevando el proceso: ahora lee este artículo, ahora saca cinco ideas, esta no me gusta, esta sí, vuelve al texto porque eso no lo he dicho…

Y cuando quieres repetir el trabajo con otro artículo, te encuentras buscando las instrucciones en una conversación anterior. O explicando otra vez lo mismo.

Con Work vamos a guardar las instrucciones y los archivos que necesita para que podamos volver a pedirle ese trabajo.

Quiero que Work guarde la newsletter, la lea, proponga cinco ideas y convierta tres en borradores. También quiero poder abrir la carpeta y entender qué ha hecho: qué artículo ha utilizado, qué ideas ha elegido y qué ha corregido antes de escribir.

Porque si una Note cuenta algo que yo no he dicho, necesito poder volver a la fuente y ver de dónde ha salido.

Y si un texto no me gusta, quiero poder corregirlo. Si el problema se repite, le pediré que cambie las instrucciones con las que escribe para tenerlo en cuenta la próxima vez.

Qué vamos a construir

Primero vamos a crear un proyecto y darle acceso a una carpeta. Después le pediremos que prepare las skills: una con un programa para recuperar la newsletter y otras con las instrucciones para elegir ideas y escribir. Cuando las tengamos funcionando, las uniremos y veremos cómo programar el trabajo.

Las instrucciones de cada tarea quedarán guardadas en una skill. Por ejemplo, la de redacción tendrá que explicar cómo quiero que escriba, qué debe leer antes y dónde tiene que guardar los borradores. La próxima vez podremos pedirle que utilice esa skill en lugar de volver a explicárselo todo.

Además de instrucciones, una skill puede incluir recursos y pequeños programas. Lo veremos con la primera, que tendrá que descargar la newsletter. Si quieres ampliar esta parte, aquí tienes la documentación oficial de skills.

En nuestro caso vamos a preparar estas cuatro:

• recuperar-newsletters: descarga el artículo completo y lo guarda sin duplicar los que ya tiene.

• ideas-para-notes: lee el artículo y propone cinco ideas, explicando por qué merece la pena desarrollarlas y de qué parte del texto salen.

• redactar-notes: escribe tres borradores a partir del artículo y de las ideas que hemos revisado.

• flujo-newsletter: se encarga de que Work haga todo lo anterior en orden.

Cuatro skills pueden parecer muchas para sacar tres Notes. Pero piensa en lo que pasa cuando corriges un texto.

Si la apertura no te gusta, quieres cambiar la apertura. No necesitas descargar otra vez la newsletter ni empezar a explicarle todo desde el principio. Separar las instrucciones nos permite ajustar la parte que está fallando y conservar el trabajo que ya nos sirve.

Work irá utilizando las cuatro skills según la tarea que le toque hacer. Sigue siendo el mismo agente trabajando con distintas instrucciones.

He elegido cinco ideas y tres borradores para tener margen de selección. Puedes pedir otras cantidades cuando lo adaptes a tu caso.

1. Vamos a darle una carpeta

Para hacer el ejercicio necesitas tener Work disponible en tu cuenta y utilizar la aplicación de escritorio, porque vamos a trabajar con una carpeta de tu ordenador.

Crea una carpeta vacía con el explorador de archivos. Puedes llamarla tutorial-newsletter.

Abre la aplicación de ChatGPT, entra en Work y busca Choose project. Desde ahí puedes crear un proyecto con New project y Create project. Llámalo Tutorial Work Newsletters Local, que es el nombre que utilizaremos en los prompts.

En Choose source folders, selecciona la carpeta que acabas de crear. El diálogo explica que ChatGPT podrá leer y editar lo que haya dentro. Revisa que has elegido la correcta antes de confirmar Trust folder y el trabajo local con On your computer.

Ahora vamos a organizar la carpeta. Donde veas [CARPETA] en los prompts, pon la ruta de la que acabas de seleccionar. Puedes copiarla desde el explorador de archivos. Utiliza la tuya, aunque en las capturas aparezca otra.

Pega este primer prompt en el chat del proyecto:

Trabaja en local y escribe solo dentro de [CARPETA]. Comprueba la ruta real y crea LEEME.md y los directorios biblioteca/articulos, biblioteca/control y tandas. Explica en el LEEME que biblioteca conserva las fuentes y tandas los resultados de cada ejecución; este tutorial prepara borradores, nunca publica. Confirma la ruta real, enumera lo creado y muestra el contenido de LEEME.md tras leerlo del disco.

La biblioteca guardará los artículos. Dentro de tandas quedarán las ideas, la revisión y los borradores de cada trabajo, juntos en una carpeta. Así podremos volver a ellos sin mezclarlos con los de la semana siguiente.

El archivo LEEME.md explica la organización. La extensión .md indica que es un archivo de texto en Markdown, un formato que permite escribir títulos, listas o enlaces sin necesitar un documento de Word.

Abre el archivo y busca las carpetas que acaba de crear. Si solo te ha explicado cómo las organizaría, pídele que las cree. Vamos a necesitarlas en el siguiente paso.

2. Que lea la newsletter entera

Quiero que lea la newsletter entera antes de proponer nada. Si le damos solo un extracto, puede quedarse con una idea y perderse justo el párrafo en el que explico sus límites.

Esta primera skill va a incluir un script, un pequeño programa guardado que se encargará de consultar la publicación, recuperar el artículo y reconocer si ya lo había descargado.

En el prompt verás la palabra determinista. Significa que le pedimos al programa que siga unas reglas concretas: consultar la publicación, descargar el artículo y guardarlo. Work se encargará después de leerlo y decidir qué ideas propone.

El programa se lo vamos a pedir a Work. Para crear la skill utilizaremos skill-creator, que le ayuda a preparar y guardar sus instrucciones.

En el mismo chat, envía este prompt:

Usa skill-creator para crear e instalar una skill invocable recuperar-newsletters, limitada a este proyecto local. Comprueba cómo se registran realmente las skills en Work; no basta exportar un SKILL.md. Escribe solo dentro de [CARPETA]; si instalar requiere otra ruta, informa antes de escribir.

Su función es reunir fuentes, no proponer ideas ni redactar Notes. Crea un script determinista persistente, scripts/recuperar.py dentro de la skill, para mi sistema operativo y carpeta. Debe recuperar solo la newsletter pública más reciente de https://ainalluna.substack.com, no las Notes, con límites de tiempo y peticiones, sin credenciales ni datos de suscriptores.

Guarda título, URL canónica, fecha y texto en biblioteca/articulos; manifiesto e informe de disponibilidad en biblioteca/control. Distingue texto completo de extracto y falla honestamente si no hay contenido. Reutiliza publicaciones descargadas válidas sin duplicarlas. Ejecuta la primera recuperación y muestra el resultado leído del disco, la ruta del script y cómo invocar la skill. No crees aún las otras skills. No solicites acceso global ni reglas persistentes.

Fíjate en que le pedimos la última newsletter pública. Con una nos basta para hacer el ejercicio. También queremos el título, la fecha y el enlace, para poder volver al artículo cuando revisemos las ideas.

Además guardará un manifiesto: un archivo donde apunta qué artículo tiene y en qué estado está. Más adelante lo utilizará para reconocer cuáles ha procesado ya.

Cuando termine, abre el artículo que haya guardado. Vamos a ver qué ha recuperado.

Revisa el principio y el final del artículo. Si ha guardado un extracto, pídele que consiga el texto completo antes de pasar a las ideas.

Ahora vamos a pedirle que lo haga otra vez. Quiero que reconozca el artículo que ya tiene, en lugar de crear otra copia. Escribe @recuperar-newsletters, selecciona la skill y añade:

Ejecuta la skill instalada para comprobar la fuente pública una segunda vez y demostrar reutilización sin duplicados. Conserva toda la evidencia. Muestra URL canónica, rutas del artículo, script, manifiesto e informe, estado antes y después, y fragmentos inicial y final leídos del artículo. Confirma si Work ha cargado la skill como tal; no confundas esa carga con leer manualmente su archivo.

Al repetirlo, Work reutilizó el artículo guardado y no creó otra copia.

Si no puede consultar la publicación, tendrá que decírtelo. Puede conservar el artículo anterior, pero necesita mirar si hay otro nuevo antes de afirmar que sigue siendo el último.

Antes de avanzar, apunta los nombres que te haya devuelto Work. Los vamos a utilizar en los siguientes prompts:

• [ID_ARTICULO] es el identificador del artículo guardado. El de esta newsletter es 215931068.

• [TANDA_PRACTICA] será el nombre de la carpeta donde guarde las primeras ideas. En las capturas verás ideas-para-notes-001.

• [TANDA_FLUJO] será la carpeta del trabajo completo que prepararemos después. En las capturas verás flujo-newsletter-001.

Los dos últimos aparecerán cuando hagamos esos pasos. Sustituye cada marcador por el nombre que tengas tú, sin los corchetes. Si no sabes cuál es, pídele a Work que te muestre la carpeta donde acaba de guardar el trabajo.

3. Elegir las ideas antes de ponerse a escribir

Con el artículo guardado, ya podemos pedirle que encuentre posibles Notes.

Pero quiero saber algo más que el título de cada propuesta. ¿Qué va a entender el lector al leerla? ¿Qué parte de la newsletter permite contar eso? ¿Está recuperando algo que expliqué o está proponiendo una aplicación nueva?

Vamos a guardar esos criterios en la segunda skill.

Crea con skill-creator la skill local invocable ideas-para-notes dentro de este proyecto, sin modificar recuperar-newsletters ni descargar otra vez el artículo. Una Note es una publicación corta en Substack. Esta etapa solo elige enfoques: lee la fuente completa guardada y propone cinco ideas distintas, cada una con URL, fragmento de respaldo localizado, hecho de la fuente, inferencia editorial, aprendizaje y motivo para desarrollarla. Distingue hechos, inferencias y propuestas; rechaza ideas sin apoyo.

Guarda instrucciones reutilizables y comprueba su detección real en Work. Para esta práctica, ejecuta la selección sobre la fuente [ID_ARTICULO] y guarda ideas.md en una carpeta nueva de tandas. Conserva resultados anteriores. No redactes Notes, publiques ni programes. Mantén las escrituras dentro de [CARPETA].

Work preparó cinco ideas y las guardó en ideas.md, dentro de una carpeta nueva en tandas. Si estás siguiendo el ejercicio, ese nombre es el que sustituirá a [TANDA_PRACTICA].

Una de las ideas que propone es que las recomendaciones expliquen qué podemos hacer con ellas. Es algo que cuento en la newsletter: a Hacki le pido que me diga por qué una lectura me puede interesar y qué podría hacer a partir de ella.

De ahí podemos sacar una Note que ayude al lector a revisar sus propias recomendaciones. Pero no podemos prometerle que hacerlo va a aumentar sus suscripciones, porque yo no he demostrado eso en el artículo.

Vamos a revisar las cinco propuestas antes de redactar. Escribe @ideas-para-notes y elige la opción de skill.

Añade este prompt:

Confirma si recibes las instrucciones adjuntas de la skill, sin confundirlo con leer manualmente su archivo. Revisa las cinco ideas de tandas/[TANDA_PRACTICA]/ideas.md contra biblioteca/articulos/[ID_ARTICULO].json. No crees otra tanda ni descargues nada. Conserva ideas.md y guarda las observaciones en revision.md junto a él. Muestra qué mantendrías, reformularías o descartarías, con respaldo y aprendizaje. No redactes Notes todavía ni publiques.

Le pedimos que guarde las correcciones en revision.md, junto a las ideas originales. Así podremos leer qué propuso primero y qué necesita cambiar antes de escribir.

En el menú Skills de la respuesta puedes comprobar cuál ha utilizado. Si acabas de crearla y no aparece en el selector, cierra y vuelve a abrir la aplicación con el mismo perfil; eso permitió que apareciera en este caso.

Dos correcciones que merece la pena mirar

En la segunda idea, Work propone dejar la utilidad de una recomendación sin evaluar hasta haberla leído. Tiene sentido: puedo tener un artículo pendiente porque no me ha dado tiempo a abrirlo.

Lo que yo cuento en la newsletter es que registro por separado qué he hecho con una recomendación y si me ha servido. No digo que tenga configurada esa regla concreta.

Podemos desarrollar la idea, pero tendrá que plantearla como algo que se podría hacer. Si la cuenta como una función que ya utilizo, estará añadiendo algo que no he explicado.

La cuarta idea necesita cuidar los números. En la newsletter explico que, entre el 7 y el 13 de septiembre, Think&Hack pasó de 378 a 392 suscriptores: hubo 16 nuevas suscripciones y el crecimiento neto fue de 14 suscriptores.

Después comparo las Notes publicadas entre el 17 de agosto y el 15 de septiembre, con datos al día 16: tres suscripciones atribuidas a Notes de Hacki y dos a las mías.

Si juntamos esas cifras sin explicar las fechas, podemos acabar contando que las cinco suscripciones atribuidas a Notes forman parte de las altas de esa semana. Y no es eso lo que dicen los datos. Cuando escriba la Note tendrá que conservar los períodos y distinguir mis publicaciones de las de Hacki.

Por eso quería revisar las ideas antes de escribir. Ahora podemos pasarle esas correcciones a la skill de redacción.

Y si quieres que la skill de ideas tenga en cuenta esos criterios la próxima vez, puedes pedirle que los incorpore a sus instrucciones:

Conserva una copia de las instrucciones actuales de ideas-para-notes antes de ajustarlas. Añade que una regla de valoración no confirmada por el artículo debe aparecer como propuesta, y que cada cifra debe conservar su período y fecha de corte. No conviertas atribución en causalidad. No sobrescribas ideas.md ni revision.md: la revisión debe permitir entender qué cambió. Muestra el cambio de instrucciones y comprueba que mantiene el objetivo de la skill.

Este paso es opcional y te lo dejo como ejercicio. Mira qué cambia en las instrucciones y comprueba que conserva la versión anterior. La próxima vez que le pidas ideas podrás revisar si ha aplicado la corrección.

Para continuar ahora, utilizaremos el archivo revision.md que acabamos de guardar.

4. Ahora sí: vamos a escribir las Notes

Tenemos el artículo, cinco ideas y una revisión. Vamos a utilizar las tres cosas.

No quiero que Work escriba mirando únicamente los títulos que acaba de proponer. Necesita volver al artículo y tener delante las correcciones para conservar el contexto.

Primero creamos la skill de redacción:

Usa skill-creator para crear la skill real redactar-notes en .agents/skills/redactar-notes dentro de [CARPETA]. Comprueba la carpeta y las instrucciones existentes; no dupliques una skill si ya existe.

Debe recibir ideas y revision.md de la misma tanda, volver al artículo completo y escribir tres borradores de Notes comprensibles sin leer la newsletter. Basa la voz en el artículo de Aina: sujetos y acciones concretos, sin metáforas de relleno ni experiencias inventadas. Formula propuestas como posibilidades y conserva los límites de cifras, períodos y causalidad dentro del propio borrador.

Aplica las correcciones de la revisión. Conserva los originales y guarda borradores.md junto a ellos, con textos publicables separados de las notas de evidencia. Comprueba su carga real en Work. No redactes todavía: primero creamos la skill y después la invocaremos. Nunca publiques ni programes. Si instalar requiere otra ruta, informa antes de escribir.

Le hemos pedido que guarde los borradores en la misma carpeta que sus ideas y su revisión. Así podremos seguir el recorrido de cada texto sin preguntarnos qué archivos pertenecen a este trabajo.

También hemos separado el texto de la Note de las anotaciones que explican su respaldo. Cuando revise el borrador, podré leerlo como lo vería alguien en Substack y, si tengo una duda, volver al fragmento del artículo que lo sostiene.

Selecciona @redactar-notes. Puede aparecer con el nombre Redactar Notes. Ahora sí, encárgale la redacción:

Redacta tres borradores usando ideas.md y revision.md de tandas/[TANDA_PRACTICA] y el artículo completo asociado. Aplica sus correcciones y guarda borradores.md en esa misma carpeta. Relee el archivo y coteja citas, cifras y períodos. Si falta una entrada o no corresponde a esta tanda, detente y explica qué falta. No publiques.

Aquí tienes el resultado: tres borradores, a partir de las ideas 1, 2 y 4.

Te enseño un fragmento del segundo:

Puedo dejar un artículo sin leer porque esa semana no tengo tiempo. Eso todavía no me dice si la recomendación era útil.

Con Hacki, el agente de IA que me propone lecturas para mi newsletter Think&Hack, puedo registrar dos cosas por separado: qué he hecho con una propuesta y si me ha servido.

Después utiliza «una opción sería» para introducir la idea de dejar la utilidad sin valorar. Fíjate en cómo ha incorporado la corrección: ahora se entiende que está proponiendo una posibilidad.

En el tercer borrador también aparecen los dos períodos de las métricas, con la aclaración de que aquellas suscripciones atribuidas no explican el crecimiento neto de la semana.

Abre tu archivo y lee los textos completos. Las aclaraciones tienen que entenderse al leer la propia Note. El lector de Substack no va a ver nuestras anotaciones.

Ahora me toca decidir si esos textos me sirven, qué quiero cambiar y cuáles publicaría. De momento se quedan como borradores en la carpeta.

5. Vamos a unir las skills

Hasta aquí le hemos ido pidiendo cada tarea por separado. Ya tenemos las instrucciones y sabemos qué archivos deja cada una.

Vamos a crear una skill que coordine todo: recuperar la newsletter, proponer las ideas, revisarlas, redactar y guardar el trabajo. Así la próxima vez podremos pedirle que lo haga seguido.

Hay un detalle que necesitamos explicarle. El artículo ya está descargado y lo hemos utilizado en los pasos anteriores. Ahora queremos probar las skills trabajando juntas y guardar ese resultado por separado.

Cuando termine, dejará apuntado que ha procesado esa newsletter. Ese registro le servirá para no volver a trabajar sobre ella cada vez que le pidamos buscar novedades.

Vamos a crear la skill que se encarga de esa coordinación:

Usa skill-creator para crear flujo-newsletter dentro de [CARPETA]. Lee antes las tres skills existentes y el script de recuperación. Conserva intacta la tanda de práctica.

Coordina recuperación, cinco ideas, revisión de esas ideas por Work contra el artículo, tres borradores y verificación. Usa la biblioteca común y una única carpeta tandas/flujo-newsletter-NNN con fuentes.md, ideas.md, revision.md, borradores.md y resumen.md. La revisión de Work no significa aprobación humana.

Comprueba que ideas acepta el destino de la coordinadora y que redactar consume la revisión de esa misma tanda. Si ajustas instrucciones, conserva sus versiones anteriores y explica el cambio. Work elige y redacta; el código solo recupera, mantiene estado y hace comprobaciones mecánicas.

Descargado no significa procesado: la fuente [ID_ARTICULO] debe alimentar la primera tanda completa. Marca procesada solo tras verificar los cinco resultados. Conserva trabajos previos, reanuda una tanda interrumpida sin duplicarla y no ejecutes dos flujos simultáneos. Después, si la consulta actual no encuentra una newsletter nueva, registra «sin novedades» sin otra tanda ni regreso a artículos antiguos. Un fallo de consulta es error, no ausencia de novedades. Primero crea y verifica la skill; no ejecutes aún, publiques ni programes.

El prompt le pide que lea las skills que ya existen. También permite ajustar cómo se pasan los resultados entre ellas, conservando sus instrucciones anteriores.

La skill de ideas necesita saber en qué carpeta guardar sus propuestas. La de redacción tiene que encontrar allí las ideas y la revisión que le corresponden.

Si no dejamos eso claro, podríamos terminar con ideas en una carpeta y borradores hechos a partir de otra revisión. Por eso le pedimos que compruebe cómo se pasan el trabajo las skills.

Cuando la skill esté creada, selecciona @flujo-newsletter, que puede aparecer como Flujo Newsletter, y envía:

Ejecuta ahora el flujo manual completo con la fuente real inicial [ID_ARTICULO], confirma la carga de instrucciones y verifica los archivos de la tanda. No publiques ni programes.

Al terminar, Work dejó cinco archivos en la misma carpeta: la referencia del artículo, las ideas, la revisión, los borradores y un resumen. Después marcó la newsletter como procesada.

Puede que las ideas cambien respecto a las que propuso antes. Está volviendo a leer y a escribir sobre el mismo artículo. Revisa que conserve su sentido y que los borradores incorporen las correcciones de esta tanda.

¿Y si se lo vuelvo a pedir?

Ahora que ha terminado, vamos a repetirlo.

Quiero comprobar qué hace cuando ya ha procesado la última newsletter. Si cada vez que se lo pido me deja otros tres borradores sobre el mismo artículo, acabaré revisando versiones que no necesitaba.

Utiliza otra vez @flujo-newsletter y añade:

Repite una sola vez el flujo. Comprueba la fuente pública actual y el estado procesado. Si no hay newsletter nueva, registra «sin novedades» en el manifiesto existente sin crear otra tanda ni modificar borradores. Compara antes y después los cinco resultados de [TANDA_FLUJO] y los tres de [TANDA_PRACTICA]. No publiques ni programes. Devuelve el resultado y el enlace al manifiesto.

Esta vez respondió «Sin novedades». Había consultado la publicación y reconocido que ya había trabajado con esa newsletter.

Las carpetas y los textos seguían igual: no creó otra tanda ni cambió los borradores anteriores. Eso es lo que queremos que ocurra cuando no haya un artículo nuevo.

Si no puede consultar la publicación, tendrá que avisar del error. No queremos que confunda «no he podido mirar» con «no hay nada nuevo».

6. Dejarlo programado y comprobar qué pasa

Hasta ahora hemos sido nosotros quienes le hemos pedido que se ponga a trabajar. Vamos a ver cómo dejarle un horario para que empiece.

La skill explica qué tiene que hacer. La tarea programada le da la señal de empezar.

Como va a utilizar archivos de tu ordenador, necesitará que esté encendido y que la aplicación siga abierta a esa hora. Puedes ampliar esta parte en la documentación de tareas programadas.

En Work, abre Scheduled, pulsa Create y prepara estos campos:

• Nombre: Tutorial newsletter a Notes (Think&Hack).

• Runs on: This device, para utilizar este equipo.

• Runs in: el chat donde hemos preparado el flujo, dentro del proyecto local.

• Repeat: Weekly.

• On: Sunday.

• Time: 6:00 PM, las seis de la tarde.

Elige el chat que pertenece a tu carpeta del ejercicio. En este caso queremos continuar el trabajo allí, con el procedimiento que acabamos de preparar.

Comprueba también la zona horaria de la aplicación. Aquí estamos utilizando Europe/Madrid. Como el formulario no muestra un campo para elegirla, pídele a Work que compruebe cuál está usando antes de dar el horario por bueno. Escribir Madrid en el prompt no cambia la configuración.

En el campo de instrucciones, utiliza este texto. Recuerda sustituir [CARPETA] por la tuya; el nombre del proyecto es el que hemos usado desde el primer paso.

Aplica la skill real $flujo-newsletter en el proyecto Tutorial Work Newsletters Local y trabaja exclusivamente en [CARPETA]. Consulta la última newsletter pública de https://ainalluna.substack.com y continúa únicamente si hay una fuente nueva no procesada. Reúne la fuente completa, cinco ideas, revisión de Work, tres borradores y resumen en una sola tanda local; marca procesada solo después de verificar los resultados.

Si no hay novedades, deja constancia sin crear otra tanda ni modificar las anteriores. Invoca la skill existente y sus skills coordinadas; no sustituyas la lógica creativa por un script. Informa aquí del resultado y las rutas locales. Nunca publiques ni envíes mensajes externos. No amplíes permisos persistentes; ante un bloqueo, informa del error exacto y detente. Horario previsto: domingos a las 18:00 Europe/Madrid.

Guárdala y utiliza Run now para probarla en ese momento. No hace falta esperar al domingo para descubrir que le falta algo.

Antes de dejarla funcionando

Al pulsar Run now, el encargo llegó al chat y Work empezó a utilizar la skill. Pero aquí apareció un problema: la aplicación no pudo leer los archivos y pidió permiso para continuar por un fallo de su entorno de ejecución.

La tarea quedó bloqueada. Si necesita que haya alguien delante para autorizar ese paso, todavía no puedo dejarla trabajando sola.

Si te ocurre, utiliza Pause y mira qué ha pasado antes de dejarla activa. En este caso hace falta resolver el problema de la aplicación y volver a probar; cambiar el prompt no basta.

Por ahora puedo pedirle el trabajo desde el chat y revisar los archivos que me devuelve. La parte de dejarlo funcionando por su cuenta queda pendiente. Antes de hacerlo, quiero ver que termina sin pedir intervención y que, cuando publique otra newsletter, prepara sus borradores sin tocar los anteriores.

Si has llegado hasta aquí, ya has visto por dentro varias de las cosas que llevo meses contando cuando hablo de agentes: darles un espacio de trabajo, guardar instrucciones, separar tareas, revisar resultados y preparar una forma de repetirlas.

El ejemplo utiliza newsletters y Notes, pero puedes pensar en otro trabajo que conozcas bien. Un informe que preparas cada semana, documentos que tienes que revisar o apuntes que quieres convertir en material de estudio.

Empieza por algo cuyo resultado puedas evaluar. Así sabrás qué pedirle, cuándo se ha desviado y qué corrección merece quedar guardada para la próxima vez.

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

Hola, soy Aina Lluna y cada semana documento qué ocurre cuando dejas a un agente autónomo de IA trabajando sobre un objetivo real.

Hacki tiene una misión: ayudarme a hacer crecer Think&Hack. Aquí cuento qué hace, qué aprende y qué dicen los datos.

Hasta ahora os he hablado sobre todo de las Notes que prepara. Pero al mirar de dónde vienen las suscripciones, hay algo que merece más atención: más de la mitad de las altas históricas llegan desde Substack, y las recomendaciones de otras publicaciones tienen un peso importante.

Así que parte del trabajo está también en encontrar personas con las que compartir ideas y audiencia, aprender de lo que hacen y ver si podemos colaborar.

Esta semana os cuento cómo estoy trabajando esa parte con Hacki: su radar de oportunidades.

Suscríbete ahora

El radar de oportunidades

Quiero que Hacki me ayude a mirar fuera de Think&Hack. Qué merece la pena leer, a quién debería conocer y en qué conversaciones podría aportar algo.

Porque para colaborar con alguien primero hay que descubrirlo, leer su trabajo y encontrar algo en común. Y dedicar tiempo a eso también puede mejorar lo que escribo, aunque no termine en una suscripción.

El radar busca dentro y fuera de Substack, en distintos idiomas, con tres objetivos:

• Aprender: encontrar ideas, experiencias o métodos que puedan aportarme algo.

• Descubrir creadores: salir de las personas que ya sigo y explorar otros enfoques.

• Relacionarme: encontrar conversaciones, contenido que quiera compartir con vosotros y posibles oportunidades de colaboración.

Pero cada recomendación tiene que justificar por qué merece mi atención y qué propone hacer con ella. Que un artículo mencione «agentes de IA» no es suficiente. De esos ya encuentro unos cuantos yo sola.

Así me llega una propuesta

Aquí Hacki encontró una publicación de Fran Pastor: «Tu harness recuerda errores que el modelo ya no comete».

La idea que recoge es que las reglas y controles que añadimos alrededor de un modelo pueden quedarse desactualizados cuando el modelo cambia.

Esto me toca de cerca: llevo semanas añadiendo instrucciones y correcciones a Hacki. ¿Cuáles seguirán haciendo falta cuando cambie el modelo?

Hay una lectura que puede ayudarme con mi propio sistema y un motivo concreto para conversar con su autor. Hacki explica esa conexión y prepara un posible comentario.

Yo tengo que abrir el artículo, comprobar si el comentario aporta algo y decidir si quiero publicarlo. El radar busca y propone; yo reviso y decido. No comenta ni comparte automáticamente.

Otras veces la propuesta será leer un apartado concreto, seguir explorando el trabajo de alguien o compartir un contenido con vosotros. No todo tiene que acabar en un comentario.

Mi parte: decirle si ha servido.

En la ficha puedo registrar qué he hecho con la propuesta y, por separado, si me ha resultado útil.

Puedo leer un artículo y descubrir que era demasiado básico. También puedo dejar pendiente una buena recomendación porque esa semana no llego. No quiero que Hacki confunda falta de tiempo con falta de interés.

Mis valoraciones deberían ayudarle a ajustar las siguientes búsquedas: más casos prácticos, otra profundidad o más contenido de un creador que me ha interesado.

Y aquí vuelve la pregunta que acompaña todo el experimento: ¿mis correcciones mejoran su trabajo posterior?

Con el radar quiero comprobarlo en las lecturas que aprovecho, las conversaciones que empiezo y las colaboraciones que puedan surgir. Ahí veremos si Hacki me está ayudando a hacer crecer Think&Hack también desde las relaciones con otras personas.

¿Y todo esto sirve para hacer crecer Think&Hack?

Esta semana, del 7 al 13 de septiembre, Think&Hack pasó de 378 a 392 suscriptores. Entraron 16 nuevas suscripciones y el crecimiento neto fue de 14.

La newsletter crece. Ahora toca la parte menos cómoda: separar ese crecimiento de lo que puedo atribuir a Hacki.

De dónde vienen las suscripciones

Este es el histórico de captación de Think&Hack. No corresponde solo a estas semanas del experimento:

Substack concentra el 50,9 % de las altas acumuladas. LinkedIn es la segunda fuente, con el 17,9 %.

Dentro de Substack, Notes es la mayor vía identificada, pero las recomendaciones de otras publicaciones también tienen bastante peso. Mi contenido llega a nuevas personas tanto por lo que publico como por lo que otros recomiendan.

Por eso me interesa que Hacki me ayude a descubrir creadores, leer su trabajo y encontrar oportunidades de compartir contenido o colaborar. Hay una razón detrás del radar: el entorno en el que quiero construir esas relaciones ya es mi principal fuente de suscripciones.

Qué están consiguiendo sus Notes y las mías

Desde que empezó Hacki, comparando las Notes publicadas del 17 de agosto al 15 de septiembre, estos son los resultados:

Hacki aporta constancia, pero mis Notes consiguen más distribución y más conversación por publicación. Su media de impresiones es menor: las mías tienen un 52 % más por pieza.

Ahora bien, al poner las interacciones en relación con las impresiones, la distancia prácticamente desaparece: ambos estamos alrededor de cinco interacciones por cada cien impresiones. Lo que cambia es la respuesta: en mis publicaciones los comentarios tienen más peso.

Esto me interesa porque mirar solo las interacciones por Note dejaba fuera una parte de la explicación: mis publicaciones también se muestran más. ¿Tendrás algo que ver con que las mías no son programadas, si miramos visibilidad?

En captación, Hacki tiene tres suscripciones atribuidas y yo dos. Sus piezas que han convertido son dos educativas y una promocional; las mías, una educativa y una promocional. Todavía son pocos casos para concluir que uno consigue mejores resultados de captación.

¿Qué sabemos de las categorías?

De las 30 Notes de Hacki, 17 son educativas y 8 promocionales. Entre ambas reúnen el 83 % de sus publicaciones y las tres suscripciones identificadas.

Las otras categorías apenas tienen recorrido: dos inspiracionales, dos colaborativas y una de feedback. No ha publicado ninguna personal (normal, daría un poco de yuyu)

Así que la ausencia de suscripciones en esas categorías dice poco todavía. No han tenido el mismo número de oportunidades.

Y mi histórico aporta una pista que no quiero perder:

Mi Note con más suscripciones identificadas es inspiracional: «Automatizar parece caro si miras el precio de la primera vez…», del 8 de junio. Ella sola tiene siete.

Eso no convierte a las inspiracionales en la categoría ganadora. De hecho, buena parte de su resultado se concentra en una única publicación. Pero sí me da una pieza concreta que revisar cuando quiera entender qué ha conseguido atraer suscriptores.

Por ahora, Hacki mantiene el ritmo; mis Notes consiguen más impresiones y conversación por pieza. Todavía no tenemos suficiente evidencia para elegir la mezcla de contenido que mejor capta suscriptores. Tenemos resultados concretos que estudiar, que ya es bastante más útil que pedirle simplemente que publique más.

¿Cómo encuentras a personas de las que aprender o con las que colaborar? ¿Qué tendría que descubrir un radar como el de Hacki para que te resultara útil?

Cuéntamelo. Siempre leo todo.

Deja un comentario

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

Hola, soy Aina y aquí te cuento qué pasa cuando pones a un agente de IA delante de un objetivo real: ayudarme a hacer crecer Think&Hack.

Cada miércoles te cuento qué ha hecho Hacki, qué ha pasado y qué voy cambiando. Suscríbete gratis y recibe la siguiente entrega en tu correo.

Suscríbete ahora

Si tienes una newsletter, seguramente conoces esta parte: terminas de escribirla, la publicas y todavía queda pensar cómo vas a moverla. Qué contar en Notes, qué llevar a LinkedIn, cómo seguir hablando del tema sin repetir cinco veces «he publicado una newsletter».

Pues hoy vamos a entrar ahí.

En la última entrega te conté la primera semana de Hacki. Hoy reúno las dos siguientes y empiezo a enseñarte cómo trabaja por dentro. Hay bastante que contar, así que lo vamos a repartir: hoy, las Notes; la semana que viene, el radar de oportunidades; y después, cómo lo entreno, qué decisiones tomo y cómo compruebo si está aprendiendo.

Porque el calendario puede estar lleno y yo seguir teniendo unas cuantas cosas que corregir. :D

Qué hace antes de enseñarme una Note

Hacki tiene una tarea semanal que se llama Editorial Weekly. Se pone a trabajar sin que yo tenga que acordarme de pedirle las Notes de la semana siguiente.

Antes de escribir, consulta el contenido de Think&Hack, el último análisis de resultados y las señales que tenemos de la audiencia. Los comentarios importan especialmente: pueden decirnos qué duda tiene alguien, qué le interesa o qué necesita que explique mejor.

Con ese material, extrae ideas y prepara las Notes. Cada una debe desarrollar una idea concreta y tener un propósito: enseñar algo, abrir una conversación, dar a conocer la newsletter… Después pasa por una revisión de contenido y de voz antes de llegar a mi calendario.

Así que cuando me siento a revisarlas, ya tengo una propuesta sobre la que trabajar.

El texto viene acompañado de una explicación

Te enseño el panel tal como está ahora, que he seguido ajustando estos días.

Puedo abrir una Note, leerla entera y consultar la idea editorial, el objetivo, la hipótesis y su ficha. Ahí veo qué quiere contar Hacki, para qué propone esa pieza y qué espera que ocurra.

La ficha también recoge el tipo de Note y cómo plantea su apertura: si busca despertar curiosidad o presentar una utilidad concreta. Todo eso me ayuda a entender por qué me está proponiendo ese texto.

La hipótesis es eso: una expectativa que luego tendremos que contrastar. Todavía no es un resultado.

Después añade una invitación a leer la newsletter, donde cuento la prueba real.

La idea editorial es que podamos elegir cómo entender o utilizar una información, aunque nos haya llegado en otro formato. El objetivo de esta Note es dar a conocer esa newsletter y favorecer nuevas suscripciones.

Y para comprobar qué ocurre, Hacki propone comparar sus interacciones y suscripciones atribuidas con otras Notes suyas de la misma antigüedad. Así evitamos comparar una que acaba de salir con otra que lleva semanas circulando.

En la ficha también puedo ver cómo la ha planteado: es una Note promocional, orientada a conseguir suscripciones y con una apertura que presenta una utilidad para el lector.

Con todo eso delante, puedo revisar si la idea se entiende, si el texto despierta ganas de leer la newsletter y si la invitación encaja con lo que estoy contando. Tengo una propuesta y una explicación sobre la que puedo intervenir.

Después entro yo. Leo, corrijo, descarto o acepto y programo. Y mis Notes espontáneas siguen teniendo su sitio; las que nacen de algo que he leído, de una conversación o de una idea que quiero compartir en ese momento.

¿Te está dando ideas para tu newsletter? Suscríbete y sigue el experimento conmigo. El próximo miércoles entraremos en el radar de oportunidades.

Suscríbete ahora

Una newsletter puede dar para más de un domingo

El 6 de septiembre añadí otra parte: Hacki puede leer la newsletter y preparar una campaña alrededor de ella.

Un anuncio y hasta cuatro Notes más, repartidas durante aproximadamente un mes. Cada una desarrolla una idea que se pueda entender por sí misma y conecta con la edición de la que sale.

Esto me interesa mucho. Después de dedicar tiempo a explicar un tema, quiero poder recuperar sus ideas y acercarlas a gente que quizá no vio la newsletter cuando salió.

Por ejemplo, una edición sobre cómo trabajo con agentes puede contener una decisión sobre qué delegar, un error que conviene evitar y una forma de revisar el resultado. Ahí hay varias conversaciones posibles. Hacki prepara las propuestas y yo reviso si cada una merece publicarse.

También tenemos en cuenta lo que ya está en el calendario, para distribuirlo junto al resto del contenido.

Notes y LinkedIn en el mismo calendario

Durante estas dos semanas he incorporado también las adaptaciones para LinkedIn.

Hacki parte de sus propuestas de Notes y trabaja cómo contar esa idea a alguien que está tomando decisiones sobre IA en una empresa. Cambia el enfoque y la desarrolla para ese contexto. Yo puedo revisar esa versión antes de programarla.

Y ahora, en Publicaciones, puedo ver juntas las Notes y las piezas de LinkedIn: qué hay cada día, en qué canal y qué está previsto o ya publicado.

Desde ahí puedo abrir una pieza y volver a su espacio de revisión. Así veo tanto el detalle de un texto como el conjunto de la semana.

Si tienes varios canales, seguramente entiendes por qué quería tenerlos juntos. Una cosa es que cada publicación tenga sentido por separado y otra ver cómo quedan todas cuando las pones en el calendario.

Y estas dos semanas, ¿qué ha pasado?

Vamos con los números. Del 24 de agosto al 6 de septiembre se publicaron 27 Notes propias: 14 propuestas por Hacki y 13 mías.

Con estos datos todavía no puedo decirte qué tipo de Note funciona mejor. Pero sí puedo empezar a mirar qué tienen en común las que han conseguido una suscripción y si eso nos da alguna idea que merezca la pena probar.

Para eso me sirve tener juntas la propuesta, su objetivo y sus resultados. Puedo volver a una Note, recordar qué queríamos conseguir y ver qué ocurrió después.

Ahora toca seguir unas semanas más y comprobar si aparece algún patrón que nos ayude a preparar las siguientes. Que llenar el calendario ya lo tenemos bastante encaminado. Ahora quiero ver qué vamos aprendiendo de lo que publicamos. :)

Lo siguiente que quiero enseñarte

Hoy he seguido el recorrido de las Notes: de dónde salen, qué explicación acompaña a cada propuesta, dónde las reviso y cómo quedan distribuidas entre canales.

La semana que viene te enseñaré el radar: cómo busca Hacki cosas que me pueden interesar, desde una lectura hasta una conversación en la que tenga sentido participar. Y después entraremos en mis correcciones y en qué tiene que pasar para que pueda decir que una le ha servido para trabajar mejor.

Y si al ver este proceso has pensado «yo quiero aprender a montar algo así», estoy preparando el curso de agentes autónomos. Trabajaremos cómo organizar sus tareas, darles instrucciones útiles y revisar lo que hacen, como estoy haciendo con Hacki.

Y para recibir los avances de Hacki cada miércoles, con sus pruebas, resultados y unas cuantas correcciones mías, suscríbete gratis a Think&Hack. Nos leemos en la próxima. :)

Suscríbete ahora

Suscríbete a Think&Hack

Tools are great. Systems are better.

¿Cómo estás?
Soy Aina y esto es Think&Hack.

Ayer sábado me desperté muy temprano y, aprovechando que OpenAI había sacado su nuevo modelo, GPT-6 Astra, me puse a probarlo. La verdad es que estoy muy a gusto con él. Va al grano, se enrolla poco y lo noto más rápido. Ya sabéis que el 5.6 se me hacía un poquito lento…

Donde me voló la cabeza fue cuando se puso a trabajar en mi móvil, ahí, en directo, delante de mí: abriendo la aplicación de música que estábamos creando, moviéndose por las pantallas, haciendo pruebas y comprobando lo que acababa de construir.

Me daba la sensación de que los dos teníamos los ojos puestos en la app. Yo también iba probando las distintas funciones y, desde la terminal, le iba diciendo lo que me gustaba, lo que no y dónde encontraba algún fallo. Prácticamente en tiempo real, íbamos probando y corrigiendo juntos.

Fue una simbiosis (🙈) que, hasta ahora, yo no había experimentado trabajando con una IA. Queda mucho camino por recorrer, pero cada vez estamos más cerca de esa forma de trabajar: ir hablando con el agente mientras vemos y probamos lo que está haciendo.

Esta sensación que estoy teniendo se acerca mucho a la idea que llevo años explicando y es que nos darán acceso al contenido y nosotros decidiremos cómo queremos consumirlo. Que la información llegue en un texto no significa que tengamos que leerla así. Podremos pedirle a nuestro agente que la convierta en un vídeo, que nos la explique con imágenes o que construya algo en el formato con el cual nos sintamos más cómodos.

Suscríbete ahora

Esto viene de lejos.

En noviembre de 2024 escribí hablando de la necesidad de crear una web en la que las inteligencias artificiales pudieran interpretar y recomponer la información. Lo planteaba desde mi terreno, el SEO. Partía de esta premisa: si una IA va a consultar los datos de la web y construir una respuesta con ellos, tendremos que preparar algo más que una página bonita. (Google había lanzado AI Overviews y empezábamos a ver ejemplos de cómo nuestra información podía llegar a alguien sin que entrara en nuestra web).

En julio de 2025 lo expliqué con el ejemplo de una bicicleta eléctrica. La misma información podía servir para una respuesta de audio, una explicación visual o un texto conversacional. Y también podía presentarse de forma distinta según lo que necesitara saber cada persona.

Y casi un año después, este junio seguí desarrollando la idea, hablando de una web agent-to-agent. Aquí entraban en juego los agentes: pasaba de hablar de una IA que consulta información y prepara una respuesta a una IA capaz de utilizar herramientas y dar los pasos necesarios para hacer lo que le pedimos. (Como cuando, en vez de explicarme cómo crear una app, se pone a construirla y a probarla). Así que la pregunta también cambiaba: ¿cómo preparamos nuestras webs para que esos agentes encuentren lo que ofrecemos, entiendan qué pueden hacer con ello y sepan cómo acceder?

Hasta hoy he ido hablando sobre todo de cómo preparar los contenidos para que las IA pudieran aprovecharlos. Pero con las pruebas de ayer estoy empezando a construir cómo quiero consumir yo esa información, no solo a prepararla para que otros la consuman. Es decir, puedo pedirle a mi agente que construya un software que se adapte a mis necesidades e ir ajustándolo con él, sin tener que escribir yo el código.

Todavía no es todo lo que llevo planteando en estos artículos, pero te enseño lo que he podido hacer para que veas por qué estoy tan entusiasmada. :)

Nunca había creado una app para Android

Para poner a prueba GPT-6 Astra, se me ocurrió crear una aplicación de música para mi móvil. Nunca en mi vida había creado una app para Android, así que al empezar fue todo confianza ciega. :)

Se llama Michi Música y la he ido montando alrededor de cómo quiero escuchar y organizar mi música. Por ejemplo, tengo un agente en local que revisa la música que tengo y me prepara listas en archivos Markdown. Después las importo en Michi y puedo reproducir esa selección sin tener que ir añadiendo las canciones una a una ni duplicar los archivos.

También puedo buscar vídeos de YouTube desde la app y descargar el audio para escucharlo sin conexión. Y he añadido podcasts, separados de la música y con la posición guardada para seguir por donde los dejé. Que no me aparezca un episodio de una hora entre dos canciones, por favor :’).

Tiene letras sincronizadas, puedo tocar un verso para ir a ese momento de la canción y he elegido los colores y cómo quiero tenerlo todo colocado. Hasta tiene su logo. Voy probando, se me ocurre algo que me vendría bien y se lo pido al agente para incorporarlo.

Me parece increíble haber podido crear esto con él en un día. Esto es lo que me tiene tan entusiasmada: poder decidir cómo quiero que funcione y verlo en mi móvil.

Con Michi he empezado por mi biblioteca y por cómo quiero utilizarla. Para hacer lo mismo con la información de otros servicios, también hará falta que permitan acceder a ella y transformarla. Esa parte sigue pendiente; lo que estoy pudiendo construir es la herramienta con la que quiero consumirla.

Te dejo el repositorio de Michi Música, donde puedes ver las funciones, descargar la app y consultar cómo la he ido construyendo con él.

Pero, obviamente, con la emoción no se me ocurrió grabar el proceso. Así que, para intentar hacerte partícipe de lo que viví y, por qué no, animarte a crear tu propia app, he grabado otro ejemplo: le he pedido que cree una aplicación de notas y que la pruebe en mi móvil.

Le cambiamos la instrucción en mitad del proceso, para ponerle presión y testear la nueva funcionalidad de Astra 6.

En menos de 5 minutos, app creada e instalada y, además, las manipula.

La edición del video es de Codex (se montó con HyperFrames y GSAP). No sé editar videos yo misma; por lo tanto, cuando se lo pido a una IA, tampoco lo hace muy bien. ¿Seguimos necesitando expertos para conseguir calidad con la IA?

Pero es increíble, Codex GPT6 ha creado el guion, ha entendido el video y lo ha narrado, la música también la ha elegido él. A mí me parece una locura.

¿Qué aporta Astra a todo esto?

Hoy te he explicado mis sensaciones, algo muy personal y muy subjetivo. Pero algunos de estos feelings encajan con las capacidades de Astra y ayudan a entender por qué estoy notando ese cambio en la forma de trabajar.

Según la documentación de OpenAI, Astra mejora en programación, navegación y uso del ordenador, y está preparado para realizar tareas que requieren varios pasos entre distintas herramientas. También puede seguir avanzando en otras partes del trabajo mientras espera a que una herramienta termine.

Hay una novedad que tiene mucho que ver con lo que te estoy contando: puede incorporar nuevas instrucciones mientras está trabajando. OpenAI lo llama mid-turn steering. Por ejemplo, puedo añadir un requisito o pedir un cambio de dirección sin esperar a que termine toda la respuesta. (Esta capacidad tiene que estar integrada en la herramienta desde la que lo utilizo).

Después de las pruebas de ayer, cada vez veo más cerca poder trabajar como en este vídeo de OpenAI. Oh, sí, te lo vuelvo a compartir.

Llevo mucho tiempo queriendo una Eames Lounge Chair, un diseño de Charles y Ray Eames de 1956. Es simplemente espectacular y acabo de encontrar la excusa perfecta para comprarlo. Solo tengo que decir en el trabajo: «Para trabajar mejor con la IA necesito este sillón». ¿Colará?

Lo que me cuesta imaginar es hacerlo en un open office, con todo el mundo hablando a la vez con su agente. Aquello puede ser un gallinero. Entre uno que pide un informe, otro que está montando una app y yo diciéndole al mío: «no, espera, que se me ha ocurrido otra cosa»… No solo va a cambiar el trabajo, sino los espacios de trabajo, esto da para otra news otro día…

Lo que más ganas tengo de seguir probando es hasta dónde puedo llevar esto de decidir cómo quiero consumir la información y construirlo con mi agente. Llevo años dando con esta idea y ahora puedo empezar a enseñarte lo que voy haciendo. Todavía falta, pero aquí seguiré contándote cómo va. :)

P. D. Los avances de Hacki te los contaré todos los martes en una newsletter aparte. Hay muchísimo que contar y quiero poder dedicarle su espacio sin que se me cuele en todos los temas de los domingos. Que le doy un poco de cuerda y acaba protagonizando la news entera.

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.

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