El cerebro de tu agente debería ser un paquete de npm

Cualquier output de un agente de IA se puede corregir, pero lo difícil es demostrar meses después con qué conocimiento exacto lo generó. Esa pregunta además suele llegar en el peor momento: cuando un cliente detecta un error en un texto publicado con su marca y quiere saber qué falló. Si nadie puede responderla con pruebas, la conversación pasa de corregir el problema a discutir de quién fue la culpa. Por eso creo que cualquier empresa que deje escribir a un agente en su nombre va a necesitar esa prueba tarde o temprano. Versionar el conocimiento del agente me parece claramente una inversión por todo lo que aporta, que se resume sobre todo en control.

El control de versiones para agentes de IA resuelve ese problema: convierte el conocimiento de un agente (sus instrucciones, su criterio, lo que sabe hacer y lo que no) en algo que se puede fijar, auditar y revertir igual que cualquier dependencia de producción. Llevamos meses aplicándolo con los employents, nuestros agentes de IA con rol de empleado, empezando por el que trabaja en marketing. En su caso, esa disciplina pasa por publicar todo lo que sabe como un paquete de npm.

Control de versiones para agentes de IA: poder demostrar qué hizo tu agente y por qué

Durante un tiempo guardamos el conocimiento de nuestro primer employent como una copia dentro del propio repositorio del proyecto. Un archivo de control anotaba de qué versión procedía esa copia, pero nadie comprobaba que esa anotación siguiera siendo cierta. Una anotación que nadie verifica funciona como una etiqueta decorativa, porque con ella no se puede demostrar qué instrucciones seguía el agente el día que algo salió mal. Sin esa prueba, cada error puede acabar en una discusión sobre responsabilidades cuando debería ser una corrección rápida.

Esa prueba pesa más a medida que el agente asume tareas con más exposición. Un borrador interno se corrige en poco tiempo, mientras que un texto publicado con tu marca sigue ahí hasta que alguien lo detecta. Cuanto más visible es el trabajo del agente, más caro resulta no poder explicar de dónde salió un error.

Por eso el equipo decidió publicar ese conocimiento como un paquete de npm fijado por un hash sha512, una especie de huella que identifica cada versión. Si lo que se descarga no coincide con esa huella, npm ci falla y el cambio no llega a ningún entorno. Además, cada actualización pasa por una pull request que revisa una persona y que no se fusiona si las evaluaciones automáticas fallan, así que queda un rastro de quién aprobó cada cambio y por qué.

Nada de esto es nuevo en desarrollo de software. Detrás de la decisión está el principio DRY (Don’t Repeat Yourself), que en ingeniería pide no volver a resolver lo que ya está resuelto. Llevamos demasiado tiempo madurando procesos de ingeniería como para no aprovecharlos ahora, así que en lugar de inventar un sistema propio para gobernar al agente decidimos aplicar esa disciplina a su conocimiento, que hasta entonces se movía sin ninguna verificación. Para quien decide si un agente puede escribir en nombre de una empresa, este cambio convierte una cuestión de confianza en una comprobación.

Cuando un cliente pregunta cómo se audita un agente que escribe en su nombre, la respuesta es una versión concreta del conocimiento, con la pull request que la aprobó y la huella que la fija. Ese control tiene un coste, porque cada cambio espera una revisión y unas evaluaciones antes de llegar a producción. A cambio, cuando algo falla, el equipo sabe qué versión revertir y qué diferencias revisar.

Capacidades nuevas sin escribir código: el coste marginal que tiende a cero

Hasta hace poco, las capacidades de un agente vivían escritas a mano en el código que lo ejecuta. Para añadir un formato de contenido nuevo, alguien del equipo tenía que programarlo, probarlo y desplegarlo, de modo que cada formato pasaba por desarrollo aunque su contenido ya estuviera definido. Ese acoplamiento convertía cada idea de marketing en una tarea de ingeniería.

Cambiamos esa lógica para que el código descubriera las capacidades a partir de lo que ya estaba publicado en el paquete de conocimiento del agente. Desde entonces, lo que el agente puede hacer depende de lo que contiene ese paquete. El equipo diseñó 5 formatos de contenido como skills dentro del paquete y el agente pudo usarlos sin que nadie escribiera una línea de código para conectarlos:

• Posts de LinkedIn
• Newsletter
• Descripciones de vídeos de YouTube
• Revisión de artículos del blog
• Traducción de artículos del blog

El primer paquete costó trabajo: migrar el conocimiento, verificarlo, publicarlo y fijarlo por su huella. Los formatos siguientes exigieron diseñarlos y revisarlos, pero ninguna línea de código, así que la cifra que conviene medir es el coste de cada capacidad siguiente. Cuando ese coste marginal tiende a cero porque las piezas básicas ya existen, la conversación con negocio también cambia. La única pregunta que queda es si merece la pena revisar la capacidad antes de activarla.

Para quien planifica, el orden de prioridades cambia: primero se decide qué debería saber el agente y después se revisa qué puede hacer con ese conocimiento. Cada formato nuevo pasa igualmente por la misma pull request revisada y por las mismas evaluaciones automáticas. El agente puede proponer un formato, pero la responsabilidad sobre lo que se publica sigue siendo de una persona.

Este mecanismo rinde distinto según la etapa en la que esté el agente. Con pocas skills publicadas, descubrirlas desde el paquete aporta poco y la mayoría del valor sigue llegando de programarlas a mano. Por eso no lo recomendaría como primer paso a un equipo que empieza con su primer agente. El ahorro aparece después, cuando el paquete ya acumula skills que se pueden reutilizar entre formatos gracias al mismo principio DRY que aplicamos al resto del software.

Cada regla en el lugar equivocado tiene un coste medible

La separación entre el conocimiento del agente y el código que lo ejecuta es frágil y suele romperse cuando hay prisa. Basta con que alguien añada al código una regla que corresponde al conocimiento, porque en ese momento parece la vía más rápida. Con cada una de esas reglas, el código acaba decidiendo algo que ya estaba escrito en otro sitio. Nadie se da cuenta hasta que las dos instrucciones chocan.

Para evitar que el código acumule esas reglas, documentamos un límite con una prueba de una sola frase: si quien escribió el conocimiento podría haber escrito también esa línea de código, la línea sobra y hay que borrarla. Aun así, incluso nuestro equipo cruzó esa línea 4 veces, cada vez por una razón puntual que en el momento parecía razonable. Por eso la regla está escrita: sin ella, esos 4 casos habrían pasado como decisiones aisladas.

El caso más grave lo explica bien. La skill que redacta los artículos del blog pide entre 3 y 5 enlaces externos por artículo, pero el código que rodea al agente tenía una regla propia que le prohibía incluir cualquier URL. El agente recibía así dos instrucciones incompatibles y siempre ganaba la del código: en 12 artículos de prueba no apareció ni un solo enlace, con 5 modelos distintos de 2 proveedores. Cuando quitamos esa regla del código, los artículos siguientes incluyeron 1, 5 y 8 enlaces reales.

Cuando 5 modelos de 2 proveedores fallan exactamente igual, el error está en algo que escribimos nosotros.

FELIPE POLO
CEO Orbitant

Que modelos tan distintos fallaran exactamente igual señalaba a nuestro propio código como origen del error. Para negocio, la lección es que una regla mal ubicada puede parecer un fallo del modelo y empujar a cambiar de proveedor sin resolver nada. Antes de culpar al modelo, conviene revisar qué le impide el código que hemos escrito alrededor.

El propio documento que fija este límite deja escritas 2 excepciones, con su motivo. Los key points todavía no tienen una skill detrás, así que ahí el código hace temporalmente ese trabajo hasta que exista esa skill. Las descripciones, además, se recortan a su primer párrafo porque la versión completa hizo fallar un caso de prueba que antes acertaba siempre: pasó de 5 aciertos de 5 a 0. Son reglas prácticas que se pueden revisar cuando cambie la situación.

Una dependencia que cabe en un archivo es una decisión reversible

Cada vez que elegimos una pieza de tecnología, también elegimos cuánto nos costará abandonarla. Con los frameworks de agentes de IA esa pregunta pesa más de lo habitual, porque el mercado cambia muy rápido y la opción segura de hoy puede quedarse atrás en un año. En una entrega anterior contamos por qué diseñamos el stack de nuestros employents para no depender de un único proveedor. Separar el conocimiento del código es la pieza que más ha reforzado esa decisión, porque hoy nuestra dependencia del framework se reduce a un solo archivo del proyecto y cambiarlo sería un trabajo acotado a ese archivo.

Una decisión así solo es reversible si se puede comprobar que el cambio no rompe nada. Cuando trasladamos el conocimiento del agente al paquete, el riesgo era que algo cambiara por el camino sin que nadie lo notara. Por eso medimos la migración antes de darla por buena y el paquete publicado resultó idéntico byte a byte a la versión anterior. Para quien tiene que aprobar un cambio de este tipo, esa comprobación convierte una apuesta en un trámite verificable.

La misma lógica sirve para elegir a quién contratar. Si tuviera que evaluar a un proveedor de agentes de IA, antes de hablar del modelo le pediría que demostrara tres cosas concretas:

1. Quién aprobó cada cambio en lo que sabe el agente y cuándo lo hizo.
2. Qué ocurre cuando un cambio empeora los resultados y qué pruebas lo frenan antes de llegar a producción.
3. Cuánto de su sistema depende de un framework concreto y cuánto costaría cambiarlo.

Este nivel de rigor cuesta y solo compensa a partir de cierta etapa. Creo que si tu agente todavía no sale de un entorno interno y nadie más depende de sus resultados, probablemente te sobra la mitad de este trabajo. En cambio, la inversión en verificar se amortiza en cuanto un error llega a un cliente.

Hay más equipos trabajando en cómo empaquetar y distribuir lo que usa un agente: Anthropic, por ejemplo, documentó su propio estándar para conectar sistemas de IA con herramientas y datos. El control de versiones para agentes de IA aplica al conocimiento del agente lo que la industria lleva años haciendo con cualquier otra dependencia de software. A medida que más empresas dejen que un agente hable en su nombre, creo que esa disciplina acabará formando parte de los requisitos de compra.

Mi recomendación se resume en una sola pregunta. La próxima vez que alguien te proponga un proveedor de agentes de IA, antes de mirar el modelo que usa, pregúntale si puede decirte dentro de 6 meses con qué versión exacta de conocimiento trabajaba el día en que un output salió mal.