Lo difícil no es encontrar buenas ideas. Es usarlas a tiempo
Cómo convertir heurísticas y conocimiento disperso en capacidades disponibles dentro de un flujo de trabajo con agentes de inteligencia artificial.
Hay una clase de conocimiento que me fascina y, al mismo tiempo, me frustra.
Son esas ideas que uno encuentra en un libro, un artículo académico, una conversación o una investigación y piensa inmediatamente: esto me serviría muchísimo para trabajar y tomar decisiones.
El problema es que unas semanas después casi nunca recuerda utilizarlas.
No necesariamente porque las haya olvidado por completo. Uno conserva algo: una intuición, un nombre, quizá una regla. Pero cuando aparece el problema real en medio de un proyecto, una negociación, una investigación o una decisión, rara vez tenemos disponible en la cabeza todo lo necesario para reconocer el patrón, recordar la herramienta adecuada, revisar sus supuestos y aplicarla bien.
Durante mucho tiempo pensé que ese era simplemente el costo de aprender: conocemos muchas más cosas de las que somos capaces de mantener activas al mismo tiempo.
Trabajar con agentes de inteligencia artificial empezó a hacerme pensar que quizá esa limitación se puede atacar de otra manera.
Y esa idea terminó llevándome a construir un skill.
La experiencia llegó antes que el nombre
Durante años tuve un problema bastante mundano con mis archivos.
Cada proyecto producía su pequeña arqueología digital: versión 1, versión 1.5, final, final-final, final draft, versión 3.
Documentos que alguna vez habían sido importantes terminaban mezclados con archivos en proceso, pruebas, exportaciones y cosas que probablemente no volvería a necesitar.
No era exactamente un archivo histórico ni una carpeta de trabajo. Era información en tránsito.
Mi solución fue crear una carpeta llamada temporal.
Todo lo que todavía no sabía dónde poner podía vivir allí. Podía abrirlo, modificarlo, clasificarlo, moverlo a otro lugar o borrarlo.
Pero había una regla: si un archivo llevaba más de treinta días en temporal, se borraba al día treinta y uno.
Treinta días no eran un número mágico. Solo necesitaba una frontera.
Si algo había pasado un mes entero en una carpeta explícitamente temporal y no había vuelto a utilizarlo, la evidencia disponible sugería que probablemente no era tan importante. Aceptaba un riesgo pequeño de perder algo útil a cambio de no acumular indefinidamente información que después tampoco iba a ser capaz de encontrar.
La regla ha fallado alguna vez.
Pero agradezco muchas más veces el orden que produce que las veces que he lamentado haber perdido algo.

Cuando una intuición adquiere nombre
Años después descubrí que esa solución casera pertenecía a una familia de problemas mucho más interesante.
En informática existe, por ejemplo, una estrategia conocida como LRU, least recently used, para decidir qué información conservar en una caché cuando el espacio es limitado.
Mi regla de los treinta días no es LRU en sentido estricto. No estoy expulsando permanentemente el elemento menos utilizado para liberar una capacidad fija. Es mucho más parecida a una política de expiración temporal.
Pero el parentesco conceptual es evidente: ambas intentan responder una pregunta parecida.
¿Qué vale la pena mantener disponible y qué podemos retirar?
Para mí, eso fue más interesante que descubrir que mi carpeta tenía un primo lejano en ciencias de la computación.
Porque ponerle nombre al problema me permitió hacer algo que la experiencia por sí sola no me permitía.
Podía investigar.
Podía preguntar cuáles eran los supuestos de esas estrategias, en qué contextos funcionaban, cuándo fallaban y qué otras soluciones existían.
La práctica había llegado primero. El concepto construyó después un mapa alrededor de ella.
Un libro abrió la puerta
Uno de mis puntos de entrada a este mundo fue Algorithms to Live By, de Brian Christian y Tom Griffiths.
El libro toma problemas estudiados en ciencias de la computación y los conecta con situaciones humanas reconocibles: cuándo dejar de buscar, cómo ordenar tareas, cuánto explorar antes de aprovechar lo que ya sabemos o cuándo conformarnos con una alternativa suficientemente buena.
Lo que más me interesó no fueron las recetas.
Fue aprender a mirar algunos problemas de otra manera.
En lugar de preguntar solamente: ¿Cuál es la decisión correcta? aparecen otras preguntas: ¿Qué estoy intentando optimizar? ¿Cuánto cuesta seguir buscando? ¿Qué información todavía me falta? ¿Qué estoy sacrificando al escoger esta alternativa? ¿Qué tendría que ocurrir para que cambiara de opinión?
Ese cambio de lenguaje es mucho más valioso que memorizar una cifra como el famoso 37 % asociado a una versión particular del problema de la secretaria.
Y también exige cautela. Ernest Davis señala parte de esa tensión al analizar críticamente la distancia entre algunos modelos computacionales y la vida cotidiana.
El modelo puede ayudarnos a pensar. Eso no significa que el mundo tenga la obligación de comportarse como el modelo.
Entonces apareció un problema nuevo
Seguí investigando.
Encontré materiales sobre exploración frente a explotación, multi-armed bandits, optimal stopping, satisficing, batching, regularización, Goodhart y muchas otras ideas.
Cada una abría una pequeña ventana.
Exploración frente a explotación permite preguntar cuánto tiempo conviene dedicar a probar alternativas y cuándo empezar a aprovechar aquello que ya funciona.
Satisficing obliga a considerar si realmente necesitamos encontrar la mejor opción o si existe un umbral a partir del cual seguir buscando cuesta más de lo que probablemente aporta.
Batching permite pensar el costo de cambiar continuamente de contexto.
Regularización ofrece una metáfora útil para desconfiar de decisiones excesivamente ajustadas a una sola experiencia.
Goodhart recuerda el peligro de convertir una métrica en objetivo y terminar destruyendo aquello que originalmente intentábamos medir.
El problema era que cuanto más interesante se volvía el mapa, más difícil era utilizarlo.
Podía leer veinte heurísticas. Podía entenderlas. Podía incluso reconocer ejemplos excelentes de cada una.
Pero tres meses después, frente a una decisión real, seguía dependiendo de recordar espontáneamente que alguna vez había leído algo relevante.
Y eso no ocurre con demasiada frecuencia.
Las fuentes le dieron respaldo al recorrido. Entre ellas estuvieron materiales de Stanford sobre exploración y explotación y un estudio de Singmann y colaboradores sobre problemas de parada óptima. Las menciono como respaldo y orientación, no para presentarme como especialista en cada uno de esos campos.
Saber que una herramienta existe no significa tenerla disponible
Aquí es donde creo que aparece una distinción importante para quienes usamos inteligencia artificial de manera relativamente avanzada.
Durante mucho tiempo tratamos el conocimiento como algo que una persona debía internalizar para poder utilizar.
Leemos. Estudiamos. Subrayamos. Tomamos notas. Construimos sistemas de conocimiento personal.
Todo eso sigue siendo valioso.
Pero hay otro problema distinto: la recuperación en contexto.
Puedo conocer perfectamente una idea y, aun así, no reconocer que es relevante para el problema que tengo delante.
Puedo recordar el nombre de una heurística y olvidar sus supuestos.
Puedo recordar una regla y olvidar justamente las condiciones que hacen peligroso aplicarla.
Puedo incluso tener excelentes notas y nunca pensar en buscarlas.
La inteligencia artificial como super memoria
Uno de los superpoderes menos espectaculares, y para mí, más interesantes, de trabajar con agentes no es que puedan producir texto.
Es que pueden ayudar a poner conocimiento en circulación.
Una heurística que antes estaba encerrada en un libro, un artículo académico, una nota o una experiencia previa puede volver a aparecer justo cuando el problema la hace pertinente.
El agente puede preguntar: ¿Qué decisión estás intentando tomar? ¿Qué restricciones existen? ¿Qué información falta? ¿Este problema se parece más a exploración frente a explotación, a parada óptima, a priorización, a asignación de recursos o a otra cosa? ¿Qué supuestos tendría que cumplir determinada heurística? ¿Qué observación indicaría que estamos aplicando mal la analogía? ¿Qué pequeña prueba podríamos hacer antes de adoptar una regla?
Eso es muy diferente de pedirle a un modelo: dime qué debo hacer.
Para mí, la parte interesante es exactamente la contraria: usar inteligencia artificial para ampliar el repertorio de preguntas que somos capaces de hacernos antes de decidir.
Y ahí es donde los skills se vuelven interesantes
Un agente general puede conocer muchas de estas ideas. Pero eso no significa necesariamente que vaya a utilizarlas de manera consistente.
Puede no reconocer el patrón. Puede escoger una analogía superficial. Puede olvidar preguntar por un supuesto importante. Puede producir una explicación excelente y, aun así, no seguir el proceso que nosotros queremos utilizar para analizar una decisión.
Ahí encontré una de las razones por las que los skills me parecen una abstracción tan interesante.
Un skill permite convertir conocimiento y metodología en algo que el agente puede recuperar y aplicar como una capacidad reconocible.
No es simplemente un prompt largo. Al menos, esa no es la parte que me interesa.
Lo que me interesa es poder decir: cuando aparezca esta clase de problema, existe una forma de abordarlo; estas son las herramientas disponibles; estos son sus supuestos; estas son las preguntas que hay que hacer; estas son sus limitaciones.
Eso reduce enormemente la distancia entre haber aprendido algo y ser capaz de usarlo.
Del conocimiento almacenado al conocimiento ejecutable
Durante años hemos construido enormes sistemas para almacenar conocimiento: documentación, wikis, marcadores, bases de conocimiento, notebooks, carpetas llenas de PDF, repositorios y notas enlazadas entre sí.
Todo eso resuelve una parte del problema.
Pero almacenar conocimiento y activar conocimiento son cosas distintas.
Los agentes permiten imaginar una capa adicional.
No solamente: aquí están mis notas sobre este tema. Sino: cuando estés trabajando conmigo y aparezca un problema de este tipo, ayúdame a reconocerlo y trae estas herramientas a la conversación.
Una heurística sigue sin ser una orden
Esta facilidad también introduce un peligro.
Hacer que una heurística sea fácil de recuperar no la convierte en verdadera. Ni universal. Ni adecuada para todos los contextos.
Mi carpeta temporal, por ejemplo, funciona porque el costo de perder ocasionalmente un archivo es aceptable para mí frente al costo cotidiano de acumular información indefinidamente.
No aplicaría la misma política a documentos legales, registros financieros, respaldos o información cuya conservación tenga valor independientemente de cuándo fue utilizada por última vez.
La heurística no contiene la decisión. Contiene una forma de pensar sobre la decisión.
Por eso creo que un buen agente no debería limitarse a decir: usa esta regla.
Debería ayudar a mostrar qué problema estamos modelando, qué objetivo estamos suponiendo, qué información tenemos, qué información falta, qué costos estamos intercambiando, qué supuestos exige la herramienta y qué podría hacer que la descartáramos.
El acceso instantáneo al conocimiento no elimina la necesidad de juicio. Probablemente hace que el juicio sea todavía más importante.
De esa frustración salió un skill
Después de acumular estas ideas llegué a una conclusión bastante sencilla.
No quería otro documento con una lista de heurísticas interesantes. Ya existen libros, artículos académicos y publicaciones excelentes.
Quería poder utilizarlas.
Quería que, frente a un problema real, el agente pudiera ayudarme a explorar ese espacio de posibilidades sin convertir ninguna heurística en una respuesta automática.
Así apareció Algoritmos para la vida, un skill público que reúne heurísticas, sus supuestos, ejemplos, límites y preguntas útiles para analizar decisiones.
No intenta convertir la vida en un problema de optimización. Tampoco intenta encontrar una fórmula matemática para cada decisión.
Hace algo mucho más modesto: ayudar a reconocer que un problema puede pertenecer a una familia que otras personas ya han estudiado y traer esas herramientas a la conversación cuando todavía pueden ser útiles.
Para mí, esa es una de las posibilidades más interesantes de los agentes y los skills.
Fuentes y lecturas
Brian Christian y Tom Griffiths — Algorithms to Live By. El libro de divulgación que abrió esta investigación y conecta problemas de las ciencias de la computación con decisiones cotidianas.
Ernest Davis — Algorithms and Everyday Life. Una lectura crítica útil para entender los límites de trasladar modelos algorítmicos a situaciones humanas.
Henrik Singmann y colaboradores — Full-Information Optimal-Stopping Problems: Providing People with the Optimal Policy Does not Improve Performance. Investigación sobre la relación entre políticas formalmente óptimas y desempeño humano.
Ashwin Rao — A Guided Tour of Chapter 15: Multi-Armed Bandits: Exploration versus Exploitation. Material docente de Stanford para profundizar en exploración y explotación.
Algoritmos para la vida — repositorio público del skill. Reúne las heurísticas, sus supuestos, ejemplos y límites para utilizarlas con agentes sin convertirlas en órdenes automáticas.
Preguntas frecuentes
¿Cuál es la diferencia entre un agente, una fuente de conocimiento y un skill?
Las fuentes contienen conocimiento; el agente razona y actúa dentro de una tarea; el skill empaqueta una forma recurrente de recuperar, contextualizar y aplicar ese conocimiento.
¿Qué es una heurística?
Es una regla o estrategia práctica que ayuda a decidir cuando el tiempo, la información o la capacidad de cálculo son limitados. No garantiza la mejor respuesta ni debe aplicarse fuera de sus supuestos.
¿Qué hace el skill Algoritmos para la vida?
Ayuda a reconocer familias de problemas, recuperar heurísticas pertinentes, revisar sus supuestos y convertirlas en preguntas o pasos accionables sin delegar el juicio de la persona.
¿La carpeta temporal aplica exactamente el algoritmo LRU?
No. La regla de borrar archivos después de treinta días se parece más a una política de expiración temporal. Comparte la pregunta sobre qué conservar, pero no es una implementación estricta de LRU.