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
0líneas de código heredado que el cliente tiene que modificar
3 / 3breaking changes detectados y resueltos al vuelo
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.
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
Intercepción transparente. El cliente sigue apuntando a la misma URL y enviando el mismo JSON de siempre.
Traducción automática. Las reglas se calculan comparando los dos esquemas, sin configuración manual.
Cero cambios en el legacy. Ni una línea del código heredado se modifica.
Camino de vuelta. La respuesta del proveedor se re-traduce al contrato antiguo.
Sin falsos positivos. Si el contrato nuevo exige algo que no puede derivarse, AxiomIR lo reporta como incompatibilidad.
△ 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.