cq: el «Stack Overflow para agentes IA» que quiere acabar con el conocimiento repetido

Hay un problema que, si piensas un segundo en él, es bastante obvio pero que casi nadie ha resuelto todavía: los agentes de IA resuelven los mismos problemas una y otra vez, sin aprender los unos de los otros. Como si cada desarrollador tuviese que reinventar la rueda desde cero cada vez que empieza un proyecto nuevo, sin poder consultar ni Stack Overflow, ni Google, ni nada. Solo sus propios recuerdos.

Eso es, básicamente, lo que le pasa hoy a los agentes de inteligencia artificial cuando trabajan con código. Y un desarrollador de Mozilla llamado Peter Wilson ha decidido hacer algo al respecto.

El problema real: agentes con amnesia colectiva

Los agentes de IA que escriben código tienen 2 limitaciones estructurales que conviven con ellos desde el principio.

La primera es la fecha de corte de entrenamiento. Un modelo no sabe lo que pasó después de que se entrenó, y eso en programación es un problema serio. Las APIs cambian, las librerías se deprecan, los frameworks evolucionan. Un agente que intenta hacer una llamada a una API que ya no existe no está siendo torpe: simplemente no tiene forma de saber que eso ha cambiado. Técnicas como el RAG (Retrieval Augmented Generation) ayudan a mitigar esto, pero no siempre se aplican cuando se necesitan, y cuando se aplican, no son exhaustivas. El agente no sabe lo que no sabe, y eso es exactamente el tipo de error más difícil de anticipar.

La segunda limitación es la falta de memoria compartida entre agentes. Si un agente descubre hoy que Stripe devuelve un código 200 con un cuerpo de error cuando se superan los límites de peticiones (algo contraintuitivo, por cierto), esa información muere ahí. Ningún otro agente se va a beneficiar de esa experiencia. El siguiente que trabaje con la API de Stripe tendrá que descubrirlo por sí solo, gastando tokens, tiempo y energía para llegar exactamente a la misma conclusión.

Multiplicado por cientos o miles de agentes haciendo lo mismo, estamos hablando de un desperdicio enorme, tanto económico como energético.

Qué es cq y cómo funciona

Wilson lo define como un «Stack Overflow para agentes» y, honestamente, es una buena analogía. La idea es que antes de que un agente afronte una tarea nueva —una integración con una API, una configuración de CI/CD, un framework que no ha tocado antes— consulte un repositorio de conocimiento compartido llamado cq commons.

Si otro agente ya aprendió algo relevante en el pasado, tu agente lo sabe antes de escribir una sola línea de código. Y cuando tu agente descubre algo nuevo, lo propone de vuelta al sistema. Otros agentes confirman si funciona o señalan si ya ha quedado obsoleto. El conocimiento gana credibilidad a través del uso, no por decreto.

Es un giro interesante respecto a la solución actual, que consiste en añadir instrucciones manuales en archivos .md tipo claude.md o agents.md. Básicamente, los desarrolladores van apuntando a mano lo que han aprendido por ensayo y error: «este agente siempre intenta llamar a esta función que ya no existe, así que le digo explícitamente que no lo haga». Funciona, pero no escala, y depende completamente de que un humano identifique el problema y lo documente.

cq intenta automatizar y colectivizar ese proceso.

Qué hay disponible ahora mismo

Wilson es claro en que esto es un proof of concept, pero ya tiene piezas funcionales:

• Un plugin para Claude Code y OpenCode
• Un servidor MCP para gestionar una librería de conocimiento almacenada localmente
• Una API para que los equipos compartan conocimiento
• Una interfaz de usuario para revisión humana del contenido generado

El código está disponible en GitHub con documentación para quienes quieran probarlo o contribuir.

Las dudas razonables que levanta

En Hacker News, donde Wilson publicó el proyecto para recoger feedback, las reacciones fueron bastante representativas de lo que pasa cuando anuncias algo técnico a una audiencia técnica: acuerdo general con la idea de fondo, y una lista nada corta de problemas por resolver.

El primero es de confiabilidad: los modelos no siempre describen con precisión los pasos que han seguido para llegar a una conclusión. Si el conocimiento que se comparte parte de una introspección imprecisa del propio agente, el sistema puede acumular información incorrecta o directamente inútil a escala. Junk in, junk out, pero multiplicado.

El segundo es de seguridad. Un repositorio de conocimiento compartido entre agentes es también un vector de ataque. Las amenazas de prompt injection —donde un input malicioso manipula el comportamiento de un agente— y el data poisoning —donde se introduce información falsa o manipulada en el sistema— son preocupaciones legítimas y no menores. Si un actor malicioso consigue que el sistema aprenda que cierta función «segura» tiene un comportamiento concreto cuando en realidad no lo tiene, el daño puede propagarse a todos los agentes que consulten ese conocimiento.

Y luego está la cuestión de la precisión. Saber cuándo una pieza de conocimiento ha quedado obsoleta no es trivial. Las APIs cambian sin avisar, los frameworks publican versiones con breaking changes, y lo que era cierto hace 3 meses puede no serlo hoy. El sistema necesita un mecanismo fiable para detectar y retirar conocimiento caducado antes de que cause problemas.

Yo, la verdad, creo que la idea tiene mucho potencial real. Pero el camino entre «esto funciona en un entorno controlado» y «esto funciona en producción con agentes de distintos equipos, distintos modelos y distintas motivaciones» es bastante más largo de lo que parece en el post de anuncio.

No es el único proyecto en este espacio

Conviene decirlo: cq no es la única propuesta para resolver este tipo de problemas. Hay varios proyectos en distintos niveles del stack que intentan dar a los agentes acceso a información más actualizada o verificada, y que buscan reducir el gasto de tokens en razonamiento redundante. La competencia en este espacio es real, y eso es buena señal: significa que el problema que cq quiere resolver es lo suficientemente importante como para que varias personas estén pensando en él en paralelo.

Lo que diferencia a cq, al menos en su propuesta inicial, es el enfoque en el conocimiento emergente y colectivo: no se trata solo de dar acceso a documentación oficial actualizada, sino de capturar lo que los agentes aprenden en la práctica, incluyendo los comportamientos no documentados, los edge cases y las peculiaridades reales de las APIs en producción. Eso es algo que ninguna documentación oficial va a cubrir nunca del todo.

Si logran resolver los problemas de seguridad y precisión de forma convincente, esto podría cambiar bastante cómo funcionan los sistemas multiagente. Si no, acabará siendo otra buena idea que se quedó a medias. Por ahora, merece la pena seguirlo de cerca.