Nos últimos tempos eu tenho lido e ouvido, com uma frequência crescente os termos ADP e EAP se relacionando com a ideia do IDP. Este é um post reflexivo sobre a definição e a evolução desses termos e como eu tenho visto a aplicação deles. É um texto com uma visão bem pessoal, não tenho a pretensão de dizer para onde as coisas vão caminhar, até porque está difícil prever isso nos próximos meses.

Vamos voltar um pouco na história para nos situarmos. O termo DevOps vem sendo usado desde 2009 e evoluindo desde então. Mais adiante, chega o termo IDP, que também não é tão novo assim. O IDP (Internal Developer Platform) foi nomeado por Evan Bottcher em 2018, como “uma fundação de APIs self-service, ferramentas e serviços organizados como um produto interno”. Ele nasceu justamente dessa evolução do DevOps ao longo dos anos 2010, quando a complexidade de infra passou a pedir mais que cultura e processo, pedia uma plataforma de verdade.

Já o ADP (Agentic Development Platform) é de 2026. Surgiu forte na comunidade de Platform Engineering pra descrever plataformas onde humanos e agentes de IA trabalham lado a lado. Em pouco tempo o ADP já virou acrônimo lotado, aparecendo em relatórios e talks com significados um pouco diferentes em cada lugar. Tem até quem defenda, que o “ADP é só o seu IDP amadurecendo”, eu diria que pode ser que sim.

E, na mesma linha, aparece o EAP (Enterprise Agentic Platform). A ideia é levar esse modelo agêntico pra empresa inteira, e não só pra engenharia de software. É o termo mais recente dos três. Vamos separar um pouco esses termos.

Na sua rotina de trabalho você provavelmente já percebeu que a IA tá mexendo no nosso dia a dia de entrega de projetos. Muita gente já usa alguma ferramenta de IA hoje, gerando de 2 a 10 vezes mais código.

Só que tem um detalhe. Escrever código deixou de ser o gargalo. Agora o desafio está em validar, entregar e governar tudo isso.

E é aí que as plataformas internas começaram a precisar de mudanças. Elas foram feitas pra humanos clicando em coisas de forma sequencial. Não pra agentes de IA disparando ações em paralelo, o dia inteiro. Bora entender como a arquitetura evoluiu em três estágios: IDP, ADP e EAP.

IDP, a base que já funcionava

O Internal Developer Platform (IDP) foi o primeiro grande acerto. A ideia é simples: uma camada self-service em cima da infra, pra tirar peso das costas do dev.

O que ele trouxe de bom:

• Golden Paths: caminhos prontos e pré-aprovados pra criar serviço, subir ambiente e configurar CI/CD.
• Platform as Product: tratar o dev interno como cliente, com feedback e métricas de adoção.
• IaC declarativo: provisionamento via Terraform, Backstage, Kubernetes.
• Shift-left security: testes SAST/DAST, análise de dependências e segredos já na esteira.

Na prática, ele resolveu três dores clássicas: a carga cognitiva absurda (o dev não precisa ser expert em rede e nuvem), o famoso “TicketOps” (abrir chamado pra tudo) e a bagunça do Shadow IT.

Mas aí a IA chegou e mostrou algumas limitações do IDP:

1. Ele é cego pra IA. Foi feito pra containers, não pra GPU/TPU, registro de modelos de ML ou gateways MCP.
2. Só enxerga uma persona. Servia o dev humano e supria segurança e FinOps por meio de golden paths.
3. Não foi pensado pro modelo agêntico. Por uma questão de linha do tempo, ele não nasceu pra isso. Em geral assume ações humanas, compassadas. Agora precisa incorporar o modelo agêntico, com agentes disparando ferramentas em paralelo, em volume muito maior.

É desse último ponto que nasce o próximo estágio. Se o IDP não foi feito pro ritmo dos agentes, alguém precisava estender essa base pra eles. É aí que entra o ADP.

ADP, quando o agente entra no time

O Agentic Development Platform (ADP) é o próximo passo. E olha, ele não joga o IDP fora. Ele estende aquela base determinística pra que humanos e agentes trabalhem juntos.

O ADP se organiza em três camadas:

• Tooling: a esteira do IDP (CI/CD, segurança, observabilidade), mas com APIs resilientes, saídas estruturadas e limites de taxa pras chamadas paralelas dos agentes.
• Path Specifications: como o trabalho é definido. São três tipos:
  • Determinístico: pipeline tradicional, regra fixa.
  • Probabilístico: tarefa feita por LLM, validada por evals e humano.
  • Híbrido (loop): o agente propõe (ex: uma mudança de código), um portão determinístico valida (ex: testes). Falhou? O erro volta pro agente se autocorrigir até passar.
• Agent Infrastructure: o chão que sustenta tudo. Divide em Harness (montagem de contexto, sandbox isolado, avaliação por rubrica) e Governança (identidade não humana, guardrails de saída, controle de custo/tokens).

Um jeito que os artigos sugerem de medir onde você está é pela maturidade agêntica:

• Nível 1, In the loop: agente sugere e autocompleta na IDE.
• Nível 2, On the loop: agente abre PRs em paralelo, humano valida o conjunto.
• Nível 3, Human as orchestrator: vários agentes rodam tarefas longas em background; humano revisa por exceção.
• Nível 4, Outside the loop: plataforma autônoma que inicia, corrige e implanta sozinha, dentro dos limites definidos.

E os problemas que ele ataca são:

• Agente sem freio: sandbox e cota evitam que um agente em background estoure o orçamento de nuvem ou colida com outro em ambiente compartilhado.
• Identidade de agente: credencial temporária, permissão escopada e rastreabilidade pra cada ação de máquina.
• Código descartado à toa: em vez de rejeitar código imperfeito na mão, o loop híbrido corrige em malha fechada.

Só que tem um limite aqui: o ADP resolve tudo isso dentro da engenharia de software. E quando a mesma necessidade de rodar agentes com governança aparece em Vendas, Jurídico ou Finanças? É essa pergunta que empurra a conversa pro próximo nível.

EAP, o modelo agêntico pra empresa inteira

O ADP foca em engenharia de software. Já o Enterprise Agentic Platform (EAP), também chamado de AEP ou Platform Engineering 2.0, leva isso pra empresa toda.

A sacada central é a invariância da infraestrutura de agentes. Traduzindo: as ferramentas e os caminhos mudam entre Engenharia, Vendas, Jurídico e Finanças. Mas a infra pra rodar e governar agente com segurança é exatamente a mesma em todo lugar.

Ele se apoia em cinco pilares:

1. AI-Native: suporte de primeira classe pra IA, com GPU/TPU sob demanda, registro de modelos e servidores MCP. Agente vira cidadão da plataforma, com autonomia delimitada (bounded autonomy).
2. Multi-Persona: uma base de API única servindo seis personas: devs de aplicação, líderes de eng/negócio, segurança/compliance, engenheiros de plataforma, cientistas de dados/ML e os próprios agentes de IA.
3. FinOps embarcado: sai da fatura no fim do mês e vai pra decisão no momento do provisionamento. Estourou o orçamento? Bloqueia o deploy. E monitora token e GPU em tempo real.
4. Security shift-down: além do shift-left, embute a segurança de forma invisível e imutável no runtime. Protege nativamente contra injeção de prompt, envenenamento de modelo, vazamento de PII e Shadow AI.
5. Composable by design: arquitetura modular em camadas (Experiência, Orquestração, Capacidades, Integração, Infra), ligadas por API aberta e conectores MCP. Dá pra trocar peça sem reconstruir tudo.

Na prática, o EAP busca resolver:

• Shadow AI e silos: nada de cada área criar sua IA por fora, sem controle.
• Custo explodindo: combate o desperdício de nuvem (estimado em 35%) e o imprevisível dos tokens, com bloqueio pré-deploy e janitor agents limpando recurso ocioso.
• Dev sobrecarregado com segurança: infra segura por padrão, sem o dev configurar rede e criptografia na mão.

Vistos os três separados (IDP, ADP e EAP), fica a pergunta que interessa: eles competem entre si ou trabalham juntos? Spoiler: é a segunda opção. Vamos ver como eles se encaixam.

Como tudo se encaixa

Aqui vai o ponto que muita gente confunde: IDP, ADP e EAP não competem. Eles empilham.

• O IDP dá a base determinística, com CI/CD, IaC e políticas. É o que segura sistemas estocásticos com segurança.
• O ADP traz o SDLC agêntico, os loops de autocorreção e o harness de execução.
• O EAP expande tudo isso pra uma escala composável, multi-persona e pra qualquer área.

E por que essa junção importa tanto? Por quatro motivos:

• A corrida é por throughput, não por velocidade. O valor não está num LLM rápido isolado, e sim em rodar vários agentes em paralelo, de forma governada. Gate determinístico + raciocínio probabilístico = escala sem perder qualidade.
• A regra dos 90/10. O raciocínio do modelo é só ~10% do fluxo. Os outros 90% são infra: montar contexto, chamar ferramenta via MCP, rodar em sandbox, avaliar por rubrica.
• Tokenomics. FinOps na camada de provisionamento evita o colapso de orçamento por agente preso em loop infinito ou GPU descontrolada.
• Infra dinâmica e imutável. Com GitOps declarativo, container, cluster e GPU são reconstruídos a partir de imagem versionada. Adeus, drift de configuração.

No fim das contas, toda essa arquitetura aponta pra uma mesma direção. E é aí que quero voltar à reflexão que abriu o post.

Resumo

Baseado nas coisas que eu tenho lido e visto empresas aplicando, volto à pergunta inicial do post: IDP e ADP parecem não ser a mesma coisa, mas também não soam como rivais. Boa parte da confusão nos termos tende a diminuir quando a gente busca enxergar o relacionamento entre eles como uma possível relação de camadas, e não de substituição.

Se essa leitura fizer sentido, dá pra imaginar um fio costurando os quatro:

• O DevOps teria trazido a cultura e a automação.
• O IDP transformaria isso em plataforma: self-service, golden paths e IaC pro dev.
• O ADP pegaria essa base determinística e a estenderia pro agente de IA, com harness e governança.
• O EAP levaria o mesmo modelo pra empresa inteira, com FinOps, segurança no runtime e múltiplas personas.

Nessa hipótese, cada um pareceria resolver justamente a dor que o anterior deixou em aberto. O ADP surgiria porque o IDP não foi pensado pro ritmo agêntico. O EAP, porque o ADP tende a parar nas fronteiras da engenharia. Se for esse o caminho, faz mais sentido pensar em IDP → ADP → EAP como uma possível continuidade do que como três produtos concorrentes. Mas é a minha leitura deste momento. Isso pode mudar no mês que vem.

Uma forma de resumir o que venho observando: a discussão parece estar deslocando a plataforma de algo feito só pra humano em direção a uma infra pra rodar humano e agente juntos, com governança. E, pelo que tenho visto, quando esse caminho é incremental, ele costuma funcionar melhor. Em vez de jogar fora o IDP, as empresas tendem a fazê-lo amadurecer e incorporar novas funcionalidades.

Uma opinião pessoal. Independentemente do nome ou da sigla, a busca sempre girou em torno de uma entrega cada vez mais rápida, tentando usar as ferramentas para fazer o trabalho repetitivo, de validação e de gestão dos fluxos, com governança e segurança. Essa tem sido a busca desde 2009, com o modelo DevOps de trabalho e assim está sendo com a IA.

Abraços!

Vida longa e próspera a todos!!

Referências

• 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 (comissionado 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” (origem do termo 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.