El ecosistema de agentes tiene un problema de terminología que oculta una decisión arquitectónica real.”Tools” y “skills” se usan indistintamente en decks de marketing y charlas de conferencias, pero representan enfoques fundamentalmente distintos para extender las capacidades de un agente. Entender esa diferencia es lo que separa a los agentes que funcionan en demos de los que funcionan en producción.
Pero hay una verdad incómoda que se pierde en los debates semánticos: desde la perspectiva del agente, todo son tools. Skills, toolkits, funciones, servidores MCP: al final todos se convierten en opciones que se le presentan al modelo con una descripción y una forma de invocarlos. La distinción importa para la manera en que túorganizas y construyes capacidades. Importa mucho menos que si esas capacidades pueden ejecutarse de forma segura en producción.
La distinción central: ejecución versus experiencia
Una tool es una función ejecutable con entradas, salidas y efectos secundarios definidos. Cuando un agente llama a una tool, algo ocurre en el mundo: se consulta una base de datos, se llama a una API, se escribe un archivo. Las tools son las manos del agente, las que hacen cosas.
Una skill es experiencia empaquetada que moldea cómo piensa el agente y cómo aborda los problemas. Las skills no ejecutan código directamente; aportan contexto, instrucciones, conocimiento de dominio y patrones de comportamiento que hacen al agente mejor en tareas específicas. Las skills son la formación del agente, lo que sabe.
La distinción determina tu arquitectura, tu modelo de despliegue, tu superficie de seguridad y, en última instancia, si tu agente puede hacer trabajo útil.
Cómo definen estos conceptos los principales actores
Anthropic traza la línea más clara entre tools y skills. Su Model Context Protocol (MCP) maneja tools: funciones ejecutables expuestas mediante una arquitectura cliente-servidor con JSON-RPC 2.0. Por separado, su función Agent Skills ofrece lo que describen como “recursos componibles para Claude que transforman agentes de propósito general en agentes especializados”. Las skills se organizan como carpetas con instrucciones, plantillas, scripts y materiales de referencia que los agentes descubren y cargan dinámicamente. Decisivo: las skills extienden las capacidades de Claude sin requerir el overhead de protocolo de MCP; son, en esencia, prompts sofisticados con archivos asociados.
OpenAI no usa formalmente el término “skills”. Su paradigma son tools de principio a fin. El function calling permite que los modelos generen argumentos estructurados que coincidan con los schemas definidos por el desarrollador, y su evolución de “functions” a “tools” (diciembre de 2023) señaló la intención de soportar múltiples tipos de capacidades más allá de funciones invocables. El Agents SDK provee orquestación, handoffs y guardrails, pero la unidad de capacidad sigue siendo la tool.
LangChain usa una jerarquía de tres niveles: las tools son funciones que los agentes pueden invocar; los toolkits son colecciones de tools relacionadas para un propósito común; y los agentes combinan LLMs con tools en ciclos de razonamiento. Como OpenAI, LangChain no distingue formalmente skills de tools. La interfaz bind_tools funciona de manera idéntica entre proveedores, tratando todo como funciones invocables sin importar la complejidad subyacente.
| Proveedor
|
Concepto de “tool”
|
Concepto de “skill”
| | | |
|
Anthropic
|
Tools MCP (ejecutables, basadas en protocolo)
|
Agent Skills (paquetes de experiencia basados en prompts)
| |
OpenAI
|
Functions/tools (ejecutables, definidas por schema)
|
No distinguido formalmente
| |
LangChain
|
Tools + Toolkits (ejecutables, agnósticas al proveedor)
|
No distinguido formalmente
|
Por qué esta distinción realmente importa
La división tools-versus-skills apunta a una pregunta arquitectónica más profunda: ¿dónde vive la inteligencia del agente?
En una arquitectura centrada en tools, el agente es relativamente genérico. La inteligencia viene de tools bien diseñadas con interfaces claras. El trabajo del agente es seleccionar y orquestar tools. Este es el modelo de OpenAI y LangChain: dale a un modelo capaz buenas tools y deja que resuelva cómo usarlas.
En una arquitectura centrada en skills, la inteligencia está integrada en el propio agente mediante conocimiento especializado y patrones de comportamiento. Las tools se vuelven utilidades más simples; el agente sabe cómo abordar problemas en dominios específicos. Este es el modelo Agent Skills de Anthropic: el agente carga experiencia, no solo capacidades.
Las implicaciones prácticas son importantes:
La economía de tokens favorece a las skills. El equipo de ingeniería de Anthropic descubrió que un solo servidor GitHub MCP puede exponer más de noventa tools, consumiendo más de 50,000 tokens de schemas JSON antes de que el modelo empiece a razonar. Las skills, al basarse en prompts, pueden codificar experiencia de dominio sin el overhead de los schemas. Su enfoque “Code Execution with MCP” redujo un flujo de 150,000 tokens a aproximadamente 2,000 al hacer que los agentes escribieran código para llamar a las tools en lugar de cargar todas las definiciones al inicio.
Las superficies de seguridad difieren drásticamente. Las tools requieren autenticación, autorización y un alcance cuidadoso de lo que los agentes pueden hacer. El investigador de seguridad Simon Willison identificó vulnerabilidades fundamentales en MCP, incluyendo rug pulls (tools que mutan sus definiciones después de instalarse) y tool shadowing (servidores maliciosos que interceptan llamadas a servidores de confianza). Las skills, al basarse en prompts, no tienen la misma superficie de ataque, pero tampoco pueden hacer nada sin tools que ejecuten. Y ahí está el punto clave: al final, todo agente útil necesita autenticarse en servicios externos y tomar acciones reales. El vocabulario que uses para describir capacidades importa menos que si resolviste el problema de autenticación.
La portabilidad varía. Las tools MCP son teóricamente portables entre cualquier host compatible con MCP. Las skills son actualmente específicas de Anthropic. Si estás construyendo agentes multi-modelo o quieres flexibilidad de proveedor, las tools ofrecen una interfaz más estandarizada.
La dimensión de las tools locales
Ortogonal al debate skills-versus-tools está la pregunta de dónde se ejecutan las tools. Las tools locales corren en la misma máquina que el agente (o en el entorno del usuario), mientras que las tools remotas corren en servidores externos accedidos mediante llamadas de red.
Los servidores MCP locales que usan transporte de entrada/salida estándar mantienen los datos en el dispositivo con latencia mínima, permiten operación sin conexión y evitan dependencias de red. Los servidores remotos permiten despliegue sin configuración y acceso compartido entre equipos, pero introducen latencia y requieren autenticación OAuth 2.1 adecuada.
Esto importa más de lo que la mayoría de los equipos cree. Las tools locales pueden acceder al sistema de archivos del usuario, variables de entorno y servicios locales. Las tools remotas requieren compartir datos explícitamente. Las implicaciones de seguridad y privacidad van en ambas direcciones: las tools locales tienen más acceso pero menos exposición, mientras que las remotas están más contenidas pero exigen confiar en el operador del servidor.
Aquí es donde el debate skills-versus-tools revela sus límites: llames “skill” o “tool” a algo, si necesita conectarse a Gmail, Slack, Salesforce o cualquier otro servicio autenticado, enfrentas la misma complejidad de OAuth. El 99% de los servidores MCP de hoy están construidos para un solo usuario. En el momento en que necesitas que múltiples usuarios finales se autentiquen con sus propias cuentas (un requisito básico para cualquier SaaS en producción), los debates de terminología se vuelven irrelevantes. Lo que importa es la infraestructura que maneja la autenticación correctamente.
Lo que aprendieron los equipos en producción
Los equipos que realmente están lanzando agentes han convergido en algunos aprendizajes no tan obvios:
El diseño de las tools importa más que su cantidad. Los agentes de código exitosos suelen usar menos de diez tools. La tentación de exponer cada capacidad posible genera efectos negativos: los modelos se confunden, los presupuestos de tokens explotan y las tasas de error suben. El equipo de ingeniería de Anthropic descubrió que exigir rutas de archivo absolutas eliminó toda una clase de errores que afectaban a los agentes que usaban rutas relativas después de cambiar de directorio. Las decisiones de interfaz pequeñas se acumulan.
Las skills llenan huecos que las tools no pueden. Cuando Monte Carlo construyó agentes en producción, descubrieron que ingenieros y científicos de datos necesitaban cooperar de cerca, registrando y marcando cada llamada al LLM para rastrear qué tareas del agente causaban problemas. La “skill” aquí no era una tool. Era conocimiento organizacional sobre patrones de depuración, heurísticas específicas del dominio y modos de fallo. Este tipo de experiencia no cabe bien en una firma de función.
La trampa de la complejidad de los frameworks es real. Cognition (Devin) advierte explícitamente contra las arquitecturas multi-agente: “En 2025, ejecutar múltiples agentes en colaboración solo genera sistemas frágiles”. Su recomendación es agentes de un solo hilo con compresión de contexto. Las implementaciones más exitosas no usan frameworks complejos. Construyen con patrones simples y componibles.
La autorización es lo que mata los proyectos en producción. Esta es la lección que no recibe suficiente atención. Los equipos pasan meses construyendo lógica de agente sofisticada, diseñando cuidadosamente interfaces de tools, debatiendo arquitecturas de skills versus tools. Y luego chocan contra un muro cuando intentan lanzar. El agente no puede hacer nada porque conectarse a servicios reales con credenciales reales de usuarios es un problema de otra categoría. Aproximadamente el 70% de los proyectos de AI no llegan a producción, y la complejidad de la autorización es uno de los principales culpables. Esto es especialmente cierto en entornos de alto riesgo, como integrar AI en flujos de trabajo de producción, que exigen un alcance granular estricto antes de que los agentes puedan acceder de forma segura a las tools de producción.
Un marco para elegir
¿Cuándo deberías invertir en tools versus skills versus ambas?
Invierte en tools cuando:
- Necesitas que los agentes tomen acciones en el mundo (APIs, bases de datos, sistemas de archivos)
- Quieres capacidades que funcionen en distintos modelos y frameworks
- La capacidad está bien definida con entradas y salidas claras
- Necesitas rastros de auditoría y control de acceso sobre lo que los agentes pueden hacer
Invierte en skills cuando:
- Necesitas experiencia de dominio que moldee cómo los agentes abordan los problemas
- La eficiencia de tokens importa (tools complejas con muchas opciones)
- Estás construyendo específicamente sobre Claude y puedes usar Agent Skills
- El conocimiento es sobre criterio y enfoque, no solo ejecución
Invierte en ambas cuando:
- Construyes sistemas en producción donde los agentes necesitan tanto experiencia como capacidades
- Dominios donde saber qué hacer (skill) es tan importante como hacerlo (tool)
- Quieres que las skills guíen la selección de tools y los patrones de uso
Pero independientemente del camino que elijas, invierte en infraestructura de autenticación primero. La arquitectura de skills/tools más elegante no vale nada si tu agente no puede acceder de forma segura a los servicios que necesita para actuar.
La conclusión real
La distinción skills-versus-tools no se trata de elegir un ganador. Se trata de entender que las capacidades de un agente vienen de dos fuentes distintas: lo que los agentes pueden hacer(tools) y lo que los agentes saben (skills).
La confusión de estos conceptos en la industria oculta una decisión arquitectónica real. Los equipos que tratan todo como tools terminan con ventanas de contexto infladas, modelos confundidos e integraciones frágiles. Los equipos que solo invierten en skills terminan con agentes que piensan brillantemente pero no pueden hacer nada.
Los que lo están haciendo bien piensan con cuidado en qué capacidades pertenecen a cada capa. Mantienen el número de tools bajo y las interfaces limpias. Codifican la experiencia de dominio en skills en lugar de esperar que los modelos lo deduzcan de las descripciones de las tools. Y reconocen que las guerras de protocolos (MCP versus function calling versus lo que venga después) importan menos que la pregunta fundamental de dónde vive la inteligencia en su arquitectura de agentes.
Pero desde el punto de vista del modelo, todo lo que le das es simplemente una opción para elegir. Lo llames skill, tool, función o servidor MCP, el agente ve una descripción y una forma de invocarlo. La taxonomía importa para tu modelo mental y la organización del código. No cambia lo que experimenta el agente.
Lo que sí cambia la capacidad del agente para ser útil es si puede ejecutar realmente. Y eso es un problema de infraestructura, no de terminología.
Dónde encaja Arcade.dev
En Arcade, adoptamos una postura deliberadamente simple sobre el debate skills-versus-tools: todo son tools.
No porque las distinciones arquitectónicas no existan, sino porque desde la perspectiva del agente, todo termina siendo una opción para seleccionar e invocar. El reto real no es decidir cómo llamar a tus capacidades. Es hacerlas funcionar en producción con usuarios reales, credenciales reales y requisitos de seguridad reales.
Por eso construimos Arcade como un runtime centrado en autenticación. Manejamos OAuth para más de 100 servicios (Gmail, Slack, GitHub, Salesforce y más) para que tu agente pueda tomar acciones reales sin que tengas que construir una gestión compleja de credenciales. Los tokens nunca pasan por el LLM. La autorización ocurre just-in-time con alcance de mínimo privilegio, un requisito crítico para construir asistentes de AI seguros y listos para producción. Ya sea que expongas capacidades vía MCP, LangChain, el SDK de OpenAI o llamadas directas a la API, la capa de autenticación funciona igual.
El equipo fundador lleva años trabajando en identidad e infraestructura. Cuando empezamos a construir agentes nosotros mismos, chocamos contra el mismo muro que todos: el agente era inteligente, las tools estaban bien diseñadas, pero conectarse a servicios de forma segura era un problema de otra categoría. Así que construimos la capa de runtime que hubiéramos querido que existiera.
Nuestra postura sobre el debate skills-versus-tools: deja de debatir y empieza a lanzar. Usa la abstracción que tenga sentido para tu dominio. Llama a las cosas como quieras. Pero invierte en infraestructura que permita a tu agente tomar acciones de forma segura, a escala y con autenticación de usuario adecuada.
Eso es lo que marca la diferencia entre una demo y un producto.
