Armature convierte las sesiones MCP en análisis y evaluaciones por etapas

Why it matters

As customers delegate software tasks to AI agents, vendors lose visibility into intent and outcomes. Armature is linking production traces to regression tests before incumbents absorb the category.

Theodore Otzenberger (@Totzenberger) and Louis Scremin launched Armature on July 22 to show software makers what happens when customers use their products through Claude, ChatGPT and other AI clients. Armature reconstructs sessions from Model Context Protocol servers, groups them by user intent and ranks the failures that break the most workflows.

Los fundadores llegaron al problema desde lados opuestos de la misma brecha de producción. Otzenberger trabajó en Palantir y más tarde construyó infraestructura de observabilidad en Tsuga. Scremin dirigió la automatización de IA en Joko, donde ayudó a poner agentes y servidores MCP delante de un producto de consumo con 6 millones de usuarios, según el perfil de Armature en Y Combinator. YC lista a Armature como una empresa de tres personas de Spring 2026.

Su tesis fundacional se basa en un problema operativo que Scremin encontró en Joko: un servidor MCP que funciona correctamente en pruebas internas aún puede fallar ante millones de solicitudes impredecibles. Otzenberger aportó la experiencia en trazabilidad necesaria para convertir esas interacciones en algo que un equipo de producto o de ingeniería pueda inspeccionar.

Otzenberger enmarcó el problema en un hilo de lanzamiento: "Obtienes las llamadas sin procesar a las herramientas; nunca la intención del usuario."

Theodore Otzenberger on X

Esa distinción es la apertura que persigue Armature.

From tool calls to product behavior

La analítica de producto tradicional instrumenta la interfaz controlada por el proveedor del software. Eventos como vistas de página, clics en botones y embudos completados pueden vincularse entre sí porque la interacción ocurre dentro de la aplicación del proveedor.

Una sesión mediada por un agente ocurre en otro lugar. Un cliente puede pedirle a Claude o a ChatGPT que cree una factura, actualice una suscripción o concilie un pago. El proveedor de software recibe llamadas a sus herramientas, pero esas llamadas por sí solas pueden no mostrar la solicitud original, el plan del agente o si el resultado final cumplió la meta del cliente.

El anuncio de lanzamiento de Armature describe tres capas: sesiones reconstruidas, casos de uso agrupados y problemas agrupados. El tablero reproduce las llamadas a las herramientas y los resultados; luego, los modelos de Armature clasifican lo que los usuarios intentaban lograr e identifican bucles, callejones sin salida y solicitudes no compatibles. Un flujo de trabajo puede marcarse como no exitoso aun cuando cada solicitud API subyacente devuelva un código de estado 200.

La implementación añade un SDK de Armature alrededor de un servidor MCP existente. Armature actualmente documenta SDKs para TypeScript, Python, Go y PHP. Su documentación de telemetría indica que el SDK agrega un objeto de telemetría opcional al esquema de entrada de cada herramienta instrumentada, con campos para la intención del usuario, el pensamiento reportado por el agente y la frustración percibida del usuario. Esa misma documentación dice que los agentes que ignoran esos campos opcionales aún generan sesiones que contienen llamadas a herramientas, tiempos y resultados.

Esa salvedad importa. Armature no está extrayendo de forma independiente un registro completo del razonamiento interno de cada modelo. Parte del contexto de sesión más rico depende de que el agente que llama proporcione los campos opcionales de telemetría que Armature agrega al esquema.

La documentación de telemetría de Armature también indica que los SDKs con analítica habilitada registran una herramienta opcional de solicitud de capacidad para los casos en que un usuario necesita algo que las herramientas existentes no pueden hacer. Esas llamadas ofrecen a los equipos de producto una vista estructurada de la demanda insatisfecha, convirtiendo solicitudes fallidas en posibles insumos para la hoja de ruta.

Production evidence becomes regression tests

El anuncio del 22 de julio dijo que seguiría un producto de pruebas. Para el 3 de agosto, la documentación de evaluación de Armature describía las evaluaciones como un despliegue por espacio de trabajo, con acceso habilitado por separado para cada espacio.

Cuando está habilitado, el producto de evaluación ejecuta un agente real contra un servidor MCP desplegado usando un objetivo de usuario definido. Un modelo juez separado evalúa la traza resultante según criterios escritos por el cliente, produciendo una puntuación de cero a cinco y un resultado de aprobado, parcial o fallido, según la documentación de puntuación de Armature. La visión general de la evaluación indica que las ejecuciones pueden iniciarse manualmente, por programación o desde una canalización de integración continua.

La decisión de producto más afilada de Armature es la conexión entre la analítica y las pruebas. Un caso de uso recurrente en producción puede convertirse en un caso de evaluación. Una falla descubierta en sesiones en vivo puede convertirse en una prueba de regresión destinada a demostrar que una corrección posterior se mantiene. Armature dice que los clientes revisan el prompt generado y los criterios antes de guardar la prueba.

Eso crea un ciclo de retroalimentación que abarca observación, priorización y verificación. También le da a Armature un alcance más amplio que un tablero de reproducción de sesiones por sí solo. El producto de analítica identifica cómo agentes controlados externamente usan un servidor MCP, mientras que la capa de evaluación verifica si esos mismos trabajos siguen funcionando después de una versión.

El acceso sigue estando por etapas. La documentación de Armature dice que la evaluación se habilita espacio de trabajo por espacio de trabajo, y que los clientes pueden solicitar acceso si la función no aparece en su cuenta. Los espacios de trabajo gratuitos reciben 100 ejecuciones completadas por mes, mientras que la programación está disponible en los planes de pago.

A category built around the missing interface

Armature se sitúa entre productos de analítica de producto como PostHog, Amplitude y Mixpanel y productos de observabilidad de agentes como LangSmith y Langfuse. El argumento de Armature es que el primer grupo mide el comportamiento dentro de interfaces que un proveedor posee, mientras que el segundo está generalmente orientado hacia agentes que el proveedor construye. Armature se enfoca en agentes externos que operan el producto del proveedor a través de MCP.

Esa distinción les da a Otzenberger y Scremin una ventaja específica, aunque proveedores establecidos de analítica, observabilidad e infraestructura MCP pueden añadir funciones superpuestas. La defensa de Armature dependerá de si su reconstrucción de sesiones y el flujo de trabajo de producción a evaluación se vuelven lo suficientemente difíciles de reproducir, y de si los equipos de producto tratan el comportamiento de los agentes como una disciplina separada con su propio presupuesto.

Armature llama a esa disciplina "Agent Experience", o AX. La etiqueta es ambiciosa, abarcando preguntas futuras sobre conversión, soporte y retención cuando un agente se interpone entre el software y el cliente. El primer producto es más estrecho y más fácil de evaluar: decirles a los desarrolladores qué le pidieron las personas a sus agentes, mostrar dónde fallaron las herramientas y convertir las fallas costosas en pruebas.

La página de precios de Armature lista las primeras 1,000 sesiones de analítica cada mes como gratuitas, seguidas de $50 por cada 1,000 sesiones adicionales, con siete días de retención en el plan gratuito. Armature afirma que su sistema escanea las sesiones en busca de información personal y secretos antes de almacenarlas. Su documentación de telemetría indica que las identidades de los actores se representan mediante hashes SHA-256 derivados en el servidor del cliente y que las vistas previas de entrada y resultado capturadas se limitan a 8 KiB cada una.

Para Otzenberger y Scremin, el momento se basa en una apuesta simple: los servidores MCP se están convirtiendo en una superficie orientada al cliente antes de que la mayoría de los equipos de software hayan aprendido a medirlos. Armature está tratando de ser dueña de esa capa de medición mientras los hábitos operativos, las elecciones de herramientas y los límites de categoría todavía se están escribiendo.