Seu próximo usuário de software é um agente de IA. Sua arquitetura está pronta?

Imagine um agente de IA lidando com uma contestação de cobrança de um cliente. Ele lê a reclamação, consulta o histórico da conta e conclui que cabe conceder um crédito. Tudo isso em questão de segundos.

Impressionante. Agora, peça que ele conceda o crédito de fato.

O contrato com o cliente está em outro sistema. As regras de aprovação estão enterradas no código do aplicativo. A ferramenta de cobrança exige que uma pessoa navegue por várias telas com cliques.

O agente entende o que precisa ser feito, mas a arquitetura não permite que ele conclua a tarefa.

Esse é o problema que espero que mais empresas encontrem à medida que a IA agêntica passe à produção. O curioso, porém, é que o obstáculo para concluir a tarefa tem muito pouco a ver com a inteligência do agente.

Passamos anos modernizando o software empresarial para as pessoas que o usam. Agora, precisamos modernizá-lo para os agentes que cada vez mais irão operá-lo.

A interface do usuário nunca foi o produto inteiro

Pense em como o software empresarial funciona hoje. As pessoas abrem aplicativos, navegam por painéis, tomam decisões e transferem o trabalho de um sistema para outro. A interface do usuário é o meio pelo qual interagem com a empresa.

Um agente não precisa necessariamente dessas telas. Ele pode consultar informações e iniciar ações por meio de APIs, servidores do Protocolo de Contexto de Modelo (MCP) e outras interfaces programáticas. Isso faz parte da transição para uma arquitetura headless.

Mas uma arquitetura headless não significa que o aplicativo desapareça. Seus dados, regras de negócio, permissões e requisitos de conformidade continuam importantes. Eu diria que são ainda mais importantes.

Durante anos, os fornecedores de software construíram vantagens competitivas com base em interfaces de usuário refinadas, hábitos dos usuários e custos de retreinamento dos funcionários. Essas vantagens diminuem quando os agentes executam mais tarefas sem abrir a interface do aplicativo. O que ganha valor é o sistema de registro subjacente: dados confiáveis, lógica de domínio validada, governança operacional e transações auditáveis.

Há também uma consequência comercial: até US$ 234 bilhões em gastos com aplicativos empresariais podem ficar expostos à disrupção causada pela IA agêntica até 2030. São gastos sob risco de disrupção, não gastos que certamente desaparecerão. E, quando os agentes realizam tarefas que antes eram feitas por pessoas em painéis, a cobrança por usuário pode dar lugar cada vez mais a modelos baseados em uso, ação ou resultado.

Para os fornecedores de software, isso representa um desafio para o modelo de negócios. Para as empresas que dependem de seus aplicativos, é um desafio de arquitetura.

Modernizamos os componentes, mas não o fluxo de trabalho

A maioria das empresas vem se modernizando há anos. Uma equipe atualiza os aplicativos legados. Outra consolida dados fragmentados em uma plataforma moderna. Uma terceira desenvolve integrações ou simplesmente reformula a interface do usuário.

Cada projeto pode ser bem-sucedido por si só. O problema começa quando um agente precisa executar um fluxo de trabalho que abrange todos eles.

Você pode fornecer informações precisas sobre um cliente a um agente, mas, se o aplicativo responsável por agir com base nelas mantiver regras essenciais enterradas no código legado, o que acontece em seguida? Ou pode disponibilizar uma API bem estruturada, enquanto os dados por trás dela continuam inconsistentes. O agente pode agir, mas é possível confiar na decisão?

Em ambos os casos, modernizamos partes da tecnologia sem modernizar o trabalho.

A IA agêntica não se importa com qual projeto de modernização foi bem-sucedido. Ela quer saber se todo o fluxo de trabalho funciona.

Veja como isso se manifesta na prática. Um cliente precisava acelerar a elaboração de orçamentos para reparos complexos de motores, cujos contratos determinam quais peças podem ser reparadas, substituídas ou recondicionadas. Cada orçamento exigia dias, às vezes semanas, de pesquisa manual em contratos e manuais de manutenção. O cliente já havia modernizado sua plataforma de dados, mas os orçamentos não saíam mais rápido, porque o gargalo nunca esteve nos dados. Estava na pesquisa. Reconstruímos esse fluxo de trabalho com base em um conjunto de agentes de pesquisa, reduzimos o tempo de pesquisa em 80% e os orçamentos passaram a ser elaborados em um ritmo completamente diferente.

Por isso, a modernização de aplicativos e a de dados não podem ser planejadas como duas frentes de trabalho independentes. A arquitetura precisa viabilizar o resultado empresarial completo.

Uma API não torna um sistema pronto para agentes

É tentador pensar que a solução é simples: disponibilizar os endpoints, conectar o agente e pronto.

Quem dera fosse tão fácil.

Consultar informações é uma coisa. Conceder um crédito, atualizar um registro financeiro ou encomendar uma peça de reposição é algo totalmente diferente. Agora estamos falando de execução, não apenas de acesso.

É aqui que uso o termo superfície de controle do agente: a interface delimitada e governada por meio da qual os agentes leem e gravam dados nos sistemas de registro.

APIs e servidores MCP podem disponibilizar ferramentas e dados para agentes. Mas o MCP não aplica automaticamente suas regras de negócio nem determina quem tem autorização para agir. Esses controles ainda precisam ser incorporados aos sistemas e fluxos de trabalho subjacentes.

O agente consegue acessar dados confiáveis e oficiais? As regras de negócio são explícitas e aplicadas de maneira consistente? Ele pode recomendar uma ação, mas executar apenas aquelas que está autorizado a realizar? Quando algo dá errado, é possível rastrear a ação, lidar com a exceção e, quando possível, revertê-la?

Não são problemas que um modelo melhor vá resolver por conta própria. São questões relacionadas a fluxos de trabalho, design de aplicações, arquitetura de dados, integração e governança. E precisam ser respondidas em conjunto.

Comece pelo trabalho, não pela tecnologia

Então, por onde começar?

Eu não começaria tornando todas as aplicações headless nem expondo todas as APIs disponíveis. Começaria com um fluxo de trabalho empresarial relevante.

Acompanhe esse fluxo do início ao fim. Quais sistemas armazenam os registros? Onde está a lógica de negócios? Em quais dados o agente pode confiar? Quais decisões precisam de aprovação humana? O que acontece quando um sistema falha no meio do processo? Como a governança é mantida?

Você encontrará as lacunas que realmente importam. Esse será seu roteiro de modernização: uma lista coordenada de tarefas para aplicações, dados, integrações e controles, orientada por um resultado empresarial, em vez de por projetos de tecnologia desconectados.

E avalie os resultados de acordo com esses critérios. Não pelo número de APIs que você expôs nem pela quantidade de dados que migrou, mas pela confiabilidade com que o fluxo de trabalho é concluído, pela forma como as exceções são resolvidas e pela melhoria dos resultados empresariais.

O objetivo não é ter autonomia em toda parte. É garantir uma execução confiável e segura, com o discernimento humano onde ele é necessário.

A verdadeira mudança vai além do headless

O que me entusiasma não é acabar com os painéis. É pensar no que acontece quando as pessoas não precisam mais transferir tarefas manualmente entre sistemas desconectados para realizar o trabalho.

Mas não chegaremos lá colocando um agente sobre uma arquitetura que nunca foi projetada para isso.

A próxima geração de software empresarial não será definida apenas pelo que permite às pessoas ver. Também será definida pelo que permite aos agentes fazer, com confiabilidade e responsabilidade.