Deja de construir agentes de IA — Empieza a construir Skills en su lugar
Pasé tres meses el año pasado construyendo un agente de IA personalizado desde cero. Cientos de líneas de system prompts. Definiciones de herramientas cuidadosamente ajustadas. Lógica de reintentos, manejo de errores, reglas de formato de salida — toda la producción. Funcionaba a la perfección para un flujo de trabajo específico. Luego el cliente me pidió que añadiera un segundo flujo de trabajo, y me di cuenta de que había construido una obra maestra que no podía crecer.
El agente sabía hacer exactamente una cosa realmente bien. Añadir una segunda significaba reescribir la mitad de la arquitectura. Añadir una tercera habría significado empezar de cero.
¿Te suena familiar? Si has construido cualquier tipo de agente de IA en el último año, probablemente hayas chocado con este muro. Tu agente es brillante en su tarea original y completamente inútil en el momento en que lo empujas fuera de ese carril. Yo lo llamaba la "trampa del especialista brillante" — y no pude encontrar la forma de evitarla hasta que vi a Barry y Mahes presentar algo que replanteó todo lo que creía saber sobre el desarrollo de agentes.
Ellos no construyeron un agente mejor. Construyeron una mejor manera de enseñar a los agentes. Y la diferencia entre esas dos ideas es la brecha entre donde la mayoría de los desarrolladores están atascados y hacia dónde se dirige todo este campo.
Por qué tu agente brillante es en realidad bastante tonto
Aquí va un experimento mental que cambió mi forma de abordar la arquitectura de agentes.
Toma a la persona más inteligente que conozcas. Dale una tarea que nunca haya enfrentado — digamos, presentar una declaración de impuestos corporativos en Alemania, o hacer un tratamiento de conducto. Su inteligencia bruta sigue ahí. Su capacidad de razonamiento no ha cambiado. Pero fracasará estrepitosamente porque la inteligencia sin conocimiento procedimental es solo energía potencial sin un lugar a donde ir.
Eso es exactamente lo que está pasando con los agentes de IA ahora mismo. Claude, GPT-4, Gemini — estos modelos son razonadores extraordinariamente capaces. Pero cuando los despliegas como agentes, esencialmente estás dejando a un genio en un trabajo desconocido y diciéndole "resuélvelo." A veces lo logran. A menudo no. Y aun cuando tienen éxito, la calidad es inconsistente porque están razonando desde primeros principios cada vez en lugar de aplicar procedimientos aprendidos.
El desarrollo tradicional de agentes intenta resolver esto metiendo todo en el system prompt. Escribes párrafo tras párrafo de instrucciones: "Cuando el usuario pregunte sobre X, primero revisa Y, luego formatea la salida como Z, y si hay un error, haz W." He escrito system prompts que eran literalmente más largos que el código que controlaban.
El problema no es que este enfoque no funcione. Funciona — para un agente haciendo una cosa. El problema es que nada de ese conocimiento se transfiere. Construye un segundo agente para una tarea diferente y empiezas desde cero. Cada instrucción, cada caso límite, cada insight ganado a pulso sobre cómo manejar fallos — encerrado dentro de un solo archivo de prompt, invisible para todo lo demás en tu sistema.
Barry y Mahes articularon lo que yo venía sintiendo pero no podía nombrar: los agentes tienen inteligencia y capacidades, pero carecen de experiencia organizada. Son generalistas brillantes que pueden razonar sobre cualquier cosa pero no han dominado nada. Y la solución no es construir agentes más inteligentes — es dar a los agentes una forma de adquirir, almacenar y compartir experiencia.
Esa solución son los skills. Y la arquitectura detrás de ellos es más ingeniosa de lo que parece a primera vista.
Qué son realmente los Agent Skills (y por qué no son solo prompts sofisticados)
Cuando escuché por primera vez "agent skills," asumí que era un cambio de nombre para plantillas de prompts. No lo es. La diferencia es estructural, y eso importa.
Un skill es una carpeta. Eso es todo en el nivel más básico — un directorio que contiene archivos que codifican conocimiento procedimental. Pero la composición específica de esos archivos es donde el diseño se pone interesante:
Scripts (herramientas): Código ejecutable que da al agente nuevas capacidades. Un skill para web scraping podría incluir un script en Python que maneja autenticación, paginación y limitación de velocidad. El agente no necesita descifrar cómo hacer scraping — llama al script.
Instrucciones en Markdown: Conocimiento procedimental escrito en lenguaje natural. Cuándo usar el skill, en qué orden realizar los pasos, qué casos límite vigilar, cómo formatear las salidas. Aquí es donde vive la experiencia del dominio.
Assets: Archivos de configuración, plantillas, datos de referencia, ejemplos de salida — cualquier cosa que el skill necesite para hacer su trabajo de manera consistente.
Aquí está la decisión de diseño que hace funcionar esta arquitectura: revelación progresiva. Cuando Claude Code carga tus skills, no los vuelca todos en la ventana de contexto de una vez. Solo ve los metadatos — el nombre del skill, una breve descripción y las condiciones de activación. El contenido completo del skill se carga solo cuando el agente realmente lo necesita.
¿Por qué importa esto? La gestión de la ventana de contexto es la mayor restricción en los sistemas de agentes. Cada token gastado en instrucciones que no estás usando actualmente es un token robado del razonamiento sobre la tarea en cuestión. La revelación progresiva significa que puedes tener cincuenta skills instalados sin pagar el costo de contexto por los cincuenta simultáneamente. El agente ve un menú de capacidades y saca la receta relevante solo cuando empieza a cocinar.
Probé esto con mi propia configuración. Tengo skills para diseño front-end, auditoría SEO, generación de contenido, análisis de seguridad y automatización de despliegues. Claude Code me muestra la lista cuando pregunto qué skills están disponibles. Pero cuando digo "rediseña esta página," solo se carga el contenido completo del skill de diseño front-end. Mi skill de SEO se queda tranquilo en segundo plano, listo pero sin consumir tokens.
Compara esto con el enfoque de system prompt monolítico. Con todo en un solo prompt, pagas el costo de contexto por cada capacidad la uses o no. Es como cargar todas las herramientas de la ferretería en tus bolsillos en lugar de caminar al pasillo correcto cuando necesitas algo.
Pero la estructura basada en carpetas desbloquea algo incluso más importante que la eficiencia de contexto — y esta es la parte que la mayoría de la gente aún no ha captado.
La verdadera jugada maestra: Los Skills son software, no prompts
Dado que los skills son simplemente carpetas con archivos, heredan todas las propiedades del software que ya sabemos gestionar.
Control de versiones. Mete tu carpeta de skills en un repositorio Git y tienes un historial completo. Quién cambió qué, cuándo, por qué. Revierte un skill a la versión del martes pasado porque la nueva introdujo un bug. Crea una rama de un skill para probar modificaciones sin afectar la versión principal. Esto es algo fundamental para el software, pero revolucionario para la ingeniería de prompts, que tradicionalmente ha sido "edita el prompt, espera que funcione, reza para recordar qué cambiaste."
Compartir y colaborar. Comprime una carpeta de skill, envíasela a un colega, y tendrán tu capacidad exacta. Nada de "copia este prompt y ajústalo para tu configuración." Nada de "asegúrate de también cambiar la configuración del modelo." El skill es autocontenido. Todo lo que necesita está en la carpeta.
Composabilidad. Esta es la grande. Múltiples skills pueden coexistir y complementarse entre sí. Mi skill de diseño front-end maneja cambios visuales. Mi skill de SEO maneja optimización. Cuando le pido a Claude que "rediseñe esta página y arregle el SEO," ambos skills se activan. No entran en conflicto porque cada uno opera en su propio dominio con sus propias instrucciones.
He estado tratando los skills como microservicios para el conocimiento del agente. Cada skill tiene una responsabilidad única, una interfaz limpia y sin dependencias ocultas de otros skills. Cuando necesito una nueva capacidad, no modifico un skill existente — creo uno nuevo. Cuando un skill se vuelve obsoleto, borro la carpeta. No se necesita refactorización.
Esta analogía de microservicios va más profundo de lo que esperaba. En el software tradicional, los microservicios se comunican a través de APIs. En la arquitectura de skills, los skills se comunican a través del razonamiento del agente — el modelo actúa como la capa de orquestación, decidiendo qué skills invocar y cómo combinar sus salidas. Es una inversión elegante del patrón habitual.
Y el ecosistema que crece alrededor de este concepto se mueve más rápido de lo que anticipé. Déjame mostrarte lo que realmente hay ahí fuera.
Las tres capas del ecosistema de Skills
Cinco semanas después del lanzamiento, ya existen miles de skills. Se clasifican en tres categorías que revelan mucho sobre hacia dónde se dirige esta tecnología.
Capa 1: Skills fundamentales. Son capacidades de propósito general que hacen a los agentes mejores en tareas comunes. Edición de documentos, síntesis de investigación científica, análisis de datos, revisión de código. Piensa en estos como la biblioteca estándar — los skills que la mayoría de los agentes probablemente deberían tener instalados. El skill de diseño front-end que uso tiene más de 100,000 instalaciones. El skill de auditoría SEO tiene alrededor de 19,000. Estos números te dicen algo sobre la demanda.
Capa 2: Skills de terceros. Aquí es donde las cosas se ponen interesantes. Las empresas están construyendo skills para sus propios productos. Browserbase creó un skill de automatización web que permite a Claude navegar e interactuar con páginas web a través de su infraestructura. Notion construyó un skill de integración con su espacio de trabajo. Estos no son genéricos — están construidos a propósito por los equipos que mejor conocen sus herramientas.
Lo que me parece convincente de los skills de terceros es la alineación de incentivos. Browserbase quiere que los desarrolladores usen su plataforma. Construir un skill de Claude Code que haga su plataforma fácil de usar es una distribución brillante. El skill se convierte en la interfaz de usuario, y Claude se convierte en el usuario. Espero que cada herramienta importante para desarrolladores lance un skill de Claude Code en los próximos doce meses.
Capa 3: Skills empresariales. Esta es la capa de la que nadie habla públicamente pero donde está el dinero real. Las empresas Fortune 100 están construyendo skills internos que codifican sus flujos de trabajo específicos, mejores prácticas, requisitos de cumplimiento y conocimiento institucional.
Imagina una firma de servicios financieros que construye un skill que codifica sus procedimientos específicos de evaluación de riesgos. Cada analista que usa Claude Code tiene acceso al mismo conocimiento procedimental — las mismas listas de verificación, las mismas referencias regulatorias, los mismos requisitos de formato. Los nuevos empleados se ponen al día más rápido porque el skill lleva la experiencia que antes solo vivía en la cabeza de los empleados senior.
He empezado a hacer esto para mis propios clientes. Cuando entrego un proyecto, incluyo una carpeta de skill que codifica los procedimientos de mantenimiento del proyecto. Cómo desplegar. Cómo ejecutar tests. Cuáles son las convenciones de nombres. Dónde están los archivos de configuración. El equipo del cliente no necesita memorizar mi documentación — le preguntan a Claude, y el skill proporciona la respuesta con los comandos exactos a ejecutar.
Esto es gestión de conocimiento procedimental en su forma más pura. Y resuelve un problema que he visto a las organizaciones luchar con durante toda mi carrera: ¿cómo preservas el conocimiento institucional cuando la gente se va?
Construyendo tu primer Skill: La guía práctica
Suficiente teoría. Aquí te explico cómo construir un skill de verdad. Te guiaré a través de la creación de uno que construí el mes pasado — un skill de verificación de despliegue que comprueba si un despliegue fue exitoso y reporta cualquier problema.
Paso 1: Crea la estructura de carpetas.
deployment-check/
├── skill.md
├── tools/
│ └── verify-deployment.sh
└── examples/
└── sample-output.md
El archivo skill.md es el cerebro. Contiene las condiciones de activación, instrucciones y contexto:
# Deployment Verification Skill
## Trigger
Activate when the user asks to verify, check, or validate
a deployment, or after any deploy command completes.
## Instructions
1. Run the verify-deployment.sh script with the target URL
2. Check HTTP status codes for all critical endpoints
3. Verify SSL certificate validity
4. Compare response times against baseline
5. Check for error patterns in response bodies
6. Generate a summary report with pass/fail status
## Edge Cases
- If the site returns 503, wait 30 seconds and retry once
- If SSL check fails, note whether the cert is expired
or misconfigured
- If response times exceed 2x baseline, flag as warning
not failure
Paso 2: Escribe el script de la herramienta.
#!/bin/bash
# verify-deployment.sh
# Checks critical health indicators for a deployed site
TARGET_URL=$1
echo "## Deployment Verification Report"
echo "Target: $TARGET_URL"
echo "Timestamp: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""
# Check HTTP status
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$TARGET_URL")
echo "### HTTP Status: $STATUS"
# Check SSL
SSL_EXPIRY=$(echo | openssl s_client -connect \
"${TARGET_URL#https://}:443" 2>/dev/null | \
openssl x509 -noout -enddate 2>/dev/null)
echo "### SSL: $SSL_EXPIRY"
# Check response time
RESPONSE_TIME=$(curl -s -o /dev/null \
-w "%{time_total}" "$TARGET_URL")
echo "### Response Time: ${RESPONSE_TIME}s"
Paso 3: Pruébalo.
Instala el skill en tu entorno de Claude Code y ejecútalo:
Verify the deployment at https://mysite.com
Claude detecta la condición de activación del skill, carga las instrucciones completas, ejecuta el script de verificación y formatea la salida según las instrucciones del skill. La primera vez que ejecuté esto, detectó un certificado SSL que expiraba en tres días — algo que habría pasado por alto hasta que los usuarios empezaran a ver advertencias en el navegador.
Consejo profesional: Empieza tus skills de forma simple. Mi primera versión de este skill era solo las instrucciones en markdown sin script — Claude ejecutaba los comandos curl por sí mismo basándose en las instrucciones procedimentales. Añadí el script después cuando quería un formato de salida más consistente. No necesitas sobre-ingeniar los skills desde el primer día. Deja que evolucionen según el uso real.
La arquitectura detrás del telón: Skills + MCP
Una pieza de este rompecabezas que no entendí inicialmente era cómo se relacionan los skills con los servidores MCP. Parecían redundantes — ambos extienden lo que Claude puede hacer, así que ¿cuál es la diferencia?
Después de trabajar extensamente con ambos, aquí está el modelo mental que me hizo clic.
Los servidores MCP (Model Context Protocol) manejan la conectividad. Son la fontanería que permite a Claude comunicarse con sistemas externos — bases de datos, APIs, sistemas de archivos, servicios de terceros. Un servidor MCP para GitHub permite a Claude leer repositorios, crear issues y abrir pull requests. Un servidor MCP para Slack permite a Claude enviar mensajes y leer canales.
Los skills manejan la experiencia. Son el conocimiento que le dice a Claude qué hacer con esas conexiones y cómo hacerlo bien.
Piénsalo como una cocina. Los servidores MCP son los electrodomésticos — la estufa, el horno, la batidora. Los skills son las recetas. Tener una estufa no te hace chef. Tener una receta no cocina la comida. Necesitas ambos.
En la práctica, esto significa que los skills a menudo dependen de servidores MCP. Mi skill de verificación de despliegue usa comandos curl que se ejecutan a través del acceso a la terminal de Claude. Una versión más sofisticada podría usar un servidor MCP para infraestructura en la nube para verificar la salud de los contenedores, comprobar configuraciones de balanceadores de carga y consultar APIs de monitoreo. El skill proporciona el conocimiento procedimental ("verifica estas cinco cosas en este orden"), y los servidores MCP proporcionan las conexiones ("así es como se accede a la API del balanceador de carga").
Esta arquitectura combinada ya está funcionando en producción en empresas de servicios financieros y ciencias de la vida. Los skills codifican procedimientos de cumplimiento y flujos de trabajo de análisis. Los servidores MCP se conectan a bases de datos internas, APIs regulatorias y herramientas de reportes. El agente orquesta todo basándose en las instrucciones del skill.
Creo que esta es la arquitectura que definirá la próxima generación de despliegues empresariales de IA. No agentes monolíticos con todo incorporado, sino agentes ligeros con ricas bibliotecas de skills y amplia conectividad MCP.
Lo que la mayoría de la gente está entendiendo mal sobre este cambio
Déjame rebatir algunas cosas que sigo viendo en las discusiones sobre agent skills.
"Los skills son solo ingeniería de prompts con pasos extra." No. La ingeniería de prompts es escribir instrucciones. Los skills son empaquetar experiencia en una unidad reutilizable, versionable, compartible y composable. Ese empaquetado es el punto central. La diferencia entre una receta suelta garabateada en una servilleta y un libro de cocina publicado no es el contenido — es el formato, la descubribilidad y la confiabilidad. El mismo principio aplica aquí.
"No necesito skills porque mi agente funciona bien." Tu agente funciona bien para lo que hace actualmente. Los skills tratan sobre lo que viene después. Cuando tu jefe le pida a tu agente que maneje un nuevo flujo de trabajo, ¿reescribes el system prompt? ¿Creas un segundo agente? ¿Construyes un enrutador para despachar entre agentes? Los skills te permiten simplemente añadir una carpeta. La simplicidad operativa es la funcionalidad.
"Las personas no técnicas no pueden crear skills." Esta está siendo refutada en tiempo real. El formato de instrucciones basado en markdown significa que cualquiera que pueda escribir procedimientos claros puede crear un skill. Vi a una coordinadora de reclutamiento — sin experiencia en programación — construir un skill que estandarizó cómo Claude filtra currículos según los criterios específicos de su empresa. Los scripts de "herramientas" son opcionales para skills que no necesitan automatización. Muchos skills son puro conocimiento procedimental en markdown, y funcionan sorprendentemente bien.
La única crítica con la que sí estoy de acuerdo: las pruebas y evaluación de skills aún son inmaduras. Cuando escribes código, tienes suites de tests, linters, verificadores de tipos. Cuando escribes un skill, ¿cómo verificas que funciona correctamente? ¿Cómo mides si la versión 2 es mejor que la versión 1? El equipo detrás de los skills ha reconocido esta brecha y la ha listado como prioridad para el desarrollo futuro. Hasta que esas herramientas existan, pruebo mis skills a la vieja usanza — los pruebo en tareas reales e itero basándome en los resultados.
Qué pasa cuando los agentes construyen sus propios Skills
Aquí es donde mi pensamiento se vuelve especulativo — pero basado en lo que ya estoy viendo.
Claude Code puede crear skills de forma autónoma. Cuando estás trabajando con Claude y descubre un procedimiento útil, puede escribir ese procedimiento como un skill para uso futuro. Vi que esto pasó accidentalmente. Estaba depurando un problema de despliegue, guiando a Claude por mi proceso de resolución de problemas paso a paso. Después de arreglarlo, Claude me preguntó si quería que guardara el procedimiento de resolución de problemas como un skill. Dije que sí. Ahora cada vez que encuentro un problema similar, Claude ya conoce los pasos de diagnóstico.
Esto es aprendizaje transferible hecho tangible. El agente experimentó una situación, extrajo el conocimiento procedimental y lo almacenó en un formato que persiste más allá de la sesión actual. Futuras conversaciones — incluso futuras versiones de Claude — pueden acceder a ese conocimiento instantáneamente.
La analogía con la historia de la computación es llamativa y no creo que sea accidental. Los modelos son procesadores — poder computacional bruto. Los runtimes de agentes son sistemas operativos — gestionando recursos y procesos alrededor del procesador. Los skills son aplicaciones — el software que resuelve problemas reales y codifica experiencia real.
Esencialmente estamos viendo la capa de aplicaciones de la IA desarrollarse en tiempo real. Y al igual que el desarrollo de software se democratizó durante décadas — desde lenguaje ensamblador hasta constructores sin código — la creación de skills ya está en esa trayectoria. Hoy requiere entender estructuras de carpetas y sintaxis de markdown. Mañana probablemente no requerirá más que mostrarle a un agente cómo hacer algo y decir "recuerda esto."
Tus próximas doce horas
Esto es lo que quiero que hagas antes de mañana. Elige un flujo de trabajo que hagas repetidamente — pueden ser verificaciones de despliegue, revisiones de código, formateo de datos, procedimientos de onboarding de clientes, cualquier cosa que hagas más de dos veces al mes.
Escríbelo como un skill. Crea una carpeta con un archivo skill.md. Describe la condición de activación. Lista los pasos. Anota los casos límite. No necesitas scripts de herramientas para tu primer skill. Solo el conocimiento procedimental en markdown.
Instálalo y pruébalo.
Te garantizo que pasarán dos cosas. Primero, te sorprenderá lo bien que Claude sigue el procedimiento — mejor que la mayoría de los humanos siguen documentación escrita, honestamente. Segundo, inmediatamente pensarás en cinco flujos de trabajo más que quieres convertir en skills.
Esa segunda reacción es la importante. Significa que has dejado de pensar en los agentes de IA como productos que construyes y has empezado a pensar en ellos como plataformas que extiendes. Y ese cambio de mentalidad — de construir agentes a construir skills — es la diferencia entre luchar contra el techo de complejidad y atravesarlo.
¿El agente en el que pasé tres meses construyendo el año pasado? Lo he reconstruido como siete skills. Cada uno me tomó menos de un día. Juntos hacen todo lo que el agente original hacía, más tres cosas que no podía. Y cuando el cliente pida una nueva capacidad el mes que viene, añadiré un octavo skill en lugar de empezar de cero.
Eso no es una mejora incremental. Es una forma fundamentalmente diferente de construir.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
