La lección de la cintura estrecha: el futuro de la IA se inventó en 1974
Tu pipeline de CI dice una cosa, tu escáner de seguridad dice otra, tu hoja de cálculo de cumplimiento dice una tercera, y la evidencia de que algo de eso es cierto vive en seis sistemas distintos — la mayoría de los cuales purgan sus registros antes de tu próxima auditoría. Mientras tanto, tus agentes de IA escriben código más rápido de lo que cualquiera de esos sistemas puede seguirles el ritmo. Si diriges una organización de ingeniería AI-first, esta es la textura diaria de tu vida: CI/CD, pruebas, escaneo de seguridad, cumplimiento y recopilación de evidencia están fragmentados, y la fragmentación empeora cada vez que agregas una herramienta o un agente.
Este no es un problema de herramientas del que puedas comprar tu salida una suscripción de SaaS a la vez. Es un problema de arquitectura, y ya se resolvió una vez antes — en 1974, para internet.
El artículo de 1974 que diseñó el centro de internet
En 1974, Vint Cerf y Bob Kahn publicaron «A Protocol for Packet Network Intercommunication» en IEEE Transactions on Communications 22(5) (doi.org). Es el artículo que introdujo lo que se convertiría en TCP/IP, y su decisión de diseño estructural no fue el formato de paquete ni el esquema de direccionamiento. Fue la decisión sobre qué se negaría a asumir el centro de la red.
La capa central de internet sabe hacer esencialmente una cosa: entregar un paquete de una dirección a otra, con el mejor esfuerzo posible, sin promesas. No sabe qué es una aplicación. No sabe si los bits son una transferencia bancaria o un video de un gato. No sabe si el enlace subyacente es Ethernet, fibra o un salto satelital. Esa ignorancia es la característica. Como el centro asume tan poco, cualquier cosa puede construirse por encima de él y cualquier tecnología de red puede transportarlo por debajo. Llegaron aplicaciones nuevas durante cincuenta años sin necesitar cambios en IP. Llegaron redes físicas nuevas sin romper las aplicaciones.
Internet escaló porque su contrato central se mantuvo pequeño: muchas aplicaciones arriba, muchas redes abajo, una interfaz estable entre ambas.
Lo que realmente afirma el modelo de reloj de arena
Micah Beck le dio a esta forma su nombre moderno y su análisis moderno en «On the Hourglass Model», publicado en Communications of the ACM 62(7), julio de 2019 (doi.org). Vale la pena exponer el argumento de Beck con cuidado, porque el reloj de arena se cita a menudo como una sensación — «mantén el centro delgado» — cuando en realidad es una afirmación sobre cómo se asigna la complejidad en un sistema que debe crecer por ambos extremos.
En una arquitectura de reloj de arena, tanto la diversidad de aplicaciones en la parte superior como la diversidad de sustratos en la parte inferior son ilimitadas y están creciendo. La única forma en que el sistema puede absorber ese crecimiento sin una explosión combinatoria es una cintura estrecha: una interfaz mínima en el centro hacia la que convergen ambos lados. No hace falta que cada aplicación conozca cada red; no hace falta que cada red conozca cada aplicación. Cada lado se integra con la cintura una sola vez.
El punto más profundo de Beck es que la cintura no es simplemente pequeña — es estable, y esa estabilidad es lo que permite que los dos extremos anchos evolucionen de forma independiente y rápida. El reloj de arena no es un diagrama de simplicidad. Es un diagrama de dónde se le permite vivir a la complejidad: en los bordes, nunca en el centro.
Ahora mira tu stack de ingeniería. Sistemas de CI, ejecutores de pruebas, escáneres SAST y DAST, generadores de SBOM, marcos de cumplimiento, sistemas de tickets, pipelines de despliegue y ahora media docena de agentes de IA de distintos proveedores. Hoy, la mayoría de estos se integran punto a punto, o a través de dashboards que agregan la salida sin ponerse de acuerdo sobre qué significa nada. Cada herramienta nueva es un impuesto de integración nuevo. Cada proveedor de agentes nuevo es un impuesto de coordinación nuevo. Eso es un sistema sin cintura, y se comporta exactamente como predice el modelo de Beck: el costo de integración crece con el producto de los dos extremos, no con la suma.
La mitad de seguridad de la misma lección
Un año después de Cerf y Kahn, Jerome Saltzer y Michael Schroeder publicaron «The Protection of Information in Computer Systems» en Proceedings of the IEEE 63(9), 1975 (web.mit.edu). Es el artículo que codificó los principios de diseño con los que todavía trabaja todo ingeniero de seguridad: privilegio mínimo, valores predeterminados a prueba de fallos, economía de mecanismo, mediación completa, diseño abierto, separación de privilegios, mecanismo común mínimo, aceptabilidad psicológica.
Léelos como el gemelo de seguridad de la lección de la cintura estrecha. La economía de mecanismo dice que mantengas la parte de confianza lo bastante pequeña como para poder razonar sobre ella de verdad. La mediación completa dice que todo acceso pasa por la comprobación, no la mayoría de los accesos. Los valores predeterminados a prueba de fallos dicen que una respuesta ausente es una denegación, no una aprobación. Saltzer y Schroeder estaban haciendo el mismo argumento estructural que hicieron Cerf y Kahn: la parte del sistema de la que todo depende debe ser mínima, explícita e imposible de evitar.
Esto importa porque internet aprendió la mitad de la lección relativa a los paquetes y se saltó la mitad relativa a la protección. Internet estandarizó la entrega de paquetes sin resolver la identidad, el fraude o la confianza — y hemos pasado cinco décadas remendando esa omisión con añadidos. El ecosistema de IA agéntica está ahora mismo en la misma bifurcación, y está eligiendo la misma dirección.
La conectividad es la mitad fácil
El ecosistema de agentes está redescubriendo la forma de reloj de arena. El Model Context Protocol estandariza cómo una aplicación impulsada por un modelo llega a herramientas y contexto; el Agent2Agent protocol aborda la comunicación entre agentes independientes. Estas son cinturas estrechas genuinas para la conectividad, y son necesarias.
Pero la conectividad es la mitad fácil. A partir de la revisión del 2026-07-28, el marco de autorización HTTP de MCP es opcional y se basa en OAuth 2.1. Las Agent Cards de A2A 1.0 pueden firmarse con JWS, y una firma verificada puede establecer la integridad de la tarjeta y el origen del proveedor — pero la firma es opcional y no es un sistema de identidad de agentes global. Lo que sigue sin estandarizarse por completo es la lista difícil: autoridad delegada a través de cadenas de agentes, atenuación de capacidades, autoridad sobre elementos de trabajo, herencia de políticas, revocación, procedencia de la evidencia, protección contra repetición, reputación y responsabilidad de extremo a extremo desde el principal hasta el agente, la herramienta y el resultado. Una instantánea de medición v1 de arXiv de mayo de 2026 encontró fallas en 119 servidores MCP reales habilitados para OAuth y evaluables — una instantánea, no una propiedad universal de los despliegues de MCP, pero una señal de dónde está poniendo su atención la industria.
En otras palabras: los protocolos conectarán tus agentes. Por sí solos no te dirán qué estaba autorizado a hacer un agente, qué hizo realmente, qué evidencia existe de que el resultado se comprobó, o quién dio el visto bueno. Si adoptas la capa de conectividad y te detienes ahí, obtienes el mismo resultado que internet: un sistema maravillosamente conectado con la confianza añadida después, a modo de parche.
Un solo sobre de evidencia, un solo plano de coordinación
La postura de Koinessa, argumentada en su totalidad en la sección 2.1 del libro blanco, es que una organización de ingeniería AI-first necesita poseer su propia cintura en lugar de esperar a que la industria estandarice la mitad que falta. En concreto, eso significa dos cosas.
Primero, un solo contrato de herramientas por encima de los modelos. Koinessa expone 366 herramientas registradas detrás de un solo contrato de búsqueda (en vivo). Agentes de seis proveedores — Kimi, Claude, Grok, Codex, Ollama local y Ollama Cloud — descubren capacidades a través de ese mismo contrato local, ya sea que se ejecuten en API de nube de frontera o en cómputo controlado por el cliente. La cintura ya fue puesta a prueba por una llegada, que es la verdadera prueba de cualquier reloj de arena: el sexto descriptor de proveedor, Devin CLI, se registró sobre un tipo de transporte existente sin código de transporte nuevo — alcanzó el mismo contrato de herramientas a través de una sola declaración de configuración. Así es como se ve operativamente una cintura estrecha que funciona: un borde nuevo se conecta sin que el centro cambie.
Segundo, un solo contrato de evidencia por debajo de la capa de verificación. En lugar de dejar que CI, los escáneres y las comprobaciones de cumplimiento emitan cada uno su propio formato de informe en su propio silo, cada acción con consecuencias produce un solo sobre de evidencia. El paquete de evidencia de un cambio producido por un agente vincula la revisión de origen, la sesión y el modelo del agente, la autorización del trabajo, las versiones de las herramientas, las comprobaciones ejecutadas con sus estados canónicos, el perfil de política que las interpretó, las aprobaciones y el digest del artefacto final — una sola cadena desde la intención hasta el despliegue. Y los estados canónicos son de cierre por defecto en el sentido de Saltzer y Schroeder: el modelo de verificación distingue PASS, FAIL, SKIPPED-NOT-APPLICABLE, INFRASTRUCTURE ERROR, TOOL MISSING y EVIDENCE INVALID (en vivo), de modo que un escáner ausente nunca puede confundirse con un escaneo limpio. Valores predeterminados a prueba de fallos, aplicados a los pipelines.
El caso de Devin también es instructivo desde fuera. La topología propia del proveedor tiene «ejecución de comandos, edición de archivos y acceso al repositorio» corriendo en máquinas que opera el cliente a través de HTTPS solo de salida, mientras el bucle del agente permanece en la nube del proveedor — y desde el 2026-07-31, sus herramientas MCP se ejecutan desde los servidores del proveedor en lugar de la máquina de la sesión. Pienses lo que pienses de esa ubicación, traza exactamente la costura de la que trata este artículo: el descubrimiento de capacidades y el estado organizativo se encuentran en un límite, y alguien es dueño de él. La lección de la cintura estrecha dice que deberías poseerlo localmente, en infraestructura que controlas, detrás de memoria compartida persistente — no alquilarlo por proveedor.
Esto es un caso de un patrón más amplio que seguimos encontrando en la literatura de sistemas — el artículo sobre las siete lecciones de cincuenta años de sistemas las recorre todas, y la visión general de la arquitectura muestra cómo el sobre de evidencia y el plano de coordinación encajan con los demás componentes.
La conclusión
La fragmentación que sientes en CI, pruebas, escaneo, cumplimiento y evidencia no es un fallo de compras. Es el estado predecible de un sistema sin cintura estrecha — cada herramienta nueva multiplica las integraciones, y cada agente nuevo multiplica las superficies de coordinación. Cerf y Kahn demostraron en 1974 que la solución es un contrato central mínimo y estable; Beck demostró que esta es una ley general de los sistemas que deben crecer por ambos extremos; Saltzer y Schroeder demostraron que el centro también debe cerrarse por defecto ante fallos y mediar por completo. La IA agéntica necesita el mismo movimiento, y los protocolos de los proveedores solo están entregando la mitad de la conectividad.
La respuesta práctica es construir tú mismo la mitad que falta: un solo contrato de herramientas a través del cual todo agente descubre capacidades, un solo sobre de evidencia que produce toda acción con consecuencias, un solo plano de coordinación al que se conecta todo proveedor — local-first, con control humano, de cierre por defecto. El argumento completo, con los datos de la instantánea y el rastro de referencias completo, está en la sección 2 del libro blanco de Koinessa.