Ingeniería de plataformas para la empresa agéntica: cómo gestionar aplicaciones, recursos y agentes de IA

El artículo, firmado por Lakmal Warusawithana (WSO2) y publicado en el blog de la CNCF, plantea que la disciplina de platform engineering —nacida para domesticar la complejidad de Kubernetes, microservicios, GitOps y arquitecturas distribuidas— se enfrenta ahora a un cambio de fondo: los agentes de IA están pasando de ser meras herramientas a convertirse en consumidores de pleno derecho de las plataformas internas de desarrollo (IDP), al mismo nivel que los desarrolladores humanos.

El texto recuerda el origen de las IDP: en lugar de exigir que cada equipo de desarrollo dominara despliegue, infraestructura, redes, seguridad, observabilidad y cumplimiento, las plataformas empaquetaron esas prácticas en flujos de autoservicio, entornos estandarizados y "golden paths", integrando con el tiempo CI/CD, GitOps, aplicación de políticas y gobernanza en un modelo operativo unificado. Ese modelo funcionó muy bien, pero partía de una asunción implícita: el usuario principal de la plataforma era siempre un humano.

Según el autor, esa asunción ya no se sostiene. Los agentes de IA aprovisionan infraestructura, despliegan aplicaciones, investigan incidentes, analizan telemetría, invocan flujos operativos y automatizan tareas que antes requerían intervención humana. Por tanto, la plataforma deja de ser exclusivamente "de desarrolladores" para convertirse en la base operativa común a través de la cual desarrolladores, ingenieros de plataforma, SRE y agentes de IA construyen, operan y mejoran continuamente el software empresarial.

El concepto central que propone el artículo es el de "empresa agéntica" (Agentic Enterprise), que no se define simplemente por la presencia de agentes de IA, sino por un cambio simultáneo en dos dimensiones: qué gestiona la plataforma y a quién sirve. Por un lado, el software empresarial deja de estar compuesto únicamente por aplicaciones (APIs, microservicios, sistemas orientados a eventos, aplicaciones web, servicios de integración); ahora los agentes de IA se convierten en participantes activos de ese ecosistema, colaborando con las aplicaciones, consumiendo y gestionando recursos, coordinando despliegues y haciendo cumplir políticas. Por otro lado, la propia plataforma debe ofrecer interfaces pensadas tanto para humanos como para agentes de IA, otorgando a cada actor una identidad propia, permisos delimitados (scoped) y un registro de auditoría claro, de modo que un desarrollador usando un portal, un SRE usando CLI/GitOps y un agente de IA invocando un servidor MCP queden gobernados bajo los mismos controles de seguridad y las mismas barreras de política.

A partir de ahí, el artículo introduce tres categorías de "activos de software de primera clase" que la plataforma debe entender y gestionar. Las aplicaciones siguen siendo el centro de la entrega de valor de negocio: implementan lógica, exponen APIs y procesan eventos. Los recursos —bases de datos, sistemas de mensajería, almacenamiento de objetos, modelos de IA, proveedores de identidad, secretos, clústeres de Kubernetes, servicios SaaS y entornos de ejecución— dejan de tratarse como meros detalles de infraestructura y pasan a convertirse en objetos de plataforma con ciclo de vida, propiedad, gobernanza e historial operativo propios. Y los agentes de IA se describen como un tipo de actor de software fundamentalmente distinto: no implementan lógica de negocio directamente, sino que razonan sobre contexto, invocan herramientas, colaboran con humanos y con otros agentes, y automatizan actividades operativas.

La idea clave que subraya el autor es que estas tres entidades no son independientes entre sí: las aplicaciones consumen recursos para ofrecer capacidades de negocio, los agentes de IA consumen muchos de esos mismos recursos para entender y operar el sistema, y a la vez interactúan con las aplicaciones, mientras estas exponen capacidades que los agentes pueden invocar. Los recursos se convierten así en el punto de conexión común entre aplicaciones y agentes. Esto desplaza el foco de la ingeniería de plataformas: ya no basta con gestionar componentes de software de forma aislada, sino que hay que entender las relaciones y dependencias entre ellos, y cómo se propagan los cambios a través de todo el sistema.

Una sección central del artículo defiende que el "contexto" se está convirtiendo en una capacidad de plataforma de primer nivel. Los sistemas de observabilidad tradicionales (logs, métricas, trazas, eventos) son descriptivos: cuentan qué ha pasado, pero raramente explican por qué ha pasado o cómo se relaciona un evento con otro. Los ingenieros experimentados, al investigar incidentes, combinan de forma natural historial de despliegues, propiedad (ownership), topología, dependencias, políticas operativas, incidentes previos y conocimiento organizativo para construir una comprensión completa del sistema. El artículo sostiene que los agentes de IA necesitan exactamente esa misma capacidad: un agente que investigue un despliegue fallido necesita saber qué aplicación es propietaria de ese despliegue, de qué recursos depende, qué ha cambiado recientemente, quién es responsable de esos recursos, qué políticas aplican y si ha habido incidentes similares antes. Sin ese contexto amplio, incluso el modelo de IA más capaz queda limitado a razonar sobre observaciones inconexas.

Por eso, según el texto, las plataformas modernas deben construir y mantener un modelo compartido de comprensión del conjunto del software empresarial, que conecte aplicaciones, recursos, agentes de IA, despliegues, propiedad, políticas, topología, historial operativo y conocimiento organizativo en una representación coherente sobre la que puedan razonar tanto humanos como agentes. Una vez que la plataforma se vuelve "consciente del contexto", puede exponer ese conocimiento a través de las interfaces adecuadas para cada consumidor: portales, CLI, APIs o dashboards para humanos, y protocolos como el MCP (Model Context Protocol) para los agentes de IA, todos ellos representando el mismo entendimiento subyacente del sistema. Este fundamento contextual también habilita, según el artículo, capacidades adicionales como "skills" reutilizables que encapsulan tareas de ingeniería comunes invocables por humanos y agentes por igual, y agentes integrados especializados en dominios como fiabilidad de sitio (SRE), seguridad, cumplimiento o FinOps, todos operando sobre el mismo modelo contextual para colaborar de forma consistente.

Como ejemplo práctico de estas ideas ya en marcha, el artículo presenta OpenChoreo, un proyecto en fase Sandbox de la CNCF, que según se describe mantiene todo lo esperable de una IDP moderna (CI/CD, GitOps, aplicación de políticas, autoservicio) usando Kubernetes como sistema de referencia, de forma que cada abstracción de la plataforma refleja el estado real en tiempo de ejecución en lugar de introducir un plano de control independiente. Lo que cambia, señala el autor, no es solo lo que gestiona la plataforma sino a quién sirve: OpenChoreo está pensado para usuarios humanos y para agentes de IA por igual, de modo que desarrolladores, ingenieros de plataforma y SRE siguen usando portales, CLI, APIs y flujos GitOps, mientras los agentes de IA acceden a la misma plataforma a través de servidores MCP, todo ello sobre el mismo entendimiento subyacente de aplicaciones, recursos, relaciones y estado operativo. En este modelo, los recursos (bases de datos, mensajería, almacenamiento de objetos, APIs, modelos de IA, secretos, proveedores de identidad, servicios externos) se modelan como objetos de plataforma gestionados, con ciclo de vida, propiedad, gobernanza y relaciones propias, en vez de tratarse como simples detalles de infraestructura. El artículo también menciona que OpenChoreo se diseña como una plataforma extensible mediante una arquitectura de ecosistema, en la que nuevas funcionalidades se incorporan a través de módulos de ecosistema que pueden ampliar las capacidades de las aplicaciones; el contenido disponible se corta en este punto, justo cuando comienza a detallar esos módulos, por lo que no es posible precisar aquí qué capacidades concretas añaden.

En conjunto, el planteamiento del artículo no es que la ingeniería de plataformas deba reinventarse desde cero, sino que debe extenderse: mantener sus fundamentos cloud-native (Kubernetes, GitOps, autoservicio, gobernanza) mientras incorpora a los agentes de IA como actores de software gestionables y como consumidores legítimos de la plataforma, y mientras convierte el contexto operativo —las relaciones entre aplicaciones, recursos y agentes— en la pieza que permite que humanos y máquinas razonen y actúen de forma coherente sobre el mismo sistema.