Durante décadas, a integração no ambiente corporativo foi tratada como um problema técnico:
Como fazer uma aplicação conversar com outra aplicação?
Consigo me lembrar de inúmeros projetos em que estive diretamente tratando esse desafio. E é bem possível que você também tenha passado por um projeto de integração durante suas vidas passadas. E alguns projetos foram épicos, ou não?! 🙂
Essa pergunta moveu boa parte da história da arquitetura empresarial. Passamos por integrações ponto a ponto, EAI, SOA, ESB, web services, WCF, APIs REST, microserviços, API gateways, SaaS, iPaaS, gRPC, events, workflows, a lista foi imensa.
Cada etapa resolveu uma parte do problema. Mas quase todas partiram de uma premissa parecida: o consumidor da integração era previsível.
Normalmente, um desenvolvedor humano lia uma documentação, entendia uma API, configurava credenciais, escrevia código e colocava a integração em produção.
Mas agora vivemos um tempo com agentes de IA, onde essa premissa muda. E essa realidade já se faz presente há alguns anos!
O novo consumidor da integração no ambiente corporativo pode ser um agente inteligente agora. Ele recebe uma intenção em linguagem natural de um usuário de negócio, interpreta o contexto, seleciona ferramentas, consulta dados, aciona APIs, interage com sistemas, pede aprovação e executa tarefas em nome do usuário, de uma equipe ou até de outra organização.
A pergunta, portanto, deixa de ser apenas:
“Como uma aplicação chama outra aplicação?”
Ela passa a ser:
“Como um agente descobre, entende e usa corretamente uma capacidade corporativa?”
Essa mudança parece sutil, mas é profunda. Ela desloca a integração do plano técnico para o plano semântico, operacional e governado.
Esse é o contexto desse artigo: sem aprofundar muito o teor técnico da conectividade e construção de agentes de IA, mas provocar uma reflexão sobre uma mudança profunda na forma como integramos aplicações, serviços e funcionalidades com os novos consumidores de conhecimento: os agentes de IA.
De 2006 a 2016 e o legado do WCF
Se você usou plataforma Microsoft para projetos de integração e serviços nos últimos 20 anos deve se lembrar do famoso WCF ou Windows Communication Foundation! Ele marcou uma geração de arquitetos e arquiteturas corporativas de soluções no ecossistema Microsoft. Quem não se lembra de nomes como JUVAL LOWY, MICHAEL MONTGOMERY, CLEMENS VASTERS ou MICHELE LEROUX BUSTAMANTE? Entre 2006 e 2016 eram desenvolvedores e arquitetos de peso sobre conectividade entre serviços e aplicações. Ok, peguei pesado!
Em sua época, o WCF organizava serviços em torno de um modelo simples e poderoso, o ENDPOINT, que era formado pelo ABC do WCF: Address, Binding e Contract.
- O Address dizia onde o serviço estava.
- O Binding definia como se comunicar com ele.
- O Contract descrevia o que o serviço oferecia.
Esse ABC era muito adequado para um tempo dominado por aplicações e desenvolvedores. O serviço era projetado, publicado, documentado e consumido por outra aplicação, tendo sempre um humano em perspectiva para o entendimento. O foco estava em localizar o serviço, configurar a comunicação e respeitar seu contrato técnico, deixando uma descrição e rastreabilidade muito claras para o desenvolvedor.
De 2016 a 2022 e o mundo pós-WCF
O tempo passou e entre 2016 e 2022, a integração de aplicações entrou em uma fase menos centrada em frameworks monolíticos de serviços, como o WCF, e mais orientada a APIs, microsserviços, eventos e cloud-native architectures. O protagonismo saiu do contrato rígido SOAP/WS-* e migrou para modelos mais leves, como REST/JSON, gRPC, GraphQL, filas, streams e event brokers. Nesse período, a exposição de funcionalidades no ambiente corporativo passou a ser organizada por API gateways, plataformas de integração como serviço, mensageria gerenciada e práticas de DevOps.
A preocupação principal deixou de ser apenas “conectar sistemas” e passou a envolver versionamento de APIs, observabilidade, autenticação via OAuth/OpenID Connect, rate limiting, governança, segurança zero trust e escalabilidade elástica em Kubernetes e cloud. E uma nova fase de projetos nasceu nesse tempo.
Foi também o período em que a integração ganhou uma linguagem mais próxima de produtos digitais: APIs passaram a ser tratadas como produtos, com portais de desenvolvedores, documentação viva, catálogos, contratos OpenAPI e estratégias de monetização ou ecossistema. Arquitetos de integração ainda continuavam importantes, mas a referência deixou de ser apenas o especialista em um framework específico e passou a ser o arquiteto capaz de combinar cloud, APIs, eventos, containers, segurança e dados. Ainda não era a era dos agentes de IA: os consumidores principais dessas capacidades eram aplicações, times de desenvolvimento, parceiros e canais digitais. Mas a descoberta, o consumo e a orquestração dos serviços ainda eram desenhados majoritariamente para humanos e sistemas tradicionais.
De 2022 a 2026 e o mundo de IA e Agentes
E então vimos o ChatGPT chegar em novembro de 2022, iniciando uma nova jornada de impacto com LLMs e GPTs. Ainda não era sobre agentes de IA, seria apenas mais uma interface de aplicações suportando a entrada de intenções do usuário via linguagem natural. Mas o impacto já foi tremendo.
A virada para “agentes de IA” veio logo depois; começa quando o LLM passa a combinar raciocínio, planejamento, uso de ferramentas, memória e execução de ações. A base conceitual já estava em trabalhos como ReAct, de 2022, que propôs intercalar raciocínio e ações, permitindo que modelos consultassem fontes externas ou interagissem com ambientes.
Mas a explosão prática veio mesmo em março de 2023, com experiências como BabyAGI (https://babyagi.org/) um framework experimental descrito como uma iniciativa para o planejamento de tarefas de agentes autônomos, ou o AutoGPT (https://github.com/Significant-Gravitas/AutoGPT) popularizando a ideia de um LLM capaz de decompor objetivos, criar subtarefas e usar ferramentas.
E a partir de 2023, a conexão de ideias foi inevitável:
Se agentes podem ser autônomos, como irão consumir funcionalidades no ambiente corporativo?
Neste momento, o WCF pode ser visto como parte de um legado corporativo distante. Impressionante isso! 🙂 Ele ainda existe, ainda sustenta aplicações críticas e ainda precisa ser mantido em algumas empresas (e conheço algumas). Mas o WCF não é mais o destino natural de novas arquiteturas conectadas. A atualização do mecanismo de conectividade com serviços, funcionalidades e sistemas passou pelo uso de novos recursos como REST, ASP.NET Core Web API, gRPC, CoreWCF e em alguns cenários de transição com eventos, SaaS, iPaaS e plataformas cloud-native.
Mas aqui está um ponto essencial desse processo:
Modernizar um framework de conectividade não resolve automaticamente o desafio de descoberta de funcionalidades por agentes de IA.
Uma API REST pode ser moderna e continuar ambígua. Um serviço gRPC pode ser performático e continuar invisível para um agente. Um endpoint pode estar protegido por um gateway e ainda assim não explicar seu risco de negócio. Um contrato técnico pode dizer o que uma operação faz, mas não quando ela deve ser usada.
Assim, se faz necessária uma nova abordagem para a exposição de funcionalidades e serviços num tempo de novos consumidores de conteúdo na forma de agentes
De APIs para capacidades e o desafio de agentes em 2026
A APIficação, que também é antiga, consolidada entre 2010 e 2016, ensinou muita gente a expor funções internas para outros sistemas. Por exemplo, a especificação OpenAPI ajudou a documentar APIs HTTP, enquanto a AsyncAPI trouxe uma lógica semelhante para eventos. E ainda havia o Arazzo, mais recente, que começou a tratar de sequências de chamadas entre APIs. E API gateways passaram a controlar autenticação, autorização, tráfego, segurança e observabilidade.
Só então vieram os protocolos mais diretamente associados ao mundo dos agentes. O MCP, Model Context Protocol, surgiu em final de 2024, como ponte entre aplicações de IA e sistemas externos, expondo ferramentas, recursos e prompts. O A2A, Agent-to-Agent, nascia em abril de 2025, apontando para um futuro em que agentes de diferentes plataformas, fornecedores ou organizações poderiam se comunicar e colaborar por meio de um protocolo aberto.
Mas veja: MCP conecta agentes a ferramentas e dados; A2A conecta agentes a outros agentes; Arazzo descreve workflows de APIs. Mas nenhum deles, isoladamente, resolve a governança das capacidades corporativas na frente de agentes de IA.
Mais recentemente, plataformas empresariais começaram a incorporar essa preocupação de forma explícita. O Agent Gateway da Gemini Enterprise Agent Platform é de abril de 2026, e é importante porque já trata a conectividade entre usuários, agentes, ferramentas e outros agentes como algo que precisa de identidade, proteção, política e observabilidade.
Agentes não podem ser tratados apenas como mais um cliente de API.
Se a frase acima é uma nova realidade, encontramos uma lacuna. Na empresa real, a API está em um gateway, a regra de negócio está no ERP, a política está em um documento, o dado sensível está em um banco, a autorização está no Gerenciador de Identidades, o workflow está em uma plataforma, os logs estão espalhados, e a descrição funcional muitas vezes está na cabeça de alguém.
Para um agente de IA, essa fragmentação de dados e assets do ambiente corporativo é um risco.
Um agente não precisa apenas de acesso. Ele precisa de compreensão. E compreensão, no contexto corporativo, significa entender finalidade, contexto, permissão, risco, dado, política, consequência e responsabilidade.
Por isso, o desafio que se apresenta para 2026 é de diferenciar API de capacidade.
Enquanto uma API é uma interface técnica, uma capacidade é uma ação de negócio compreensível, contextualizada e governada.
Ou seja,
- POST /billing/recalculate é uma API.
- “Recalcular cobrança de cliente corporativo em modo de simulação, considerando contrato ativo, regras fiscais, histórico de faturamento e política de aprovação” é uma capacidade.
Essa diferença será central na era dos agentes.
A nova descoberta dinâmica feita por agentes
Na integração tradicional, a descoberta era humana. Um arquiteto procurava uma API, um desenvolvedor lia a documentação, um time configurava o acesso e um sistema chamava outro sistema.
Com agentes, parte dessa descoberta pode acontecer em tempo de execução. Imagine que um usuário peça algo como:
“verifique se este cliente foi cobrado corretamente e prepare uma recomendação de ajuste”.
Para cumprir essa tarefa, o agente precisa descobrir quais capacidades podem ajudar: consultar contrato, buscar faturas, acessar regras comerciais, simular recálculo, verificar política fiscal, gerar relatório, solicitar aprovação e registrar evidência.
Isso exige um novo tipo de catálogo. Não é apenas um catálogo de APIs ou um diretório de endpoints. O agente precisa de um catálogo de capacidades. Em outras palavras:
- Para o usuário de negócio, isso significa operar sistemas complexos sem navegar por várias telas.
- Para o arquiteto, significa transformar funcionalidades dispersas em capacidades formalmente descritas.
- Para a segurança, significa mover o controle do nível da API isolada para o nível da intenção, do contexto e da ação do usuário.
- Para o jurídico e compliance, significa trazer LGPD, auditoria e responsabilização para dentro da arquitetura, não apenas para processos posteriores.
É aqui que os agentes começam a mudar a estratégia das aplicações LOB (Line of Business), as aplicações que sustentam vendas, finanças, atendimento, operações, supply chain, RH, jurídico, logística, compras e compliance.
Durante décadas, a interface dessas aplicações foi a tela. O usuário precisava abrir sistemas, navegar por menus, preencher campos, exportar relatórios e combinar informações manualmente.
Com agentes, a interface passa a ser a intenção. O usuário poderá pedir:
“Compare este contrato com as últimas três faturas e identifique divergências”
Ou ainda:
“Prepare uma proposta de renovação considerando margem, risco, histórico e política comercial”.
E isso não elimina as aplicações existentes na camada LOB. Pelo contrário, elas continuam sendo o núcleo operacional da empresa. Mas sua forma de acesso muda. A aplicação deixa de ser apenas uma tela e passa a ser um conjunto de capacidades acionáveis por agentes.
Do ABC do WCF ao ABCD dos Agentes
A evolução da integração corporativa não aconteceu em linha reta. Ela passou por diferentes ondas: SOA, WCF, ESB, REST, OpenAPI, SaaS, iPaaS, microsserviços, gRPC, eventos, AsyncAPI, workflows, MCP, A2A e, mais recentemente, frameworks de agentes. Cada ciclo resolveu parte do problema: conectar aplicações, expor serviços, padronizar contratos, desacoplar sistemas, distribuir eventos e compor processos.
Mas a atual era dos agentes exige uma nova formulação.
Durante anos, a integração foi explicada pelo antigo ABC: Address, Binding e Contract. Era preciso saber onde estava o serviço, como acessá-lo e qual contrato técnico deveria ser respeitado.
Mas no mundo dos agentes, isso já não basta. Surge a necessidade de um novo ABCD: Address, Binding, Contract e Description/Discovery.
Essa quarta dimensão representa o salto da integração técnica para a integração inteligente: não é apenas expor interfaces, mas tornar capacidades compreensíveis, descobríveis, contextualizadas e seguras para agentes de IA.
Podemos afirmar que a próxima fronteira da IA corporativa talvez não esteja apenas em escolher o melhor modelo, nem em adotar o framework de agentes mais recente. Talvez esteja em transformar o legado da empresa, seus sistemas, dados, documentos, processos, APIs e regras de negócio, em capacidades que possam ser descobertas, compreendidas e acionadas com governança pelos novos consumidores de conhecimento do mundo corporativo.
Em resumo, APIs continuam sendo fundamentais, mas não são suficientes, sozinhas, para o novo cenário em que agentes de IA precisam descobrir, entender, escolher, usar e auditar capacidades corporativas.
Deveremos ver cada vez mais a consolidação de um novo Agent Capability Gateway ou Gateway de Capacidades para Agentes, para a descoberta de capacidades corporativas da empresa para agentes de IA.
Se a APIficação tornou a empresa programável para aplicações, os novos Agente Capability Gateways irão tornar a empresa inteligível e segura para agentes de IA.
Para pensar! Até a próxima!
Referências e leituras adicionais
Alguns artigos relacionados e referências que usei no texto estão a seguir:
AI Agentic workflows and Enterprise APIs: Adapting API architectures for the age of AI agentes. https://arxiv.org/abs/2502.17443
Agent-First Tool API: A Semantic Interface Paradigm for Enterprise AI Agent Systems. https://arxiv.org/abs/2605.10555
Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions. https://arxiv.org/abs/2503.23278
Semantic Tool Discovery for Large Language Models: A Vector-Based Approach to MCP Tool Selection. https://arxiv.org/abs/2603.20313
MCP-Zero: Active Tool Discovery for Autonomous LLM Agents. https://arxiv.org/abs/2506.01056
