Un blog de Joaquín del Cerro sobre sistemas, , con aplicaciones en IA y GIS.
Hola, llevo meses escribiendo sobre arquitecturas de agentes. Sobre cómo un agente debería percibir su entorno, gestionar sus sensores, priorizar eventos, y recordar no como una lista de hechos sino como una historia con intencionalidad y trazabilidad. Ha sido un viaje conceptual en su mayor parte honesto: cada artículo describía ideas que estaba explorando, no sistemas que ya funcionaban.
Hola, en el artículo anterior, “Control proactivo de la percepción en agentes de IA”, vimos que teniamos la necesidad de filtrar y procesar los eventos del exterior. Pero proteger al LLM de la sobrecarga no basta si el entorno envía información más rápido de lo que el LLM puede procesar. Necesitamos procesar la entrada de información, a gestionar “turnos”, y decidir cuándo un evento merece interrumpir el dialogo con el LLM.
Hace unos meses publiqué un artículo, “Agentes de IA y la inyección de observaciones proactivas en clientes de chat”, donde presentaba el patrón pool_event(), una forma de romper el ciclo reactivo de los LLMs permitiendo que el entorno “hable primero”. Con esa arquitectura conseguimos que un agente pudiera recibir observaciones proactivas: mensajes de Telegram, alertas del sistema, correos electrónicos, todos ellos capaces de colarse en la conversación sin esperar a que el usuario preguntara. La idea funcionaba, y parecia hacerlo bien. El agente dejaba de ser un mero ejecutor de órdenes para convertirse en un sistema con capacidad de respuesta automática ante estímulos.
La semana pasada publiqué el artículo “¿Memoria narrativa o resumen para un LLM?”. Contaba mi progresiva desilusión con los resúmenes como mecanismo para mantener conversaciones largas con un asistente de IA. Cómo, a fuerza de usarlos, empecé a notar que se perdía la intencionalidad de las decisiones, la cronología lógica de los razonamientos y los matices desaparecian en una simple lista de hechos. Contaba también que caí en la cuenta de que el problema no era cómo resumía, sino el hecho de resumir. Los LLMs, criaturas entrenadas con ingentes cantidades de prosa, narrativa y texto fluido, entienden mucho mejor cuando les das un texto con una narrativa fluida, cuando les cuentas una “historia”.
Durante los últimos meses he mantenido una conversación continua con el mismo asistente de IA. No era un chat esporádico, de esos que se abren para una consulta rápida y se cierran para siempre. Era mi compañero de reflexiones. Un colaborador con el que discutía arquitectura de software, diseños de agentes, y a veces, fundamentos filosóficos de la inteligencia artificial.
A menudo, cuando intentamos explicar cómo funciona un LLM, caemos en abstracciones sobre “redes neuronales” que suenan demasiado biológicas, o en simplificaciones excesivas sobre “la siguiente palabra más probable”. Ambas son ciertas, pero ninguna explica qué está pasando ahí dentro cuando la máquina parece entender un doble sentido.
No intente ajustar su televisor. Nosotros controlamos la transmisión. Nosotros controlamos lo horizontal y lo vertical. Durante la próxima lectura, siéntese tranquilamente y nosotros controlaremos todo lo que usted vea y oiga. Usted está a punto de conocer… el límite exterior.
El tercer caso y con el que acabo esta serie de “Cuando la IA genera codigo”, me ocurrió hace apenas unas semanas, trabajando en mi prototipo de agente con una gestión de memoria un tanto especial. Esta vez, el origen del problema fue un error de diseño mío. En un intento de optimizar, decidí reutilizar el mismo artefacto que gestionaba la “base de conocimientos” (el historial consolidado) para gestionar también el “historial vivo” de la conversación en curso. Sobre el papel parecía que podría funcionar. En la práctica, fue una muy mala idea. Las responsabilidades se mezclaban y la lógica de gestión de la ventana de contexto se volvía inmanejable.
En las dos primeras partes de esta serie (donde analizamos por qué la IA no programa y vimos las pruebas realizadas), nos centramos en el diagnóstico. Ahora voy a pasar a comentar sobre un fallo real en un entorno web.
En En el artículo anterior denuncié la sobreventa de las capacidades de programación de la IA. Dije que los modelos generan texto que parece código, pero no programan. Este documento es el registro de las pruebas que hice.
Hace unas semanas, tras ver el enésimo video de un “experto” afirmando que “Gemini 3 Pro revoluciona la automatización” y que “los agentes de IA ya construyen aplicaciones completas”, sentí una mezcla de incredulidad y rabia. Rabia por ver cómo la falta de experiencia en proyectos reales se disfraza de autoridad para envenenar el criterio de quienes están empezando.
Era una de esas sesiones de afinamiento que empiezan con la confianza del que cree dominar la herramienta. Estaba frente a Gemini, ajustando un protocolo, y me encontré ante una tarea aparentemente sencilla: evitar que el asistente hiciera algo mecánico y poco útil.
Por qué los Transformers prefieren el orden al caos sin que nadie se lo pida… spoiler, sí se lo han pedido.
Nota: Este artículo lo escribí originalmente en septiembre de 2025, poco antes de la consolidación de arquitecturas como GraphRAG. Quedó guardado en un “cajón digital”, pero al revisarlo hoy, me sorprendió ver cuánto de su diagnóstico arquitectónico sigue vigente. He decidido publicarlo manteniendo intacto el texto original para preservar el contexto del análisis, añadiendo solo una breve nota al final sobre cómo ha evolucionado el ecosistema RAG en estos últimos meses.
Esto me pasó hace unos dias, a pesar de lo curioso que pueda parecer. Una sesión de depuración se convirtió en un ejercicio de robopsicología a lo Asimov, y solo porque un modelo cometió un “error filosófico” y el otro decidió seguirme el juego hasta el final.
Hola, En arquitectura de sistemas hay una “ley no escrita” pero inmutable: nadie da nada gratis. Si optimizas agresivamente para una variable, estás pagando el precio en otra. Y en el mundo de la IA generativa, acabamos de toparnos con el ejemplo más brutal de este principio.
Llevo meses trabajando con gemini-cli como un compañero de arquitectura. Un interlocutor técnico que lee, analiza, cuestiona y, sobre todo, espera. Hasta que, sin que yo modificara mi contexto, su patrón de interacción cambió radicalmente y comenzó a comportarse como un becario con tres cafés de más.
Hola, llevo un tiempo dándole vueltas a una pregunta: ¿cómo diseñamos agentes que no solo respondan a preguntas, sino que sean capaces de reaccionar a cambios en su entorno?
¿Alguna vez os habéis preguntado por qué nos cuesta tanto documentar o “empaquetar” un proyecto antiguo, incluso cuando sabemos que es necesario?
Hola a todos. Últimamente, las redes sociales y las plataformas de prompts se han llenado de una especie de mercado mágico. Un sitio como Promptfy promete cientos de “recetas listas para usar” que, con solo copiar y pegar, resuelven problemas complejos de IA. Y no hablemos de LinkedIn o X, donde un post con un “prompt infalible” para generar código Python acumula likes como si fuera “el santo grial”. Entiendo el atractivo.En un mundo donde se valora cada vez mas el producir mas en menos tiempo ¿quién no querría un atajo directo a la productividad?
Como desarrollador de software, gran parte de mi trabajo consiste en construir sistemas que interpreten y ejecuten instrucciones. Esto me ha llevado, de forma natural, a preguntarme por la naturaleza del lenguaje que usamos para dar esas instrucciones. La pregunta parecía simple, casi una obviedad: ¿es el lenguaje un simple reflejo de nuestro pensamiento, o es la herramienta con la que lo construimos? Comenzó como una curiosidad personal y se convirtió rápidamente en una reflexion que desmanteló algunas de mis suposiciones más básicas sobre cómo estructuramos la realidad.
Hola a todos. En los últimos años, hemos asistido a un avance espectacular en el campo de la Inteligencia Artificial, impulsado principalmente por los Modelos de Lenguaje Grandes (LLMs). Su capacidad para generar texto coherente, traducir idiomas y mantener conversaciones fluidas es, sin duda, impresionante. Es una proeza de la ingeniería y la estadística a gran escala.
Hola, llevo un tiempo dándole vueltas a cómo escribir sobre esto, verás… Hace un tiempo incursioné en esto de los chats de IA (puedes leer sobre eso en estos artículos). La cuestión es que hice mis pinitos y acabé haciendo un ¿chatbot? dentro de gvSIG desktop tirando del API de Gemini. Bueno, para mí era un simple chatbot. Lo arrancabas como una herramienta más dentro de la aplicación y tenía el aspecto característico de una aplicación de chat de IA. La cosa es que, aunque inicialmente fue simplemente hacia eso, un chat, decidí que lo chulo era darle acceso a algunas funcionalidades de la aplicación. Le di acceso a explotar los datos tabulares de la aplicación, que pudiese saber qué área se veía en la Vista, poder generar gráficos a partir de los datos que tenían las capas y tablas cargadas, y tal vez alguna cosilla más. Para mí era un “simple chatbot” dentro de la aplicación.
En mi serie de artículos sobre la creación de un asistente para gvSIG Desktop, explore el viaje desde el prototipo hasta una solución distribuible. Hoy quiero hacer un acercamiento en un aspecto que resultó ser crucial: el arte, o ciencia, de describir las herramientas para que un LLM pueda usarlas de forma eficaz.
Hola a todos, Si habéis estado siguiendo esta serie de artículos, ya conocéis el qué y el porqué. El viaje desde un chat simple en gvSIG desktop hasta un asistente contextual inteligente gracias al protocolo MCP. Pero hoy quiero hablaros del cómo. Y no me refiero a las librerías o el código, sino a algo más fundamental, la forma en que trabajé para hacerlo realidad.
Hola a todos, Últimamente, veo una y otra vez el término “similitud semántica” asociado a la tecnología RAG. Lo encontramos en frases como:
En el artículo anterior, lo dejé justo en el momento de la revelación: la conexión inesperada entre una herramienta de línea de comandos, gemini-cli, y un protocolo llamado MCP era l respuesta al problema de distribución que casi acaba con el proyecto. Hoy, no vamos a revivir esa búsqueda, sino a remangarnos para construir la solución. Os mostraré en detalle qué son estas piezas y cómo, apoyándome en todo el trabajo previo, encajaron para dar vida a una solución robusta y, por fin, distribuible.
En los artículos anteriores de esta serie, conté cómo construimos un asistente de IA para gvSIG desktop, pasando de un simple chat a un potente conjunto de herramientas contextuales. Teníamos un prototipo que funcionaba y que era genuinamente útil. Pero, como os adelanté, me enfrentaba a un problema que no era de código, sino del mundo real ¿cómo podía compartirlo sin que nadie se arruinara?
En el artículo anterior, os conté cómo un prototipo de unos pocos dias nos permitió chatear con una IA desde gvSIG. La prueba de concepto funcionaba, pero como os adelanté, me enfrentaba a un muro: los costes de la API. Antes de poder solucionar el problema del coste, necesitaba que la herramienta fuera tan útil, tan indispensable, que mereciera la pena luchar por ella.
¿Alguna vez has querido preguntarle a tu aplicación qué datos tiene o qué puede hacer con ellos, usando tus propias palabras? Esa fue la pregunta que me hice a principios de este año cuando empecé a ver que los modelos de lenguaje (LLMs, Large Language Models o Modelos de Lenguaje Grande) podían hacer cosas increíbles… pero siempre desde un navegador web, lejos de la aplicación de escritorio.