Axiom ataca dos dolores masivos y multimillonarios del desarrollo de software
y la integración de sistemas: el coste de tokens que las flotas de
agentes queman releyendo repositorios enteros, 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 al enviar tríadas IR en lugar de esquemas en texto plano
0líneas de código heredado que el cliente tiene que modificar
3 / 3breaking changes detectados y resueltos al vuelo en la prueba en vivo
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 Axiom. 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.
Axiom añade dos capacidades que van más allá del aviso:
comprime el contexto a tríadas lógicas 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 a Representación Intermedia
No mandes el repositorio. Manda la mutación.
Axiom no envía el código ni la documentación. Comprime las mutaciones y las
estructuras de los contratos en tríadas lógicas universales: una línea por
cambio, legible por cualquier agente sin importar el modelo ni el proveedor.
Los símbolos no son arbitrarios: provienen del diccionario del propio protocolo
AxiomV, de modo que una tríada IR es interpretable por el mismo motor simbólico.
⟨ Sujeto · Propiedad · Mutación → Objeto ⟩
Símbolos de mutación y su nombre canónico en AxiomV
Símbolo
Significa
Nombre en el diccionario
¿Rompe al cliente?
≈
la propiedad no cambió
APROX
no
⤳
renombrada o movida de ruta
TRANSFORMA
sí
⊚
pasó de plana a anidada
CAPAS
sí
⊕
propiedad nueva en el destino
COOPERACION
no
⊖
propiedad que desaparece
SEPARACION
sí
↔
cambió el tipo de dato
INTERCAMBIA
sí
⚠
ahora es obligatoria
RIESGO
sí
Antes · los dos esquemas en texto plano
Pulsa «Medir compresión» para que el motor devuelva el contenido real.
Después · tríadas IR
—
Demo A · Compresor IR
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 y documentado, aplicado por igual al antes y
al después. También puedes pegar un changelog en texto libre y ver cómo se comprime.
Esperando la respuesta del motor…
⊚ Solución 2 · Edge Proxy escuchante
El cliente heredado sigue hablando su idioma. Axiom traduce en el camino.
△Cliente legacyPOST con el contrato v1
→
⊚Axiom Edgeintercepta la petición
→
⤳Mapa IRreglas derivadas al vuelo
→
□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.
Mapeo al vuelo. Las reglas se calculan comparando los dos esquemas en el momento de la petición, no se mantienen a mano.
Cero cambios en el legacy. Ni una línea del código heredado se modifica, ni se despliega nada en el lado del cliente.
Camino de vuelta. La respuesta del proveedor se re-traduce al contrato antiguo, incluidos los campos que el cliente no conoce y que se descartan.
Confianza declarada. Cada regla viaja con su puntuación y su evidencia; las dudosas se marcan para revisión en lugar de aplicarse en silencio.
Sin falsos positivos. Si el contrato nuevo exige algo que no puede derivarse, Axiom lo reporta como incompatibilidad en vez de inventar un valor.
△ Arquitectura · tres componentes
Un núcleo agnóstico del entorno, con dos adaptadores: servidor local y Cloud Functions.
⊚
COMPONENTE 01
Parser de Contratos y Generador de Tríadas
Lee JSON Schema, OpenAPI 3.x (resolviendo $ref locales) o changelogs en
texto libre, y los aplana a rutas con tipo, obligatoriedad, formato, unidad y valor
por defecto. De ahí salen las tríadas IR.
Compara las dos versiones y deriva las reglas de traducción sin intervención humana:
tokeniza las rutas, aplica clases de equivalencia semántica y distancia de edición,
pondera tipo y estructura, y emite una confianza con su evidencia.
Intercepta la petición antigua, transforma la carga útil, la reenvía por HTTP real al
proveedor y re-traduce la respuesta al contrato heredado. Devuelve cabeceras de
evidencia y nunca fabrica un éxito: propaga el error 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 Axiom 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 Axiom · el cliente legacy contra la API v2
Sin ejecutar todavía.
✓ Con Axiom · 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 Axiom
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
Axiom se apoya en AxiomV, el protocolo simbólico de EngineV: el mismo diccionario
de formas lógicas que ya traduce lenguaje natural entre inteligencias, aplicado ahora a
los contratos entre sistemas.