Deja de programar agentes de IA que improvisan: haz esto en su lugar

El que fue el primero de todos mis agentes de IA funcionaba tres veces de cada diez. Y no, el problema no se arregló poniendo un modelo más caro, cambiando de framework o escribiendo un prompt de cuatro mil palabras que parecía la Constitución.

Lo arreglé dejando de pedirle al modelo que improvisara cosas que yo ya sabía hacer. Empecé a darle piezas ya construidas, probadas y reutilizables.

Porque si tus agentes de IA entran en bucle, inventan parámetros, se olvidan de información importante o se gastan tu cuota haciendo intentos absurdos, probablemente no tienes un problema de inteligencia artificial. Tienes un problema de arquitectura.

La pregunta no es: ¿qué modelo debería usar? La pregunta es: ¿qué le estoy pidiendo que adivine que podría estar escrito en un archivo desde hace meses?

El fallo real: agentes de IA intentando adivinar una API

Imagina una tarea totalmente normal: tienes los datos de un alumno y necesitas darlo de alta en una matrícula a través de una API interna de tu empresa.

La API existe, está en producción y funciona. Pero el modelo no conoce sus campos porque nadie fuera de tu equipo conoce esa documentación. No sabe si el parámetro correcto se llama student_id, idAlumno, curso o cualquier otra cosa.

Entonces le pides a los agentes de IA que llamen a la API y completen el registro. ¿Qué hacen? Empiezan a inventar:

• Prueban con StudentID, CourseID y email.
• La API devuelve una petición no válida.
• Como el error no les revela los campos correctos, vuelven a probar con otros parámetros.
• Falla otra vez, vuelven a intentarlo y empieza el festival de tokens.

El modelo no se ha vuelto tonto. Está haciendo exactamente lo que le pediste: adivinar y seguir intentándolo hasta que ocurra algo.

En ese caso se rompen tres cosas a la vez:

1. Parámetros inventados. Si no le has dado el contrato de la API, utilizará patrones que haya visto antes y se imaginará los campos.
2. Bucles de reintentos. No dispone de una forma fiable de saber qué intentó, qué falló y cuándo debe parar.
3. Deriva de contexto. Después de muchos pasos, la información importante que recibía al principio queda enterrada o directamente fuera de contexto.

Estos tres problemas comparten la misma raíz: has dejado que un modelo de lenguaje improvise durante la ejecución algo que debería estar definido de forma explícita.

Llamar correctamente a una API no es un ejercicio de inteligencia. Es una función. Y si es una función, debería estar escrita como código.

Function calling, MCP y skills: no son lo mismo

Hay tres conceptos que se mezclan constantemente en el mundo de los agentes de IA: function calling, MCP y skills. Se habla de ellos como si fueran sinónimos, pero resuelven preguntas completamente diferentes.

1. Function calling: ¿cómo pide el modelo una acción?

El function calling, o llamada a funciones, es el mecanismo que permite al modelo solicitar una acción de manera estructurada.

En vez de generar texto libre diciendo algo como “creo que voy a registrar a este alumno”, el modelo devuelve una llamada con un formato definido. Es la gramática de la petición: qué herramienta quiere usar y qué argumentos debe enviar.

Esto es muy útil, pero no arregla el problema entero. Tener function calling sin una buena arquitectura es como tener un formulario perfectamente diseñado para rellenar datos que el modelo se sigue inventando.

2. MCP: ¿de dónde salen las herramientas?

MCP, Model Context Protocol, es un protocolo estándar para conectar herramientas con modelos y clientes compatibles.

Piensa en él como un USB-C. Te permite enchufar una herramienta a Claude, OpenAI, Gemini u otros sistemas que hablen el mismo protocolo sin reescribir toda la integración cada vez.

Los servidores MCP son útiles porque estandarizan el acceso a las herramientas. Pero MCP no define por sí mismo cómo deben trabajar tus agentes de IA ni les enseña cuándo usar cada acción.

3. Skills: ¿qué sabe hacer el sistema y cuándo debe hacerlo?

Una skill es una habilidad concreta y reutilizable. En su forma más sencilla, es una carpeta que contiene instrucciones y los scripts que ejecutan el trabajo real.

La diferencia es enorme. El modelo no tiene que reinventar cómo descargar un vídeo, transcribir un audio, validar una fecha o enviar una petición a una API. Solo debe detectar qué habilidad necesita en ese momento y activarla.

Usando la analogía de una cocina:

• El function calling es cómo se canta la comanda.
• El MCP es la conexión estándar que permite usar cualquier fogón compatible.
• La skill es la receta: ingredientes, cantidades, pasos y utensilios.

Ninguna de estas capas sustituye a las otras. El error aparece cuando eliges una y esperas que resuelva todos los problemas.

Qué es una skill de verdad

Una skill no tiene por qué ser magia oscura ni una arquitectura gigantesca. De hecho, estructuralmente es bastante simple:

• Una carpeta para una tarea concreta.
• Un archivo skill.md con nombre, descripción e instrucciones.
• Scripts junto a ese archivo para ejecutar las acciones deterministas.

La parte importante está en cómo se reparte el trabajo.

El modelo debería encargarse de lo que realmente requiere criterio: decidir qué contenido merece entrar en un artículo, adaptar el tono, ordenar ideas, encontrar un ejemplo claro o redactar una explicación que se entienda.

El código debe encargarse de lo repetible: descargar un recurso, verificar si hay subtítulos, convertir un archivo, validar campos, llamar a una API con los parámetros correctos o aplicar una plantilla.

Si algo tiene que salir siempre igual, no se lo encargues al texto. Escríbelo en código.

Las skills no llenan el contexto innecesariamente

Una de las ventajas más potentes de las skills es que se cargan bajo demanda. El modelo puede conocer una descripción breve de cada habilidad y abrir sus instrucciones completas solo cuando las necesita.

Esto te permite tener una biblioteca amplia sin meter un prompt gigantesco en cada conversación. Puedes tener decenas de skills sin obligar al sistema a tragarse cada instrucción, cada ejemplo y cada excepción todo el rato.

Un prompt enorme no funciona así. Un prompt enorme entra entero, venga o no venga a cuento. Consume contexto, aumenta el ruido y hace que sea más fácil perder lo importante.

No vas a conseguir un sistema 100% determinista, y está bien

Hay que ser honestos: mientras haya un LLM tomando decisiones, no existe un sistema completamente determinista.

El script sí puede ser determinista. Si recibe los mismos datos, realizará la misma validación o enviará la misma estructura a la API. Pero decidir si debe llamar al script, cuándo debe hacerlo y con qué objetivo general sigue siendo responsabilidad del modelo.

Lo que consigues no es eliminar la incertidumbre. Consigues moverla al lugar correcto.

Antes tenías incertidumbre en todas partes: en los campos enviados, en el formato, en los reintentos, en la memoria y en el resultado final. Con una biblioteca de skills, la incertidumbre queda concentrada en una decisión mucho más controlable: elegir entre piezas conocidas y probadas.

Esa elección se puede registrar, evaluar y mejorar. La improvisación libre buscando a ciegas no.

Un flujo real: de una URL de YouTube a un artículo listo para publicar

Este es exactamente el tipo de sistema que utilizo para producir contenido. Una URL de YouTube entra y sale un artículo preparado para publicar, con estructura, encabezados y el formato habitual.

Pero no hay un agente intentando hacer todo desde cero. Hay una cadena de responsabilidades muy clara:

1. Una skill descarga la información necesaria del vídeo.
2. Si no existen subtítulos, el sistema falla de una forma concreta y avisa.
3. Otra skill puede descargar el audio.
4. Otra realiza la transcripción de audio a texto cuando hace falta.
5. Otra transforma ese material en un artículo con la estructura editorial definida.

El sistema no inventa el contenido de un vídeo si no puede obtenerlo. Tampoco negocia cada vez la estructura de un artículo. Las reglas editoriales, la plantilla y los formatos ya existen como piezas reutilizables.

El modelo se queda con lo que merece su capacidad: redactar, resumir, seleccionar ideas, encontrar el ángulo y decidir qué conviene dejar fuera.

El resultado no funciona porque el modelo sea diferente. Puede ser exactamente el mismo modelo que antes fallaba. Funciona porque cada responsabilidad está colocada en la capa adecuada.

Cuatro reglas para construir tu biblioteca de skills

No empieces diseñando una arquitectura preciosa una tarde de domingo. Ese camino suele acabar con un diagrama muy bonito y cero automatizaciones útiles.

Empieza por lo que repites

Si ya le has explicado a la IA cómo hacer algo tres veces, no tienes una conversación repetida. Tienes una skill que todavía no has escrito.

Empieza por tareas pequeñas y frecuentes: renombrar archivos, preparar una publicación, validar datos, convertir formatos o generar una estructura de proyecto.

Una skill, un trabajo

Cuando una skill intenta hacer dos o tres cosas distintas, el modelo empieza a dudar sobre cuándo utilizarla. Y una skill que se dispara cuando no toca puede ser peor que no tener nada, porque consume tokens y añade ruido.

Separar descargar audio, transcribir audio y escribir un artículo parece más lento al principio. En la práctica hace el sistema mucho más claro, comprobable y fácil de reparar.

La descripción es crítica

La descripción de la skill no es decoración. Es la señal principal que usa el modelo para decidir si esa habilidad sirve para la tarea actual.

Si escribes una descripción vaga, la skill puede no activarse nunca. Describe con claridad qué hace, en qué casos debe utilizarse y cuál es su resultado.

Prueba casos reales, no el ejemplo bonito

El ejemplo perfecto casi siempre funciona. Lo que rompe el sistema es el vídeo sin subtítulos, el PDF escaneado y torcido, la fecha escrita al revés por un cliente o el archivo incompleto.

Una skill vale lo que vale su comportamiento cuando las cosas vienen mal dadas. Prueba los casos incómodos antes de confiarle horas de trabajo.

Tu biblioteca de skills sobrevive a los cambios de modelo

Los modelos cambian. Los frameworks cambian. Las herramientas de moda de hoy quizá dentro de seis meses ya ni se mencionan.

Pero una biblioteca compuesta por instrucciones claras y scripts útiles tiene mucha más vida. Si mañana aparece un modelo mejor, puedes cambiarlo sin tener que reescribir toda tu operativa. Tus piezas siguen ahí.

Es una caja de herramientas. No compras un destornillador para usarlo una sola vez y tirarlo cuando cambia la marca del taladro. Lo conservas, lo mejoras y lo usas cada vez que hace falta.

Si quieres profundizar en herramientas, protocolo, orquestación y decisiones de arquitectura con proyectos reales, tienes el curso de Ingeniería de Agentes de IA. También puedes consultar todas las formaciones de Inteligencia Artificial disponibles en Frogames.

Deja de pedirle a tus agentes de IA que improvisen

No se trata de dejar de usar agentes de IA. Un agente con una buena biblioteca de herramientas es precisamente lo que quieres construir.

Lo que no funciona es un agente al que le pides que se invente contratos de APIs, formatos, procesos empresariales y decisiones repetibles en cada ejecución.

Así que antes de cambiar de modelo, antes de culpar al framework y antes de añadir dos mil palabras más a tu prompt, hazte esta pregunta:

¿Qué le estoy pidiendo que adivine y qué podría dejar escrito para siempre?

Empieza esta semana con una sola skill. Una tarea que repites, que te roba tiempo y que debería funcionar igual cada vez. Esa primera pieza puede ahorrarte muchas más horas de las que imaginas.

Porque los mejores agentes de IA no son los que más improvisan, sino los que saben cuándo dejar de hacerlo.