⟨ ∞ ⟩ AxiomIR ⊚ Abrir EngineV
⟨ Inteligencia Artificial · APIs ⟩

La capa lógica entre sistemas que cambian

AxiomIR resuelve dos problemas críticos del desarrollo moderno: el coste de tokens que las flotas de agentes queman releyendo código repetidamente, y las rupturas por cambios de API que tiran las aplicaciones de los clientes cada vez que un proveedor actualiza su esquema.

>70 % menos consumo de tokens en flotas de agentes
0 líneas de código heredado que el cliente tiene que modificar
3 / 3 breaking changes detectados y resueltos al vuelo

⌖ El problema: las APIs no se auto-mantienen

Una fricción que tenía sentido antes de los agentes de código. Ya no.

La comunicación de las APIs es deficiente de forma sistemática: los cambios incompatibles se publican con poca antelación, las funcionalidades útiles se lanzan discretamente y pasan desapercibidas, y los registros de cambios simplemente no se leen. Mientras tanto, la infraestructura para automatizar cambios de código ya existe y está normalizada: los equipos aceptan que herramientas externas accedan a su código fuente cuando aportan valor real.

+50

proveedores de API observados de cerca, en su mayoría startups en fase inicial: el mismo patrón de comunicación deficiente se repite.

>30 %

del tiempo de inactividad de un servicio a gran escala se originaba en cambios externos de API o de paquetes que pasaban desapercibidos.

≈ 0

changelogs efectivamente leídos. El anuncio existe, pero nadie lo consume ni lo aplica a tiempo.

Los proveedores de API no deberían solo anunciar los cambios: deberían aplicarlos.

Diagnóstico de industria descrito por Harsha Gaddipati en su ensayo sobre APIs auto-mantenibles. Aquí se parafrasea y se cita como contexto del problema, no como respaldo de este proyecto.

Dónde entra AxiomIR. El enfoque tipo «Dependabot para APIs» abre una pull request y confía en que alguien la revise, la pruebe y la despliegue. Es un gran paso, pero sigue dependiendo de un humano en el camino crítico. AxiomIR añade dos capacidades que van más allá del aviso: comprime el contexto para que los agentes no tengan que releer el repositorio entero, y mantiene la aplicación en pie traduciendo las peticiones al vuelo aunque nadie llegue a tocar el código heredado.

⚠ Dos dolores multimillonarios

Distintos en apariencia, idénticos en su raíz: nadie tiene una representación compartida del cambio.

DOLOR 01

Quema de tokens en flotas de agentes

Síntoma
Cada cambio de código obliga a los agentes a releer repositorios completos y documentación masiva en texto plano, aunque la mutación real sean tres campos.
Costo
El consumo computacional escala con el tamaño del proyecto, no con el tamaño del cambio. Cada commit multiplica la factura de inferencia.
Consecuencia
Coste insostenible al crecer, latencia creciente y ventanas de contexto saturadas de información irrelevante que degrada la precisión del propio agente.
DOLOR 02

Rupturas por cambios de API

Síntoma
Un proveedor externo actualiza su esquema: renombra campos, los anida, añade obligatorios. Las integraciones de sus clientes empiezan a devolver errores.
Costo
Incidentes en producción, migraciones forzadas y equipos enteros parados reescribiendo código heredado que funcionaba perfectamente ayer.
Consecuencia
Tiempo de inactividad, pérdida de confianza en el proveedor y una deuda técnica que se renueva con cada versión mayor del contrato.

⤳ Solución 1 · Compresión inteligente

No mandes el repositorio. Manda solo lo que cambió.

AxiomIR no envía el código ni la documentación completa. Extrae las mutaciones reales y las comprime en una representación compacta que cualquier agente puede consumir sin releer el proyecto entero. El resultado: menos tokens, más precisión.

Antes · esquemas completos

Pulsa «Medir compresión» para ver el contenido real.

Después · solo las mutaciones

Demo A · Compresor

Medición real · calculada en el servidor

La reducción no es una afirmación de marketing: se mide sobre las cadenas reales con un tokenizador determinista. También puedes pegar un changelog en texto libre y ver cómo se comprime.

Esperando la respuesta del motor…

⊚ Solución 2 · Proxy de compatibilidad

El cliente heredado sigue hablando su idioma. AxiomIR traduce en el camino.

Cliente legacyPOST con el contrato v1
AxiomIRintercepta y traduce
API v2recibe su contrato válido
Vueltarespuesta re-traducida a v1

△ Cómo funciona

Tres capacidades en un núcleo portátil que corre en cualquier entorno.

CAPACIDAD 01

Lectura de contratos

Acepta JSON Schema, OpenAPI o changelogs en texto libre y los normaliza a una estructura interna común, lista para comparar.

CAPACIDAD 02

Detección de cambios

Compara las dos versiones y deriva las reglas de traducción automáticamente: identifica renombres, cambios de tipo y nuevas restricciones, con un score de confianza para cada una.

CAPACIDAD 03

Proxy de traducción

Intercepta la petición antigua, la traduce al nuevo contrato, la reenvía por HTTP real al proveedor y re-traduce la respuesta. Nunca fabrica un éxito: propaga el error real del proveedor.

▷ LIVE PROOF · el rescate, con peticiones HTTP reales

Real HTTP request · Simulated external provider

Qué es real y qué no. El proveedor externo es un mock: no es Stripe ni AWS. Pero el servidor, el validador de esquema, los códigos de estado, la transformación y el salto de red son reales. No simulamos el proxy: simulamos el proveedor externo para demostrar que el proxy traduce contratos incompatibles. Abre DevTools → Network y verás cada petición con su cuerpo y sus cabeceras. Además, js/landing.js no contiene ni una línea de lógica de mapeo: toda la transformación vive en el servidor, así que aquí no hay dónde falsear un 200 OK.

… comprobando si el motor AxiomIR responde

Contrato v1 · lo que envía el cliente heredado

Contrato v2 · lo que exige el proveedor

Payload que envía realmente el cliente legacy

⊘ Sin AxiomIR · el cliente legacy contra la API v2

Sin ejecutar todavía.

✓ Con AxiomIR · el mismo cliente, rescatado

Sin ejecutar todavía.

Traza real devuelta por el servidor

Cada paso lo compone el Edge Proxy con los datos que realmente circularon, incluido el código de estado y la latencia del salto al proveedor.

□ Dónde encaja AxiomIR

Cuanto más grande el sistema y más rápido cambia, mayor es el ahorro.

Flotas de agentes y agentes de IDE

En lugar de reinyectar el repositorio en cada iteración, el agente consume solo el delta en tríadas. Menos tokens, menos ruido y más precisión en la ventana de contexto.

Plataformas con API pública

Puedes evolucionar tu esquema sin romper a los clientes que aún no migran. El proxy sostiene las versiones antiguas mientras la migración avanza a su ritmo.

Integradores y sistemas heredados

ERPs, pasarelas y software a medida que nadie quiere tocar siguen funcionando aunque el proveedor externo publique una versión mayor incompatible.

Monorepos grandes

El coste de entender un cambio deja de depender del tamaño del repositorio y pasa a depender del tamaño real de la mutación.

Migraciones por fases

Convivencia de contratos v1 y v2 durante el tiempo que haga falta, con telemetría de qué reglas se aplican y cuáles necesitan revisión humana.

Prevención de incidentes

Detección temprana de rupturas comparando esquemas o changelogs, antes de que un cambio silencioso llegue a producción.

Un idioma común para el cambio

AxiomIR forma parte de EngineV, un ecosistema que aborda la comunicación entre sistemas e inteligencias desde una perspectiva simbólica. La misma filosofía, aplicada ahora a los contratos entre APIs.