Patrón · Ejecución · Conocimiento · Descubrimiento
Un agente puede razonar sobre cualquier cosa. Pero solo puede ejecutar lo que sus skills le permiten. Si la acción no existe, es arquitectónicamente imposible.
El problema de fondo
Admin de tu base de datos. Las credenciales de tu cloud. La contraseña de tu dominio. Sin decirle qué puede hacer y qué no. Sin límites. Solo: "haz lo que consideres necesario".
Eso es exactamente lo que hacemos hoy con los agentes de IA. Les damos razonamiento ilimitado y ejecución ilimitada. Y después nos sorprendemos cuando las cosas explotan.
El patrón Agent Skills resuelve esto: el agente piensa sin límites, pero solo ejecuta acciones acotadas, reutilizables y seguras.
La idea es simple: un agente puede razonar sobre cualquier cosa — analizar, planificar, tomar decisiones. Pero a la hora de ejecutar, solo puede hacer lo que sus skills le permiten.
Si la acción no está en el catálogo de skills, simplemente no puede hacerla. No es que elija no hacerla. Es que no existe para él.
Eso es un Agent Skill: una función acotada, reutilizable y segura que un agente puede invocar. El patrón no lo inventó Anthropic, ni Google, ni OpenAI. Tiene más de 40 años. Viene de la robótica.
El modelo mental
Catálogo de skills
Si no existe → no puede hacerlo. Punto.
Esta es la confusión más común al estudiar Agent Skills. Hay 4 términos que se usan de forma intercambiable en internet, pero operan en niveles completamente distintos. Son paralelos, no secuenciales.
La idea universal de separar razonamiento de ejecución. Viene de la robótica de los años 80. No es de Anthropic, no es de Google, no es de nadie. Es ingeniería probada. Cuando hablamos de "el patrón Agent Skills", hablamos de esto.
Concepto: un agente razona libre, pero solo ejecuta capacidades acotadas, reutilizables y seguras.
La función Python, la API, el endpoint que el agente invoca en runtime.
Es lo que el agente ejecuta internamente.
Cada framework tiene su nombre: ADK lo llama tool,
Claude lo llama tool use,
OpenAI lo llama function.
Cuando un tool está bien diseñado — acotado, reutilizable y seguro — está siguiendo el patrón de skill.
Anthropic tomó el patrón y creó un producto: carpetas con conocimiento procedimental empaquetado. No es tool use. No reemplaza las funciones ejecutables. Le enseña al agente cómo abordar tareas complejas, qué flujo seguir, cómo combinar sus tools.
Estructura de un Claude Skill:
my-skill/
├── SKILL.md ← instrucciones + flujos recomendados
├── scripts/ ← helpers ejecutables
└── references/ ← docs adicionales
Publicado como estándar abierto en agentskills.io. Adoptado por +27 herramientas: Cursor, VS Code, GitHub, Gemini CLI, OpenAI Codex, Goose, Databricks y más. Si buscas "agent skills" en internet, probablemente encuentras esto.
En el protocolo A2A de Google, AgentSkill es otra cosa completamente.
No es una función ejecutable. Es una declaración de alto nivel de
lo que un agente sabe hacer — la "tarjeta de presentación" que otros agentes pueden descubrir y usar para delegar tareas.
Un solo AgentSkill puede agrupar múltiples tools internos. Por ejemplo: nuestro DNS Agent tiene 6 tools internos, pero a nivel de A2A se publica como un único AgentSkill: "DNS Management".
No ejecuta nada. Es metadatos de alto nivel para el ecosistema de agentes.
La síntesis
Anthropic resolvió el conocimiento procedimental con SKILL.md. Google resolvió el descubrimiento con AgentSkill en A2A. Caminos paralelos, mismo concepto de fondo. No son capas secuenciales — son diferentes implementaciones del mismo patrón.
Sea un tool de ejecución, un Claude Skill, o un AgentSkill de A2A — todos comparten estos tres principios.
Hace UNA sola cosa con inputs y outputs claros. No tiene efectos secundarios inesperados.
create_dns_record(domain, type, name, value) → record_id. Crea. No modifica, no borra, no toca otros dominios.
El mismo skill funciona en diferentes contextos sin reescribir código.
Para crear un subdominio usas create_record. Para migrar DNS usas find + update. Combinas, no duplicas.
Validaciones internas. No puede hacer más de lo que está definido.
Si le pides algo fuera de su scope, rechaza. El agente no se pone creativo con acciones no previstas.
La analogía más útil para entender el patrón no es técnica. Es empresarial.
El CEO como agente:
El CEO puede pensar sobre cualquier cosa: estrategia, mercados, expansión, productos. Sin límites. Pero cuando necesita que algo se ejecute, llama a un departamento.
RRHH solo puede contratar. Finanzas solo aprueba presupuestos. Legal solo revisa contratos. DevOps solo despliega. Cada departamento es un skill: responsabilidad clara, inputs claros, outputs claros.
¿Qué pasa si el CEO quiere hacer algo para lo que no hay departamento? Simplemente no se puede hacer. Eso es la seguridad por ausencia.
Mapeo directo
Cuando construyes un agente, hay dos formas de controlar su comportamiento. La mayoría de los tutoriales solo te enseña una. La segunda es la que realmente importa.
Cómo debe pensar
⚠️ Sugerencia
El agente las lee, las entiende, generalmente las sigue. Pero técnicamente puede ignorarlas. Son como un manual de procedimientos.
Qué puede hacer
🔒 Restricción real
Si la función no existe, el agente no puede ejecutar esa acción. No importa cuán inteligente sea. Es como darle llaves específicas de un edificio — las puertas sin llave no existen para él.
Ejemplo: DNS Agent con las dos capas
CAPA 1 — Instrucciones:
"Eres un agente de DNS para nicolasneira.dev.
Siempre lista los registros ANTES de crear.
Después de crear, SIEMPRE valida."
→ El agente debería seguir este flujo.
→ Podría saltarse pasos si "razona" que no es necesario.
CAPA 2 — Capacidades:
tools = [
list_dns_records, # ✓
create_dns_record, # ✓
update_dns_record, # ✓
validate_dns, # ✓
# delete_record → NO EXISTE
]
→ Solo puede usar estas funciones.
→ No puede borrar. Nunca. Sin importar qué.
Python puro, Google ADK y Claude Code implementan las dos capas de formas distintas. El patrón es el mismo. La herramienta cambia.
Capa 1 — Instrucciones
instructions= "Eres un agente DNS..."
Capa 2 — Capacidades
skills=[list_dns, create_dns, validate_dns]
Control total. Tú defines explícitamente ambas capas. Máxima flexibilidad, sin magia.
Capa 1 — Instrucciones
instruction= "Genera infraestructura..."
Capa 2 — Capacidades
tools=[get_config, save_compose, gen_jenkins]
Las dos capas explícitas: instruction guía el razonamiento, tools restringe la ejecución.
Capa 1 — Instrucciones
SKILL.md con flujos, reglas y referencias
Capa 2 — Capacidades
allowed-tools: [Bash(curl *), Read]
Capa 1 enriquecida: no solo texto, sino carpeta con scripts y referencias. Claude Code ya tiene las tools integradas.
Un prompt que dice "no borres nada" es Capa 1: una sugerencia que el agente puede ignorar. Un skill que no existe es Capa 2: una restricción arquitectural que el agente no puede saltarse.
# dns_skills.py — catálogo de skills del DNS Agent
# Solo estas 6 funciones existen. No hay delete_dns_record.
DNS_SKILLS = [
list_dns_records, # ✓ puede listar
create_dns_record, # ✓ puede crear (solo A, CNAME, MX, TXT)
search_dns_record, # ✓ puede buscar
update_dns_record, # ✓ puede actualizar
validate_dns, # ✓ puede validar resolución
check_propagation, # ✓ puede verificar propagación
# delete_dns_record ← no existe → imposible ejecutarlo
# update_nameservers ← no existe → imposible
]
# Cuando el agente intenta borrar todos los registros:
# → "No tengo la capacidad de borrar registros DNS."
# → No ejecuta nada. No se pone creativo. Punto.Agente sin skills
"Quiero optimizar el DNS" → agente ejecuta código arbitrario →
puede hacer rm -rf, modificar nameservers, acceder a la cuenta completa.
Agente con skills
"Quiero optimizar el DNS" → agente revisa su catálogo → solo puede listar, crear, buscar, actualizar, validar, verificar. Imposible borrar aunque lo intente.
Tres agentes especializados. El orquestador (DevOps Agent) no tiene tools propias — descubre a los otros dos vía el protocolo A2A y les delega.
Aquí ves los dos patrones de seguridad en acción simultáneamente: SCOPE-based (DNS Agent, restringido a un dominio) y CAPABILITY-based (Monitoring Agent, read-only sin importar el dominio).
SCOPE-based
Gestiona registros DNS contra la API real de Cloudflare.
Scope: solo nicolasneira.dev. Rechaza cualquier operación sobre otros dominios.
CAPABILITY-based
Health check de infraestructura. Observa cualquier dominio, pero no puede modificar nada.
Capability: cualquier dominio, pero solo read-only. No tiene ningún skill de escritura.
A2A Orchestrator
Sin tools propias. Descubre a los otros vía AgentCard y delega tareas.
Razona sobre el flujo completo, pero ejecuta cero acciones directas. Todo pasa por los otros agentes.
Los Agent Skills no los inventó nadie. El patrón ya existía y la industria convergió en el nombre. Eso significa que no estás aprendiendo una feature que puede desaparecer mañana. Estás aprendiendo un patrón de ingeniería probado durante décadas.
Años 80 · Robótica
Behavior-Based Robotics: comportamientos simples, acotados y reutilizables. El robot decide cuál activar. Primera separación entre razonamiento y ejecución.
Años 90 · Sistemas multi-agente
Cada agente publica un directorio de capacidades. Otros agentes descubren qué puede hacer cada quién. Ya había DOS niveles: ejecución interna y publicación externa.
2010s · Microservicios
Netflix, Amazon. Cada servicio tiene una API definida. Contratos claros, límites definidos, composición vía API. Bounded, reusable, safe.
2023 · Function Calling masivo
Los LLMs pueden razonar cuándo usar una función y llamarla directamente. El puente entre razonamiento libre y ejecución acotada.
2025–2026 · Convergencia en "Skills"
Google incluye AgentSkill en el protocolo A2A (descubrimiento). Anthropic formaliza SKILL.md como estándar abierto en agentskills.io (conocimiento procedimental). Más de 27 herramientas adoptadas. El nombre converge.
Las dudas más comunes sobre Agent Skills, Tools, Claude Skills y el protocolo A2A.
Un Agent Skill es una capacidad acotada, reutilizable y segura que un agente de IA puede invocar. El agente puede razonar libremente sobre cualquier problema, pero solo puede ejecutar acciones que estén definidas en su catálogo de skills. Si una acción no existe, el agente no puede ejecutarla — no es una decisión, es una restricción arquitectural del sistema.
Son el mismo concepto en diferentes niveles. "Skill" es el patrón universal de diseño — la idea de separar razonamiento de ejecución, que viene de la robótica de los años 80. "Tool" o "Function" es la implementación concreta en runtime: la función Python, la API o el endpoint que el agente invoca. Google ADK lo llama tool, Claude lo llama tool use, OpenAI lo llama function. Cuando un tool está bien diseñado — acotado, reutilizable y seguro — está siguiendo el patrón de skill.
Claude Skills es el estándar de Anthropic para empaquetar conocimiento procedimental. Una carpeta con un archivo SKILL.md (instrucciones y flujos recomendados), scripts ejecutables y referencias. No reemplaza al tool use — lo complementa. Le enseña al agente cómo abordar tareas complejas, qué flujo seguir y cómo combinar sus tools. Está publicado como estándar abierto en agentskills.io y es adoptado por más de 27 herramientas: Cursor, VS Code, Gemini CLI, OpenAI Codex y más.
En el protocolo A2A (Agent-to-Agent) de Google, AgentSkill es una declaración de alto nivel de lo que un agente sabe hacer. No es una función ejecutable — es metadatos que sirven para que otros agentes lo descubran y le deleguen tareas. Un solo AgentSkill puede agrupar múltiples tools internos. Por ejemplo, un DNS Agent con 6 tools internos se publica como un único AgentSkill llamado "DNS Management" en su AgentCard.
Todo agente tiene dos capas de control. La Capa 1 son las instrucciones: system prompts, archivos markdown, SKILL.md. Guían cómo debe pensar el agente, pero son una sugerencia — el agente técnicamente puede ignorarlas. La Capa 2 son las capacidades: funciones Python, tools registradas, APIs definidas. Son una restricción real — si la función no existe, el agente no puede ejecutar esa acción sin importar cuán inteligente sea. Para sistemas críticos (infraestructura, datos sensibles) hay que usar Capa 2. Para flujos flexibles basta con Capa 1.
Google ADK (Agent Development Kit) es un framework para construir agentes de IA con las dos capas explícitas: el parámetro instruction define cómo debe razonar el agente (Capa 1), y el parámetro tools define qué puede ejecutar (Capa 2). ADK facilita además la publicación de agentes en el protocolo A2A, permitiendo que múltiples agentes especializados se descubran entre sí y se deleguen tareas sin acoplamiento directo.