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, que tampoco es tan nuevo. El IDP (Internal Developer Platform) 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. Y aquí está mi inquietud: 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, con razón, que “el ADP es solo tu IDP madurando”.

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. Es el término más reciente de los tres. Vamos a separar un poco estos términos.

Probablemente ya sentiste 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. Vamos a entender cómo la arquitectura evolucionó en 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 y 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 (ADP) es el siguiente paso. Y mira, 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 bien concretos:

• 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 (EAP), 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 lo que le quita el sueño a quien cuida de infra hoy:

• 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, toda esta arquitectura apunta en una misma dirección. Y es ahí donde quiero volver a la reflexión que abrió el post.

Resumen

Basado en las cosas que he leído y visto aplicar a las empresas, vuelvo a la pregunta inicial del post: IDP y ADP parecen no ser lo mismo, pero tampoco suenan como rivales. Buena parte de la confusión en los términos tiende a disminuir cuando uno intenta ver la relación entre ellos como una posible relación de capas, y no de sustitución.

Si esta lectura tiene sentido, se puede imaginar un hilo cosiendo los cuatro:

• 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 uno parecería resolver justamente el dolor que el anterior dejó abierto. El ADP surgiría porque el IDP no fue pensado para el ritmo agéntico. El EAP, 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 mi lectura de este momento. Esto puede cambiar 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 infra 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 e incorporar nuevas funcionalidades.

Una opinión personal. Independientemente del nombre o de la sigla, la búsqueda siempre giró en torno a una entrega cada vez más rápida, intentando usar las herramientas para hacer el trabajo repetitivo, de validación y de gestión de los flujos, con gobernanza y seguridad. Esa ha sido la búsqueda desde 2009, con el modelo DevOps de trabajo, y así sigue siendo 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.