Dois números da mesma semana contam a história inteira da IA corporativa em 2026.
O primeiro é do Gartner: até o fim de 2026, cerca de 40% das aplicações enterprise terão agentes de IA task-specific embutidos — contra menos de 5% em 2025. É uma das curvas de adoção mais rápidas que a categoria de software corporativo já viu.
O segundo é da Deloitte: aproximadamente 60% das empresas com iniciativas avançadas de IA apontam a integração com sistemas legados como o principal entrave para escalar. Não o custo do modelo. Não a falta de casos de uso. Não a regulação. A integração.
Juntos, os dois números dizem algo desconfortável: todo mundo comprou o modelo, quase ninguém construiu a camada de acesso. E a diferença entre uma POC bonita e um agente em produção mora exatamente aí.
O gargalo em um parágrafo: por que a POC não vira produção
A demo funciona porque a demo é de leitura, com dado mock ou snapshot. O agente resume, classifica, responde, sugere. Todo mundo aplaude. Aí vem a pergunta que mata o projeto: "ele consegue conferir o estoque no ERP, abrir o pedido no sistema, atualizar o CRM e disparar a confirmação no WhatsApp — sozinho, com autenticação, sem duplicar e deixando rastro para auditoria?"
Nesse momento, o time descobre que os sistemas que rodam o negócio não foram feitos para serem consumidos por um agente. Foram feitos para serem consumidos por uma tela, por um humano, dentro de uma sessão. Não há API de escrita governada; há uma tela. Não há evento de mudança de estado; há um job noturno. Não há trilha de auditoria por identidade de máquina; há um usuário genérico de integração cuja senha está em um .env de 2019.
A POC não morre por falta de inteligência. Morre por falta de permissão, de contrato e de encanamento.
O que o agente precisa e o legado não entrega
Vale ser específico, porque "integrar com o legado" é vago demais para virar backlog. Um agente que executa — e não apenas conversa — precisa de cinco coisas que a maioria dos sistemas internos não oferece:
Leitura em tempo real. O agente decide com o dado do instante. Um endpoint que devolve o estoque de ontem transforma o agente em um mentiroso convincente — o que é pior do que um agente que não responde.
Escrita transacional. Ler é fácil e é onde 90% das POCs param. O valor está em escrever: abrir pedido, gerar ticket, aplicar desconto, agendar entrega. Escrita exige transação, validação de regra de negócio e, principalmente, um caminho de rollback quando algo dá errado no meio.
Idempotência. Este é o requisito que quase ninguém antecipa, e que gera o primeiro incidente sério. Agentes repetem chamadas — por timeout, por retry, por reflexão sobre a própria saída, por um loop de planejamento que reconsiderou o passo. Se a sua API de criação de pedido não é idempotente, o cliente vai receber três pedidos idênticos. A chave de idempotência deixa de ser boa prática e vira requisito de segurança operacional.
Autenticação por escopo. O agente não pode carregar as credenciais de um superusuário. Ele precisa de identidade própria, com escopo mínimo por ferramenta: pode ler estoque, pode criar pedido até X reais, não pode cancelar nota fiscal. Sem isso, um prompt malicioso vira uma vulnerabilidade com permissão de administrador.
Trilha de auditoria. Quando um agente toma uma decisão errada — e ele vai tomar —, alguém precisa reconstruir o que aconteceu: qual ferramenta chamou, com quais parâmetros, em resposta a qual entrada, em nome de quem. Sem log estruturado por chamada de ferramenta, não há governança possível, e o jurídico está certo em barrar o projeto.
MCP em 2026: o que muda com a spec stateless — e o que ele não resolve
O Model Context Protocol amadureceu rápido. A spec de julho de 2026 caminha para uma arquitetura stateless, o que é um sinal claro de maturidade corporativa: sem estado de sessão preso ao servidor, o transporte fica muito mais fácil de escalar horizontalmente, de colocar atrás de um load balancer, de rodar em serverless e de operar com o mesmo ferramental de qualquer API HTTP. Padronização de como um modelo descobre e chama ferramentas é uma vitória real — resolve um problema que, até ontem, cada empresa resolvia com um adaptador caseiro.
Mas é preciso ser claro sobre o que o MCP não resolve, porque a confusão está custando caro nos comitês de arquitetura:
O MCP é o plugue. Ele padroniza a tomada. Ele não faz a instalação elétrica.
Ele não cria a API de escrita que o seu ERP não tem. Não torna idempotente a rotina que duplica pedido. Não gera o evento de mudança de estoque que hoje só existe dentro de um job. Não implementa o controle de escopo por ferramenta, nem a trilha de auditoria, nem o rollback. Um servidor MCP mal desenhado por cima de um legado mal exposto entrega, com elegância de protocolo, exatamente os mesmos problemas de antes — agora acessíveis a um agente que age rápido e em escala.
Ter MCP sem uma camada de integração governada por trás é ter uma tomada bonita ligada a um fio solto.
A camada que falta: APIs governadas + eventos + idempotência
A arquitetura que tira o agente da POC não tem nada de exótico. É engenharia de integração clássica, aplicada com um consumidor novo em mente:
Uma camada de API governada sobre o legado. Não expor o ERP direto. Colocar na frente uma camada de APIs com contrato explícito, versionada, com validação de regra de negócio, limites e escopos — API-led connectivity, no vocabulário MuleSoft. É essa camada, e não o sistema legado, que o agente enxerga.
Eventos para o que muda. Estoque, preço, status de pedido e cadastro precisam publicar eventos (Kafka, RabbitMQ) quando mudam. Isso mata a dependência de polling e de batch, e dá ao agente — e a todo o resto da operação — uma visão atualizada em segundos.
Idempotência e retry como padrão. Toda operação de escrita exposta a um agente aceita chave de idempotência e trata retry sem duplicar efeito. Não é opcional.
Identidade de máquina com escopo mínimo. Cada ferramenta do agente recebe credencial própria, com permissão mínima e revogável, e todo uso é logado por chamada.
Observabilidade de ponta a ponta. Tracing distribuído que amarra a intenção do usuário, a decisão do agente, a chamada de ferramenta e o efeito no sistema de origem. Sem isso, depurar um agente em produção é adivinhação.
Repare no que essa lista não tem: nenhuma linha sobre escolha de modelo, fine-tuning ou prompt. Porque o gargalo nunca esteve lá.
Como a CCX ajuda: do inventário de sistemas à exposição segura para agentes
É exatamente esse o trabalho da nossa prática de Integrações & APIs Enterprise (§13): conectividade entre sistemas via REST, GraphQL e gRPC, arquitetura event-driven com Kafka e RabbitMQ, integrações SAP ↔ e-commerce, Protheus, CRMs (Salesforce, HubSpot), gateways de pagamento e ERPs de médio porte. Somam-se a isso a consultoria MuleSoft (§26) para API-led connectivity e Anypoint, e a prática de IA para Negócios (§19) — RAG, agentes, automação com LLMs — do lado de quem consome.
O método é o mesmo que aplicamos em migração e em projetos de core: começa com discovery e inventário (1–2 semanas) — quais sistemas o agente precisa tocar, quem é dono de cada dado, o que já existe como API, o que só existe como tela. Segue para arquitetura-alvo: quais operações viram API governada, quais viram evento, onde entra idempotência, qual o modelo de identidade e escopo por ferramenta, como fica a trilha de auditoria. Depois, implementação em sprints, QA com teste de carga e security, e go-live assistido — com suporte dedicado nas primeiras 72h.
Se você não tem gente sobrando para essa frente, é o caso clássico de squad dedicada: engenheiros sêniores (10+ anos de média) com onboarding em 48h, integrados ao seu time (§10).
Seu agente já sabe conversar. Falta ele conseguir fazer. A CCX expõe seus sistemas legados como APIs e eventos governados — para o agente executar de verdade, com auditoria e rollback.
Implementar IA no meu negócio →
FAQ
Preciso de MCP para colocar um agente em produção?
Não necessariamente. MCP padroniza a descoberta e a chamada de ferramentas, o que ajuda bastante em ecossistemas com muitos agentes e muitas ferramentas. Mas a camada crítica é a de APIs governadas e eventos por trás — sem ela, o MCP não tem o que expor.
Por onde começar se meu ERP não tem API de escrita?
Pelo inventário. Mapear quais operações o agente realmente precisa executar (normalmente são poucas, 5 a 10) e expor só essas, com contrato, escopo e idempotência. Não é um projeto de "abrir o ERP inteiro".
Quanto tempo leva para tirar um agente da POC?
A parte de IA costuma levar semanas. A parte de integração é que define o cronograma — e depende de quantos sistemas o agente toca e do estado das APIs existentes. É por isso que o inventário vem primeiro: ele transforma uma incerteza em um plano.
Idempotência é mesmo tão importante?
É o primeiro incidente de quase todo agente em produção. Agente repete chamada por natureza — timeout, retry, replanejamento. Sem chave de idempotência, o cliente recebe o pedido em triplicata e a confiança no projeto vai junto.