En los últimos tiempos he leído y escuchado, con una frecuencia creciente, los términos ADP y EAP relacionándose con la idea de IDP. Este es un post reflexivo sobre la definición y la evolución de esos términos y sobre cómo he visto su aplicación. Es un texto con una visión bastante personal; no tengo la pretensión de decir hacia dónde van a ir las cosas, entre otras razones porque está difícil prever eso en los próximos meses.

Volvamos un poco en la historia para situarnos. El término DevOps viene usándose desde 2009 y evolucionando desde entonces. Más adelante llega el término IDP (Internal Developer Platform), que tampoco es tan nuevo. El IDP fue nombrado por Evan Bottcher en 2018, como “una base de APIs self-service, herramientas y servicios organizados como un producto interno”. Nació justamente de esa evolución del DevOps a lo largo de los años 2010, cuando la complejidad de la infra pasó a exigir más que cultura y proceso: pedía una plataforma de verdad.

Ya el ADP (Agentic Development Platform) es de 2026. Surgió con fuerza en la comunidad de Platform Engineering para describir plataformas donde humanos y agentes de IA “trabajan codo a codo”. En poco tiempo el ADP ya se volvió un acrónimo saturado, apareciendo en informes y charlas con significados un poco distintos en cada lugar. Hay incluso quien defiende que “el ADP es solo tu IDP madurando”; yo diría que puede que sí.

Y, en la misma línea, aparece el EAP (Enterprise Agentic Platform). La idea es llevar ese modelo agéntico a toda la empresa, y no solo a la ingeniería de software o infra. Es el término más reciente de los tres. Vamos a profundizar un poco en estos términos.

En tu rutina de trabajo probablemente ya notaste que la IA está moviendo el tablero en nuestro día a día de entrega de proyectos. Mucha gente ya usa alguna herramienta de IA hoy, generando de 2 a 10 veces más código.

Solo que hay un detalle. Escribir código dejó de ser el cuello de botella. Ahora el aprieto está en validar, entregar y gobernar todo eso.

Y es ahí donde las plataformas internas empezaron a necesitar cambios. Fueron hechas para humanos haciendo clic en cosas de forma secuencial. No para agentes de IA disparando acciones en paralelo, todo el día. Este post tiene el objetivo de entender cómo la arquitectura evolucionó en estas tres etapas: IDP, ADP y EAP.

IDP, la base que ya funcionaba

El Internal Developer Platform (IDP) fue el primer gran acierto. La idea es simple: una capa self-service sobre la infra, para quitarle peso de encima al dev.

Lo que trajo de bueno:

• Golden Paths: caminos listos y preaprobados para crear servicio, levantar ambiente y configurar CI/CD.
• Platform as Product: tratar al dev interno como cliente, con feedback y métricas de adopción.
• IaC declarativo: aprovisionamiento vía Terraform, Backstage, Kubernetes.
• Shift-left security: pruebas SAST/DAST, análisis de dependencias y secretos ya en el pipeline.

En la práctica, resolvió tres dolores clásicos: la carga cognitiva absurda (el dev no necesita ser experto en red, infra o nube), el famoso “TicketOps” (abrir ticket para todo) y el desorden del Shadow IT.

Pero entonces llegó la IA y mostró algunas limitaciones del IDP:

1. Es ciego a la IA. Fue hecho para contenedores, no para GPU/TPU, registro de modelos de ML o gateways MCP.
2. Solo ve una persona. Servía al dev humano y cubría seguridad y FinOps por medio de golden paths.
3. No fue pensado para el modelo agéntico. Por una cuestión de línea de tiempo, no nació para eso. En general asume acciones humanas, acompasadas. Ahora necesita incorporar el modelo agéntico, con agentes disparando herramientas en paralelo, en un volumen mucho mayor.

Es de este último punto que nace la siguiente etapa. Si el IDP no fue hecho para el ritmo de los agentes, alguien tenía que extender esa base para ellos. Es ahí donde entra el ADP.

ADP, cuando el agente entra al equipo

El Agentic Development Platform es el siguiente paso; no tira el IDP a la basura. Extiende aquella base determinista para que humanos y agentes “trabajen juntos”.

El ADP se organiza en tres capas:

• Tooling: el pipeline del IDP (CI/CD, seguridad, observabilidad), pero con APIs resilientes, salidas estructuradas y límites de tasa para las llamadas paralelas de los agentes.
• Path Specifications: cómo se define el trabajo. Son tres tipos:
  • Determinista: pipeline tradicional, regla fija.
  • Probabilístico: tarea hecha por un LLM, validada por evals y humano.
  • Híbrido (loop): el agente propone (ej.: un cambio de código), una compuerta determinista valida (ej.: pruebas). ¿Falló? El error vuelve al agente para autocorregirse hasta pasar.
• Agent Infrastructure: el suelo que sostiene todo. Se divide en Harness (armado de contexto, sandbox aislado, evaluación por rúbrica) y Gobernanza (identidad no humana, guardrails de salida, control de costo/tokens).

Una forma que los artículos sugieren para medir dónde estás es por la madurez agéntica:

• Nivel 1, In the loop: el agente sugiere y autocompleta en el IDE.
• Nivel 2, On the loop: el agente abre PRs en paralelo, el humano valida el conjunto.
• Nivel 3, Human as orchestrator: varios agentes ejecutan tareas largas en background; el humano revisa por excepción.
• Nivel 4, Outside the loop: plataforma autónoma que inicia, corrige e implementa sola, dentro de los límites definidos.

Y los problemas que ataca son:

• Agente sin freno: sandbox y cuota evitan que un agente en background reviente el presupuesto de nube o choque con otro en un ambiente compartido.
• Identidad de agente: credencial temporal, permiso acotado y trazabilidad para cada acción de máquina.
• Código descartado en vano: en lugar de rechazar código imperfecto a mano, el loop híbrido corrige en lazo cerrado.

Solo que hay un límite aquí: el ADP resuelve todo eso dentro de la ingeniería de software. ¿Y cuándo la misma necesidad de ejecutar agentes con gobernanza aparece en Ventas, Legal o Finanzas? Es esa pregunta la que empuja la conversación al siguiente nivel.

EAP, el modelo agéntico para toda la empresa

El ADP se enfoca en ingeniería de software. En cambio el Enterprise Agentic Platform, también llamado AEP o Platform Engineering 2.0, lleva eso a toda la empresa.

La idea central es la invariancia de la infraestructura de agentes. Traduciendo: las herramientas y los caminos cambian entre Ingeniería, Ventas, Legal y Finanzas. Pero la infra para ejecutar y gobernar agentes con seguridad es exactamente la misma en todos lados.

Se apoya en cinco pilares:

1. AI-Native: soporte de primera clase para IA, con GPU/TPU bajo demanda, registro de modelos y servidores MCP. El agente se vuelve ciudadano de la plataforma, con autonomía delimitada (bounded autonomy).
2. Multi-Persona: una base de API única sirviendo a seis personas: devs de aplicación, líderes de ingeniería/negocio, seguridad/compliance, ingenieros de plataforma, científicos de datos/ML y los propios agentes de IA.
3. FinOps embebido: sale de la factura de fin de mes y pasa a la decisión en el momento del aprovisionamiento. ¿Se pasó del presupuesto? Bloquea el deploy. Y monitorea token y GPU en tiempo real.
4. Security shift-down: además del shift-left, embebe la seguridad de forma invisible e inmutable en el runtime. Protege nativamente contra inyección de prompt, envenenamiento de modelo, fuga de PII y Shadow AI.
5. Composable by design: arquitectura modular en capas (Experiencia, Orquestación, Capacidades, Integración, Infra), unidas por API abierta y conectores MCP. Se puede cambiar una pieza sin reconstruir todo.

En la práctica, el EAP busca resolver:

• Shadow AI y silos: nada de que cada área cree su IA por fuera, sin control.
• Costo explotando: combate el desperdicio de nube (estimado en 35%) y lo imprevisible de los tokens, con bloqueo pre-deploy y janitor agents limpiando recursos ociosos.
• Dev sobrecargado con seguridad: infra segura por defecto, sin que el dev configure red y cifrado a mano.

Vistos los tres por separado (IDP, ADP y EAP), queda la pregunta que interesa: ¿compiten entre sí o trabajan juntos? Spoiler: es la segunda opción. Veamos cómo encajan.

Cómo encaja todo

Aquí va el punto que mucha gente confunde: IDP, ADP y EAP no compiten. Se apilan.

• El IDP da la base determinista, con CI/CD, IaC y políticas. Es lo que sostiene sistemas estocásticos con seguridad.
• El ADP trae el SDLC agéntico, los loops de autocorrección y el harness de ejecución.
• El EAP expande todo eso a una escala componible, multi-persona y para cualquier área.

¿Y por qué importa tanto esta unión? Por cuatro motivos:

• La carrera es por throughput, no por velocidad. El valor no está en un LLM rápido aislado, sino en ejecutar varios agentes en paralelo, de forma gobernada. Compuerta determinista + razonamiento probabilístico = escala sin perder calidad.
• La regla del 90/10. El razonamiento del modelo es solo ~10% del flujo. El otro 90% es infra: armar contexto, llamar herramienta vía MCP, ejecutar en sandbox, evaluar por rúbrica.
• Tokenomics. El FinOps en la capa de aprovisionamiento evita el colapso de presupuesto por un agente atrapado en un loop infinito o una GPU descontrolada.
• Infra dinámica e inmutable. Con GitOps declarativo, contenedor, clúster y GPU se reconstruyen a partir de una imagen versionada. Adiós, drift de configuración.

Al final de cuentas, toda esta arquitectura apunta en una misma dirección.

Resumen

Basado en lo que vengo leyendo y viendo aplicar a las empresas, se puede afirmar que IDP y ADP no son lo mismo, pero tampoco son rivales. Buena parte de la confusión entre los términos tiende a disminuir cuando entendemos la relación entre ellos como una superposición de capas, y no como sustitución.

Así, se puede imaginar un hilo cosiendo los cuatro temas:

• El DevOps habría traído la cultura y la automatización.
• El IDP transformaría eso en plataforma: self-service, golden paths e IaC para el dev.
• El ADP tomaría esa base determinista y la extendería al agente de IA, con harness y gobernanza.
• El EAP llevaría el mismo modelo a toda la empresa, con FinOps, seguridad en el runtime y múltiples personas.

En esa hipótesis, cada capa parecería resolver justamente el dolor que la anterior dejó abierto. El ADP surgiría porque el IDP no fue pensado para el ritmo agéntico. El EAP surgiría porque el ADP tiende a detenerse en las fronteras de la ingeniería. Si ese es el camino, tiene más sentido pensar en IDP → ADP → EAP como una posible continuidad que como tres productos competidores. Pero es solo mi lectura de este momento, algo que puede cambiar ya el mes que viene.

Una forma de resumir lo que vengo observando: la discusión parece estar desplazando la plataforma de algo hecho solo para humanos hacia una infraestructura para ejecutar humano y agente juntos, con gobernanza. Y, por lo que he visto, cuando ese camino es incremental, suele funcionar mejor; en lugar de tirar el IDP, las empresas tienden a hacerlo madurar, incorporando nuevas funcionalidades en vez de sustituirlo.

Una opinión personal: independientemente del nombre o de la sigla, la búsqueda siempre giró en torno a entregar cada vez más rápido, usando herramientas para automatizar el trabajo repetitivo, la validación y la gestión de los flujos, con gobernanza y seguridad. Esa ha sido la búsqueda desde 2009, con el modelo de trabajo DevOps, y así sigue siendo ahora con la IA.

¡Un abrazo!

¡¡Larga vida y prosperidad para todos!!

Referencias

• Kaspar von Grünberg — “Welcome to the Age of Agentic Platforms” (Substack)
• Platform Engineering / Kaspar von Grünberg, Ajay Chankramath — “How to architect Agentic Development Platforms” (18 jun. 2026)
• Platform Engineering — “The four levels of agentic software development in the enterprise”
• Weave Intelligence (comisionado por Broadcom) / Sam Barlien, Pankaj Gupta — “Platform Engineering 2.0: An Evolution for the AI Era” (2026)
• Fairwinds — “An Agentic Development Platform Is Just Your IDP Growing Up”
• Platform Engineering — “The story of platform engineering” (origen del término IDP, Evan Bottcher, 2018)

Entre em contato:

NewsLetter - https://engineeringmanager.com.br/
Linkdin - linkedin.com/in/leonardoml/
Twitter: @infraascode_br

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.