Artículo

Laboratorio de SMLs: La Estrategia de los Agentes

Jesús Manuel Nieto Carracedo etani.es AgentesIA OrquestaciónIA AGENTS.md TASKS.md PLAN.md

En la arquitectura de sistemas impulsados por IA, la clave no reside únicamente en la potencia del modelo individual, sino en la estructura de colaboración que diseñamos para ellos. Para escalar procesos complejos, debemos dejar de ver a la IA como un simple chat y empezar a tratarla como una fuerza laboral organizada.

Ficheros como Planificación: La Memoria Compartida

Uno de los pilares fundamentales en este laboratorio es el uso de ficheros como planificación. En un entorno de agentes, la memoria no puede ser efímera; debe ser persistente y accesible.

De esta forma obtenemos ventajas adicionales:

  • Podemos hacer modulares nuestras planificaciones en diferentes ficheros que podemos versionar y almacenar con git, además esto es una forma de realizar una especie de integración continua con los prompts. Creamos ficheros de control, los versionamos, mejoramos, compartimos, modificamos, etc...
  • Podremos ir con el paso del tiempo, refinando y añadiendo agentes en su fichero AGENTS.md, de alguna forma, dejarme soñar despierto, evolucionar este tipo de ficheros, implica que la experiencia del trabajo diario, empiece a almacenarse en ellos. Además podremos refinar y crear mejores competencias a través de SKILLS.md. Realizar y pulir bien estos ficheros supondrá a parte de un arte, acumular conocimiento experto, ya que si yo no conozco la empresa en la que trabajo, no podré ajustar a mis agentes del mismo modo que lo haría una inteligencia externa, sea esta artificial o natural. Aunque en un principio, contar con un LLM comercial para pulir estos agentes, será no sé si imprescindible, pero altamente recomendado. Es tan abierta la parametrización de los ficheros, que necesitas un consultor al lado que te guie, haga la primera plantilla que revises, refines y consultes.
  • Podemos definir jerarquías de agentes, como un agente supervisor con el contexto completo del proyecto, y agentes "curries" (en referencia a "Fraggle Rock" para los que ya tenemos una edad...), que hagan tareas cortas, pequeñas, y con contextos mucho menores, para ejecutarse en VRAM de forma muy rápida. Es decir tendremos la potencia de trabajar con roles como lo llevamos haciendo los responsables de equipos durante toda la vida, con personas.

No entraré en este blog a hablar de la ética y la política derivada del uso de agentes por empresas, si alguien quiere debatir sobre157535 ello, podríamos crear otra entrada en el blog.

Ficheros como TASKS.md y `PLAN.md actúan como la "memoria compartida" del equipo. Estos documentos son los que definen:

  • Qué se va a hacer (objetivos claros).
  • Quién lo hará (asignación de roles).
  • Cómo se medirá el éxito (criterios de aceptación).

La creencia extendida sobre muchos usuarios que piensan que usar modelos de lenguaje es simplemente tener conversaciones en un chat, es bastante extendida por desgracia, además se tiene a pensar que estos modelos pueden memorizar nuestras conversaciones, extraer datos, almacenarlos en base de datos, para mezquina y usurariamente nutrirse de ellos a tiempo real con eso que llaman "entrenamiento de modelos". Ojalá un modelo de lenguaje pudiese almacenar información con la misma facilidad que un programa de escritorio, en una base de datos convencional, pero de hacerlo de esta forma, no podrían comportarse como lo hacen, relacionando tantos conceptos.

Un modelo, una vez entrenado se puede contextualizar con la conversación, pero no podrás guardar datos persistentes, como se hace en una base de datos. Hay técnicas como el uso del System Prompt, que puede dar el mismo cierto contexto al modelo en cada conversación, al final son tokens que suman, recuerda el artículo anterior. En modelos comerciales, se ha desarrollado ciertos mecanismos o soluciones para dar más personalización al usuario. Al no declarar normalmente el tamaño de su contexto, almacenan cierta memoria sobre el usuario, detalles que guardan en algo equivalente a un fichero. El mecanismo, en muchísimo resumen, simplemente quiero que tengas unas nociones o ideas, no pretendo hacer un paper científico sobre las cabezas de auto-atención de un transformer, toma unas notas que, cuando inicias una conversación, las carga en el contexto directamente, quieras o no. Esto es un mecanismo de fuerza bruta. En un modelo local, contar con un contexto en VRAM de solo 132K tokens, es un lujo, cualquier modelo comercial dispone de muchísimo más. Este es otro de los motivos por los cuales los modelos locales no son capaces de gestionar muchísimas relaciones entre conceptos.

La suerte que tenemos si administramos nuestros modelos, es que nosotros podemos beneficiarnos de este mecanismo, creando "notas" más cortas, resumidas, específicas, para el modelo.

La idea principal es, que un modelo de lenguaje solo aprende con el entrenamiento. Sino lo has entrenado con datos nuevos, lo estás contextualizando y si usas otro contexto (otra conversación), sentirás lo mismo que Nemo hablando con Dori cada 2-3s...

Por ejemplo, imagina un comercial que usa un CRM, una herramienta de gestión de relaciones entre contactos. ¿Nunca te has preguntado por qué, alguien que no te conoce de nada, te llama cada 6 u 9 meses, para preguntarte por tu mujer, hijos, o tu equipo de fútbol favorito, antes de colarte su mejor oferta? Bueno, los que ya vamos teniendo una edad, vivimos en etapas anteriores este sistema, que ahora sería un marketing primitivo. Realmente muchos comerciales guardaban una tarjeta escrita con toda esta información que para ellos les parece relevante, tu edad, gustos políticos, deportivos, familiares, problemas, etc... para tratar de "empatizar" contigo. Cuando cierras la puerta de casa, le hayas o no cogido uno o veinte libros, en la puerta de al lado, tu vecino sentirá la misma experiencia de usuario, "Juan, el comercial de los libros, que majo es, siempre se acuerda de la enfermedad de mi madre", y Juan probablemente no recuerde nada, antes de leer la tarjeta.

Pues los modelos de lenguaje funcionan siguiendo este patrón. ¿Es memoria? Si y no como la conocemos. ¿Es posible que en un futuro usen esta información para aprenderla y sumarla a sus conocimientos? Pues depende de lo que ellos consideren de importancia. Piensa que cada parámetro entrenable de un modelo, tiene un coste brutal, lo mismo saber que te llevas mal con tu vecina, o que tu vecino no usa desodorante en verano, y que es mejor ir por la escalera si ha ido él antes al garaje, no sea algo que google desee incorporar al próximo modelo puntero de IA... Si es cierto que, cuando una empresa te permite usar su modelo gratis, al final algo se llevará a cambio, y si en alguna conversación encuentra valor en tus datos, los podría usar, por ejemplo, imagina que como yo, de vez en cuando compites en Kaggle, y creas scripts que buscan soluciones de ML para problemas que te dan (predecir cuantos supervivientes habría entre una lista de pasajeros del Titanic), si he conseguido una puntuación altísima en mi entrenamiento, porque he usado una técnica nueva, ingeniosa, novedosa, podría ocurrir (es un ejemplo, dudo que yo pueda desarrollar algo que le interese a una gran empresa de IA) que clasifiquen mi código compartido como útil y lo incorporen, en 5-6 meses si alguien solicita un ejemplo para este torneo, el modelo entrenado con mi código, podría usar partes de él, o usarlo como base para prototipar una posible solución. O bien, puede que mi algoritmo no le parezca atractivo, pero al pasarle mis datos de entrenamiento, donde tengo datos bancarios, edades, nombres y apellidos de los niños que entrenan lectura en mi empresa, en unos meses los use tal cual, para pasárselos como datos de prueba a alguien que le pida hacer algo, donde estos datos encajen. Con esto podrías estar exponiendo los datos de tus clientes al mundo.

Otro de los problemas de los modelos locales, y que tuvieron al principio los comerciales, ahora solo ocurre en conversaciones larguísimas, es porque su contexto se llena. Muchas veces, tenemos conversaciones con modelos en las que estamos perfilando ideas, y de 50 mensajes, solo hay valor en 3-4. Para esto existen mecanismos de compactación, que básicamente resumen. Puedes dejar que sea el modelo o cliente agéntico quien lo haga, o hacerlo tú, generando ficheros con la condensación de lo esencial.

Otro motivo para usar ficheros resumen, es que además cada modelo usa un número diferente de tokens para codificar (primera fase) el texto de un prompt, y distintos tokenizadores, luego no es buena idea usar en la misma conversación modelos de familias diferentes, o incluso entre modelos diferentes, por ello cobra muchísimo más sentido usar ficheros, porque si tu modelo qwen 3.5 se quiere entender con `Gemma 4, exporta ficheros de texto, los transforma de sus embeddings (representación numérica de tokens y relaciones ente ellos) internos a texto natural, y el siguiente modelo, lee, tokeniza y genera su propio contexto.

Una buena técnica es, comenzar un proyecto hablando en modo /plan con una IA potente y buena en redacción, los modelos Gemma 4 de Google son brutales para esto, incluso desde su versión e2b, para que "entienda", es decir, "contextualice" lo que queremos hacer.

De nuevo seguimos el mismo patrón que utilizaríamos de forma natural con un agente humano, primero hablamos con él o ella, enviamos modelos, usamos patrones estandarizados, etc... y cuando nos aseguramos en una reunión, o herramienta de gestión de proyectos, que ha comprendido su misión, le decimos que cree la documentación (ficheros para agentes) y ejecute el proceso.

Además otra de las ventajas, es que podremos partir un proyecto en versiones para varios modelos, que podemos ejecutar en paralelo, por ejemplo, una carga de trabajo puede ser más adecuada para modelos locales, otras para comerciales, o puede ser que usemos varios comerciales porque uno redacta mejor, otro tiene buena visión para hacer test, y otro es experto y rápido para documentación.

Agentes como Roles: Especialización sobre Generalización

Siguiendo con el patrón anterior, lo podemos implementar de la siguiente forma, repartiendo las responsabilidades en roles específicos. Cada agente es un especialista con un "manual de instrucciones" derivado directamente de nuestros archivos de planificación. Por ejemplo, para redactar artículos de blog podríamos tener:

  • Agente Coordinador: Encargado de la planificación, coordinación y control del Plan de acción y los agentes.
  • Agente Redactor: Encargado de la creación inicial de contenido técnico.
  • Agente Humanizador: Especializado en ajustar el estilo y fluidez natural.
  • Agente Revisor: El control de calidad final, encargado de verificar coherencia y datos técnicos.

Para cada agente, podríamos definir sus SKILLS.md, competencias, para asegurarnos que realiza todo lo que queremos, de la forma más profesional posible. Imagina poder tener un empleado senior al momento.

Para la creación de este blog, desarrollé unos apuntes generales con todo el laboratorio. Al pasar a pdf los apuntes superaban ampliamente las 500 páginas. Metí configuraciones, descripción técnica detallada, etc... Es mi manual de supervivencia sobre mis semanas profundizando, de forma totalmente autodidacta en este maravilloso mundo.

Usé Gemma 4 12b, para diseñar los ficheros de planificación, y creé los agentes anteriores. Entre ellos y yo, hemos realizado este blog. El agente humano, es decir, yo mismo, me he situado sobre todo después de la acción del redactor, para revisar, y añadir o eliminar contenido, porque SIEMPRE tendrás que revisar a la IA, no pienses que esto es darle al botón y dejarla en piloto automático. Hará el trabajo sucio, pero tu eres el responsable de ese trabajo.

Después me ubico detrás del agente revisor, para ponerle el papel de regalo y el lazo al blog.

Norma de oro, la única fuente de conocimiento, es mi fichero "madre", esa es una regla dura imprescindible para que el modelo ni invente, ni complete, o cambie. Luego, hay quien podrá decir que me redactó este blog la IA. Le diré, usó mi trabajo como base, le pedí que después de leer 500 páginas escritas por mi, aprendiese mi estilo e intentara emularlo, y cada artículo tiene 3 revisiones por mi parte. Ahora acude a un periódico o revista de "antaño maricastaño" y que te expliquen sin el director del periódico revisaba y escribía uno por uno cada uno de sus artículos...

Otro caso de uso

Relativo a lo anterior, se pueden hacer trabajos tan maravillosos como el siguiente. Usé Qwen 3.5 4b, modelo muy pequeño que no debería servir para mucho (eso piensa quien ve de lado este tipo de modelos), y le pregunté, "oye ¿Sabes que es C/AL?, sino lo conoces, responde que no" y me respondió que no. Fue obediente, y con una temperatura de 0.1, lo tenía algo atado... Los modelos pequeños tienen la peculiaridad de no dejar mucho espacio a la creatividad, por eso son muy buenos como "gregarios", los modelos grandes tienen cierto complejo de estrellas...

C/AL es un lenguaje propietario que usa Navision para su famoso ERP. Navision no fue creado por Microsoft, sino por una empresa danesa creo recordar, y hasta su versión 4 ó 5, no podías programarlo con .net. Es decir, es un lenguaje a la altura de Cobol en rareza, es una "lengua muerta" se podría decir, porque Cobol es ampliamente utilizado en la actualidad, pero C/AL ha sido retirado poco a poco.

¿Que hice? Mi modelo puede usar herramientas para leer ficheros, de disco, buscadores de internet, o endpints (urls) directamente, además se las puedes pasar como envías un documento a ChatGPT. Le envié un tutorial de 22 páginas, en este caso en pdf, y en 6,6s ya estaba programando en C/AL. Mi siguiente prompt fue pedirle un árbol de navidad con código C/AL, para la implementación de recursividad. Lo hizo, vaya si lo hizo en tan solo 3,2s.

¿Que conclusión se puede observar?, durante los primeros años, nos ha fascinado la cantidad de conocimiento que tienen los modelos grandes comerciales. Esto implica tener un tamaño gigantesco de conocimiento entrenado en miles de millones de parámetros, y esto requiere una bestial cantidad de recursos. La IA local no se basa en usar modelos de lenguaje como enciclopedias, eso es absurdos, se basa en modelos que sea lo suficientemente inteligentes como para hacer uso de herramientas. Si mi modelo qwen3.5-4bes suficientemente inteligente como para usar una herramienta de buscador, leer un pdf, un ebook, etc... y organizar los conceptos de la fuente de verdad que le proporcione, no necesito que los tenga precargados. Esto es un absurdo que nos están vendiendo, y uno de los motivos por los cuales nos hemos quedado sin chips para los modelos locales.

Conclusión: El eterno debate sobre que es inteligencia y que es memoria. Conocer muchos conceptos ¿te hace inteligente? o ser capaz de comprender está por encima de los conocimientos memorizados?

Orquestación del Flujo: La Coreografía de la IA

La verdadera magia ocurre en la orquestación. No es solo ejecutar tareas; es la coreografía de cómo estos roles colaboran para planificar, ejecutar, revisar y documentar los resultados.

Este flujo puede ser secuencial (un paso tras otro) o paralelo (múltiples agentes trabajando simultáneamente en diferentes partes de un proyecto). La clave es que cada paso alimenta al siguiente mediante la actualización constante de nuestros archivos de planificación, asegurando que el "estado" del proyecto siempre esté actualizado.

Y dime, hasta aquí, ¿sigues creyendo que programar con IA, es cortar y pegar trozos de código en ChatGPT, Gemini, Claude, y "fusilar" lo que te escupa la IA?

Entrada Anterior Siguiente Entrada