refleja el estado de Claude Skills, MCP y subagentes a febrero de 2026. La IA se mueve rápido, por lo que algunos detalles pueden estar desactualizados cuando lea esto. Sin embargo, los conceptos en los que se centra esta publicación son atemporales.
Si ha estado desarrollando LLM durante un tiempo, probablemente haya vivido este ciclo una y otra vez: se toma su tiempo para crear un mensaje excelente que genere resultados excelentes y luego, unos días después, necesita el mismo comportamiento nuevamente, por lo que comienza a realizar mensajes desde cero nuevamente. Después de algunas repeticiones, es posible que se dé cuenta de las ineficiencias, por lo que guardará la plantilla del mensaje en algún lugar para poder recuperarla para más adelante, pero incluso entonces necesita encontrar el mensaje, pegarlo y modificarlo para esta conversación en particular. Es tan tedioso.
Esto es lo que yo llamo la rueda de hámster de ingeniería rápida. Y es un flujo de trabajo fundamentalmente roto.
Claude Skills es la respuesta de Anthropic a este problema de “mensajes reutilizables”, y más. Más allá de simplemente salvarlo de indicaciones repetitivas, introducen un enfoque fundamentalmente diferente a la gestión del contexto, la economía de tokens y la arquitectura de los flujos de trabajo de desarrollo impulsados por IA.
En esta publicación, explicaré qué son realmente las habilidades y los subagentes, en qué se diferencian del MCP tradicional y hacia dónde se dirige la combinación de habilidad/MCP/subagente.
¿Qué son las habilidades?
En esencia, las habilidades son conjuntos de instrucciones reutilizables a las que los agentes de IA, como Claude, pueden acceder automáticamente cuando son relevantes para una conversación. Escribes un archivo Skill.md con algunos metadatos y un cuerpo de instrucciones, lo colocas en un directorio .claude/skills/ y Claude lo toma desde allí.
sus miradas
En su forma más simple, una habilidad es un archivo de rebajas con un nombre, una descripción y un cuerpo de instrucciones, como este:
— nombre: descripción: —
Sus puntos fuertes
La principal fortaleza de las habilidades radica en la autoinvocación. Al iniciar una nueva conversación, el agente solo lee el nombre y la descripción de cada habilidad para ahorrar tokens. Cuando determina que una habilidad es relevante, carga el cuerpo. Si el cuerpo hace referencia a archivos o carpetas adicionales, el agente también los lee, pero sólo cuando decide que son necesarios. En esencia, las habilidades son un contexto cargado de pereza. El agente no consume la instrucción completa configurada por adelantado. Se revela información progresivamente a sí mismo, obteniendo solo lo que se necesita para el paso actual.
Esta divulgación progresiva opera en tres niveles, cada uno con su propio presupuesto de contexto:
Metadatos (cargados al inicio): el nombre de la habilidad (máximo 64 caracteres) y descripción (máximo 1024 caracteres). Esto cuesta aproximadamente ~100 tokens por habilidad, una sobrecarga insignificante incluso con cientos de habilidades registradas. Cuerpo de habilidad (cargado al invocarlo): el conjunto de instrucciones completo dentro de Skill.md, hasta ~5000 tokens. Esto solo ingresa a la ventana de contexto cuando el agente determina que la habilidad es relevante. Archivos de referencia (cargados bajo demanda): archivos, carpetas o scripts de rebajas adicionales dentro del directorio de habilidades. Prácticamente no hay límite aquí, y el agente los lee a pedido, solo cuando las instrucciones hacen referencia a ellos y la tarea actual lo requiere.
Insight: Las habilidades son conjuntos de instrucciones reutilizables, de carga diferida y de invocación automática que utilizan la divulgación progresiva en tres niveles: metadatos, cuerpo y archivos de referencia. Esto minimiza el costo inicial al evitar volcar todo en la ventana contextual (mirándote, MCP 👀).
El problema de la economía simbólica
Factores de costo
No es ningún secreto; El espacio de la ventana de contexto de un agente no es gratuito y llenarlo tiene costos compuestos. Cada token en su ventana contextual le cuesta de tres maneras:
Costo real: el más obvio es que estás pagando por token. Esto puede ser directamente mediante el uso de API o indirectamente mediante límites de uso. Latencia: también estás pagando con tu tiempo, ya que más tokens de entrada significan respuestas más lentas. Algo que no se adapta bien a la longitud de la ventana de contexto (~mecanismo de atención). Calidad: finalmente, también hay una degradación de la calidad debido a las largas ventanas de contexto. Es evidente que los LLM obtienen peores resultados cuando su contexto está lleno de información irrelevante.
Los costosos gastos generales de los MCP
Pongamos esto en perspectiva, mediante un rápido cálculo aproximado. Mis opciones de MCP preferidas para la programación son:
AWS para implementación de infraestructura. Tres servidores (aws-mcp, aws-official, aws-docs) combinados generan un costo de alrededor de ~8500 tokens (13 herramientas). Context7 para documentación. Los metadatos rondan los ~750 tokens (2 herramientas). Figma por llevar el diseño al desarrollo frontend. Los metadatos rondan los ~500 tokens (2 herramientas). GitHub para buscar código en otros repositorios. Los metadatos rondan los ~2000 tokens (26 herramientas). Lineal para la gestión de proyectos. Los metadatos rondan los ~3250 tokens (33 herramientas). Serena para la búsqueda de códigos. Los metadatos rondan los ~4500 tokens (26 herramientas). Sentry para seguimiento de errores. Los metadatos rondan los ~12.500 tokens (22 herramientas).
Eso es un total de aproximadamente ~32 000 tokens de metadatos de herramientas, cargados en cada mensaje, ya sea que esté interactuando con la herramienta o no.
Para poner una cifra en dólares: Claude Opus 4.6 cobra 5 dólares por millón de tokens de entrada. Esos 32.000 tokens de metadatos de MCP inactivos añaden 0,16 dólares a cada mensaje que envía. Eso suena pequeño, hasta que te das cuenta de que incluso una simple conversación de 5 mensajes ya suma $0,8 en gastos generales puros. Y la mayoría de los desarrolladores no envían sólo 5 mensajes; agregue algunas aclaraciones breves y preguntas para recopilar contexto y rápidamente llegará a decenas, si no a cientos, de mensajes. Digamos que, en promedio, envía 50 mensajes al día durante un mes laboral de 20 días, eso es $8/día, ~$160/mes* en gastos generales puros, solo para descripciones de herramientas en contexto. Y eso es antes de tener en cuenta la latencia y el impacto en la calidad.
*Un pequeño asterisco: la mayoría de los modelos cobran significativamente menos por los tokens de entrada almacenados en caché (90% de descuento). Un asterisco detrás de este asterisco es que algunos de ellos cobran más cuando habilitan el almacenamiento en caché, y no siempre habilitan el almacenamiento en caché (API) de forma predeterminada (tos, Claude, tos).
El enfoque rentable de las habilidades
El patrón de carga de Habilidades cambia fundamentalmente los tres factores de costo. Al principio, el agente solo ve el nombre de cada habilidad y una breve descripción, aproximadamente ~100 tokens por habilidad. De esta manera, podría registrar 300 habilidades y aún así consumir menos tokens que mi configuración de MCP. El cuerpo completo de la instrucción (~5000 tokens) solo se carga cuando el agente decide que es relevante, y los archivos a los que se hace referencia solo se cargarán cuando el paso actual los necesite.
En la práctica, una conversación típica puede invocar una o dos habilidades mientras que el resto permanece invisible en la ventana de contexto. Esa es la diferencia clave: el costo de MCP aumenta con la cantidad de herramientas registradas (en todos los servidores), mientras que el costo de las habilidades aumenta más estrechamente con el uso real.
Información: MCP está "ansioso" y carga todos los metadatos de la herramienta por adelantado, independientemente de si se utilizan. Las habilidades son “perezosas” y cargan el contexto progresivamente y sólo cuando son relevantes. La diferencia importa en términos de costo, latencia y calidad de salida.
Espera, ¿eso es engañoso? ¡Las habilidades y MCP son dos cosas completamente diferentes!
Si lo anterior parece que las habilidades son los nuevos y mejores MCP, entonces permítanme corregir ese encuadre. La intención era ampliar sus patrones de carga y el impacto que tienen en el consumo de tokens. Funcionalmente son bastante diferentes.
MCP (Model Context Protocol) es un estándar abierto que brinda a cualquier LLM la capacidad de interactuar con aplicaciones externas. Antes de MCP, conectar modelos M a N herramientas requería M * N integraciones personalizadas. MCP colapsa eso a M + N: cada modelo implementa el protocolo una vez, cada herramienta lo expone una vez y todos interoperan. Es un cambio de infraestructura simple, pero realmente poderoso (no es de extrañar que haya conquistado al mundo).
Las habilidades, por otro lado, son en cierto modo “indicaciones glorificadas”, y lo digo de la mejor manera posible. Proporcionan al agente experiencia y dirección sobre cómo abordar una tarea, qué convenciones seguir, cuándo utilizar qué herramienta y cómo estructurar su resultado. Son conjuntos de instrucciones reutilizables que se obtienen bajo demanda cuando sea relevante, nada más y nada menos.
Información: MCP brinda capacidades al agente (el "qué"). Las habilidades le dan experiencia (el “cómo”) y por lo tanto son complementarias.
He aquí un ejemplo para concretar esto. Supongamos que conecta el servidor MCP de GitHub a su agente. MCP le brinda al agente la capacidad de crear solicitudes de extracción, enumerar problemas y buscar repositorios. Pero no le dice al agente, por ejemplo, cómo su equipo estructura las relaciones públicas, que siempre incluye una sección de prueba, que etiqueta por tipo de cambio, que hace referencia al ticket lineal en el título. Eso es lo que hace una habilidad. El MCP proporciona las herramientas, la habilidad proporciona el manual.
Entonces, cuando antes mostré que las habilidades cargan el contexto de manera más eficiente que MCP, la verdadera conclusión no es "usar habilidades en lugar de MCP", sino que la carga diferida como patrón funciona. Por lo tanto, vale la pena preguntarse: ¿por qué el acceso a la herramienta MCP no se puede cargar también de forma diferida? Ahí es donde entran los subagentes.
Subagentes: lo mejor de ambos mundos
Los subagentes son agentes secundarios especializados con su propia ventana de contexto aislada y herramientas conectadas. Dos propiedades los hacen poderosos:
Contexto aislado: un subagente comienza con una ventana de contexto limpia, precargada con su propio indicador del sistema y solo las herramientas que se le asignan. Todo lo que lee, procesa y genera permanece en su propio contexto, el agente principal sólo ve el resultado final. Herramientas aisladas: cada subagente puede equiparse con su propio conjunto de servidores y habilidades MCP. El agente principal no necesita conocer (ni pagar) herramientas que nunca utiliza directamente.
Una vez que un subagente finaliza su tarea, se descarta todo su contexto. Los metadatos de la herramienta, el razonamiento intermedio, las respuestas de la API: todo desapareció. Sólo el resultado regresa al agente principal. En realidad, esto es algo grandioso. No sólo evitamos inflar el contexto del agente principal con metadatos de herramientas innecesarios, sino que también evitamos que tokens de razonamiento innecesarios contaminen el contexto. Como ejemplo ilustrativo, imagine un subagente que investiga la API de una biblioteca. Puede buscar en múltiples fuentes de documentación, leer docenas de páginas e intentar varias consultas antes de encontrar la respuesta correcta. Aún paga por el uso del token del subagente, pero todo ese trabajo intermedio, los callejones sin salida, las páginas irrelevantes, las consultas de búsqueda, se descarta una vez que el subagente finaliza. El beneficio clave es que nada de esto se integra en el contexto del agente principal, por lo que cada mensaje posterior en su conversación se mantiene limpio y barato.
Esto significa que puede diseñar su configuración para que solo se pueda acceder a los servidores MCP a través de subagentes específicos, y nunca se carguen en el agente principal. En lugar de llevar ~32.000 tokens de metadatos de herramientas en cada mensaje, el agente principal lleva casi cero. Cuando necesita abrir una solicitud de extracción, activa un subagente de GitHub, crea el PR y devuelve el enlace. Al igual que las habilidades son un contexto de carga diferida, los subagentes son trabajadores con carga diferida: el agente principal sabe a qué especialistas puede recurrir y solo activa uno cuando una tarea lo exige.
Un ejemplo práctico
Hagamos esto tangible. Un flujo de trabajo que uso a diario es un "resumen de rama de funciones" que automatiza la mayor parte de una parte muy tediosa de mi ciclo de desarrollo: abrir una solicitud de extracción. Así es como interactúan las habilidades, el MCP y los subagentes.
Después de que el agente principal y yo terminemos el trabajo de codificación, le pido que concluya la rama de funciones. El agente principal no se encarga de esto por sí solo; delega todo el flujo de trabajo de relaciones públicas a un subagente dedicado. Este subagente está equipado con el servidor GitHub MCP y una habilidad de informe de cambios que define cómo mi equipo estructura las relaciones públicas. Su Skill.md se parece más o menos a esto:
— nombre: descripción del informe de cambios: utilícelo al generar un informe de cambios para un PR. Define la estructura de relaciones públicas del equipo, las reglas de categorización y las convenciones de formato. — 1. Asegúrese de que no queden cambios provisionales; de lo contrario, informe al agente principal. 2. Ejecute `git diff dev…HEAD –stat` y `git log dev..HEAD –oneline` para recopilar todos los cambios en esta rama de funciones. 3. Analice las diferencias y categorice los cambios más importantes por tipo (nuevas funciones, refactorizaciones, correcciones de errores o cambios de configuración). 4. Genere un informe de cambios estructurado siguiendo la plantilla en `pr-template.md`. 5. Abra el PR a través de GitHub MCP, completando el título y el cuerpo del informe generado. 6. Responda con el enlace PR.
El archivo pr-template.md en el mismo directorio define la estructura de relaciones públicas de mi equipo: secciones para resumen, desglose de cambios y notas de prueba. Este es el nivel 3 de divulgación progresiva: el subagente solo lo lee cuando el paso 4 se lo indica.
Esto es lo que hace que esta configuración funcione. La habilidad proporciona la experiencia sobre cómo mi equipo informa sobre los cambios, GitHub MCP proporciona la capacidad de crear realmente el PR y el subagente proporciona el límite de contexto para realizar todo este trabajo. El agente principal, por otro lado, solo llama al subagente, espera a que se complete y recibe una confirmación o un mensaje de lo que salió mal.
Insight: las habilidades, los MCP y los subagentes trabajan en armonía. La habilidad proporciona experiencia e instrucción, MCP proporciona la capacidad, el subagente proporciona el límite del contexto (manteniendo limpio el contexto del agente principal).
El panorama más amplio
En los primeros días de los LLM, la carrera giraba en torno a mejores modelos: menos alucinaciones, razonamiento más agudo, más resultados creativos. Esa carrera no se ha detenido por completo, pero el centro de gravedad ciertamente ha cambiado. MCP y Claude Code fueron genuinamente revolucionarios. Honestamente, actualizar Claude Sonnet de 3.5 a 3.7 no lo fue. Las mejoras incrementales del modelo que estamos obteniendo hoy importan mucho menos que la infraestructura que construimos a su alrededor. Las habilidades, los subagentes y la orquestación de múltiples agentes son parte de este cambio: de “cómo hacemos que el modelo sea más inteligente” a “cómo sacamos el máximo valor de lo que ya está aquí”.
Insight: el valor en el desarrollo de la IA ha pasado de mejores modelos a una mejor infraestructura. Las habilidades, los subagentes y la orquestación de múltiples agentes no son solo mejoras en la experiencia del desarrollador; son la arquitectura que hace que la IA agente sea económica y operativamente viable a escala.
donde estamos hoy
Las habilidades resuelven la rueda de hámster de la ingeniería de indicaciones al convertir sus mejores indicaciones en conjuntos de instrucciones reutilizables y autoinvocadas. Los subagentes resuelven el problema de la sobrecarga del contexto aislando el acceso a las herramientas y el razonamiento intermedio en trabajadores dedicados. Juntos, hacen posible codificar su experiencia una vez y aplicarla automáticamente en cada interacción futura. Esto es lo que ya hacen los equipos de ingeniería que siguen el estado de la práctica con la documentación, las guías de estilo y los runbooks. Las habilidades y los subagentes simplemente hacen que esos artefactos sean legibles por máquina.
El patrón de subagente también está desbloqueando el paralelismo entre múltiples agentes. En lugar de que un agente trabaje en tareas de forma secuencial, puede activar varios subagentes simultáneamente, hacer que trabajen de forma independiente y recopilar sus resultados. El propio sistema de investigación multiagente de Anthropic ya hace esto: Claude Opus 4.6 orquesta mientras los subagentes de Claude Sonnet 4.6 se ejecutan en paralelo. Esto naturalmente conduce a un enrutamiento de modelos heterogéneo, donde un modelo de frontera costoso orquesta y planifica, mientras que modelos más pequeños y más baratos se encargan de la ejecución. El orquestador razona, los trabajadores ejecutan. Esto puede reducir drásticamente los costos y al mismo tiempo mantener la calidad de la producción.
Hay una advertencia importante aquí. Mientras que el paralelismo funciona bien para tareas de lectura, se vuelve mucho más difícil para tareas de escritura que tocan el estado compartido. Digamos, por ejemplo, que está creando un subagente de backend y frontend en paralelo. El agente backend refactoriza un punto final API, mientras que el agente frontend, trabajando a partir de una instantánea tomada antes de ese cambio, genera código que llama al punto final antiguo. Ninguno de los agentes se equivoca por sí solo, pero juntos producen un resultado inconsistente. Este es un problema de concurrencia clásico, proveniente de los flujos de trabajo de IA del futuro cercano, que hasta la fecha sigue siendo un problema abierto.
hacia donde se dirige
Espero que la composición de habilidades se vuelva más sofisticada. Hoy en día, las habilidades son relativamente planas: un archivo de rebajas con referencias opcionales. Pero la arquitectura naturalmente admite habilidades en capas que hacen referencia a otras habilidades, creando algo así como una jerarquía hereditaria de experiencia. Piense en una habilidad básica de “revisión de código” ampliada por variantes específicas del idioma, ampliada aún más por convenciones específicas del equipo.
La mayoría de los sistemas multiagente actuales son estrictamente jerárquicos: un agente principal delega en un subagente, el subagente finaliza y el control regresa. Actualmente todavía no hay mucha colaboración entre pares entre subagentes. La función “equipos de agentes” lanzada recientemente por Anthropic para Opus 4.6 es un primer paso hacia esto, permitiendo que múltiples agentes se coordinen directamente en lugar de enrutar todo a través de un orquestador. En cuanto al protocolo, el A2A (Protocolo de agente a agente) de Google podría estandarizar este patrón entre proveedores; donde MCP maneja la comunicación de agente a herramienta, A2A manejaría la comunicación de agente a agente. Dicho esto, la adopción de A2A ha sido lenta en comparación con el crecimiento explosivo de MCP. Uno para observar, ninguno por el que apostar todavía.
Los agentes se convertirán en las nuevas funciones.
Aquí está surgiendo una abstracción más amplia que vale la pena retroceder para apreciarla. El famoso tweet de Andrej Karpathy “El nuevo lenguaje de programación más popular es el inglés” capturó algo real sobre cómo interactuamos con los LLM. Pero las habilidades y los subagentes llevan esta abstracción un nivel más allá: los agentes se están convirtiendo en las nuevas funciones.
Un subagente es una unidad de trabajo autónoma: toma una entrada (una descripción de tarea), tiene su propio estado interno (ventana de contexto), utiliza herramientas específicas (servidores MCP), sigue instrucciones específicas (habilidades) y devuelve una salida. Se puede llamar desde varios lugares, es reutilizable y componible. Esa es una función. El agente principal se convierte en el hilo de ejecución: orquestando, ramificando, delegando y sintetizando resultados de trabajadores especializados.
Aparte de la analogía, puede tener las mismas implicaciones prácticas que las funciones tuvieron para la ingeniería de software. El aislamiento limita el radio de explosión cuando falla un agente, en lugar de corromper todo el sistema, y las fallas se pueden detectar mediante mecanismos de prueba-excepto. La especialización significa que cada agente puede optimizarse para su tarea específica. La componibilidad significa que puede crear flujos de trabajo cada vez más complejos a partir de piezas simples y comprobables. Y la observabilidad surge de forma natural; Dado que cada agente es una unidad discreta con entradas y salidas claras, rastrear "por qué el sistema hizo X" se convierte en inspeccionar una pila de llamadas en lugar de mirar un volcado de contexto de 200.000 tokens.
Conclusión
Las habilidades parecen simples “indicaciones reutilizables” en la superficie, pero en realidad representan una respuesta reflexiva a algunos de los problemas más difíciles de las herramientas de IA: gestión del contexto, eficiencia de los tokens y la brecha entre la capacidad bruta y la experiencia en el dominio.
Si aún no ha experimentado con las habilidades, comience poco a poco. Elija su patrón de indicaciones más repetido, extráigalo a un Skill.md y vea cómo cambia su flujo de trabajo. Una vez que haga clic, dé el siguiente paso: identifique qué herramientas MCP no necesitan vivir en su agente principal, o qué subprocesos requieren mucho razonamiento que se utiliza después de encontrar la respuesta, y aplíquelos a subagentes dedicados. Se sorprenderá de lo limpia que se vuelve su configuración cuando cada agente solo lleva lo que realmente necesita.
Ideas clave de esta publicación
Las habilidades son conjuntos de instrucciones reutilizables, de carga diferida y de invocación automática que utilizan la divulgación progresiva en tres niveles: metadatos, cuerpo y archivos de referencia. Esto minimiza el costo inicial al evitar volcar todo en la ventana contextual (mirándote, MCP 👀). MCP está "ansioso" y carga todos los metadatos de la herramienta por adelantado, independientemente de si se utiliza o no. Las habilidades son “perezosas” y cargan el contexto progresivamente y sólo cuando son relevantes. La diferencia importa en términos de costo, latencia y calidad de salida. MCP brinda capacidades al agente (el "qué"). Las habilidades le dan experiencia (el “cómo”) y por lo tanto son complementarias. Las habilidades, los MCP y los subagentes trabajan en armonía. La habilidad proporciona experiencia e instrucción, MCP proporciona la capacidad, el subagente proporciona el límite del contexto (manteniendo limpio el contexto del agente principal). El valor del desarrollo de la IA ha pasado de mejores modelos a una mejor infraestructura. Las habilidades, los subagentes y la orquestación de múltiples agentes no son solo mejoras en la experiencia del desarrollador; son la arquitectura que hace que la IA agente sea económica y operativamente viable a escala.
Información final: la rueda de hámster de ingeniería rápida es opcional. Es hora de bajar.
¿Encontró esto útil? ¡Sígueme en LinkedIn, TDS o Medium para ver mis próximas exploraciones!
Todas las imágenes mostradas en este artículo fueron creadas por mí, el autor.