Memoria para los Agentes de IA

¡Hey! Esta vez quiero platicar sobre otro tema que me parece muy interesante: la memoria para los agentes de IA. Primero veremos por qué puede ser necesaria y después exploraremos algunas estrategias de implementación.

Para seguir el artículo, ayuda tener una idea general de qué es un agente: un sistema que usa un modelo de IA para decidir cómo avanzar en una tarea y que, según el caso, puede apoyarse en herramientas y conservar información útil. No necesitas conocer un framework en particular. Si quieres una introducción previa, puedes leer la explicación de Anthropic.

¿Por qué un agente necesita memoria?

Imagina un agente que analiza datos de ventas y le pide al usuario información para completar un dashboard. Durante la ejecución ocurre un error que obliga a reiniciar el agente. Al retomar la tarea…

Al reiniciarse, si el agente no guardó el estado de la tarea ni las respuestas del usuario, su contexto ya no incluye esa información. Por eso no sabe qué estaba haciendo ni qué datos había solicitado. Podría tener que empezar de nuevo o volver a pedirle al usuario información que ya había proporcionado. Un mecanismo de memoria puede conservar ese estado para que el agente retome la tarea.

Memoria de trabajo o corto plazo

Como ya mencioné los agentes cuentan con algo que se conoce como ventana de contexto que les permite tener presente la información de la conversación durante una sesión. Esta memoria de trabajo es muy útil, pero tiene dos limitaciones:

1. El costo de la autoatención puede crecer de forma cuadrática

Los LLM (large language model o modelo grande de lenguaje) que utilizan los agentes están basados en una arquitectura Transformer. Seguro puedes encontrar en la red más información de cómo funcionan exactamente. Aquí lo relevante es tener en mente que utilizan un mecanismo de autoatención, que calcula la relación de cada token (lo que puede ser una palabra, un fragmento de palabra o incluso un signo) con todos los demás tokens presentes en la ventana de contexto.

Matemáticamente, si el contexto tiene una longitud de n tokens, el cómputo de la autoatención densa estándar escala en un orden de O(n^2), considerando la notación Big-O. Esto significa que, al duplicar la longitud del contexto, el trabajo requerido por este mecanismo puede llegar aproximadamente a cuadruplicarse. Algunas implementaciones modernas optimizan el uso de memoria y el tiempo real de ejecución, pero procesar contextos cada vez más extensos continúa teniendo un costo.

Muchos agentes operan mediante ciclos continuos de razonamiento-acción-observación. El agente en cada paso añade más a la ventana de contexto el prompt del sistema, las descripciones de herramientas, el historial de conversación, los resultados intermedios de APIs y la información recuperada de fuentes externas. En implementaciones comunes, una parte importante de este contexto vuelve a ser procesada en cada iteración para que el agente pueda decidir su siguiente acción. Por esto, si el contexto crece de manera desproporcionada, también puede aumentar la latencia y el costo.

Este crecimiento puede degradar el rendimiento y contribuir a un fenómeno conocido como dilución de la atención. Como resultado, el agente puede pasar por alto información relevante y generar respuestas deficientes, inconsistentes o con mayor riesgo de alucinaciones.

2. Puede perderse al reiniciar

Para este punto pongamos en nuestra mente un sistema agéntico de atención al cliente. Al comenzar la conversación, se inicializa un agente que habla con el usuario y conserva temporalmente en su contexto información como su nombre, número de orden y el problema o asunto a tratar.

Si esta información se encuentra únicamente en la ventana de contexto y el sistema debe reiniciarse debido a una actualización o a un fallo inesperado, el nuevo proceso no tendrá acceso a la conversación anterior. Para el agente sería como comenzar desde cero y probablemente tendría que pedir al usuario toda la información de nuevo.

Esto se debe a que el LLM no recuerda por sí mismo las conversaciones entre ejecuciones. En cada llamada necesita recibir nuevamente el historial o la información relevante. Para poder retomar el trabajo después de un reinicio, el sistema debe guardar su estado utilizando algún mecanismo persistente. Esto puede ser una base de datos, un archivo, un almacén de memoria o un sistema de checkpoints.

Tipos de Memoria

Hasta ahora hemos hablado de la memoria de trabajo, y como seguro estarás imaginando, pasemos a lo que puede considerarse memoria a largo plazo. Esta complementa la memoria de trabajo o corto plazo y permite que el agente conserve información más allá de una tarea o sesión determinada.

Dependiendo del caso de uso, un agente necesitará recordar diferentes clases de información y recuperarla de diferentes maneras. Aunque no existe una única clasificación, normalmente se habla de los siguientes tipos de memoria:

• Memoria Episódica – Experiencias
• Memoria Semántica – Hechos
• Memoria Procedimental – Instrucciones

Memoria Episódica

Si trasladamos este tipo de memoria a un ser humano, podríamos verla como el recuerdo de nuestras experiencias; es decir, las cosas que hicimos, el contexto en el que sucedieron y sus resultados. En un agente de IA podría representar interacciones o ejecuciones anteriores: qué acciones realizó, qué decisiones tomó, cuál fue el resultado y qué retroalimentación recibió. De esta manera, el agente podría recuperar una experiencia pasada cuando se encuentre ante una situación similar.

Memoria Semántica

En ocasiones necesitamos que el agente recuerde hechos concretos, por ejemplo el nombre de un usuario, sus preferencias, la descripción del problema o el estado actual de una situación que se está resolviendo con un cliente. Esto es, conservar estos datos sin tener que recuperar el momento exacto en el que el usuario dijo su nombre, relató el problema, explicó todo lo que había sucedido hasta llegar al estado actual. Esto último incluso podría regresarnos a los problemas relacionados con el crecimiento de contexto.

Memoria Procedimental

Este tipo de memoria es todo lo relacionado sobre cómo debe actuar el agente: instrucciones, pasos, políticas, reglas, y formas de ejecutar determinadas tareas. Los modelos son hoy en día tienen una gran capacidad para realizar diferentes actividades, pero no necesariamente saben cómo queremos que procedan dentro de un sistema u organización.

La intención no es proporcionarle simplemente toda la documentación de los procedimientos de una empresa de manera cruda o no estructurada. Esto nos podría poner de nuevo en los problemas con el crecimiento de contexto. Esta información se puede organizar mediante skills, de manera que el agente consulte las instrucciones y los recursos correspondientes según la tarea que necesite realizar. Las instrucciones procedimentales también pueden formar parte de los prompts, las configuraciones, el código, los guardrails o el harness encargado de controlar la operación del agente.

Almacenamiento y herramientas habituales

Las siguientes asociaciones no son reglas estrictas. Un mismo tipo de memoria puede utilizar diferentes formas de almacenamiento, y una misma herramienta puede servir para implementar más de un tipo.

• Memoria de Trabajo
• Qué conserva: la conversación y el estado de la tarea actual.
• Almacenamiento habitual: estado en memoria o checkpoints persistentes.
• Recuperación: por sesión, hilo o identificador.
• Herramientas: Redis, SQLite, PostgreSQL o checkpointers de LangGraph.
• Memoria Episódica
• Qué conserva: Experiencias, acciones, y resultados anteriores.
• Almacenamiento habitual: bases de datos relacionales o documentales y registros de eventos.
• Recuperación: por fecha, sesión, filtros o similitud semántica
• Herramientas: SQLite, PostgreSQL o MongoDB; pgvector o Qdrant cuando se necesite localizar experiencias similares.
• Memoria Semántica
• Qué conserva: hechos, preferencias, conceptos y relaciones.
• Almacenamiento habitual: bases de datos relacionales, clave-valor, vectoriales o de grafos.
• Recuperación: mediante consultas exactas, búsqueda por similitud semántica o relaciones entre entidades.
• Herramientas: PostgreSQL, pgvector, Qdrant, Zep, Mem0, o Google Agent Platform Memory Bank.
• Memoria Procedimental
• Qué conserva: instrucciones, políticas, y formas de realizar tareas.
• Almacenamiento habitual: archivos versionados, código, configuraciones o registros de prompts.
• Recuperación: por tarea, versión o regla de activación.
• Herramientas: skills, LangMem, Git, archivos markdown, o registros de prompts.

Similitud semántica

En varios puntos hemos hablado de la similitud semántica, esto hace referencia a una técnica que permite localizar información por su significado y no únicamente por la coincidencia exacta de palabras.

Para realizar este tipo de búsqueda, un modelo de embeddings convierte textos, imágenes u otros datos en representaciones numéricas llamadas vectores. Posteriormente, estos vectores pueden almacenarse e indexarse en un almacén vectorial para encontrar aquellos que se encuentran más próximos entre sí y que, de acuerdo con el modelo utilizado, representan contenidos similares.

Por ejemplo, un agente de soporte podría guardar la descripción de un problema, las acciones realizadas y su resultado. Si posteriormente recibe un caso similar, aunque esté expresado con palabras diferentes, el sistema puede generar su embedding, compararlo con los vectores almacenados y recuperar las experiencias más cercanas para que el agente las utilice como referencia.

Esto permite que una frase como “cambié de teléfono y no puedo entrar” pueda relacionarse con una experiencia anterior descrita como “el usuario perdió el acceso porque la autenticación de dos factores estaba vinculada a su dispositivo anterior”.

Consideraciones generales para la memoria

De manera general, una de las decisiones más importantes consiste en seleccionar estratégicamente qué información se va a almacenar. Como hemos revisado, la implementación no siempre tiene que ser algo muy complejo: incluso un archivo Markdown con un resumen podría funcionar como una forma sencilla de memoria externa o contexto persistente, siempre que el agente pueda consultarlo y actualizarlo cuando sea necesario.

Algunas consideraciones útiles para administrar la memoria son las siguientes:

• Consolidación: la información relacionada puede combinarse, resumirse y actualizarse para evitar recuerdos duplicados o contradictorios. Por ejemplo, varios episodios podrían consolidarse en un hecho, una conclusión o una preferencia más general.
  
  Un caso práctico en herramientas de línea de comandos como Claude Code o Codex consiste en pedirle al agente que mantenga un archivo Markdown durante una investigación. En lugar de agregar indefinidamente todos los hallazgos, el agente puede actualizarlo periódicamente, agrupando información relacionada, resumiendo los puntos más importantes y reemplazando conclusiones que hayan quedado obsoletas.
  
  De esta manera, el archivo funciona como una memoria externa persistente que puede consultarse durante las siguientes etapas del trabajo. Al ser un formato legible para las personas, también podemos abrirlo, buscar información específica y corregir su contenido sin necesidad de invocar al modelo ni consumir tokens. Cuando el agente necesite utilizarlo, puede recuperar únicamente la información relevante e incorporarla nuevamente a su contexto.

• Podado o eliminación (eviction): no todo debe recordarse indefinidamente. Pueden aplicarse políticas basadas en la antigüedad, frecuencia de uso, vigencia y utilidad de la información para eliminar recuerdos obsoletos o poco relevantes antes de incorporarlos nuevamente al contexto.

• Múltiples estructuras de memoria: no toda la información tiene que almacenarse de la misma manera. Investigaciones recientes, como FluxMem, exploran la combinación de estructuras lineales —como secuencias temporales—, grafos —para representar relaciones— y estructuras jerárquicas —como temas y resúmenes—, seleccionando la más apropiada según el contexto de la consulta. Aunque es una línea de investigación prometedora, todavía no constituye una regla general para implementar memoria en todos los agentes.

¿El RAG es memoria?

Para dar un poco de contexto, el RAG (Retrieval-Augmented Generation ó generación aumentada por  recuperación) es una técnica que permite buscar información relevante en una fuente externa antes de generar una respuesta. Esta información puede ser especializada, privada o reciente, y no haber estado disponible durante el entrenamiento del modelo. Además, esta información puede proporcionarse al modelo sin necesidad de volver a entrenarlo.

Una forma práctica de verlo es como si le proporcionáramos al agente el acceso a una biblioteca. Entonces en vez de memorizar todos los libros, busca aquellos relacionados con la pregunta, recupera los fragmentos relevantes y los utiliza de referencia para elaborar su respuesta.

Esto no quiere decir que el contenido quede incorporado permanentemente en los parámetros del modelo: normalmente solo se encuentran disponible durante esa ejecución.

Pero bueno, entonces, ¿RAG es memoria o no? Depende de cómo se utilice el término. El trabajo original sobre RAG describe el almacén externo como una memoria no paramétrica. Sin embargo, dentro de un sistema agéntico, RAG se entiende como un mecanismo de recuperación y no necesariamente como memoria del agente.

Por ejemplo, si nuestro agente consulta manuales, documentos o políticas, estará accediendo a una fuente externa de conocimiento. Pero si el sistema conserva experiencias anteriores (memoria episódica), hechos y preferencias (memoria semántica), o incluso lineamientos sobre cómo realizar ciertos procedimientos (memoria procedimental), entonces esa información puede formar parte de la arquitectura de memoria del agente. RAG podría utilizarse como el mecanismo para recuperar, desde las fuentes externas, los detalles necesarios cuando resulten relevantes.

Una forma simplificada y práctica de verlo sería que el agente conservara en su memoria algo como: “El documento de procedimientos contables fue útil para revisar cómo registrar las pólizas”. La próxima vez que necesite resolver una situación relacionada con pólizas, ese recuerdo podría llevarlo a consultar nuevamente la fuente, mientras que RAG ayudaría a recuperar los fragmentos relevantes del documento.

La diferencia principal está en el contenido y en cómo se mantiene: RAG explica cómo recuperar información relevante, mientras que la memoria también implica decidir qué conservar, cómo actualizarlo, durante cuánto tiempo mantenerlo y cuándo olvidarlo.

¿Y si mi recuerdo no es seguro?

Para cerrar, esta parte me parece sumamente interesante. Recuerdo que alguna vez un profesor nos decía que el equipo más seguro era aquel que se encontraba cerrado, desconectado y apagado. Más que nada, trataba de advertirnos que, al abrir una puerta para compartir información, también comienzan a aparecer problemas de seguridad.

Al conectar un agente con fuentes externas en las que almacenamos y recuperamos información, ampliamos su superficie de ataque. Los principios de seguridad que normalmente aplicamos a los sistemas determinísticos también aplican aquí. Por ejemplo, el principio del mínimo privilegio o PoLP (Principle of Least Privilege) continúa siendo necesario: el agente solamente debería tener acceso a los datos y herramientas indispensables para realizar su tarea.  También es estratégico limitar el acceso en cada servicio o herramienta que el agente puede utilizar, de manera que el agente solamente cuente con los permisos necesarios para realizar su tarea.

Además, aparecen riesgos particulares de estos sistemas. Por ejemplo, podrían introducirse recuerdos falsos o manipulados en la memoria, algo conocido como memory poisoning (envenenamiento de memoria), o almacenarse instrucciones maliciosas donde el agente esperaba encontrar solamente datos. Si posteriormente el sistema recupera esa información y la considera confiable, podría alterar su comportamiento en futuras ejecuciones. Por ello, también es importante validar el origen y la integridad de los recuerdos, separar los datos de las instrucciones y mantener registros que permitan saber de dónde provino la información.

Por otro lado, también es importante que el agente pueda olvidar. Dentro del ámbito de la privacidad existe el concepto de RTBF (Right to Be Forgotten), conocido en español como derecho al olvido. Esto no significa que toda información deba eliminarse siempre y sin excepción, pero sí que debemos considerar cuándo corresponde borrar los datos personales. De manera similar a como lo hacemos en los sistemas determinísticos, también es necesario establecer políticas de retención que definan qué información se conserva, durante cuánto tiempo y bajo qué condiciones debe actualizarse o eliminarse.

Vaya! con esto dimos un pequeño recorrido a los conceptos generales de la memoria, te dejo algunas referencias en la parte de abajo y como siempre ...

Espero te sea de utilidad...

Salu2

___

Referencias:

• Ilustraciones: Creadas con ayuda de ChatGPT (OpenAI), a partir de ideas y descripciones propias.
• https://docs.cloud.google.com/architecture/choose-agentic-ai-architecture-components
• https://datahub.com/blog/context-window-optimization/
• https://binzhango.net/posts/2026/03-15-attention-dilution/
• https://en.wikipedia.org/wiki/Big_O_notation
• https://help.openai.com/es-419/articles/4936856-understanding-and-counting-tokens
• https://developers.google.com/machine-learning/crash-course/embeddings?hl=es-419
• https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

Skills para agentes de IA

Wow, ha sido un rato que no pongo nada en mi blog :O... recientemente terminé unos estudios en IA y me gustaría ir compartiendo temas que me parecen interesantes, o que han sido relevantes para mí.

Ya tenía tiempo queriendo escribir en este blog con varios temas e ideas en la cabeza, este primer tema que seleccioné, es relacionado con los skills que se utilizan por agentes de IA que operan en la terminal, como Gemini CLI, Claude Code o Codex. Para este post asumiré que ya tienes una idea general de qué son estas herramientas y para qué sirven. En caso de que no, puedes buscarlas en la red y seguro encontrarás rápidamente una introducción y para qué se utilizan.

Para este post tomaré como referencia el formato abierto Agent Skills, aunque algunos detalles de su implementación pueden variar entre herramientas.

Pero, ¿para qué un skill?

La primera vez que yo escuché sobre ellos, me pregunté, pero si se supone que estas herramientas ya son inteligentes y tienen super conocimientos generales, ¿por qué necesitamos darles además instrucciones adicionales para realizar ciertas tareas? 

Ok, una forma de verlo es imaginando este escenario. Cuando trabajamos en algo contamos con los siguientes elementos a grandes rasgos:

1. Una descripción de la tarea que tenemos que hacer.
2. Nosotros como ejecutores de la tarea.
3. Finalmente, una guía o conocimiento de cómo podemos ejecutar la tarea de la mejor manera posible y qué herramientas utilizar.

Podríamos decir que el punto 3 es opcional, pero si no tenemos esa guía podríamos estar improvisando cada vez que tenemos ese tipo de tarea particular. Además este punto 3 podría indicarnos atajos o recomendaciones de dónde encontrar herramientas que nos pueden servir para hacerlo mejor, más rápido y de una forma consistente. Pues bien cada uno de esos puntos se pueden ver de la siguiente forma cuando trabajamos con agentes de IA:

1. La descripción de la tarea podría ser lo que entendemos como el prompt, junto con el contexto que proporcionamos.
2. En este punto 2 (el ejecutor) sería el agente o sistema agéntico, por ejemplo, Gemini CLI, Claude Code o Codex. También puede ser un sistema agéntico orquestado mediante un framework como LangGraph, al que se le haya incorporado un mecanismo para descubrir y utilizar skills. Este utiliza un LLM (Large Language Model o Modelo Grande del Lenguaje), herramientas, contexto y un entorno de ejecución para realizar la tarea.
3. Finalmente, este punto 3 sería el skill, que le indica al agente o sistema agéntico cómo abordar cierto tipo de trabajo de manera consistente.

Podemos concluir de manera general que un skill para un agente de IA es: un paquete reutilizable que contiene instrucciones y que también puede incluir documentos de referencia, scripts, plantillas y otros recursos para ejecutar una tarea de manera consistente. 

Super, entonces, le doy todo y ya está...

Si ya habías oído sobre los skills, podrías estarte preguntando, ok para que me ayude, le doy un bonche de documentos donde explique cómo hacer todo lo que yo hago y ya está, ahí quedaron mis skills; y la respuesta es sí pero no exactamente así, para los skills se recomienda utilizar una estructura, y seguro te preguntarás, ¿por qué?

Una de las principales razones para utilizar esta estructura es por algo que se conoce como ventana de contexto (context window). La ventana de contexto es la cantidad limitada de información - expresada en tokens - que el modelo puede considerar durante una ejecución. Vamos a hacer una comparación simplificada de lo que sucede, ya que es algo que en cierta forma nos pasa también a nosotros. 

Normalmente cuando tenemos algo que hacer utilizamos nuestra memoria de trabajo, esto es, mientras realizamos una tarea tenemos que acordarnos de cosas mientras la ejecutamos, por ejemplo, imagina una persona trabajando en un almacén, le podrá ser muy sencillo recordar los números del código de barras, tal vez de algunos que acaba de registrar, pero tal vez ya olvidó aquellos no tan comunes del día anterior. Bien, imagina que simplemente le decimos a la persona que tiene que leer todos los números de todos los productos antes de empezar a trabajar y luego empezar a trabajar. Esto aunque es posible, no sería lo más eficiente. Una mejor estrategia es decirle, te doy esta herramienta o documento donde puedes encontrar el número de código de barras de un producto cada vez que lo necesites. De manera muy simplificada, esta es una de las ideas detrás de los skills: en lugar de cargar desde el principio toda la información que el agente podría llegar a necesitar, le proporcionamos una forma organizada de localizarla y consultarla cuando resulte relevante.

Diversas evaluaciones han demostrado que el rendimiento de los modelos puede degradarse a medida que aumenta la cantidad de información en el contexto, incluso antes de alcanzar su límite máximo, especialmente cuando la información es extensa y está mezclada con contenido irrelevante o difícil de localizar. 

Aunque los modelos actuales cada vez pueden manejar ventanas de contexto más grandes, esto no quiere decir que toda la información se vaya a utilizar con la misma eficacia. Cuando el contexto crece demasiado puede aumentar el costo y la latencia, y también puede resultar más difícil localizar o utilizar correctamente la información relevante.

Además de manera análoga a nuestro ejemplo, la ventana de contexto es también limitada. Para trabajar durante periodos prolongados, algunos sistemas eliminan información anterior o utilizan mecanismos de compactación que conservan el estado más relevante utilizando menos tokens. Sin embargo, durante este proceso podrían perderse algunos detalles, por lo que sigue siendo conveniente evitar cargar información innecesaria desde el principio.

Entonces, cuando ponemos un skill a disposición de un agente, es como decirle: "Hey agente, cuando trabajes este tipo de tarea, aquí puedes encontrar instrucciones y recursos que podrían ayudarte". Inicialmente, el agente solo recibe algunos metadatos del skill, esto es básicamente su nombre y descripción. Análogamente a nuestro ejemplo, es como si únicamente supiera que tiene a disposición una guía de productos y sus códigos de barras. No necesita leer toda la lista desde el principio; solo sabe que existe y que puede consultarla. Si detecta que el skill puede ser relevante para la tarea, carga las instrucciones de su archivo SKILL.md y posteriormente consulta documentos de referencia, scripts o utiliza otros recursos conforme los necesite. Este proceso se conoce como divulgación progresiva (progressive disclosure).

Estructura de un skill

La estructura de un skill es la siguiente:

nombre-del-skill/

├── SKILL.md              # Obligatorio

├── references/           # Documentación de apoyo, opcional

├── scripts/              # Código ejecutable, opcional

└── assets/               # Plantillas y otros recursos, opcional

SKILL.md

Vamos que lleva esto, el primero de ellos es el archivo SKILL.md:  

______________________________________________________________________

---

name: validating-evidences

description: Validates evidence and generates a report. Use when reviewing evidence packages.

---

# Instructions 

When you use this skill:

1. Review the input entry

2. Follow this procedure

3. Validate the result

4. Show the output in this format

For more detail rules, review:

- `references/rules.md`

For validation, execute:

- `scripts/validation.py`

______________________________________________________________________

El nombre solo puede contener letras minúsculas, números y guiones; no puede empezar o terminar con un guión ni contener guiones consecutivos. Además, debe coincidir con el nombre de la carpeta, máximo 64 caracteres, y aunque no es un requisito en algunas guías se recomienda utilizar gerundio (por ejemplo, processing-pdfs).

En el caso de la descripción, contiene la explicación de que hace el skill y cuándo conviene utilizarlo. Normalmente se recomienda redactar en tercera persona, contener términos clave y contextos de activación, máximo 1024 caracteres.

De manera general, se recomienda que el archivo no pase de las 500 líneas. No es obligatorio escribirlo en inglés; sin embargo, hacerlo puede facilitar su reutilización y colaboración entre equipos internacionales. Además, algunas evaluaciones multilingües han encontrado diferencias de rendimiento entre idiomas, particularmente entre el inglés y los idiomas con menos datos disponibles. Esto depende del modelo, el idioma y el tipo de tarea, por lo que escribir un skill en inglés no es una restricción ni un requisito técnico.

references/

Esta carpeta es opcional y aquí podríamos tener información de apoyo:

references/

├── rules.md

├── api-specification.yaml

└── evidence-schema.json

scripts/

En esta carpeta se pueden encontrar scripts que puedan ser de utilidad para realizar la tarea, por ejemplo:

scripts/

├── validation.py

├── check_evidence.js

└── generate_report.sh

No necesariamente deben estar en un lenguaje específico (como Python por ejemplo), tampoco todos en el mismo lenguaje, pero sí conviene incluir en el SKILL.md las instrucciones para que el agente sepa cómo utilizarlos.

Esta carpeta es opcional; no todos los skill necesitan tener scripts. 

assets/

La idea es que esta carpeta contenga archivos que se utilizan para generar el resultado, como formatos, plantillas, imágenes, etc.

assets/
├── report-template.docx
├── results-template.xlsx
└── logo.png

¿Y quién o quienes los hacen?

Ok, aquí viene lo más interesante de todo esto: podemos pedirle a un agente de IA que nos ayude a construir el skill. Podemos darle los lineamientos generales, el objetivo y algunos ejemplos, y este lo va a generar con la estructura recomendada. Esto no quiere decir que lo creará 100% como lo necesitamos. Si llegaste hasta aquí ahora ya conoces la estructura de un skill, por lo que podemos revisar el contenido, instrucciones, scripts y demás recursos, para validar que cumplan con lo que necesitamos.

Pero espera, esto no termina aquí. Una estrategia interesante consiste en separar la creación y la prueba del skill entre dos agentes. Por ejemplo, un agente A construye el skill, y otro agente B lo utiliza. Si en los resultados encontramos errores o cosas por mejorar, esto se documenta y se lo pasamos al agente A para que ajuste el Skill. Posteriormente se lo damos de nuevo al B y, como puedes ver aquí tenemos ese ciclo de mejora para nuestros skills.

Elaboración propia basada en el ciclo de creación, evaluación y mejora de skills.

¿Dónde puedo compartir mis skills?

Bueno, lo simple es crear un repositorio, por ejemplo en GitHub, y compartirlos desde ahí. Sin embargo, uno de los directorios más populares es https://www.skills.sh/ operado por Vercel. Este sitio permite explorar skills para diferentes agentes, como Claude Code, Codex y Gemini, y también consultar cuáles son los más utilizados, cuáles provienen de organizaciones reconocidas y cuáles cuentan con alguna auditoría de seguridad.

Los skills alojados en GitHub pueden aparecer automáticamente en este directorio cuando los usuarios los instalan mediante el comando:

$ npx skills add <owner/repo>

ejemplo:

$ npx skills add omaryahir/el-skill

⚠ Importante - Nota de Seguridad: Como te puedes dar cuenta podemos consumir skills creados por otras personas u organizaciones. Antes de utilizar cualquier skill, es importante revisar sus instrucciones, scripts y demás recursos, ya que podrían indicarle al agente que ejecute código o acceda a archivos del entorno para realizar acciones no deseadas o incluso inseguras.

Por el momento, hasta aquí llegamos, espero te sea de utilidad!

Referencias:

Lost in the Middle: How Language Models Use Long Contexts

https://arxiv.org/abs/2307.03172

Degradación del rendimiento con entradas de contexto extensas.

Agent Skills

https://agentskills.io/specification

Skills.sh Documentation

https://www.skills.sh/docs

Problemas con virtualenvwrapper en Python 3.8 +

Ok estuve teniendo unos problemillas tratando de instalar virtualenvwrapper con Python 3.8, si ya se que esta versión trae un manejo de ambientes incluido, pero a poco no es cómodo utilizar un simple $ workon myenv y listo ahi esta tu ambiente sin necesidad de estar buscando la carpeta del proyecto, bueno entonces me puse manos a la obra e hice mi propio virtualenvwrapper es super sencillo y solo tiene los comandos más básicos pero funciona aquí te dejo un link para que lo pruebes:

https://github.com/omaryahir/virtualenvwrapper
(echa un lente ^)

Espero te sea de utilidad !

Intro al Tipado de Python

Listado de Tipos:

from typing import (
    Dict,
    List,
    Tuple,
    Set,
    Deque,
    NamedTuple,
    IO,
    Pattern,
    Match,
    Text,
    Optional,
    Sequence,
    Iterable,
    Mapping,
    MutableMapping,
    Any,
)

Ejemplo(s):

### Clases

from typing import ClassVar, Dict, List

class Foo:

    x: int = 1  # instance variable. default = 1
    y: ClassVar[str] = "class var"  # class variable

    def __init__(self) -> None:
        self.i: List[int] = [0]

    def foo(self, a: int, b: str) -> Dict[int, str]:
        return {a: b}

foo = Foo()
foo.x = 123

### ContextManager

from typing import ContextManager, Generator, IO
from contextlib import contextmanager

@contextmanager
def open_file(name: str) -> Generator:
    f = open(name)
    yield f
    f.close()

cm: ContextManager[IO] = open_file(__file__)
with cm as f:
    print(f.read())

Referencias:

https://www.pythonsheets.com/notes/python-typing.html

Git Cherry Pick / git-cherry-pick

 Saludos Estimados !!

Hace mucho tiempo que no escribo aquí, y hoy me tope con algo que ya había realizado muchas veces en el pasado pero me enrede y ya no me salía, por lo que les compartó y/o me autocomparto por si lo vuelvo a necesitar el buen git-cherry-pick.

No es muy recomendable ya que un abuso de este comando puede dejarte una buena enredadera que después es difícil encontrarle forma, pero si que es útil como en el siguiente caso.

Necesitamos pasar un commit de un branch a otro, esto por que el branch original quedo muy desactualizado y por error se utilizó, es verdad que el rebase es una opción pero será un largo camino que recorrer además de que puede prestarse a errores de dedo en el camino, so el cherry pick en este caso nos resulta más económico además que no son muchos cambios que pueden revisarse fácilmente aquí los pasos:

1. Nos movemos a la branch donde tenemos nuestro commit: 

    git checkout MiBranchConCommit

2. Ahora vamos a revisar cuál es el hash de nuestro commit:

    git log --one line

    La salida de este comando será algo como:

    86f82f9 (HEAD -> SSCI-101-cherry-pick, origin/SSCI-101-cherry-pick) BRANCH-01test 1

    90805b1 (origin/master, origin/SSCI-85, origin/HEAD, master) BRANCH-02 test 2

    c3451b8 BRANCH test 3

    Vamos a tomar el último de este commit por lo que el número será: 86f82f9

3. Ahora vamos al branch de destino:

    git checkout BranchDestino

4. Una vez que nos encontremos ahí entonces aplicaremos el siguiente comando:

    git cherry-pick 86f82f9

Con este último comando se aplicará el mismo commit a este branch. Una opción interesante (que usualmente utilizo) solo en caso de que tuviéramos la misma base (o HEAD) en las ramas seria utilizar:

    git cherry-pick 86f82f9 --ff

Esta opción --ff hace referencia a fast forward existen más opciones por acá https://git-scm.com/docs/git-cherry-pick sin embargo este nos colocará el commit hacia adelante o por arriba de todos los previous commits.

¿Cómo ves?, si consideras que puede haber otros caminos, te agradezco me los compartas en los comentarios.

Espero te sea de utilidad !

Referencias:

https://git-scm.com/docs/git-cherry-pick

Detalle con Google Chrome Free 3 of 9 Extended

El día de hoy me tope con un detalle con Google Chrome y la fuente Free 3 of 9 Extended usualmente la fuente funcionaba correctamente en una aplicación me toco desarrollar alguna vez pero derepente empezó a fallar, buscando en línea me encontre con que había al parecer un detalle con la forma en que renderiza las fuentes, y bueno finalmente con el link que agrego a las referencias una forma de como solucionarlo, lo que me funciono a mí fue en el código html colocar la fuente directamente en el tag usando el atributo style y sin colocar la palabra Extended en la fuente de la siguiente forma:

<font style="font-family:'Free 3 of 9'">*123*</font>

NOTA: Observen las comillas simples ' para la fuente.

De esta forma el problema se soluciono.


Espero te sea de utilidad !


Referencias
https://productforums.google.com/forum/#!topic/chrome/_KLiTgccPLA
https://productforums.google.com/forum/#!topic/chrome/Vd5abMVzKFI

Detalle con Google Chrome Free 3 of 9 Extended

El día de hoy me tope con un detalle con Google Chrome y la fuente Free 3 of 9 Extended usualmente la fuente funcionaba correctamente en una aplicación me toco desarrollar alguna vez pero derepente empezó a fallar, buscando en línea me encontre con que había al parecer un detalle con la forma en que renderiza las fuentes, y bueno finalmente con el link que agrego a las referencias una forma de como solucionarlo, lo que me funciono a mí fue en el código html colocar la fuente directamente en el tag usando el atributo style y sin colocar la palabra Extended en la fuente de la siguiente forma:

<font style="font-family:'Free 3 of 9'">*123*</font>

NOTA: Observen las comillas simples ' para la fuente.

De esta forma el problema se soluciono.


Espero te sea de utilidad !


Referencias
https://productforums.google.com/forum/#!topic/chrome/_KLiTgccPLA
https://productforums.google.com/forum/#!topic/chrome/Vd5abMVzKFI