Como los agentes de IA implementan habilidades en la practica: comparacion completa entre plataformas

Introduccion

Todos los frameworks de agentes de IA enfrentan la misma pregunta fundamental: como hacer que un LLM sea bueno en algo especifico? El modelo en si tiene un amplio conocimiento general, pero cuando necesitas que realice una revision de codigo, despliegue infraestructura o navegue en Minecraft, necesita instrucciones especializadas, acceso a herramientas y contexto de dominio.

Este es el problema de la inyeccion de habilidades. Y cada framework principal lo resuelve de manera diferente.

Algunas plataformas vuelcan todo en el prompt del sistema desde el principio. Otras usan carga diferida, revelando capacidades solo cuando el agente las necesita. Algunas usan bases de datos vectoriales para recuperar habilidades relevantes basandose en similitud semantica. Las diferencias no son academicas: afectan directamente los costos de tokens, la fiabilidad del agente y cuantas habilidades puede manejar un agente de manera realista.

Analizamos 11 plataformas principales de agentes de IA para entender exactamente donde se ubican las habilidades en el prompt, cuando se cargan, cuanto cuestan en tokens y como sobreviven cuando la ventana de contexto se llena. Esta no es una comparacion superficial de caracteristicas. Revisamos el codigo fuente, la documentacion y los diagramas de arquitectura para mapear los mecanismos de inyeccion precisos de cada plataforma.

Tabla comparativa principal

Aqui esta la vision general completa antes de entrar en los detalles.

Mecanismos de inyeccion: donde, cuando y como

Persistencia, costo de tokens y comportamiento siempre activo

¿Listo para hacer crecer tu negocio?

Comienza tu prueba gratuita hoy y ve resultados en días.

Solicitar demo Iniciar sesión

Que significa realmente “inyeccion de habilidades”

Antes de profundizar en la comparacion, definamos el espacio del problema. La ventana de contexto de un agente de IA —el texto total que el LLM ve en cada llamada— tiene un tamano fijo. Cada token de instruccion, historial de conversacion, definicion de herramienta y datos recuperados compite por espacio en esa ventana.

Una “habilidad” en el contexto del agente es cualquier paquete estructurado de experiencia que cambia como se comporta el agente. Esto puede ser:

• Instrucciones que le dicen al agente como abordar un dominio especifico (directrices de revision de codigo, listas de verificacion de despliegue)
• Definiciones de herramientas que le dan al agente funciones invocables (integraciones de API, operaciones de archivos)
• Ejemplos few-shot que le muestran al agente como se ve una buena salida
• Conocimiento recuperado de bases de datos vectoriales o documentos externos

El mecanismo de inyeccion —donde y cuando este contenido entra en el contexto— determina tres propiedades criticas:

1. Eficiencia de tokens: Cuantos tokens consume la habilidad, y ese costo se paga incluso cuando la habilidad no se necesita?
2. Fiabilidad: El agente usara la habilidad de manera consistente cuando sea relevante, o podria perder la senal?
3. Escalabilidad: Cuantas habilidades puede acceder el agente antes de que la saturacion del contexto degrade el rendimiento?

Cada framework hace diferentes concesiones en estas tres dimensiones. Examinemos cada uno.

El espectro de inyeccion: de siempre activo a bajo demanda

En las 11 plataformas, los enfoques de inyeccion de habilidades se distribuyen a lo largo de un espectro desde “todo cargado por adelantado” hasta “nada cargado hasta que se necesite explicitamente.”

En un extremo, plataformas como CrewAI, SuperAGI y CAMEL-AI inyectan el contenido completo de cada habilidad activada en cada llamada al LLM. El agente siempre tiene toda su experiencia disponible. Simple, fiable, pero costoso en tokens.

En el otro extremo, Claude Code, LangChain Deep Agents y la API de Responses de OpenAI usan divulgacion progresiva: el agente ve solo los nombres y descripciones breves de las habilidades al inicio, y el contenido completo se carga bajo demanda. Eficiente, escalable, pero requiere que el agente reconozca cuando necesita una habilidad.

En el medio, AutoGen Teachability y Voyager usan recuperacion semantica para inyectar solo las habilidades mas relevantes por turno, creando un patron de inyeccion dinamico y sensible al contexto.

Y luego hay enfoques unicos: DSPy compila ejemplos few-shot optimizados offline y los incorpora permanentemente en los prompts de los modulos. MetaGPT codifica habilidades como plantillas de accion que se activan solo cuando un rol especifico transiciona a una accion especifica.

Examinemos cada uno en detalle.

Únete a nuestro boletín

Obtén los últimos consejos, tendencias y ofertas gratis.

Dirección de correo electrónico

Suscribirse

Claude Code: divulgacion progresiva en tres capas

Claude Code implementa una de las arquitecturas de inyeccion de habilidades mas sofisticadas, utilizando un sistema de divulgacion progresiva de tres capas que equilibra el conocimiento con la eficiencia de tokens.

Capa 1: siempre en el contexto

Al inicio de la sesion, el nombre y la descripcion de cada habilidad disponible se inyectan en un mensaje system-reminder —un bloque de metadatos que el modelo siempre ve. Esto cuesta aproximadamente 250 caracteres por habilidad, consumiendo alrededor del 1% del presupuesto de la ventana de contexto para todas las descripciones de habilidades combinadas (aproximadamente 8K caracteres como presupuesto de respaldo, configurable via la variable de entorno SLASH_COMMAND_TOOL_CHAR_BUDGET).

De manera similar, las herramientas diferidas —herramientas cuyos esquemas JSON completos aun no se han cargado— aparecen como una lista de solo nombres en bloques system-reminder. A partir de Claude Code v2.1.69, incluso las herramientas del sistema integradas como Bash, Read, Edit, Write, Glob y Grep se difieren detras de ToolSearch, reduciendo el contexto de herramientas del sistema de aproximadamente 14-16K tokens a aproximadamente 968 tokens.

El agente ve lo suficiente para saber que esta disponible sin pagar el costo de tokens de las definiciones completas.

Capa 2: al activarse

Cuando un usuario escribe un comando slash (por ejemplo, /commit) o el modelo auto-coincide una habilidad basandose en su descripcion, el cuerpo completo del SKILL.md se carga como un mensaje de conversacion a traves de la herramienta Skill. Este cuerpo contiene las instrucciones completas —a veces miles de tokens de orientacion detallada.

Detalle clave: el preprocesamiento de shell se ejecuta primero (cualquier directiva !command en el archivo de habilidad se ejecuta y su salida reemplaza la directiva), y una vez cargado, el cuerpo de la habilidad permanece en la conversacion durante el resto de la sesion.

Capa 3: bajo demanda

Los recursos adicionales —documentos de referencia, scripts, archivos de activos— solo se leen cuando el modelo decide explicitamente usar la herramienta Read para acceder a ellos. Estos nunca se cargan automaticamente.

Comportamiento de compactacion de contexto

Cuando la conversacion se acerca al limite de contexto y se activa la compactacion, Claude Code vuelve a adjuntar las habilidades invocadas mas recientemente con un presupuesto de 5K tokens por habilidad y un maximo combinado de 25K. Las habilidades invocadas mas recientemente obtienen prioridad. Las habilidades mas antiguas pueden eliminarse por completo.

Esta arquitectura de tres capas significa que un agente con mas de 20 habilidades disponibles paga un costo inicial minimo pero puede acceder a la experiencia completa de cualquiera de ellas en un solo turno.

CrewAI: inyeccion completa en cada prompt de tarea

CrewAI adopta el enfoque opuesto a la divulgacion progresiva. Cuando una habilidad se activa para un agente, su contenido completo se inyecta en cada prompt de tarea que el agente ejecuta.

Como funciona

Las habilidades en CrewAI son directorios autocontenidos, cada uno con un archivo SKILL.md que contiene frontmatter YAML (nombre, descripcion, licencia, compatibilidad, herramientas permitidas) y un cuerpo en markdown. El sistema de habilidades distingue entre habilidades y herramientas: las habilidades inyectan instrucciones y contexto que dan forma a como piensa el agente, mientras que las herramientas proporcionan funciones invocables para acciones.

Durante la inicializacion del agente, Agent.set_skills() llama a discover_skills() para escanear directorios de habilidades a nivel de metadatos, luego activate_skill() para leer los cuerpos completos de las habilidades. En el momento de ejecucion de la tarea, _finalize_task_prompt() llama a format_skill_context() para cada habilidad activada y agrega todo el contenido formateado de habilidades al prompt de la tarea.

El LLM recibe: [mensaje del sistema] + [prompt de tarea + TODOS los cuerpos de habilidades]

Implicaciones de tokens

CrewAI impone una advertencia suave a 50,000 caracteres por habilidad pero sin limite estricto. La documentacion recomienda mantener las habilidades enfocadas y concisas porque las grandes inyecciones de prompt diluyen la atencion del modelo —una preocupacion real dada la investigacion sobre la degradacion del contexto.

La concesion es directa: el agente siempre tiene toda la experiencia disponible (alta fiabilidad), pero el costo de tokens escala linealmente con el numero de habilidades por tarea (baja eficiencia). Para agentes con 1-2 habilidades enfocadas, esto funciona bien. Para agentes que necesitan conjuntos amplios de capacidades, se vuelve costoso rapidamente.

Sin persistencia entre tareas

Cada tarea recibe una inyeccion fresca. No hay acumulacion de contenido de habilidades entre tareas —lo cual es en realidad una caracteristica, no un error. Significa que cada tarea comienza con un contexto limpio, evitando los problemas de obsolescencia que la persistencia basada en sesiones puede crear.

LangChain Deep Agents: carga controlada por el agente via SkillsMiddleware

LangChain Deep Agents implementa un sofisticado sistema de habilidades basado en middleware donde el propio agente decide cuando cargar el contenido completo de una habilidad —un verdadero modelo de divulgacion progresiva donde el agente controla la activacion.

Los tres niveles

Nivel 1 (Indice): SkillsMiddleware analiza todos los frontmatter de SKILL.md al inicio e inyecta un indice ligero en el prompt del sistema. Este indice contiene solo nombres y descripciones, costando aproximadamente 278 tokens por habilidad versus 3,302 tokens para el contenido completo.

Nivel 2 (Contenido completo): Cuando el agente determina que una habilidad es relevante, llama a read_file() en la ruta del SKILL.md de la habilidad. Esta es una llamada de herramienta regular —el framework no inyecta el cuerpo; el agente toma una decision deliberada de cargarlo. El contenido completo entra en el historial de conversacion como resultado de herramienta.

Nivel 3 (Profundizacion): Los materiales de apoyo, documentos de referencia y scripts solo se acceden cuando el agente los lee explicitamente.

Eficiencia de tokens en la practica

Con 12 habilidades, la divulgacion progresiva reduce el contexto de aproximadamente 30,000 tokens (todo cargado) a aproximadamente 600 tokens (solo indice), expandiendose a 2,000-5,000 cuando las habilidades relevantes se cargan para una tarea especifica. Eso es una reduccion potencial del 83-98% en el consumo de tokens relacionado con habilidades.

Se pueden superponer multiples fuentes de habilidades, y cuando los nombres colisionan, la ultima fuente gana. Los archivos de mas de 10 MB se saltan automaticamente.

La diferencia clave con Claude Code

Mientras que Claude Code usa una herramienta Skill dedicada para activar la carga, Deep Agents reutiliza la herramienta read_file existente del agente. Esto significa que el mecanismo de carga es transparente —el agente lee archivos de habilidades de la misma manera que lee cualquier otro archivo. La desventaja es que no hay un comportamiento especial de compactacion: el contenido de habilidades que entra en el historial de conversacion esta sujeto al recorte estandar de mensajes de LangChain, sin tratamiento prioritario.

OpenAI Responses API y Agents SDK: carga diferida gestionada por la plataforma

OpenAI implementa la inyeccion de habilidades a traves de dos mecanismos distintos pero filosoficamente alineados: el tipo de herramienta tool_search de la API de Responses y el ToolSearchTool del Agents SDK.

Responses API: tool_search

El tipo de herramienta tool_search (disponible en GPT-5.4+) permite a los desarrolladores diferir grandes superficies de herramientas hasta el tiempo de ejecucion. Hay tres estrategias de aplazamiento disponibles:

• Aplazamiento de funcion individual: @function_tool(defer_loading=True) — el modelo ve el nombre y la descripcion de la funcion pero el esquema de parametros se difiere. Ahorra tokens a nivel de parametros.
• Aplazamiento de namespace: tool_namespace(name=..., description=..., tools=[...]) — agrupa funciones bajo un unico namespace. El modelo ve solo el nombre y la descripcion del namespace, ahorrando significativamente mas tokens.
• Aplazamiento de servidor MCP: HostedMCPTool(tool_config={..., "defer_loading": True}) — difiere superficies de herramientas de servidores MCP completos.

Cuando el modelo determina que necesita una herramienta especifica, emite una llamada tool_search. La API devuelve 3-5 definiciones de herramientas relevantes, inyectadas al final de la ventana de contexto para preservar el almacenamiento en cache del prompt.

Agents SDK: ToolSearchTool

El Agents SDK proporciona un equivalente programatico. Los namespaces de herramientas se registran pero no se cargan:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

En tiempo de ejecucion, el agente ve solo los nombres de los namespaces. Llama a ToolSearchTool("crm") para descubrir y cargar los esquemas completos, y luego puede llamar a herramientas individuales dentro de ese namespace.

Sin persistencia entre solicitudes

Cada solicitud API es independiente. Las herramientas descubiertas no persisten entre llamadas. Este es el enfoque mas sin estado de nuestra comparacion —limpio, predecible, pero requiere re-descubrimiento en cada solicitud si las herramientas cambian.

AutoGen Teachability: recuperacion semantica por turno

La capacidad Teachability de AutoGen adopta un enfoque fundamentalmente diferente de todos los demas frameworks en esta comparacion. En lugar de inyectar contenido de habilidades estatico, recupera dinamicamente “memos” relevantes de una base de datos vectorial ChromaDB en cada turno individual.

El bucle de recuperacion por turno

Teachability registra un hook en process_last_received_message que intercepta cada mensaje entrante del usuario antes de que el agente lo procese:

1. Un TextAnalyzerAgent extrae conceptos clave del mensaje entrante
2. Estos conceptos se usan para consultar ChromaDB (usando embeddings de Sentence Transformer por defecto)
3. Los top-K memos mas relevantes se recuperan (configurable via max_num_retrievals, por defecto 10)
4. Los memos recuperados se agregan al texto del mensaje antes de que el agente lo vea

Punto critico: el mensaje modificado no se propaga al historial de conversacion almacenado —solo se almacena el mensaje original. Esto evita que el contenido de los memos se acumule entre turnos.

Bucle de aprendizaje

Despues de que el LLM responde, un segundo hook analiza la respuesta en busca de nuevos aprendizajes:

1. TextAnalyzerAgent identifica nuevo conocimiento en la respuesta
2. Se extraen nuevos memos como pares clave-valor (texto de entrada -> texto de salida)
3. Estos memos se almacenan en ChromaDB, disponibles para futuros turnos y sesiones

Esto crea un genuino bucle de aprendizaje donde el agente acumula experiencia con el tiempo.

Persistencia entre sesiones

AutoGen Teachability es una de solo tres plataformas en nuestra comparacion (junto con Voyager y DSPy) que persiste habilidades entre sesiones. La base de datos ChromaDB vive en disco, lo que significa que un agente puede aprender de interacciones el lunes y aplicar ese conocimiento el viernes.

El parametro recall_threshold (por defecto 1.5) controla cuan similar debe ser un mensaje a un memo almacenado para la recuperacion, y reset_db puede borrar toda la memoria cuando sea necesario.

Eficiencia de tokens

Dado que solo los memos relevantes se inyectan por turno (tipicamente 3-5), el costo de tokens esta naturalmente acotado independientemente de cuan grande crezca la base de datos de memos. Un agente con 10,000 memos almacenados solo paga por el punado mas relevante para el turno actual.

Semantic Kernel: esquemas de plugins como definiciones de herramientas siempre presentes

Semantic Kernel de Microsoft adopta un enfoque directo: los plugins son colecciones de objetos KernelFunction registrados con el Kernel, y sus esquemas se exponen al LLM como definiciones de herramientas de function-calling.

Dos rutas de inyeccion

Function Calling: Cuando se establece ToolCallBehavior.AutoInvokeKernelFunctions, todas las funciones registradas se envian al LLM como herramientas disponibles en cada solicitud API. El LLM decide cual llamar; Semantic Kernel maneja la invocacion y el enrutamiento de resultados.

Plantillas de prompt: La sintaxis de plantillas de Semantic Kernel ({{plugin.function}}, Handlebars o Liquid) permite llamar funciones inline durante el renderizado del prompt. Los resultados se incrustan directamente en el texto del prompt antes de que llegue al LLM —una forma de evaluacion anticipada en lugar de llamada diferida de herramientas.

Sin divulgacion progresiva

El esquema de cada plugin registrado se incluye en cada llamada API. No hay carga diferida integrada, agrupacion por namespace ni activacion bajo demanda. La documentacion recomienda explicitamente importar solo los plugins necesarios para un escenario especifico para reducir el consumo de tokens y las llamadas erroneas.

Esto hace que Semantic Kernel sea una de las plataformas mas predecibles —siempre sabes exactamente a que tiene acceso el agente— pero limita la escalabilidad. Un agente con 50 funciones registradas paga el costo completo del esquema en cada llamada individual.

Persistencia

El registro de plugins es por instancia de Kernel y en memoria. No hay un mecanismo integrado para persistencia de habilidades entre sesiones.

MetaGPT: plantillas de accion dentro de SOPs basados en roles

MetaGPT codifica habilidades no como paquetes independientes sino como plantillas de accion incrustadas dentro de Procedimientos Operativos Estandar (SOPs) que gobiernan el comportamiento del rol.

Arquitectura de Role y Action

Cada Role en MetaGPT tiene un prefijo de persona inyectado en los prompts y un conjunto de clases Action. Cada Action contiene un proxy LLM invocado via aask(), que usa plantillas de prompts en lenguaje natural para estructurar la llamada al LLM.

Cuando se ejecuta Role._act(), soporta tres modos de reaccion:

• "react": El LLM selecciona acciones dinamicamente en bucles de pensar-actuar
• "by_order": Las acciones se ejecutan secuencialmente en un orden predeterminado
• "plan_and_act": El agente planifica primero, luego ejecuta las acciones segun el plan

Ventana de inyeccion estrecha

Solo la plantilla de prompt de la Action actual esta activa en un momento dado. El agente no ve plantillas de otras acciones —solo ve su prefijo de rol mas el contexto de la accion especifica. Esta es la ventana de inyeccion mas estrecha de todos los frameworks que examinamos.

Las funciones de analisis de contexto dentro de las clases Action extraen informacion relevante de las entradas, de modo que cada accion recibe un subconjunto curado del contexto disponible en lugar del historial completo de conversacion.

Persistencia de un solo turno

La plantilla se renderiza de nuevo para cada ejecucion de accion. No hay acumulacion ni persistencia entre sesiones. Esto mantiene cada accion enfocada pero significa que el agente no puede construir sobre contenido de habilidades previamente cargado dentro de un mismo flujo de trabajo.

Voyager: recuperacion de habilidades basada en embeddings para aprendizaje de por vida

Voyager, el agente de exploracion de Minecraft de NVIDIA y Caltech, implementa una de las arquitecturas de inyeccion de habilidades mas elegantes: una biblioteca creciente de programas verificados recuperados por similitud de embeddings.

La biblioteca de habilidades

Cuando Voyager escribe codigo que pasa la auto-verificacion (el JavaScript generado de Mineflayer realmente funciona en el juego), el codigo y su cadena de documentacion se almacenan en una base de datos vectorial. El embedding del docstring se convierte en la clave de recuperacion.

Recuperacion por tarea

En cada nueva tarea propuesta por el curriculum automatico:

1. La descripcion de la tarea y la retroalimentacion del entorno se convierten en embeddings
2. Busqueda de similitud coseno contra todos los embeddings de habilidades almacenados
3. Se recuperan las top-5 habilidades mas relevantes
4. El codigo de habilidades recuperado se incluye en el prompt del agente de accion como ejemplos few-shot

El prompt se ve asi:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

El codigo generado puede llamar habilidades recuperadas por nombre, habilitando la construccion composicional de habilidades —comportamientos complejos construidos a partir de primitivas mas simples y verificadas.

Persistencia de por vida

La biblioteca de habilidades es el mecanismo central de “aprendizaje de por vida”. Crece a lo largo de toda la vida del agente, y las nuevas habilidades se construyen sobre las antiguas. A diferencia de la mayoria de los frameworks donde las habilidades son creadas por humanos, las habilidades de Voyager son generadas, verificadas y almacenadas por el propio agente.

El costo de tokens esta naturalmente acotado: independientemente de si la biblioteca contiene 50 o 5,000 habilidades, cada tarea solo paga por las 5 recuperaciones mas relevantes.

DSPy: ejemplos few-shot compilados como habilidades congeladas

DSPy adopta un enfoque radicalmente diferente de todos los demas frameworks. En lugar de inyectar habilidades en tiempo de ejecucion, DSPy compila demostraciones few-shot optimas offline y las incorpora permanentemente en los prompts de los modulos.

El proceso de compilacion

Dos optimizadores principales manejan la compilacion:

BootstrapFewShot: Usa un modulo profesor para generar trazas a traves del programa. Las trazas que pasan una metrica definida por el usuario se mantienen como demostraciones. Cada modulo dspy.Predict dentro del programa obtiene su propio conjunto curado de demostraciones.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Un proceso en tres fases:

1. Bootstrap: Generar conjuntos candidatos de demostraciones
2. Proponer: Generar textos de instrucciones candidatos que sean conscientes tanto de la distribucion de datos como de las demostraciones
3. Busqueda: Optimizacion bayesiana sobre el espacio combinado de instrucciones x demostraciones en todos los modulos

Parametros como max_bootstrapped_demos (ejemplos generados) y max_labeled_demos (de datos de entrenamiento) controlan cuantos ejemplos terminan en el prompt de cada modulo.

Fijo despues de la compilacion

Una vez compiladas, las demostraciones se almacenan en el atributo demos de cada modulo Predict y se formatean en el prompt en cada llamada al LLM. No cambian en tiempo de ejecucion —la “habilidad” esta congelada.

Esto significa que las habilidades de DSPy son las mas predecibles de nuestra comparacion: el costo de tokens se conoce despues de la compilacion, no hay varianza entre turnos, y el agente siempre ve las mismas demostraciones. La desventaja es la inflexibilidad —para cambiar habilidades, debes recompilar.

Persistencia

Los programas compilados se serializan a JSON, incluyendo todas las demostraciones. Son completamente persistentes y cargables entre sesiones, haciendo de DSPy uno de los mecanismos de almacenamiento de habilidades mas duraderos.

SuperAGI: registro anticipado basado en toolkits

SuperAGI usa un patron de toolkit tradicional donde todas las herramientas se registran en la inicializacion del agente.

Cada toolkit extiende BaseToolkit con:

• Atributos name y description
• Metodo get_tools() que devuelve una lista de instancias de BaseTool
• get_env_keys() para variables de entorno requeridas

Los toolkits se instalan desde repositorios de GitHub via el gestor de herramientas de SuperAGI. En la inicializacion del agente, BaseToolkit.get_tools() devuelve todas las herramientas, y sus esquemas completos se exponen al LLM como definiciones de function-calling.

No hay carga diferida, no hay divulgacion progresiva y no hay filtrado por turno. Cada esquema de herramienta registrada esta presente en cada llamada. Este es el modelo de inyeccion mas simple y funciona bien para agentes con conjuntos de herramientas enfocados y pequenos, pero no escala a agentes que necesitan docenas de capacidades.

CAMEL-AI: registro de herramientas en ChatAgent

CAMEL-AI sigue un patron similar de registro anticipado. Las herramientas de varios toolkits (por ejemplo, MathToolkit, SearchToolkit) se pasan como una lista a ChatAgent(tools=[...]) en la inicializacion.

El framework enfatiza que las funciones personalizadas necesitan nombres de argumentos claros y docstrings completos para que el modelo pueda entender el uso —el esquema de la herramienta es el unico contenido de “habilidad” que el modelo ve. No hay un mecanismo separado de inyeccion de instrucciones.

Las adiciones recientes incluyen soporte MCP (Model Context Protocol) via MCPToolkit, permitiendo que ChatAgent se conecte a servidores MCP y registre herramientas externas. Esto expande la superficie de herramientas disponibles pero no cambia el modelo de inyeccion —todas las herramientas MCP descubiertas aun se registran por adelantado.

Comparacion entre plataformas

Cuando se inyectan las habilidades

Modelos de persistencia

Supervivencia a la compactacion de contexto

El patron de divulgacion progresiva

La tendencia arquitectonica mas significativa en estas plataformas es la adopcion de la divulgacion progresiva —un concepto tomado del diseno de interfaces donde la informacion se revela incrementalmente segun la necesidad.

Por que importa la divulgacion progresiva

Un enfoque ingenuo de inyeccion de habilidades —cargar todo por adelantado— crea dos problemas:

1. Desperdicio de tokens: La mayoria de las habilidades no son relevantes para la mayoria de los turnos. Cargar 20 cuerpos completos de habilidades cuando solo se necesitan 1-2 por turno desperdicia mas del 90% de los tokens relacionados con habilidades.
2. Dilucion de la atencion: La investigacion sobre la degradacion del contexto muestra que los LLMs rinden peor cuando su contexto contiene grandes cantidades de informacion irrelevante. Mas habilidades en el contexto pueden realmente reducir la calidad de la aplicacion de habilidades.

La divulgacion progresiva resuelve ambos problemas manteniendo un indice ligero de habilidades disponibles mientras carga el contenido completo solo cuando se necesita.

Variaciones de implementacion

Claude Code usa un sistema dedicado: metadatos de habilidades en mensajes system-reminder, una herramienta Skill para activacion y ToolSearch para esquemas de herramientas diferidas. El framework gestiona la inyeccion automaticamente con compactacion basada en prioridad.

LangChain Deep Agents usa la capacidad existente de lectura de archivos del agente: SkillsMiddleware inyecta el indice, y el agente carga el contenido completo via read_file(). Esto es mas transparente pero ofrece menos optimizacion a nivel de framework.

OpenAI Responses API usa agrupacion basada en namespaces con busqueda gestionada por la plataforma: los namespaces de herramientas proporcionan descripciones de alto nivel, y tool_search devuelve esquemas relevantes. La plataforma maneja la logica de busqueda completamente.

Ahorro de tokens en la practica

Los numeros son convincentes. Con 12 habilidades:

• Inyeccion siempre activa (estilo CrewAI/SuperAGI): ~30,000 tokens
• Solo indice de divulgacion progresiva: ~600 tokens
• Indice + 2 habilidades activadas: ~2,000-5,000 tokens

Eso es una reduccion del 83-98% en el consumo de tokens relacionado con habilidades por turno. A lo largo de una sesion larga con cientos de turnos, los ahorros se acumulan dramaticamente.

Patrones arquitectonicos y concesiones

Observando las 11 plataformas, emergen cuatro patrones arquitectonicos distintos:

Patron 1: inyeccion siempre activa

Usado por: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Como funciona: El contenido completo de habilidades o esquemas de herramientas estan presentes en cada llamada al LLM.

Ventajas:

• Maxima fiabilidad — el agente siempre tiene toda la experiencia disponible
• Implementacion mas simple — no se necesita logica de activacion
• Costos de tokens predecibles — iguales en cada turno

Desventajas:

• El costo de tokens escala linealmente con el numero de habilidades
• Dilucion de la atencion con muchas habilidades
• No escala mas alla de ~5-10 habilidades por agente

Mejor para: Agentes enfocados con 1-3 habilidades principales que siempre son relevantes.

Patron 2: divulgacion progresiva

Usado por: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Como funciona: Metadatos ligeros siempre presentes; contenido completo cargado bajo demanda.

Ventajas:

• Escala a docenas o cientos de habilidades disponibles
• Costo minimo de tokens cuando las habilidades no se necesitan
• Preserva la cache del prompt cuando los esquemas completos se agregan al final

Desventajas:

• El agente podria perder la senal para activar una habilidad relevante
• Latencia adicional del paso de activacion
• Implementacion de framework mas compleja

Mejor para: Agentes de proposito general que necesitan acceso a muchas capacidades pero usan solo unas pocas por tarea.

Patron 3: recuperacion semantica

Usado por: AutoGen Teachability, Voyager

Como funciona: Las consultas a bases de datos vectoriales revelan habilidades/conocimiento relevante basado en similitud semantica con el contexto actual.

Ventajas:

• Costo de tokens naturalmente acotado independientemente del tamano de la biblioteca
• La relevancia del contenido mejora con el tiempo a medida que crece la biblioteca
• Aprendizaje y acumulacion entre sesiones
• No se necesita activacion explicita — la relevancia se calcula automaticamente

Desventajas:

• La calidad de recuperacion depende de la calidad del modelo de embeddings
• Riesgo de recuperar informacion desactualizada o sutilmente incorrecta
• Requiere infraestructura de base de datos vectorial
• Menos predecible — diferentes turnos cargan diferente contenido

Mejor para: Agentes que aprenden de la experiencia y necesitan acumular conocimiento de dominio con el tiempo.

Patron 4: inyeccion compilada/estatica

Usado por: DSPy, MetaGPT

Como funciona: Las habilidades se compilan en contenido de prompt fijo (DSPy) o se activan a traves de plantillas de accion rigidas (MetaGPT).

Ventajas:

• Comportamiento mas predecible — mismo contenido cada vez
• La optimizacion se puede hacer offline (compilacion de DSPy)
• Sin sobrecarga en tiempo de ejecucion para la seleccion de habilidades
• Demostrado efectivo para tareas bien definidas y repetibles

Desventajas:

• Inflexible — cambiar habilidades requiere recompilacion (DSPy) o cambios de codigo (MetaGPT)
• No puede adaptarse a situaciones novedosas fuera de los ejemplos compilados
• El proceso de compilacion de DSPy en si requiere muchas llamadas al LLM

Mejor para: Pipelines de produccion con tareas bien definidas donde la fiabilidad supera a la flexibilidad.

Implicaciones practicas para constructores de agentes

Elegir el patron correcto

La arquitectura de inyeccion de habilidades correcta depende del perfil de tu agente:

Si tu agente tiene un rol estrecho y bien definido (por ejemplo, un bot de revision de codigo, un agente de soporte al cliente para un producto), la inyeccion siempre activa (patron CrewAI/SuperAGI) es la mas simple y fiable. El costo de tokens de 2-3 habilidades siempre presentes es manejable, y evitas la complejidad de la logica de activacion.

Si tu agente necesita capacidades amplias pero usa solo unas pocas por interaccion (por ejemplo, un asistente de desarrollo, un agente de automatizacion de proposito general), la divulgacion progresiva (patron Claude Code/Deep Agents) es el claro ganador. Los ahorros de tokens del 83-98% a escala son demasiado significativos para ignorar.

Si tu agente necesita aprender y mejorar de las interacciones (por ejemplo, un asistente personal, un experto de dominio que acumula conocimiento), la recuperacion semantica (patron AutoGen Teachability) proporciona el bucle de aprendizaje que otros patrones carecen. Solo asegurate de tener controles de calidad sobre lo que entra en la base de conocimiento.

Si tu agente ejecuta pipelines bien definidos (por ejemplo, procesamiento de datos, generacion de informes, flujos de trabajo estandarizados), la inyeccion compilada (patron DSPy) te da el comportamiento mas predecible y optimizado.

El enfoque hibrido

Para equipos de agentes en produccion donde los agentes necesitan funcionar de inmediato, recomendamos un enfoque hibrido:

Habilidades principales (1-2 por agente, definiendo su experiencia de dominio principal): siempre inyectadas en el prompt del sistema, estilo CrewAI. Estas son capacidades no negociables que el agente necesita en cada turno.

Habilidades extendidas (capacidades adicionales que el agente podria necesitar): solo metadatos en el prompt del sistema, cargadas via un mecanismo de busqueda/carga cuando se necesitan, estilo Deep Agents. Estas expanden el conjunto de capacidades del agente sin pagar el costo de tokens cuando no son relevantes.

Conocimiento aprendido (experiencia de dominio acumulada): almacenado en una base de datos vectorial y recuperado semanticamente por turno, estilo AutoGen. Esto permite que el agente mejore con el tiempo sin la creacion manual de habilidades.

Esta arquitectura en capas se mapea naturalmente a como se construye un prompt del sistema: fecha -> persona -> instrucciones del sistema -> habilidades principales -> indice de habilidades -> contexto de rol/equipo. Las habilidades principales y el indice agregan un costo de tokens predecible y manejable, mientras que los cuerpos completos de habilidades solo aparecen cuando se necesitan.

Mejores practicas de presupuesto de tokens en todos los frameworks

Independientemente de que patron de inyeccion uses, estas estrategias de gestion de tokens se aplican universalmente:

Ordenamiento compatible con cache

Apila el contexto que no cambia (instrucciones del sistema, esquemas de herramientas) al frente del prompt. En proveedores que soportan almacenamiento en cache de prompts, los tokens en cache cuestan un 75% menos. Claude Code y OpenAI inyectan los esquemas de herramientas descubiertos al final del contexto especificamente para preservar los aciertos de cache en el prefijo estatico.

Descarga

Resume las respuestas de herramientas en lugar de mantener los resultados completos en el contexto. Almacena los datos completos en referencias externas que el agente puede leer bajo demanda. Esto es especialmente importante para agentes que hacen muchas llamadas de herramientas por sesion.

Reduccion

Compacta el historial de conversacion mediante resumen. Extrae hechos clave de intercambios largos en representaciones condensadas. Cada framework con persistencia basada en sesiones se beneficia de una gestion agresiva del historial.

Recuperacion sobre pre-carga

Recupera dinamicamente la informacion relevante en tiempo de ejecucion en lugar de cargar todo por adelantado. Esto se aplica a habilidades, bases de conocimiento e incluso historial de conversacion. Los estudios muestran que esto puede reducir los tamanos de prompt hasta en un 70%.

Aislamiento

Usa sub-agentes para tareas especificas de modo que el contexto de cada agente se mantenga enfocado. En lugar de darle a un agente 20 habilidades, crea un equipo de 5 agentes con 4 habilidades cada uno. Cada agente mantiene una ventana de contexto compacta, y el equipo colectivamente cubre el conjunto completo de capacidades.

Conclusion

La forma en que los frameworks de agentes de IA inyectan habilidades en el contexto es una de las decisiones arquitectonicas mas consecuentes en el diseno de agentes —y sin embargo rara vez se discute a este nivel de detalle.

El campo esta convergiendo claramente hacia la divulgacion progresiva como el patron preferido para agentes de proposito general, con Claude Code, LangChain Deep Agents y OpenAI llegando independientemente a arquitecturas de tres niveles similares. Mientras tanto, patrones especializados como la recuperacion semantica (AutoGen, Voyager) y la inyeccion compilada (DSPy) sirven nichos importantes que la divulgacion progresiva por si sola no aborda.

Para los profesionales que construyen sistemas de agentes hoy, la idea clave es que la inyeccion de habilidades no es un problema de talla unica. El enfoque correcto depende del rol de tu agente, el numero de habilidades que necesita, si necesita aprender con el tiempo, y tu tolerancia a las concesiones entre costos de tokens y fiabilidad.

Los sistemas de produccion mas robustos probablemente combinaran multiples patrones —siempre activo para capacidades principales, divulgacion progresiva para habilidades extendidas y recuperacion semantica para conocimiento acumulado— creando agentes que sean tanto eficientes como expertos.