O despertar da integração agêntica
PUBLISHED
October 29, 2026
No início deste ano, a Bessemer Venture Partners publicou The Agentic Awakening, um guia para líderes de engenharia desenvolvido a partir de entrevistas com mais de 20 CTOs. Sua principal conclusão é desconfortável: a maioria das empresas subestima a jornada necessária para transformar suas equipes de engenharia de software em times AI-native.
Mesmo entre os usuários mais avançados, que conseguem gerar código até 10 vezes mais rápido, a realidade corporativa é que grande parte desse ganho acaba sendo absorvida pelos processos envolvidos e pelo surgimento de novos gargalos.
Analisamos esse guia em profundidade porque estamos lidando com esse desafio há 18 meses. E, enquanto aplicamos IA ao desenvolvimento de código internamente, também construímos uma solução de integração AI-native para nossos clientes.
São equipes responsáveis por conectar o ERP ao CRM, o armazém à plataforma de e-commerce e um mainframe de 30 anos a um agente de IA criado há três meses. Quando uma equipe de software entrega uma funcionalidade em um dia, mas precisa esperar três semanas para conectá-la aos sistemas de registro da empresa, somos nós que recebemos a ligação.
A plataforma Digibee oferece às equipes de integração tudo o que precisam para fazer a transição para uma integração AI-native: inteligência, Harness e uma metodologia para que pessoas e IA trabalhem em conjunto.
Este artigo não é uma contestação ao modelo da Bessemer. Pelo contrário, recomendamos fortemente sua leitura. Nossa proposta é complementar essa perspectiva. A integração faz parte da engenharia de software e praticamente tudo o que o guia apresenta se aplica diretamente às equipes de integração. Mas essa área tem suas próprias particularidades.
Ler o material da Bessemer foi como assistir a um filme que retratava uma experiência que nós mesmos já havíamos vivido.
No início de 2025, antecipamos o enorme potencial da IA agêntica para aliviar a pressão sobre equipes de integração sobrecarregadas. Isso aconteceu antes mesmo de os principais fornecedores de modelos de IA encontrarem uma fórmula eficaz para gerar código com IA, mas já conseguíamos enxergar a transformação que estava por vir.
Como era de se esperar, nossos engenheiros de IA começaram trabalhando com prompts. Passaram por muitos ciclos de otimização e, embora tenham conseguido fazer com que os LLMs produzissem fluxos de integração aparentemente viáveis, essas soluções não se sustentavam em produção.
Foi uma experiência que nos trouxe humildade. Contratempos como esses fazem parte do desenvolvimento de software, mas, como fundadores de uma empresa que nasceu na vanguarda da tecnologia em nuvem, foi frustrante descobrir o quanto era difícil avançar para essa nova fronteira. Precisamos reavaliar o escopo do desafio para além da utilização de agentes genéricos de programação orientados por prompts.
Nossa própria plataforma precisava passar por uma reestruturação arquitetural. Sua interface e as APIs de suporte haviam sido desenvolvidas para atender usuários humanos, enquanto usuários agênticos têm necessidades diferentes. Os conectores e o runtime que sustentavam a plataforma eram sólidos e se tornaram a base de tudo o que construímos a partir dali. Foi quando começamos a observar um progresso real e consistente.
O passo seguinte foi definir e desenvolver o conjunto adequado de subagentes altamente especializados. Incorporamos décadas de conhecimento em integração e experimentamos diferentes abordagens até identificar o melhor modelo para executar cada tarefa.
Além da tecnologia, também precisamos repensar a forma como as pessoas trabalham: orientando, colaborando e delegando tarefas à IA. A especificação se tornou o elemento central dessa interação e, ao longo do processo, também resolveu um problema recorrente: fluxos de integração sem documentação.
Por fim, como discutiremos na Parte II, tivemos que aprender a conquistar a adesão e a confiança das pessoas para conduzi-las nessa transformação. Cometemos erros, corrigimos a rota e agora compartilhamos o que aprendemos.
– Peter Kreslins, cofundador e CTO da Digibee
Escrevemos este artigo pensando em dois públicos. O primeiro é o CIO ou VP de Integração que deseja entender o que a transformação agêntica significa para sua equipe, seu backlog e seus profissionais. O segundo é o líder de engenharia de plataformas de IA, público original da Bessemer, que talvez ainda não tenha percebido o quanto do limite de 50% de ganho de produtividade está relacionado a problemas de integração. Há uma seção dedicada a esse público mais adiante.
Os exemplos apresentados vêm de dezenas de conversas com CIOs, arquitetos e engenheiros de integração de empresas que vão de startups a grandes organizações, em setores como manufatura, finanças, seguros, logística e software. Os insights também incluem a experiência das equipes de Forward Deployed Engineering e Professional Services da Digibee, que trabalham diretamente nos ambientes tecnológicos dos clientes.
A primeira recomendação da Bessemer é preparar o ambiente antes de tentar transformar as pessoas. Comprar licenças de ferramentas de IA, sejam acessos ao Copilot e ao Claude Code ou um complemento de IA para sua plataforma de integração, é apenas o ponto de partida.
O guia avalia essa base em quatro dimensões: infraestrutura de desenvolvimento de código, AI Ops, mensuração e segurança. Concordamos com todas elas e, nesta seção, vamos mostrar como se aplicam às equipes de integração.
O primeiro passo é avaliar em que estágio suas equipes estão hoje. Existem quatro níveis de maturidade, que vão desde o uso da IA como assistente até uma equipe autônoma de agentes operando em uma dark factory, cenário que, por enquanto, ainda está longe de ser uma realidade para a maioria das organizações.
A maioria das equipes de integração com as quais conversamos está no Nível I. Elas utilizam um assistente de IA em sua plataforma de integração ou recorrem ao Copilot para gerar uma linha de código. O critério é o mesmo utilizado pela Bessemer para engenharia de software: uma pessoa ainda limita a capacidade de entrega? Se cada mudança depende de alguém para escrever o código, sua equipe está no Nível I.
O Nível IV representa um futuro prometido pelos laboratórios de IA e que consideramos possível no longo prazo, mas ainda não é um objetivo viável no curto prazo. Como a integração sustenta operações corporativas críticas, os critérios de confiabilidade são rigorosos. Muito antes de esse nível se tornar tecnicamente viável, as empresas precisarão estabelecer mecanismos para que a IA comprove sua confiabilidade e competência, tanto em toda a organização quanto em casos específicos de integração.
À medida que as equipes de integração ampliam sua capacidade e reduzem atritos, uma parcela maior do ambiente tecnológico passa a ser centralizada e governada. A equipe de integração continua responsável por determinar quais sistemas exigem supervisão humana, quais categorias de integração um agente pode desenvolver sem aprovação individual e quais informações devem ser registradas nos logs. Algumas organizações com ambientes bem documentados poderão começar a avançar para o Nível IV nos próximos anos. Já aquelas com ambientes desorganizados, ou sem urgência para resolver esses problemas, poderão levar uma década ou mais.
Na Parte I, na seção How the Strongest Teams Build It, a Bessemer argumenta que os agentes de programação estão se tornando commodities e que a vantagem competitiva duradoura está na forma como contexto, ferramentas e skills são disponibilizados a esses agentes. Para um agente de programação, o contexto mais valioso muitas vezes nem está no repositório de código. Está em saber quais dados o ERP aceita, como o CRM identifica um cliente e quais campos do sistema de faturamento são considerados a fonte confiável de informação. Esse é o conhecimento de integração. Um agente de programação apoiado por um agente especializado em integração é muito mais eficaz do que outro que tenta compreender o ambiente corporativo sem esse suporte.
Se sua equipe desenvolve integrações com agentes de programação de uso geral, como Microsoft Copilot ou Claude Code, definir um objetivo não é suficiente. Esses agentes não possuem conhecimento especializado em integração nem conhecem o ambiente tecnológico da sua empresa. Cabe à equipe fornecer boas práticas, padrões organizacionais e diretrizes estratégicas para orientar decisões que envolvem diferentes alternativas.
Ao desenvolver integrações com IA, as equipes precisam direcioná-la para além de seu comportamento padrão. Agentes de uso geral tendem a buscar a solução aparentemente mais rápida e, às vezes, sugerem atalhos que não existem. Engenheiros de um de nossos clientes observaram um agente de programação sugerir tabelas inexistentes no NetSuite, relacionamentos entre campos que não estavam disponíveis e scripts de transformação de dados que ignoravam a plataforma na qual precisariam ser executados.
Identificamos as seguintes estratégias que ajudam os agentes a apresentar resultados melhores em projetos de integração:
No artigo APIs legadas: o desafio e a oportunidade para agentes de IA, aprofundamos a importância de encapsular APIs legadas frágeis em pipelines responsáveis pelo sequenciamento de operações e pela recuperação de erros, evitando que os agentes precisem lidar diretamente com essas fragilidades.
O modelo de mensuração da Bessemer evolui do consumo de tokens para a qualidade, a produtividade e os benchmarks. A pergunta central é simples: as equipes estão desenvolvendo a solução certa para cada problema, com o custo adequado? No contexto da integração, avaliamos quatro aspectos:
Existe uma questão que nenhum agente consegue resolver sozinho: o significado dos dados. Para operar no ambiente tecnológico de uma empresa, um agente precisa compreender o significado de campos, propriedades e estados em diferentes domínios. Uma conexão incorreta costuma gerar uma falha evidente. Já divergências de significado podem passar despercebidas. Cada sistema continua funcionando de maneira internamente coerente até o momento em que uma auditoria exige que as informações sejam consistentes entre si. Segundo a Gartner, o custo médio anual da baixa qualidade dos dados é de US$ 12,9 milhões, sendo a inconsistência entre fontes de dados um fator relevante.
A semântica de um sistema define como determinada aplicação funciona, incluindo os motivos pelos quais o modelo de dados de um fornecedor foi estruturado daquela forma. Esse conhecimento pode ser registrado e assimilado por um agente que tenha acesso a uma boa biblioteca de conectores.
A dificuldade aparece na interoperabilidade semântica:
Um de nossos clientes descreveu um desafio comum: conciliar registros de diferentes sistemas para identificar corretamente uma mesma pessoa. Os registros de doadores e as vendas de ingressos estavam armazenados em sistemas separados, que utilizavam identificadores diferentes. Um trabalhava com IDs de contas, enquanto o outro utilizava endereços de e-mail dos clientes. Ao tentar relacionar os registros, a equipe não conseguia garantir que cada combinação de ID de conta e e-mail correspondia à pessoa correta.
Essas definições semânticas, que atravessam sistemas e domínios, precisam ser documentadas e acessíveis para que os agentes consigam operar de forma eficaz no ambiente corporativo. O processo humano de descobrir qual colega, em outra área da empresa, sabe explicar como uma propriedade de RH corresponde a outra propriedade em TI não é viável para agentes.
Este é o momento de investir na documentação desse conhecimento institucional e estabelecer uma disciplina organizacional para mantê-lo atualizado.
O ideal é que exista uma função central responsável por esse trabalho, com autoridade e atribuições definidas, em vez de tratá-lo como uma iniciativa secundária. Muitas organizações não possuem essa estrutura, principalmente nas conexões entre sistemas. Essa lacuna se torna mais cara à medida que as empresas delegam operações de domínio aos agentes. Uma pessoa que concilia manualmente dois sistemas acaba percebendo quando seus significados divergem. Já um agente responsável por um domínio pode tomar decisões que parecem corretas localmente, sem comparar essas definições com as utilizadas por outro agente.
A semântica corporativa determina o significado dos dados quando dois sistemas apresentam informações divergentes, como definir quando um pedido deve ser considerado enviado ou qual registro representa o cliente correto. À medida que pessoas ou agentes tomam essas decisões, elas são registradas nas especificações dos projetos e, posteriormente, incorporadas à memória organizacional.
A Bessemer apresenta quatro áreas de risco relacionadas à segurança agêntica. No contexto da integração, também identificamos quatro áreas de risco, cada uma com uma resposta objetiva.
As integrações atuam diretamente sobre os sistemas e dados que sustentam as operações corporativas: ERP, registros de clientes e fluxos de pagamentos. O agente responsável por desenvolver integrações não deveria ter esse mesmo acesso direto. Sua função deve ser projetar, desenvolver e testar em um ambiente de sandbox, submetendo o resultado à aprovação humana antes da entrada em produção.
Quando um agente de integração, ou uma pessoa, incorpora agentes como etapas de um fluxo de trabalho, os riscos aumentam. Cada integração possui credenciais de acesso a sistemas importantes e, por definição, recebe informações de fontes externas à organização. Ao inserir um modelo nesse processo, um invasor pode ocultar instruções em um arquivo enviado por um parceiro ou em um webhook recebido, fazendo com que essas credenciais sejam utilizadas contra a própria empresa. As equipes de segurança chamam esse tipo de ataque de confused deputy: quando um componente confiável é induzido a utilizar indevidamente suas próprias permissões.
Em fevereiro de 2026, o título de uma issue no GitHub foi utilizado para comprometer o Cline, um assistente de programação de IA de código aberto. O Cline utilizava o Claude como bot para realizar a triagem de novas issues. Um invasor criou um título que simulava um erro de ferramenta e instruía o bot a instalar um pacote malicioso. Isso permitiu que o invasor obtivesse as credenciais de publicação de pacotes do Cline. Em seguida, ele publicou uma atualização comprometida que permaneceu disponível por aproximadamente oito horas e instalava discretamente um agente de IA, o OpenClaw, nos computadores que instalaram ou atualizaram o Cline durante esse período. O agente em si não era malicioso, mas o episódio demonstrou que a vulnerabilidade podia ser explorada.
A resposta envolve duas medidas. A primeira é manter os modelos fora do caminho crítico de execução. Quando um fluxo inclui um modelo, seu papel deve ser complementar a uma operação crítica. Bons exemplos incluem classificar documentos, extrair campos ou identificar anomalias. Uma etapa agêntica não deveria escrever diretamente em um sistema de registro crítico. Essa responsabilidade deve ficar com o pipeline determinístico que a envolve.
A segunda medida é centralizar o controle de acesso. Cada agente deve possuir sua própria identidade, com permissões concedidas, delimitadas e revogadas de forma centralizada. As credenciais devem ser intermediadas por mecanismos seguros e ter validade limitada. Nunca devem ser inseridas em prompts ou registradas em especificações.
Quando uma equipe precisa permitir que um agente acesse um novo sistema, a solicitação deve passar pelo mesmo processo de aprovação utilizado para todos os demais acessos. Dessa forma, evitamos que agentes recebam permissões específicas sem controle centralizado e que acabem esquecidas.
Uma solução de integração agêntica construída sobre um único LLM dificilmente terá o modelo mais eficaz e econômico para cada tarefa executada pelos agentes. O custo dos tokens do modelo mais caro da OpenAI pode ser 200 vezes maior do que o do mais barato, mas ambos possuem aplicações adequadas. Alguns modelos são melhores para mapear schemas, diagnosticar erros ou processar documentação. Outros apresentam resultados superiores em tarefas diferentes, e essas classificações mudam a cada lançamento.
A Harvey, plataforma de IA para escritórios de advocacia, prefere o GPT-5.2 para produzir conteúdos extensos e bem fundamentados em fontes, o Claude Opus 4.6 para análises jurídicas com múltiplas etapas e o Sonnet 4.6 ou Gemini 3 Flash para tarefas de alto volume e baixa latência.
O agente de atendimento ao cliente do Airbnb utiliza 13 LLMs de fornecedores como OpenAI, Google e Alibaba, além de projetos de código aberto. A plataforma utiliza principalmente o Qwen, da Alibaba, descrito pelo CEO Brian Chesky como “rápido e barato”. Na Digibee, o Digital Worker desenvolve fluxos de integração principalmente com o Claude Sonnet 5.5, enquanto o Claude Haiku 5.5 e o Gemini 3 Flash são utilizados em tarefas de validação.
Além de otimizar custos e desempenho, arquiteturas que utilizam LLMs de diferentes fornecedores aumentam a resiliência operacional. Um modelo alternativo permite manter uma etapa agêntica em funcionamento caso um fornecedor enfrente uma indisponibilidade. Essa abordagem também reduz o custo de migração quando um fornecedor altera suas condições comerciais, preços ou políticas de retenção de dados.
Naturalmente, essas decisões exigem profissionais especializados e capacidade dedicada para avaliar modelos em tarefas reais e repetir os testes a cada lançamento importante. A maioria das equipes não dispõe desses recursos. Em uma pesquisa da Menlo Ventures realizada em meados de 2025 com 150 líderes técnicos, apenas 11% haviam trocado de fornecedor de LLM no ano anterior. Dois terços haviam atualizado os modelos dentro do fornecedor atual e quase um quarto não havia realizado nenhuma alteração em seus LLMs.
A equipe de engenharia de IA da Digibee testou modelos da Anthropic, Google e OpenAI para o conjunto de tarefas especializadas executadas por nossos Digital Workers e repete essas avaliações à medida que novos modelos são lançados. Optar pelo maior LLM é fácil, mas a equipe descobriu que o Haiku executava a validação de fluxos de integração com resultados quase tão bons quanto os do Sonnet, por um vigésimo do custo. No artigo O que foi necessário para fazer uma LLM criar integrações corporativas?, explicamos como a Digibee avalia cada implementação comparando-a com integrações de referência desenvolvidas por especialistas.
Se sua empresa depende de um fornecedor de plataforma para desenvolver agentes de integração, pergunte como ele seleciona o LLM para cada tarefa e com que frequência realiza novas avaliações.
Uma integração desenvolvida por um agente só é confiável na medida em que você consegue explicar seu funcionamento. É necessário saber por que determinadas decisões foram tomadas, como a integração foi desenvolvida e quais motivos levaram a cada alteração, mesmo 18 meses e quatro milhões de execuções depois, quando a pessoa que aprovou essas decisões já não faz parte da equipe.
A resposta é estabelecer a governança por meio da especificação. O agente registra cada decisão de desenho da solução à medida que a toma. Toda aprovação humana é atribuída a uma pessoa identificada. Esse rigor não termina quando os fluxos entram em produção. A manutenção também precisa seguir a especificação, garantindo que ela continue sendo uma fonte de informação confiável e permanente. Aprofundamos esse tema no artigo A verdade está no seu código ou na sua especificação?
Isso atende às exigências de auditoria e oferece um benefício ainda mais importante: qualquer integrante da equipe pode assumir uma integração e compreender por que ela foi construída daquela maneira. O conhecimento deixa de ficar concentrado em uma única pessoa.
As integrações estão no centro das operações corporativas. Quando uma delas falha, as consequências podem incluir perda de receita, comprometimento da confiança dos clientes e, em setores regulamentados, multas.
Em muitos fluxos de trabalho, os agentes não deveriam ter autonomia para tomar decisões durante a execução. Em vez disso, devem atuar na etapa de desenvolvimento.
Os agentes aceleram o caminho entre a intenção e o código pronto para produção e, com um Harness adequado e colaboração humana, também melhoram a qualidade do resultado. Apresente seus objetivos aos agentes de integração e permita que conduzam as etapas de descoberta e desenho da solução. Peça que registrem o plano e apresentem as alternativas que exigem uma decisão humana.
Quando o plano estiver suficientemente completo, segundo a sua avaliação, delegue o desenvolvimento ao agente de integração. Ele deverá construir a solução conforme a especificação.
Essa abordagem mantém a participação humana nos momentos em que ela realmente importa. Nada entra em produção sem aprovação humana, seja diretamente ou por meio de uma autorização permanente para determinada categoria de integração. Na maioria dos casos, o que chega à produção é um pipeline predominantemente determinístico.
A implementação de uma integração é relativamente fácil de verificar. Seu comportamento em produção, não. Como mencionamos anteriormente, os ambientes de sandbox dos fornecedores diferem dos ambientes de produção em aspectos importantes. Um engenheiro de uma empresa de logística nos contou que sua equipe desenvolve integrações em um sandbox com apenas uma fração dos registros existentes em produção. Com isso, os problemas aparecem somente depois da implantação.
Por essa razão, a etapa de aprovação humana permanece necessária, mas tem um custo. Outro líder de integração, desta vez de uma grande operadora de planos de saúde, nos contou que a velocidade de tudo o que a IA gera acaba sendo determinada pela capacidade de quem precisa revisar o resultado.
Os agentes de integração podem melhorar significativamente esse processo ao gerar um conjunto de mecanismos de verificação que, utilizados em conjunto, aumentam a confiança na solução. Esses mecanismos podem incluir mocks desenvolvidos a partir de contratos de dados, testes de contrato, transações sintéticas, execuções paralelas em modo de observação (shadow runs) e reconciliação de dados. Cada mecanismo identifica determinados problemas e deixa outros passarem. Mas, quando combinados, oferecem uma cobertura robusta.
A necessidade de aprovação humana individual diminui à medida que essas camadas de verificação demonstram sua eficácia. Quando as integrações de um domínio passam consistentemente pelas validações e apresentam um histórico confiável em produção, os engenheiros podem estabelecer aprovações baseadas em políticas e diretrizes, em vez de revisar cada implementação.
Com isso, os domínios de integração passam a ser distribuídos em três categorias:
Todos os domínios de integração começam na categoria orientada por humanos. À medida que o agente desenvolve mais projetos dentro de determinado domínio e comprova seu funcionamento adequado em produção, ele conquista maior autonomia. Um domínio também pode retornar a uma categoria com mais supervisão. Quando um fornecedor realiza uma reformulação significativa em seu catálogo de APIs, por exemplo, novas integrações relacionadas àquele domínio passam a exigir mais atenção.
Com a base estabelecida, você está pronto para a etapa que provavelmente é ainda mais difícil: transformar a maneira como as pessoas pensam e trabalham. Essa mudança precisa partir da liderança, idealmente com líderes que já incorporaram a IA à própria rotina e demonstram iniciativa para transformar sua forma de trabalhar.
Disponibilizar a ferramenta não significa promover essa transformação. Também não é possível resolver o desafio contratando novos profissionais, porque eles ainda não conhecem o ambiente tecnológico da empresa. Na maioria das organizações, existe uma pessoa por domínio de integração que sabe por que determinado mapeamento descarta silenciosamente um campo, por que um parceiro exige uma lógica personalizada de novas tentativas e qual dos dois sistemas com informações divergentes representa a fonte confiável. Esse conhecimento raramente é documentado.
Seus profissionais naturalmente se distribuirão em quatro grupos, independentemente de você identificá-los formalmente. As equipes de integração apresentam os mesmos quatro perfis descritos pela Bessemer para engenheiros de software, mas com algumas diferenças na proporção de cada um.
Para os Usuários de ferramentas, observar o resultado alcançado por um colega torna a transformação mais concreta. Muitas vezes, esses profissionais utilizam IA para gerar um mapeamento inicial ou uma transformação padronizada e depois continuam o desenvolvimento manualmente, porque ninguém demonstrou como a tecnologia funciona em problemas mais complexos. Mostre exemplos reais de aplicações bem-sucedidas.
À primeira vista, engenheiros Resistentes e Guardiões podem parecer semelhantes, já que ambos utilizam pouco as ferramentas. A diferença está nos motivos. Os Guardiões apresentam objeções que podem ser resolvidas. Os Resistentes não, e insistir na persuasão dificilmente mudará seu comportamento.
As equipes de integração costumam ter uma proporção maior de Guardiões. Isso não é uma característica natural da personalidade desses profissionais. É consequência de anos sendo a única pessoa que sabe por que o fluxo de faturamento falha no último dia do trimestre.
A principal recomendação para o CIO é não tentar contornar esse conhecimento. É preciso registrá-lo. O papel do Guardião passa a ser ensinar ao agente aquilo que sabe, em um formato que ele próprio consiga inspecionar e no qual possa confiar.
Profissionais especializados em integração são ainda mais escassos do que profissionais de engenharia de software. A Bessemer afirma que não é possível superar a transformação apenas por meio de contratações. Isso é ainda mais verdadeiro na integração, onde o número de profissionais disponíveis é menor. Uma abordagem prática é combinar novos talentos AI-native com arquitetos e engenheiros de integração experientes, que conheçam profundamente o ambiente tecnológico da empresa, permitindo que cada grupo aprenda com o outro.
Como os Guardiões representam o maior grupo na maioria das equipes de integração, vale analisá-los com mais atenção. A Bessemer identifica dois subtipos. Os Guardiões vinculados à arquitetura têm razão ao afirmar que o ambiente ainda não é seguro para agentes de integração. Nesse caso, a solução está nos sistemas. Já os Guardiões vinculados à identidade profissional podem trabalhar em um ambiente adequado, mas resistem às mudanças em seu papel. Nesse caso, a transformação precisa acontecer com a pessoa.
A integração acrescenta um terceiro perfil: o Guardião preocupado com a responsabilidade, cuja principal questão é quem responderá quando um fluxo de integração apresentar problemas.
Os Guardiões vinculados à arquitetura apontam condições que precisam ser atendidas: ambiente de testes limitado para o ERP, ausência de mecanismos para reprocessamento de operações, falta de testes de contrato ou inexistência de alguém responsável por aprovar mudanças. São questões objetivas, não percepções subjetivas. Para conquistar a confiança desses profissionais, é necessário resolver esses problemas.
A Bessemer apresenta seis estratégias para preparar ambientes legados para agentes: Verification Layer, Headless Split, Boundary Redraw, Strangler, Rewrite e Map.
No contexto da integração, comece pelo mapeamento. Pouquíssimas empresas possuem um panorama completo de seu ambiente. Embora nenhuma pesquisa mensure diretamente a visibilidade das integrações, o indicador mais próximo, apresentado no estudo 2026 State of ITAM, da Flexera, mostra que 36% das organizações possuem visibilidade completa de TI. Esse percentual caiu em relação aos 43% registrados no ano anterior.
A documentação, ou aquilo que chamamos de especificação, é o equivalente mais próximo de um mapa do ambiente de integração. Também costuma ser a primeira atividade sacrificada quando a equipe opera com capacidade limitada. Um engenheiro desenvolve uma versão funcional dentro de um prazo apertado, pretende voltar depois para documentá-la e torná-la mais robusta, mas uma nova emergência aparece. Em pouco tempo, a empresa passa a ter um ambiente que ninguém consegue descrever completamente.
Um engenheiro de integração de uma empresa de logística descreveu seu ambiente como um “emaranhado de espaguete”. Sua equipe passou meses fazendo engenharia reversa dos pipelines para construir grafos de dependência e compreender o que existia.
Um agente não consegue tomar as decisões corretas sobre um ambiente que não consegue enxergar. Ele não sabe quais sistemas existem, quais estão conectados ou como essas conexões funcionam. Por isso, o primeiro projeto agêntico para a maioria das equipes de integração deve ser a descoberta: permitir que agentes mapeiem sistemas, fluxos de dados e dependências e produzam a documentação que nunca foi criada. Esse mapeamento passa a fornecer o contexto necessário para todos os desenvolvimentos seguintes.
Os Entusiastas e Usuários de ferramentas também enfrentam limitações quando esse mapeamento não existe. Mesmo um engenheiro que já adotou a IA fica impedido de avançar em um ambiente que não está documentado.
As demais estratégias partem desse mapeamento. A fragilidade do ambiente corporativo não está restrita a uma base de código sob seu controle. Grande parte dela existe nas conexões entre sistemas de terceiros: a API de um fornecedor SaaS, o fluxo EDI de um parceiro ou um mainframe que ninguém quer modificar. A camada de integração é a única que alcança todos esses pontos.
Para os Guardiões vinculados à identidade profissional, estão em jogo o domínio técnico, o reconhecimento e o controle sobre o trabalho. Na integração, frequentemente ouvimos: “Eu conseguiria desenvolver isso mais rápido do que explicar para a IA”. A frase parece refletir rigor técnico e preocupação com velocidade. Muitas vezes, porém, revela falta de adesão à mudança.
O papel do CIO não é discutir com esses profissionais, mas tornar o futuro da função algo concreto e confiável, porque esse novo papel oferece oportunidades melhores. O engenheiro de integração deixa de ser um executor de demandas e passa a atuar como consultor. Em vez de trabalhar em uma fila de chamados, participa diretamente das decisões das áreas de negócio, colaborando com marketing, RH ou jurídico e compreendendo suas estratégias a ponto de identificar oportunidades de automação que essas áreas ainda nem pensaram em solicitar. Mais impacto, menos backlog e menos emergências. Comunique essa visão com clareza e demonstre sua viabilidade por meio de um Guardião que já tenha realizado essa transição.
Depois, mude o que a organização valoriza. As equipes de integração tendem a priorizar integrações implantadas acima de qualquer outra entrega. As especificações ficam em segundo plano e, às vezes, sequer são criadas. Inverta essa lógica. A especificação e seus critérios de aceitação devem ter mais valor do que a integração implantada, que pode ser gerada novamente. Essa mudança só se sustenta se as especificações também forem consideradas nas avaliações de desempenho. Dizer que elas são importantes não é suficiente.
A integração acrescenta um terceiro tipo de Guardião. São profissionais responsáveis por atender emergências em fluxos críticos para a receita da empresa, que podem falhar às duas da manhã. Se um agente de programação desenvolveu aquele fluxo durante uma sessão isolada de outro colega, eles não possuem o contexto necessário para entender como tudo funciona em conjunto.
É uma objeção legítima, mas não representa um problema novo. Engenheiros de plantão sempre precisaram corrigir códigos que não escreveram ou que desenvolveram há tanto tempo que já não lembram dos detalhes. Agora, existe mais um motivo convincente para adotar a abordagem orientada por especificações: esses profissionais terão mais contexto do que jamais tiveram durante uma emergência. A especificação mostra o que o fluxo deveria fazer e por que cada decisão foi tomada. Isso é muito mais útil do que tentar compreender o código escrito por outra pessoa.
Pergunte a cada Guardião quais condições precisariam ser atendidas para que ele permitisse que um agente desenvolvesse uma integração.
Ofereça a cada grupo aquilo que solicitou e comece com projetos menores. Não peça que nenhum deles permita que um agente desenvolva, logo de início, uma integração nova e de alto risco.
A Bessemer estabelece uma distinção entre vibe coding, prática em que se aceita o resultado gerado pela IA sem maior avaliação, e engenharia agêntica, na qual as decisões de desenho e arquitetura continuam sob responsabilidade humana.
Essa distinção tem um nome: spec-driven design, ou desenvolvimento orientado por especificações. O engenheiro ou arquiteto de integração define e aprova o desenho da solução antes de iniciar qualquer desenvolvimento. A contribuição humana de maior valor deixa de ser a construção do fluxo em si. Passa a ser determinar como o trabalho deve ser dividido, definir quais resultados são considerados corretos e registrar o comportamento esperado quando algo falha.
Um profissional experiente pode afirmar que ainda consegue desenvolver uma solução melhor manualmente. Muitas vezes, isso é verdade, mas não é o ponto central. O conhecimento aplicado a uma implementação específica perde valor quando o sistema muda. Esse mesmo conhecimento, quando registrado como critérios de aceitação, pode ser utilizado em todas as implementações futuras, inclusive depois que o especialista deixa a equipe.
A Bessemer dá menos importância às especificações ao afirmar que “a versão beta é a especificação”. Esse é um dos pontos em que nossa perspectiva é diferente, pelo menos no contexto das integrações corporativas. Ignorar a especificação significa trocar segurança por velocidade. Sem ela, o código se torna o único registro do que um sistema deveria fazer. Isso funciona até que alguma coisa falhe. No desenvolvimento de software, é possível corrigir um bug. A integração não pode assumir esse risco da mesma maneira. Um fluxo que duplica pagamentos durante uma hora gera registros no livro-razão de um parceiro que podem ser corrigidos, mas nunca apagados, e alguém da equipe financeira precisará passar a semana conciliando essas informações.
A especificação também atende às necessidades da equipe no longo prazo. Ela orienta cada nova implantação e, quando uma integração apresenta problemas, informa ao engenheiro ou agente o que a conexão deveria fazer e por que a empresa precisava dela.
Existem algumas verdades sobre integração agêntica que ainda não recebem a atenção necessária:
Os agentes não mudam quem é responsável por uma integração. Eles mudam a quantidade de trabalho que uma pessoa consegue assumir. Ser responsável por uma integração sempre significou compreendê-la, estar disponível para atendê-la, identificar alterações inesperadas e responder quando algo falha. Por isso, a capacidade das equipes de integração sempre cresceu de acordo com o número de profissionais.
A responsabilidade continua sendo das pessoas, mas os agentes de integração permitem ampliar o alcance dessa responsabilidade. Quando cada projeto importante e cada frente de trabalho possuem seu próprio agente, que mantém continuamente as especificações, o histórico e os cenários de falha, os engenheiros de integração podem dedicar menos tempo à supervisão constante dos fluxos.
Nossos clientes relatam que, em algumas equipes de integração, apenas um ou dois engenheiros conhecem cada projeto ou especialidade. Preparar outros profissionais exige tempo e esforço que a equipe não consegue disponibilizar quando ocorre uma falha.
Quando um agente mantém o contexto de um projeto, um engenheiro júnior ou um profissional sênior de outra especialidade pode fazer perguntas diretamente a ele. O agente fornece informações, fontes e análises. O profissional que está assumindo o contexto pode preparar correções para problemas menos prioritários enquanto o engenheiro responsável resolve a situação mais urgente. Depois, o responsável principal avalia, ajusta ou rejeita as propostas.
A função começa a se parecer com a de um gestor de portfólio: definir resultados, governar comportamentos e administrar exceções. Uma equipe de integração formada por três pessoas nos contou que essa estrutura permitiria absorver atividades que hoje são encaminhadas a ferramentas e fornecedores externos. Segundo seu líder, isso daria à equipe uma flexibilidade muito necessária.
As equipes de integração precisam desenvolver uma habilidade que não era necessária há alguns anos: identificar quais etapas de um fluxo de trabalho devem ser determinísticas e quais devem ser agênticas.
Um pipeline determinístico é previsível, econômico e auditável. Uma etapa agêntica pode raciocinar sobre entradas inesperadas, conciliar registros ambíguos ou realizar análises preliminares. Esse valor é real, assim como os riscos: o raciocínio não determinístico durante a execução significa que uma mesma entrada pode gerar resultados diferentes. Também aumenta a latência e elimina a possibilidade de revisar uma decisão antes que ela seja tomada.
A habilidade está em introduzir raciocínio de forma criteriosa, apenas onde seu valor justifica os riscos, como no processamento de entradas não estruturadas ou em decisões durante a execução que sejam complexas demais para regras convencionais. Tudo o que precisa acontecer da mesma maneira em todas as execuções deve permanecer em um pipeline convencional. Os agentes que monitoram a produção e propõem correções devem operar ao lado do caminho transacional, e não dentro dele, executando tarefas específicas e com escopo bem definido. As equipes que dominarem essa abordagem e orientarem seus agentes de integração a fazer o mesmo terão custos menores, entregas mais rápidas e menos preocupações operacionais.
Exploramos os aspectos de rastreabilidade para auditoria e previsibilidade de custos no artigo Como quase tudo em tecnologia, IA não é uma questão de tudo ou nada.
Nem todos os profissionais que precisam passar por essa transformação trabalham diretamente para sua organização. Grande parte dos projetos de integração é executada por integradoras de sistemas e empresas de alocação de profissionais. Em uma pesquisa da Gartner de 2025, apenas 14% das empresas planejavam realizar seus projetos de IA principalmente com recursos internos.
Um fornecedor que cobra por hora ganha menos à medida que os agentes reduzem o esforço de execução. Isso cria um desincentivo para melhorar sua própria eficiência. Já um fornecedor que cobra pelo número de integrações sob sua gestão ganha mais conforme se torna mais eficiente. Entenda quais modelos contratuais sua empresa utiliza antes de definir o planejamento. Um consultor de integração nos contou que espera ver agentes reduzirem de cinco para dois dias o tempo de desenvolvimento de uma integração e que seus colegas precisarão aderir à mudança, porque ela acontecerá de qualquer forma. Sempre que possível, substitua contratos baseados em horas e materiais por contratos orientados a resultados no momento da renovação. A IDC prevê que 30% dos contratos de serviços de TI serão baseados em resultados até 2029.
A terceira conclusão da Bessemer é a que deveria preocupar todos os CIOs. Mesmo as empresas que estabeleceram a base necessária e transformaram a maneira como suas equipes trabalham continuaram encontrando dificuldades para superar ganhos de produtividade próximos de 50%.
O aumento da velocidade de desenvolvimento individual com IA não se traduziu em maior capacidade de entrega para toda a organização. O código produzido encontrou outros gargalos. Na integração, observamos uma realidade semelhante: a IA consegue desenvolver código de integração, mas sua velocidade continua limitada pela capacidade da organização de definir o que precisa ser construído.
Hoje, as etapas de descoberta e desenho da solução costumam ser as mais demoradas do ciclo de vida de uma integração. O levantamento de requisitos envolve semanas de conversas entre stakeholders das áreas de negócio e analistas, não apenas para definir objetivos, mas também para esclarecer campos, regras e exceções específicas. São reuniões, trocas de e-mails, interrupções e retomadas, além de interpretações equivocadas e expectativas diferentes sobre quais informações são necessárias e em que momento.
Um desenvolvedor com quem conversamos atribuiu um ano de retrabalho a um projeto que havia sido “mal definido e mal concebido desde o início”. O mesmo engenheiro afirmou que a abordagem utilizada por sua empresa para levantar requisitos de negócio era insuficiente, pois não considerava as particularidades de como determinados fornecedores tratavam os dados.
Adicionar um LLM de uso geral ao final desse processo significa incluir mais um intermediário, sem necessariamente melhorar a qualidade do resultado. Um estudo de 2025 apontou que um LLM generalista tinha 41% de probabilidade de inferir corretamente um requisito não declarado. Além disso, essas inferências apresentavam o dobro de probabilidade de falhar quando o modelo ou o prompt era alterado.
Três abordagens ajudam a reduzir esse gargalo:
Ao prever estruturas mais horizontais nas organizações de engenharia de software, a Bessemer propõe quatro lideranças responsáveis por Arquitetura, Produto, Design e Segurança. Elas supervisionam aspectos que os agentes não conseguem identificar sozinhos, como a consistência entre projetos e a tendência de adotar determinadas bibliotecas apenas porque são populares. Uma startup analisada no estudo perdeu aproximadamente US$ 500 mil em faturamento devido a uma aplicação interna desenvolvida sem revisão arquitetural. Essas lideranças também serão responsáveis por supervisionar agentes de integração.
Na integração, o cenário ideal é que um único agente de integração full stack seja capaz de se especializar profundamente no projeto em andamento e utilizar o conhecimento organizacional acumulado sobre sistemas, integrações e padrões.
Essa especialização full stack reúne as competências de cinco profissionais e elimina quatro transferências de responsabilidade entre etapas.
Um agente de programação de uso geral não consegue desempenhar bem nenhum desses papéis sem receber treinamento e contexto adequados. Para ter sucesso na integração, ele precisa se especializar nas cinco funções. A partir daí, passa a trabalhar ao lado de profissionais humanos, cujas responsabilidades se concentram cada vez mais em orientar e aprovar decisões.
Com a integração agêntica, a necessidade de especializações muito restritas dentro das equipes de integração diminui. Quando um agente especializado reúne competências de desenho da solução, arquitetura, desenvolvimento, testes e operações, a fila de trabalho entre essas funções desaparece. O papel do engenheiro se amplia. Uma única pessoa pode acompanhar uma integração desde o desenho inicial até sua operação, sem precisar transferi-la para outro profissional a cada etapa. A maioria das equipes de integração já recebe mais solicitações do que consegue atender. Com agentes, essas mesmas equipes passam a conseguir assumir um volume maior de demandas.
Também observamos uma elevação do nível técnico em toda a equipe. Um engenheiro júnior aprende acompanhando as decisões tomadas por um agente de integração e recebe orientação sobre as alternativas que exigem julgamento humano. Já um especialista sênior em integração passa a contar com um parceiro de raciocínio sempre disponível para discutir alternativas, avaliar prioridades e identificar oportunidades de otimização aplicáveis a todo o ambiente tecnológico.
O guia da Bessemer destaca uma proporção que se inverte quando a engenharia deixa de ser o gargalo: historicamente, havia aproximadamente um gerente de produto para cada seis engenheiros. A integração possui sua própria versão dessa transformação.
Hoje, um pequeno grupo de arquitetos define padrões para muitos engenheiros responsáveis por desenvolver e manter fluxos de integração. À medida que os agentes assumem o desenvolvimento, os engenheiros que já fazem parte da equipe passam a evoluir para funções de arquitetura.
Eles desenvolvem soluções ao lado dos agentes, acompanham cada questão que o agente identifica e aprendem quais decisões ele não consegue tomar sozinho. Determinar quais respostas se aplicam a uma única integração e quais devem valer para toda a organização é trabalho de arquitetura, algo que exige prática e tempo reservado para aprendizado. Um engenheiro de Forward Deployed Engineering ou um profissional interno que promova a adoção da tecnologia pode acelerar essa evolução.
A transformação do papel do arquiteto também muda a finalidade dos documentos de padrões técnicos. Antes frequentemente ignorados, eles deixam de ser páginas de wiki consultadas superficialmente por fornecedores e passam a fornecer o contexto utilizado pelos agentes para tomar decisões em escala.
Um engenheiro de software principal nos contou que sua equipe havia começado a armazenar padrões técnicos no Confluence e disponibilizá-los aos agentes por meio de MCP. A tendência é que práticas semelhantes se tornem cada vez mais comuns.
As solicitações de integração feitas por equipes de IA são diferentes daquelas apresentadas pelas áreas de negócio. Uma integração corporativa é desenvolvida uma vez e executada de maneira determinística, sob condições estáveis e previamente revisadas. Já um agente desenvolvido por uma equipe de IA acessa a camada de integração em momentos imprevisíveis e apresenta comportamentos que não seguem um roteiro predefinido.
Isso cria riscos que as equipes de IA e integração precisam reduzir trabalhando juntas e compartilhando conhecimentos e skills. As equipes de integração ainda não possuem um modelo consolidado para avaliar agentes consumidores com comportamento não determinístico. Por outro lado, as equipes de IA muitas vezes desconhecem por que repetir uma operação em um livro-razão pode provocar consequências graves. Combinar essas competências reduz pontos cegos e gera resultados melhores.
Essa colaboração pode ser difícil quando as equipes respondem a líderes diferentes, o que é comum. Em uma pesquisa da Deloitte realizada em 2026 com 662 líderes seniores de tecnologia, 71% afirmaram que suas organizações possuem cinco ou mais executivos de tecnologia no C-level. Em outra pesquisa da Deloitte, realizada em 2025, as equipes que colaboravam entre diferentes unidades de negócio apresentavam uma probabilidade 30% maior de relatar ganhos significativos com IA. Nem toda organização consegue reformular seu organograma, mas aquelas que têm essa possibilidade podem encontrar vantagens em reunir IA e integração sob uma mesma liderança.
Reestruturações, aquisições, desinvestimentos e entrada em novos mercados são discutidos como estratégias nas reuniões de diretoria, mas executados por meio de integrações. Uma análise da Deloitte com 30 transações de fusões e aquisições identificou que a TI foi responsável por mais da metade do valor capturado nessas operações. A amostra é pequena, mas sugere que o valor de uma transação se concretiza na camada de integração, independentemente de como os documentos estratégicos atribuem os resultados.
Uma empresa que possui um mapeamento validado de seu ambiente de integração consegue reconciliar dois ambientes tecnológicos em semanas. Já uma organização que precisa enviar profissionais para investigar cada sistema individualmente leva trimestres para concluir o mesmo trabalho.
Os benefícios também aparecem em mudanças menores. Um de nossos clientes descobriu, durante o desenvolvimento, que sua plataforma EDI estava descontinuando uma chamada utilizada pelo fluxo para marcar transações como processadas. Como conhecia o ambiente, ele sabia que outros fluxos utilizavam a mesma chamada e conseguiu corrigi-los antes que apresentassem problemas. Ele nos contou que gostaria que um agente corrigisse automaticamente todos os fluxos que utilizassem aquela operação. Isso só seria possível se já existisse um registro de todos os fluxos que dependem dela e do que cada um deveria fazer.
Esta seção é destinada ao público original da Bessemer: líderes de engenharia responsáveis por desenvolver uma estrutura de engenharia de IA. Grande parte do que suas equipes constroem com agentes de programação precisa acessar sistemas ou dados corporativos. Isso é integração. Você pode permitir que agentes genéricos de programação tentem resolver esse desafio sozinhos ou disponibilizar agentes especializados em integração, que conheçam a maneira correta de executar esse trabalho.
A recomendação prática é simples. Inclua a equipe de integração nas discussões sobre AI Engineering Ops desde agora, antes que os agentes de programação precisem ficar esperando por ela.
A Bessemer divide seus leitores em três grupos: aqueles que já incorporaram plenamente a IA, os que avançam com cautela e estão próximos dessa transformação e os que ainda exigem revisão humana para cada mudança. Vale repetir uma de suas conclusões: “O momento de começar criou a vantagem inicial. As decisões operacionais determinam o ritmo de evolução.”
Hoje, a maioria das equipes de integração ainda pertence ao grupo mais resistente à autonomia, por motivos justificáveis. Elas trabalham com sistemas nos quais os erros custam caro e são responsáveis por tecnologias legadas que ninguém mais quer assumir. Mas esses mesmos fatores fazem das equipes de integração aquelas com potencial para acelerar mais rapidamente sua evolução. A IA aplicada ao desenvolvimento, orientada por especificações e com aprovação humana, se encaixa naturalmente na maneira como a integração já precisa funcionar. Mesmo quem começa mais tarde ainda pode conquistar uma posição de destaque.
Na conclusão de The Agentic Awakening, a Bessemer recomenda: “Observe o tempo. Depois, observe o ritmo de evolução.” Algumas organizações começaram sua transformação agêntica antes de outras, mas a velocidade de evolução importa mais do que o momento de partida. As equipes de integração podem acelerar esse processo.
Os agentes são tão úteis quanto os sistemas aos quais conseguem acessar. A maioria desses sistemas está fora dos limites da sua organização. As equipes de integração que criarem caminhos rápidos, seguros e governados para superar essa última etapa levarão suas empresas mais longe do que qualquer novo lançamento de LLM. A autonomia na integração é conquistada um domínio de cada vez. As equipes que começarem a conquistá-la agora não precisarão correr atrás das demais no futuro.
Peter Kreslins
Peter acredita no poder de um mundo digital. Como CTO e cofundador da Digibee, une sua paixão por tecnologia, especialmente por arquiteturas de software elegantes, ao trabalho com um time de desenvolvedores para repensar a forma como as empresas conectam e lançam serviços digitais.Sua experiência no setor inclui passagens pela Zup Innovation e pela CA Technologies. Peter é formado em Ciência da Computação pela Universidade de São Paulo (USP).
MORE RESOURCES
