Deja de programar agentes de IA — HAZ esto en su lugar

Vídeo em Espanhol, publicado pelo canal Juan Gabriel Gomila.

Sobre este contenido: El resumen, los puntos principales y los temas que aparecen a continuación se generan automáticamente a partir de la transcripción del vídeo. Reflejan el contenido, las opiniones, afirmaciones y predicciones presentadas en el vídeo y no representan una posición, validación o verificación de hechos por parte de IA Dots.

Resumen del vídeo

O vídeo explica as causas comuns de falha em agentes autônomos de inteligência artificial, apontando a improvisação dos modelos como o principal problema, e apresenta a divisão em três capas (chamadas de função, protocolos MCP e habilidades) como solução para estruturar sistemas eficientes.

Puntos principales

• Agentes autônomos falham frequentemente porque os modelos de linguagem improvisam parâmetros e criam bucles de erro ao tentar adivinhar informações desconhecidas.
• O problema não é a inteligência do modelo, mas a decisão de design de pedir para ele improvisar em tempo de execução o que deveria estar definido em arquivos.
• São distinguidas três capas fundamentais que não competem entre si: chamadas de função (function calling), Model Context Protocol (MCP) e habilidades (skills).
• Uma habilidade (skill) consiste em uma pasta com um arquivo de instruções (skill.md) e scripts que realizam o trabalho determinista de forma controlada.
• As habilidades são carregadas sob demanda, evitando o esgotamento do contexto do modelo e movendo a incerteza para a escolha da ferramenta correta.
• A recomendação para iniciar na criação de agentes é começar por tarefas repetitivas, definir uma função por habilidade e testar com casos reais e problemáticos.

Temas

Agentes AutônomosInteligência ArtificialModelos de LinguagemFunction CallingModel Context ProtocolSkillsAutomação

Transcripción del vídeo

Texto de los subtítulos disponibles; puede contener errores.

Mi primer agente autónomo funcionaba tres veces de cada 10 y lo que arregló el problema no fue usar un modelo mejor, no fue usar un framework más listo, ni siquiera un prom de 4000 palabras superesecial. Fue dejar de pedirle al modelo que improvisara cosas que yo ya sabía hacer y empezar a darle piezas que ya funcionaban. Hoy te voy a enseñar las tres capas que casi todo el mundo mezcla, porque esa mezcla es justo lo que mete a tu agente en bucle y el sistema con el que produzco los vídeos, los cursos o los artículos del blog de nuestro canal y de nuestra empresa funcionando en vivo al final del vídeo. Y te aviso desde ya porque conozco el titular que has leído. Esto no va dejar de usar agentes, va de dejar de construirlos con la capa equivocada. Empecemos con un fallo real. Nada de diapositivas todavía. Terminal. Este es un agente al que le voy a pedir una tarea de lo más normal y corriente. Toma estos datos de un alumno y llama a esta API que tengo en producción en mi servidor, lo puedes ver en juabrielgomila.com y dame de alta la matrícula. Un detalle importante para que nadie se piense que yo he elegido una rara a propósito. Esta API la he escrito yo, yo mismo, es una API interna para el vídeo de hoy. El modelo no puede saber cómo se llaman sus campos. No es como la API de Stripe o como la API de Open Weather, que normalmente ya se la saben los modelos porque han estado scrapeando toneladas y toneladas de documentación con código conectando a dichas APIs. Esto es exactamente igual que no sabrá cómo se llama tu API el día que tú la quieras publicar. en tu empresa. Y fíjate en lo que pasa en la ventana de la izquierda, que es la de la API, ahí está lo que le está llegando. Le está llegando campos como Student ID, Course ID, email, pero ninguno de esos campos existe. Se los está inventando el propio modelo. La API le devuelve un error y fíjate en qué error. Petición no válida. no le dice qué campos faltan como cualquier API interna de cualquier empresa. Así que el modelo no tiene de dónde aprender y en lugar de parar corrige inventándose otros campos distintos, fallando nuevamente, tercer intento, cuarto intento y gastándose tokens de mi cuota. Y fíjate porque no es lo que parece. El modelo no se ha vuelto tonto. Está haciendo exactamente lo que le he pedido. Adivinar. Le he dado una API y le he dicho, "Apáñate y tira para adelante hasta que la matrícula esté insertada." Un modelo de lenguajes cuando no sabe qué hacer, no se calla, se lo inventa. Si te has fijado bien, aquí hay tres cosas rompiéndose a la vez y conviene separarlas porque no son la misma. La primera, los parámetros inventados. Nadie le dijo que campos existen de verdad, así que se los está imaginando a partir de lo que ya ha visto en internet. La segunda, el bucle reintenta porque no tiene una forma fiable de saber que ya ha probado una cosa y que ha fallado. Y cada vuelta es una llamada y cada llamada es dinero de mi cuota. Y la tercera, la deriva del contexto. En el paso 40 ya no se acuerda de lo que le has dicho en el paso número tres. No es mala fe, es simplemente que le pusiste a sostener con la memoria algo que tenía que estar escrito. La memoria de los lls es limitada y si la sobrepasamos empezará a olvidar lo más antiguo. Y ahora viene la parte incómoda. Resulta que ninguno de estos tres fallos es culpa del modelo. No es que Cloud sea idiota. Los tres son la misma decisión de diseño repetida tres veces. Le he pedido que improvisara en tiempo de ejecución algo que podría estar en un archivo desde hace meses. Llamar a esta API con los campos correctos no es un problema de inteligencia, es una función y llevo un año sin volver a pedirle a un modelo que la adivine, porque si te has metido en esto en los últimos meses, has oído tres palabras mezcladas como si fueran sinónimos, llamadas a funciones, MCPs y skills. Pues resulta que no lo son. Son tres capas totalmente diferentes. Resuelven tres problemas diferentes y no compiten entre ellos. Esta sería la slide que quiero que te lleves del vídeo. Haz una captura de pantalla sin problema. Vamos una por una y cada una con la pregunta que resuelve. Llamadas a funciones o function calling. ¿Cómo pide el modelo una acción? Es el mecanismo de la API. Tú declaras herramientas con un esquema y el modelo, en lugar de escupir texto libre, te devuelve una llamada estructurada. Es básicamente la gramática de la petición que permite que las salidas estén estructuradas. MCP, el model context protocol. ¿De dónde salen esas herramientas que el modelo quiere usar? Es un protocolo, es un estándar, es el USBC que le enchufas a cualquier cliente que hable MCP sin tenerla que reescribir para cada uno. Esto hace que los servidores MCP sirvan para cloud o sirvan para Openi o sirvan para Gemini, etcétera. Y las herramientas, ¿qué sabe hacer y cuándo la aplica? una carpeta con un archivo de instrucciones y al lado los scripts que hacen el trabajo. Y es que las skills es algo superfácil de crear y de implementar. De hecho, tenemos varios vídeos aquí en el canal de YouTube y es que el modelo resulta que solo carga una habilidad cuando la necesita. Piénsalo como un restaurante, una cocina. La llamada función es cómo se canta la comanda. El MCP es la toma de gas, el estándar que hace que cualquier fogón se encaje. Y una habilidad es la receta escrita con sus pasos y sus cantidades. Ninguna sustituye a la otra, las tres son necesarias. Y ahí está el error que te está costando las noches. La gente suele elegir una y espera que le resuelva el problema entero. Llamadas a funciones sin habilidades es un modelo improvisando con una buena sintaxis. Y habilidades sin disciplina es otro prompt largo pero con carpetas. Lo que de verdad arregla el bucle que has visto hace 2 minutos es esto. El trabajo exacto lo hace el código. El modelo solo elige qué código es el que debe tocar. Y bueno, si has llegado hasta aquí, esto es exactamente lo que damos paso a paso y con proyectos reales en nuestro curso de ingeniería de agentes de inteligencia artificial engaformación, como diseñar el sistema entero, herramientas, el protocolo, la orquestación y las decisiones de arquitectura que no salen en los tutoriales de 15 minutos en YouTube. Son 26 horas de contenido, casi 27, y es el curso más avanzado que tenemos sobre esto. Te voy a dejar el enlace abajo en la descripción. Y ahora seguimos porque viene la parte que se ve en la pantalla. Como te he dicho, en el canal ya hice un vídeo entero sobre cómo crear tu primera skill, así que aquí no te voy a repetir el tutorial, te voy a enseñar la parte que importa para lo que estamos hablando, porque una skill arregla lo que un prompt nunca es capaz de arreglar. Estructuralmente es simple, casi te diré que decepcionante una vez que lo descubres. Una skill es una carpeta, una habilidad, una carpeta. Dentro hay un fichero llamado skill.md que tiene dos partes diferenciadas, arriba el nombre y una descripción y debajo las instrucciones. Y al lado, en la misma carpeta, los scripts que realmente hacen el trabajo de verdad. Pero hay dos detalles que son los que cambian el resultado final. El primero, se carga la habilidad bajo demanda. Y es que el modelo no va a leer las instrucciones completas de todas tus habilidades todo el rato gastándote los tokens. No leerá la descripción, que son dos líneas, y solo abrirá la skill entera cuando le haga falta. Por eso puedes tener 40 skills y no reventar el contexto. Un prompt gigante no te da eso. Eso te lo tragas entero con patatas siempre, aunque no venga a cuento, aunque no lo tengas que utilizar. Y segundo, y este de hecho es el corazón del vídeo, el trabajo determinista está en el script, no en el texto. Si algo tiene que salir siempre igual, la estructura de un archivo, el formato de una fecha, los campos de una llamada a una API, eso es código. El modelo no lo escribe cada vez, lo ejecuta. Y aquí te tengo que ser honesto, porque hay mucho vídeo por ahí vendiéndote esto como si fuera magia oscura. Esto no te da un sistema 100% determinista. De hecho, no existe tal cosa mientras haya un modelo de lenguaje en el circuito. El script hace siempre lo mismo, sí, pero quién decide llamarlo y cuándo sigue siendo un LLM. Lo que ganas es otra cosa muy diferente y es enorme. No eliminas la incertidumbre, la mueves al sitio correcto. Antes tenías incertidumbre en cada paso, ahora la tienes en un solo sitio. En la elección, la elección entre piezas conocidas se prueba, se registra y se arregla. Una improvisación libre del modelo intentando encontrar a ciegas los datos que necesita, ¿no? Pues bien, basta ya de tanta teoría. Este es el repogain. No es un ejemplo de juguete montado para el vídeo, es pues básicamente el repoir todo lo que son las chuletas, los artículos, los guiones de este canal, incluido, por ejemplo, el guion que he utilizado para el vídeo de hoy. Luego volveremos a esto. Si simplemente aquí abro mi cloud, mi sesión de cloud, te voy a enseñar la lista de skills, porque si hago barra, tengo aquí centenares de skills. Todas ellas empiezan por CC de content creation, donde hay simplemente un content creation para generar una chuleta, para publicar una lección directamente en nuestra plataforma, para configurar un text to speech, por ejemplo, para nuestros cursos de inglés o de francés, los estándares que se deben seguir a la hora de crear contenido, a la hora de reemplazar un vídeo con unos subtítulos o, por ejemplo, traducirlo a otro idioma. Transcripción de audio de vídeo. En definitiva, aquí tengo un montonazo de herramientas que son las que utilizo diariamente. En particular, voy a lanzar una sola para que lo veas. Simplemente tenemos una de aquí que es CC YouTube to blog, que sería esta de aquí, YouTube to blog, a la que le puedo pasar una URL. En este caso le he pasado la URL de un vídeo mío de YouTube donde precisamente creábamos la primera skill para Cloud Code. Y lo que quiero simplemente con YouTube to blog es que me escriba un artículo del blog que esté listo para publicar. Así que le voy a dar y mientras corre, pues mira el reparto por dentro, porque es exactamente lo que hemos estado dibujando. En este caso, para el vídeo de YouTube, bajar el script del vídeo lo hace un script, una habilidad, siempre igual. Y si el vídeo no tiene subtítulos, fallará de una forma concreta y me avisará. No se inventará el contenido de mi propio vídeo, que es justo lo que haría un modelo al que le pides, consígueme el texto de ese vídeo. La estructura del artículo, nuestros artículos siempre llevan encabezados, el formato de la salida, básicamente una plantilla. Eso no se negocia en cada ejecución. Ya se lo damos preparado para que nuestros artículos tengan ya un estilo. ¿Y qué es lo que hace el modelo? Pues el modelo, lo único que yo no puedo escribir en un script, redactar, escribir el ángulo, encontrar el ejemplo que se entiende, decidir qué se queda en el artículo y qué se va fuera. Pues aquí estaría el artículo. Esto es lo que quiero que veas y es que no ha entrado en bucle, no se ha inventado un parámetro y no se ha olvidado de la mitad de lo que estábamos haciendo. Y no porque el modelo sea más listo que el de la primera demo. De hecho, el modelo es exactamente el mismo, Cloud Code Opus 5. Lo único que ha cambiado es dónde puse cada una de las responsabilidades que debía llevar a cabo. Y de hecho, para que me creas, he entrado en la carpeta de los vídeos donde él simplemente me va preparando las estructuras de los vídeos que voy grabando. Y el guion de este vídeo ha salido precisamente de otra de las skills de esa misma forma. En este caso tengo por ejemplo aquí el guion que simplemente es lo que he utilizado para presentar el vídeo de hoy. Y por ejemplo, me ha preparado también las slides para que tenga yo un material con el que poder enseñarte la información pasito a pasito y me sea también más fácil usar como un nexo cuando te explico las cosas. Es básicamente como trabajo en forgmación. Vale. Sí. ¿Y por dónde empiezas tú? Porque el error clásico aquí es ponerse a diseñar una arquitectura preciosa un domingo por la tarde cuando no echan nada en la película de Antena 3 y esto suele no terminar nunca. Cuatro reglas básicas que te dejo sobre la mesa y las cuatro me las he ganado equivocándome. Estas cuatro reglas si las hubiera sabido hace un año, estaría ya a kilómetros de distancia. Número uno, empieza por lo que repites, no por lo que impresiona. Mi regla es muy sencilla. Si se lo has explicado a la IA ya tres veces, ya no es una conversación, es una skill que no has escrito. Número dos, una skill, un trabajo. En cuanto una skill hace dos cosas, el modelo empieza a dudar de cuándo usarla. Y una skill que se dispara a destiempo es siempre peor que no tenerla porque te va a consumir los tokens. Fíjate que en mi caso tenía una skill que me servía para poder descargar el audio de YouTube y otra que me servía para hacer la transcripción del audio a texto y otra que me servía para a partir de la transcripción de mi vídeo poder escribir el blog del post. Número tres, la [carraspeo] descripción no es decorativa, es literalmente lo único que el modelo lee para decidir si te sirve. Si esa descripción es muy vaga, tu skill no existirá, no será llamada nunca ni será tenida en cuenta por tu propio modelo. Y cuatro, pruébala con casos reales, no con el ejemplo bonito que siempre funciona. El ejemplo bonito siempre, siempre, siempre te va a funcionar. Lo que se rompe es cuando el vídeo no tiene subtítulos. El PDF, en lugar de estar bonito, está escaneado, le falta un trozo, está torcido. El cliente escribe la fecha al revés. Todas esas cosas hay que probarlas porque hasta que no se prueban no se sabe si la skill que has preparado te va a ahorrar horas de trabajo o simplemente te va a hundir más en la miseria. ¿Y por qué esto merece la pena, aunque mañana cambie todo? Porque es que tus skills son texto y scripts, no están atados a un framework que en 6 meses no existe. Sí, yo aquí he usado cloud code, pero esto te funcionará con cualquier LM o con cualquier modelo que exista ahora o que se vaya a lanzar en el futuro. El día que salga un modelo mejor, pues lo cambias y tu biblioteca de habilidades sigue ahí. Es como la caja de herramientas que se compra todo el mundo para hacer bricolaje. Esa caja de herramientas vale tu peso en oro si las conservas y las pules de forma correcta. Yo ya lo he hecho varias veces y no he tenido que reescribir nada. Ya he cambiado varias veces de modelo. Antes usaba Antigravity con Gemini, ahora estoy con Cloud Code y la verdad no he tenido que reescribir nada. La misma librería que me funcionaba con una me funciona con la otra. Y ojo que quede claro para cerrar el círculo del título. Esto no es dejar de usar agentes. Un agente con una biblioteca de piezas buenas es justo lo que tú quieres tener. Esa caja de herramientas donde siempre tienes el destornillador a punto cuando te hace falta. Eso te salva horas de tener que ir a comprar una herramienta para arreglar justo lo que se te había roto en la casa. Lo que no funciona es el agente que improvisa. Y llevamos un año confundiendo las dos cosas. Eh, así que si tu agente te está fallando antes de cambiar de modelo y decir, "Es que este modelo es una mierda", hazte una sola pregunta. ¿Qué le estoy pidiendo que adivine? ¿Qué podría estar escrito y no lo está? Empieza por ahí, por una esta misma semana, ahora cuando termines y cuéntamelo en los comentarios cuál es esa primera skill que vas a crear que te va a ahorrar horas de trabajo. Me los voy a leer y de hecho, si se me ocurre algo, te voy a contestar para que la puedas pulir y mejorar. Si este vídeo te ha servido, suscríbete y dale like, que es lo que hace que estos vídeos lleguen a más gente que realmente se está peleando con el mismo problema. Y por aquí al lado te voy a dejar el paso a paso de cómo se crea una skill desde cero, la carpeta, el archivo y sobre todo por qué a veces no se dispara la dichosa skill. Ese era el siguiente que te quería mostrar, pero como ya lo tenemos, nos vemos en ese vídeo.

Assistir ao vídeo original no YouTube

Assuntos: Agentes de IA. Publicado no YouTube em 2026-09-10.

Seleção automática por assunto e idioma. O vídeo pertence ao canal de origem.