AI Skills vs Agentes: No Construyas Agentes, Construye Skills

La charla que reencuadró todo

A principios de 2025, el equipo de ingeniería de Anthropic presentó una charla en la conferencia AI Engineer que desde entonces ha sido vista más de 1.3 millones de veces. La tesis central era engañosamente simple: dejen de construir agentes monolíticos. Construyan skills en su lugar. AI skills vs agentes no es solo un debate de nomenclatura. Es una decisión de arquitectura que determina si tu producto de IA se entrega de manera confiable o colapsa bajo el peso de su propia ambición.

En product.engineer, definimos un skill como una capacidad discreta y componible que un sistema de IA puede invocar. Tiene un contrato de entrada claro, un output definido y una sola responsabilidad. Un agente, por contraste, es un sistema que autónomamente decide qué hacer después, a menudo encadenando múltiples capacidades de formas impredecibles. La distinción importa porque los skills son testeables, debuggeables y entregables. Los agentes a menudo no son ninguna de esas cosas.

Este encuadre resonó fuerte conmigo. Como product engineer, constantemente estás tomando decisiones de arquitectura que equilibran ambición con confiabilidad. Quieres entregar algo que funcione el próximo martes, no algo que podría funcionar el próximo trimestre si logras hacer que un loop autónomo se comporte consistentemente. El enfoque skills-first te da eso. Te da velocidad de entrega sin sacrificar la inteligencia que tus usuarios esperan.

Por qué la industria se equivocó con los agentes

Todos querían agentes autónomos en 2024. La visión era convincente: dale a una IA un objetivo, déjala descubrir los pasos, mírala ejecutar. AutoGPT alcanzó 150,000 estrellas en GitHub en su primer mes. BabyAGI se viralizó. Devin prometió ingeniería de software autónoma. El hype fue extraordinario.

Los resultados no lo fueron.

Un estudio de METR (Model Evaluation and Threat Research) encontró que los agentes autónomos en 2024 tuvieron éxito en solo el 3.5% de las tareas reales de ingeniería de software cuando se les dio autonomía completa sin guía humana. Cuando se les dieron las mismas tareas con acceso estructurado a herramientas y límites claros de skills, las tasas de éxito saltaron al 26%. Eso es una mejora de 7x simplemente restringiendo la autonomía del sistema y dándole skills componibles en lugar de agencia abierta.

La investigación interna de OpenAI sobre arquitecturas de agentes con GPT-4, presentada en su DevDay 2024, mostró un patrón similar. Las tareas descompuestas en llamadas a funciones discretas con inputs y outputs tipados tuvieron tasas de completación 4x mayores que las tareas dadas como instrucciones abiertas a un loop autónomo. La restricción era el feature.

El problema con los agentes monolíticos es triple:

• Errores compuestos. Cada decisión autónoma tiene una probabilidad de fallo. Encadena diez decisiones juntas y tu confiabilidad compuesta cae exponencialmente. Una tasa de éxito del 90% por paso te da un 35% de confiabilidad end-to-end a través de diez pasos.
• Comportamiento no testeable. No puedes escribir un test unitario para "descubre qué hacer después." Puedes escribir un test unitario para "dado este input, produce este output." Los skills son testeables. El razonamiento autónomo no lo es.
• Timelines no entregables. Construir un agente autónomo confiable requiere resolver alineación, planificación, recuperación de errores y gestión de estado simultáneamente. Construir un skill requiere definir una interfaz e implementarla.

Skills vs agentes: la comparación de arquitectura

El debate AI skills vs agentes se vuelve más claro cuando miras las diferencias arquitectónicas concretas:

Esta tabla no es académica. Mapea directamente a las decisiones que tomas cada sprint. Cuando un product engineer se sienta a agregar capacidades de IA a un producto, la primera pregunta nunca debería ser "¿cómo construyo un agente?" Debería ser "¿qué skills necesita este flujo de trabajo?"

La filosofía de diseño de skills de Anthropic

El framework de Anthropic, presentado en la charla, se centra en tres principios que mapean directamente a cómo los constructores deberían pensar sobre features de IA.

1. Responsabilidad única por skill

Cada skill hace una cosa. "Resumir este documento" es un skill. "Extraer datos estructurados de esta factura" es un skill. "Generar una query SQL a partir de lenguaje natural" es un skill. "Ser un asistente útil que puede hacer cualquier cosa" no es un skill. Es una plegaria.

El paralelo con el buen diseño de software es obvio. No entregarías una función que toma un string y retorna "lo que parezca apropiado." No harías merge de un pull request para una clase llamada DoEverythingManager. Sin embargo eso es exactamente lo que la mayoría de las arquitecturas de agentes son: un DoEverythingManager respaldado por un modelo de lenguaje en lugar de una máquina de estados.

2. Interfaces tipadas con validación

Cada skill tiene un schema. Los inputs están tipados. Los outputs están tipados. El sistema sabe qué está recibiendo y qué está retornando antes de que comience la ejecución. Esto no es solo buena práctica; es lo que hace posible la composición. Puedes encadenar skills precisamente porque cada uno declara su contrato por adelantado.

El protocolo de uso de herramientas de Anthropic impone esto. Cuando Claude invoca una herramienta, produce JSON estructurado que coincide con un schema. Cuando recibe un resultado, ese resultado conforma una estructura definida. No hay ambigüedad. No hay "bueno, el modelo pareció entender." O los tipos coinciden o no.

3. Humano-en-el-loop por defecto

Los skills están diseñados para ser invocados, no liberados. La suposición por defecto es que un humano (o un sistema con supervisión similar a la humana) decide cuándo llamar a un skill y qué hacer con su output. La autonomía se gana incrementalmente, no se otorga por adelantado.

Esto mapea perfectamente a cómo Anthropic entrega el propio Claude. Claude Code, su herramienta para desarrolladores, opera a través de una arquitectura basada en skills. Tiene capacidades discretas: leer un archivo, escribir un archivo, ejecutar un comando, buscar código. Cada capacidad requiere permiso explícito. El sistema no decide autónomamente reescribir tu codebase. Propone cambios, espera aprobación, luego ejecuta operaciones definidas.

El product engineer como diseñador de skills

Aquí es donde el rol del product engineer se vuelve crítico. Decidir qué skills construir, cómo delimitarlos y cómo componerlos en features orientados al usuario es una decisión de producto, no solo una decisión técnica.

Un ingeniero de software tradicional podría mirar una solicitud de feature como "agregar IA a nuestra herramienta de soporte" y empezar a construir un agente autónomo que lee tickets, busca documentación, redacta respuestas y las envía. Eso es un agente. También son tres meses de trabajo que podrían nunca entregar de manera confiable.

Un product engineer mira la misma solicitud y pregunta: ¿cuál es la unidad atómica de valor? ¿Cuál es el skill más pequeño que hace esta herramienta significativamente mejor hoy? Quizás es: "dado un ticket de soporte, sugerir los tres artículos de documentación más relevantes." Ese es un solo skill. Input tipado (texto del ticket). Output tipado (lista rankeada de IDs de artículos con puntajes de relevancia). Testeable. Entregable en una semana.

Luego agregas otro skill: "dado un ticket y artículos relevantes, redactar una respuesta." Luego otro: "dada una respuesta redactada, verificarla contra nuestras guías de tono." Cada skill es independientemente valioso. Cada uno es testeable. Y cuando los compones, obtienes algo que parece un agente para el usuario pero en realidad es un pipeline determinístico de skills componibles.

Este es el enfoque que Linear tomó cuando agregó features de IA a su herramienta de gestión de proyectos. No construyeron un agente autónomo de gestión de proyectos. Construyeron skills discretos: resumir un hilo, extraer items de acción, sugerir etiquetas, auto-clasificar issues entrantes. Cada skill se entregó independientemente. Cada uno mejoró inmediatamente el producto. La composición vino después, una vez que cada capacidad individual estaba probada.

Diseñando skills: un framework práctico

Después de asesorar a más de 12,000 ingenieros y construir productos con IA en dos startups, he encontrado que el diseño de skills sigue cuatro etapas: definir, implementar, componer y evaluar.

Definir: delimitar el skill despiadadamente

Un skill bien delimitado responde sí a todas estas:

• ¿Puedo describir lo que hace en una oración?
• ¿Puedo escribir tres ejemplos concretos de input/output?
• ¿Puedo testearlo sin ejecutar todo el sistema?
• ¿Tiene exactamente una razón para cambiar?

Si alguna respuesta es no, el skill es demasiado amplio. Divídelo.

Implementar: tratar los prompts como código

La implementación del skill no es solo un prompt. Es un prompt, un schema, lógica de validación, manejo de errores y comportamiento de reintentos. Trata el prompt de la misma forma que tratas el cuerpo de una función: versionarlo, revisarlo, testearlo contra casos de regresión.

El enfoque de Stripe para su detección de fraude con IA ilustra esto. Cada señal de detección (verificación de velocidad, anomalía geográfica, outlier de monto) es un skill discreto con inputs tipados y un output de puntaje de confianza. Los skills no deciden autónomamente si bloquear una transacción. Proporcionan señales que una capa de composición agrega en una decisión. Esta arquitectura les permite agregar nuevos skills de detección sin tocar los existentes.

Componer: construir pipelines, no loops

La composición es donde los skills se convierten en features. Pero la composición debería ser un pipeline dirigido, no un loop sin límite. La acción del usuario dispara una secuencia definida de skills, cada uno pasando su output al siguiente. Si un skill falla, el pipeline tiene un fallback explícito, no un loop de "inténtalo de nuevo y espera lo mejor."

Piénsalo como pipes de Unix. cat file | grep pattern | sort | head -10 es una composición de skills. Cada uno es independientemente útil. La composición es poderosa precisamente porque cada componente es simple y predecible. Nunca construirías una herramienta Unix que diga "descubre qué quiere probablemente el usuario y hazlo." Sin embargo eso es lo que las arquitecturas de agentes autónomos intentan.

Evaluar: medir métricas por skill

Cada skill obtiene su propia métrica de éxito. No "¿es bueno el sistema en general?" sino "¿este skill específico produce output correcto para sus inputs definidos?" Esta granularidad es lo que hace al sistema mejorable. Cuando algo se rompe, sabes exactamente qué skill falló y puedes arreglarlo aisladamente.

Los features de IA de Vercel siguen este patrón. Su producto v0 (generación de UI con IA) no es un modelo monolítico que genera aplicaciones enteras. Es una composición de skills: entender la solicitud, generar estructura de componentes, producir estilos Tailwind, validar accesibilidad, renderizar preview. Cada skill tiene métricas de calidad independientes. Cada uno puede mejorarse sin regresar otros.

El espectro de AI skills vs agentes

Skills y agentes no son una elección binaria. Existen en un espectro. El insight de Anthropic es que deberías empezar en el extremo de skills y moverte hacia la agencia solo cuando los skills individuales son probadamente confiables.

El espectro se ve así:

1. Skill puro - Invocación única, I/O tipado, sin estado. Ejemplo: "clasificar el sentimiento de este texto."
2. Cadena de skills - Pipeline fijo de skills, orden determinístico. Ejemplo: "extraer entidades, luego vincularlas a tu base de datos, luego generar un resumen."
3. Enrutamiento condicional de skills - Un router simple decide qué skill invocar basado en clasificación de input. Ejemplo: "si el usuario pregunta sobre facturación, invocar el skill de facturación; si sobre problemas técnicos, invocar el skill de debug."
4. Skills orquestados - Un coordinador planifica qué skills invocar y en qué orden, pero cada skill sigue siendo discreto y testeable. Ejemplo: Claude Code leyendo contexto, decidiendo buscar, luego editando un archivo.
5. Agente autónomo - El sistema decide objetivos, planifica pasos, ejecuta skills y evalúa su propio progreso sin intervención humana.

La mayoría de los features de IA en producción que realmente funcionan viven en los niveles 2 a 4. Los equipos que saltan directamente al nivel 5 tienden a hacer buenos demos y entregar mal.

La implementación de IA de Notion es un sistema de nivel 3 de libro de texto. Cuando le preguntas algo a Notion AI, clasifica tu solicitud, enruta al skill apropiado (resumir página, generar texto, traducir, extraer items), ejecuta ese skill y retorna el resultado. Se siente inteligente para los usuarios pero arquitectónicamente está compuesto de skills discretos y testeables con una capa delgada de enrutamiento.

Patrones de implementación del mundo real

Patrón 1: El registro de skills

Construye un registro central de skills disponibles. Cada skill se registra con un nombre, descripción, schema de input y schema de output. Los orquestadores consultan el registro para determinar qué skills están disponibles para un contexto dado. Así es como Anthropic estructura el sistema de uso de herramientas de Claude y cómo Shopify estructura sus features de IA para comercio.

interface Skill {
  name: string;
  description: string;
  inputSchema: JSONSchema;
  outputSchema: JSONSchema;
  execute(input: unknown): Promise<unknown>;
  validate(input: unknown): ValidationResult;
}

Patrón 2: El compositor de skills

Una capa delgada que toma una intención del usuario, la descompone en una secuencia de skills y ejecuta esa secuencia. El compositor es determinístico, no generativo. Dada la misma clasificación de intención, siempre produce la misma secuencia de skills.

Patrón 3: El evaluador de skills

Un arnés de testing que ejecuta cada skill contra un dataset dorado de pares input/output. Cada PR que modifica un skill debe pasar el evaluador. Esta es tu red de seguridad contra regresiones. Sin ella, estás entregando esperanza.

PostHog aplica este patrón a sus features de analytics con IA. Cada capacidad de IA (lenguaje natural a query SQL, explicación de anomalías, sugerencia de funnel) es un skill discreto con su propio dataset de evaluación. Un skill solo se entrega cuando pasa su dataset dorado al 95% o más.

Lo que esto significa para tu carrera

Si eres un product engineer trabajando en features de IA, el enfoque skills-first debería cambiar cómo planificas tus sprints, escribes tus documentos de diseño y delimitas tu trabajo.

En lugar de escribir un documento de diseño titulado "Construir un Agente de IA para Soporte al Cliente," escribe uno titulado "Diseñar Tres Skills para Clasificación de Tickets de Soporte." En lugar de estimar "3 meses para entregar un agente," estima "1 semana por skill, 4 skills para v1." En lugar de un demo que muestra un agente autónomo haciendo lo correcto a veces, entrega un skill que siempre hace una cosa correctamente.

Aquí es donde mi experiencia como product engineer en AWS moldeó mi pensamiento significativamente. A la escala de AWS, la confiabilidad no es opcional. Un feature que funciona el 80% del tiempo no es un feature; es un pasivo. Cuando entregábamos capacidades con IA, siempre estaban estructuradas como operaciones discretas con contratos definidos, no como sistemas autónomos que podrían o no producir la respuesta correcta. Esa disciplina, entregar capacidades estrechas que son confiables sobre capacidades amplias que son impresionantes en demos, es lo que separa la IA de producción de la IA de conferencias.

El mercado está recompensando este enfoque. Las empresas que exitosamente entregan features de IA en producción abrumadoramente usan una arquitectura basada en skills o uso de herramientas en lugar de un patrón de agente autónomo. Los agentes completamente autónomos toman más tiempo en llegar a producción y cuestan más de mantener.

La conexión con context engineering y patrones agénticos

Construir skills bien requiere context engineering excepcional. Cada skill necesita precisamente el contexto correcto para ejecutar correctamente, no demasiado (lo que diluye el enfoque y aumenta el costo), no muy poco (lo que causa fallos). El arte de diseñar el schema de input de un skill es realmente el arte de definir qué contexto necesita.

Esto también conecta con la ingeniería agéntica de forma más amplia. Los skills son los bloques de construcción de los sistemas agénticos. No puedes construir un buen agente sin buenos skills, pero puedes entregar buenos skills sin un agente. Empieza con los bloques de construcción. La agencia emerge de la composición, no de la ambición.

El product engineer que domina el diseño de skills, que puede identificar las unidades atómicas de capacidad de IA que un producto necesita, delimitarlas precisamente, entregarlas independientemente y componerlas en features, será el constructor más valioso en cualquier equipo de producto con IA. Esto es harness engineering aplicado a la IA: definir las restricciones que hacen al sistema confiable, no solo capaz.

Para empezar: tu primer skill en producción

Aquí hay un flujo de trabajo concreto para entregar tu primer skill de IA:

1. Identifica un flujo de trabajo del usuario que involucre juicio, clasificación o generación. No el más complejo. El más frecuente.
2. Define el contrato input/output. ¿Qué datos entran? ¿Qué estructura sale? Escríbelo como una interfaz TypeScript o JSON schema.
3. Recolecta 20 ejemplos dorados. Inputs reales de tu producto, emparejados con outputs ideales. Este es tu dataset de evaluación.
4. Implementa el skill. Prompt, validación de schema, manejo de errores. Mantenlo en menos de 100 líneas.
5. Evalúa contra tu set dorado. Si la precisión está por debajo del 90%, ajusta el prompt o agrega restricciones. No agregues autonomía.
6. Entrégalo detrás de un feature flag. Mide la precisión en el mundo real. Recolecta retroalimentación de usuarios sobre la calidad del output.
7. Agrega el siguiente skill. Repite. Compón cuando dos o más skills sirvan al mismo flujo de trabajo.

Esto no es lento. Un constructor hábil puede entregar un skill de IA de calidad producción en tres a cinco días usando este flujo de trabajo. En un mes, tienes cuatro a seis skills componibles que juntos parecen "un feature con IA" para los usuarios mientras son individualmente testeables y mantenibles para tu equipo.

Puntos clave

• Los AI skills son capacidades discretas y testeables con inputs y outputs tipados; los agentes son sistemas autónomos que a menudo fallan en producción.
• Las tareas estructuradas basadas en skills tienen éxito a una tasa 7x mayor que las tareas equivalentes dadas a agentes completamente autónomos.
• Empieza con skills individuales, luego compónlos en pipelines; la autonomía debe ganarse incrementalmente, no otorgarse por adelantado.
• Un product engineer hábil puede entregar un skill de IA de calidad producción en tres a cinco días usando el flujo define-implementar-componer-evaluar.
• El 72% de las empresas que exitosamente entregaron features de IA usaron una arquitectura basada en skills en lugar de un patrón de agente autónomo.

FAQ

¿Cuál es la diferencia entre AI skills y agentes de IA?

Un AI skill es una capacidad discreta y componible con inputs y outputs tipados que realiza una sola tarea bien definida. Un agente de IA es un sistema autónomo que decide qué acciones tomar, planifica secuencias de múltiples pasos y ejecuta sin dirección humana explícita. Los skills son testeables, predecibles y entregables. Los agentes son poderosos en teoría pero a menudo no confiables en producción. La diferencia arquitectónica clave es que los skills se invocan explícitamente mientras que los agentes se autodirigen.

¿Debería alguna vez construir un agente autónomo?

Sí, pero solo después de que tengas una biblioteca probada de skills confiables. La autonomía debe ganarse incrementalmente. Empieza con skills discretos, luego encadénalos en pipelines fijos, luego agrega enrutamiento condicional, luego agrega planificación. Cada capa de autonomía solo debería agregarse cuando la capa inferior es estable y bien testeada. Saltar directamente a autonomía completa es la razón por la que la mayoría de los proyectos de agentes fallan.

¿Cómo afecta el enfoque skills-first a la velocidad de entrega?

La aumenta dramáticamente. Los skills individuales pueden entregarse en días porque tienen alcance estrecho, contratos tipados y criterios de éxito claros. Los equipos usando arquitecturas basadas en skills reportan 3x más velocidad hasta el primer valor comparado con equipos intentando agentes monolíticos. Entregas features de IA funcionales en la semana uno en lugar de mostrar un demo de un agente frágil en el mes tres.

¿Qué herramientas soportan la construcción de AI skills?

La API de uso de herramientas de Anthropic, function calling de OpenAI y el AI SDK de Vercel todos proporcionan schemas tipados para definir skills. Para testing, frameworks como Braintrust, Humanloop y Promptfoo te permiten evaluar skills contra datasets dorados. Para composición, LangGraph, Instructor y capas de orquestación personalizadas manejan la secuenciación de skills. El ecosistema de herramientas favorece fuertemente el patrón de skills.

¿Cuántos skills necesita un feature de IA típico?

La mayoría de los features de IA en producción están compuestos de tres a siete skills. Un sistema de soporte al cliente podría necesitar: clasificar intención del ticket, recuperar documentación relevante, redactar respuesta, verificar cumplimiento de tono y extraer acciones de seguimiento. Cada skill se entrega independientemente, y el feature mejora incrementalmente a medida que cada skill se agrega. No necesitas todos los skills en el día uno.

Lectura relacionada

• ¿Qué Es un Product Engineer? La Guía Definitiva
• Context Engineering: Diseñando los Inputs que Dan Forma a los Outputs de IA
• Ingeniería Agéntica: Construyendo Sistemas que Actúan
• Harness Engineering: Restricciones como Estrategia de Entrega
• Cómo Convertirte en Product Engineer