O Projeto Agêntico (E o Chão Sobre o Qual Nunca Foi Construído)

Sobre visões arquiteturais, operações em falta, e as perguntas que importam às 2 da manhã.

A McKinsey Technology publicou recentemente um artigo intitulado «Repensar a Arquitetura Empresarial para a Era Agêntica». Está bem escrito, bem estruturado, e apresenta um quadro claro para os líderes de tecnologia que ponderam como integrar AI agêntica nas suas arquiteturas empresariais.

Merece atenção — não por estar errado, mas pelo que não diz. E o que não diz revela algo importante sobre como a indústria pensa a transformação.

O Quadro

O artigo apresenta dois caminhos. Integração incremental: sobrepor AI agêntica aos sistemas existentes, aumentando o que funciona, reduzindo a desordem ao longo do tempo. Transformação abrangente: reconstruir de raiz, colocando os agentes de AI no centro das operações, substituindo por completo os sistemas tradicionais.

A análise é ponderada. O caminho incremental preserva a memória institucional mas arrisca acumular dívida técnica. O caminho transformacional promete uma empresa verdadeiramente adaptativa mas exige um investimento maciço e carrega um risco significativo de falha. A maioria das organizações, reconhecem os autores, seguirá um caminho intermédio.

Isto é pensamento estratégico sólido. É também inteiramente arquitetural. E é aí que começam as lacunas.

O Chão em Falta

A arquitetura é o aspeto de um sistema num quadro branco. As operações são o que acontece quando esse sistema processa dois mil milhões de euros em transações batch noturnas enquanto está aberto um incidente de severidade um e o engenheiro de prevenção tenta perceber por que o Job 4712 não terminou.

O artigo da McKinsey vive inteiramente no quadro branco.

A palavra «incidente» não aparece uma única vez. «Batch» não aparece. «Prevenção» não aparece. «Recuperação» não aparece. A palavra «operações» é usada, mas apenas como abstração — nunca como a realidade vivida de manter sistemas a funcionar às três da manhã.

Isto não é uma omissão menor. É a omissão. Porque toda a visão arquitetural, por mais elegante que seja, acaba por ter de sobreviver ao contacto com a produção. E a produção não quer saber do seu quadro conceptual. A produção quer saber se a coisa funciona, se alguém a compreende quando não funciona, e se o caminho de recuperação foi testado.

A «Malha Agêntica» — Quem Vigia os Vigias?

Um dos conceitos mais interessantes do artigo é a malha agêntica — uma camada de orquestração que liga os agentes de AI uns aos outros e aos sistemas tradicionais. Impõe regras de negócio, mantém uma fonte de verdade partilhada, e evita a fragmentação quando dezenas de agentes operam com funções-objetivo diferentes.

O conceito é sólido. Na verdade, já existe numa forma menos glamorosa. As plataformas de automação de cargas de trabalho fazem exatamente isto há décadas — orquestrando processos em sistemas heterogéneos, impondo dependências, gerindo exceções, mantendo trilhos de auditoria. A linguagem é nova. O problema não é.

Mas a descrição que o artigo faz da malha agêntica levanta uma pergunta a que não responde: o que acontece quando a própria malha falha?

Se a malha agêntica é o sistema nervoso da empresa, então uma falha nessa camada não é uma indisponibilidade de aplicação. É um evento sistémico. Cada agente que depende da malha para coordenação, governação e verdade está agora a operar sem barreiras de proteção. Em arquiteturas tradicionais, a falha de um scheduler é um cenário bem compreendido com procedimentos de recuperação documentados. Numa falha de malha agêntica, o caminho de recuperação depende de compreender o estado de cada agente no momento da falha — um estado que pode ser dinâmico, distribuído e não documentado.

O artigo recomenda a malha agêntica como facilitadora da governação. Não pergunta o que governa a malha.

Agentes Auto-Organizados em Ambientes Regulados

O caminho da transformação abrangente imagina agentes que «negoceiam o acesso a recursos e modificam fluxos de trabalho dinamicamente». A empresa torna-se «uma rede viva de agentes inteligentes capazes de auto-organização e adaptação contínua».

É uma alegação extraordinária. Pode até ser tecnicamente alcançável. Mas embate de frente numa parede que o artigo não reconhece: a realidade regulatória.

Serviços financeiros sob o DORA. Infraestrutura crítica sob a NIS2. Saúde sob governação de dados específica do setor. Em todos estes ambientes, um regulador pode — e vai — fazer uma pergunta simples: explique a decisão que levou a este resultado.

Um agente auto-organizado que modificou dinamicamente um fluxo de trabalho é, por definição, difícil de auditar a posteriori. A adaptabilidade que o torna arquiteturalmente elegante torna-o problemático do ponto de vista regulatório. Um auditor não quer ouvir que o sistema «se adaptou». Um auditor quer ver a cadeia de decisão, a regra de negócio que a despoletou, e o humano que a aprovou.

Isto não significa que as arquiteturas agênticas sejam incompatíveis com a regulação. Significa que o modelo de governação para sistemas agênticos é fundamentalmente diferente da governação de TI tradicional — e essa diferença merece mais do que um parágrafo sobre «plataformas de governação de AI que monitorizam, validam e coordenam o comportamento dos agentes em tempo real». Essa frase contém uma indústria inteira de problemas por resolver.

A Pergunta dos 100 Engenheiros

O artigo inclui uma projeção impressionante: «Um projeto que antes exigia 100 engenheiros durante um ano inteiro poderia ser concluído por um punhado de equipas a trabalhar em concerto com fábricas de agentes».

Deixando de lado se isto é alcançável hoje. A pergunta mais importante é o que acontece ao conhecimento que esses 100 engenheiros transportavam.

Em grandes ambientes empresariais, a equipa de engenharia não é apenas uma função de produção. É um repositório de conhecimento. Cada engenheiro transporta contexto sobre por que certas decisões foram tomadas, quais as integrações frágeis, onde vivem as dependências não documentadas, e o que falhou da última vez que alguém tentou mudar aquele módulo.

Reduza-se essa equipa a um punhado, e o conhecimento institucional evapora-se — mesmo que o código seja perfeitamente mantido por agentes. Porque o conhecimento nunca esteve no código. Estava nas conversas, nos post-mortems de incidentes, na memória tribal do que aconteceu às 2 da manhã naquela terça-feira de novembro há quatro anos.

As fábricas de agentes conseguem gerar código, documentação, testes e deployments. Não conseguem gerar o discernimento que vem de se ter sido responsável quando algo correu mal. E esse discernimento é exatamente o que se precisa quando a própria fábrica de agentes encontra algo para o qual não foi desenhada.

«Basta Escolher» — O Conselho Mais Caro da Consultoria

A recomendação principal do artigo é desarmantemente simples: fazer uma escolha deliberada. Decidir entre incremental e transformacional. Comprometer-se. Executar depressa.

Em princípio, isto está correto. A indecisão é cara. Mas a recomendação pressupõe que a informação necessária para fazer essa escolha já existe dentro da organização. Na prática, raramente existe.

A maioria das empresas não tem um inventário claro e honesto do que os seus sistemas legados de facto fazem, como interagem, onde estão as dependências críticas, e quais os processos genuinamente compreendidos pelas suas equipas atuais. Sem essa linha de base diagnóstica, escolher entre incremental e transformacional não é uma decisão estratégica. É um palpite informado vestido de quadro conceptual.

A escolha que importa não é «incremental ou transformacional». A escolha que importa é: compreendemos o que temos bem o suficiente para tomar qualquer das decisões de forma responsável?

Na maioria dos casos, a resposta honesta é não. E isso não é uma falha de estratégia. É uma falha de diagnóstico.

O Que o Quadro Branco Não Mostra

Nada disto diminui o valor do pensamento arquitetural. A arquitetura empresarial importa. Os quadros estratégicos importam. A escolha entre evolução e revolução é real e consequente.

Mas arquitetura sem operações é um projeto sem fundação. Descreve o que se quer construir. Não descreve o que vai acontecer quando se constrói em cima de trinta anos de decisões acumuladas, dependências não documentadas, e sistemas que funcionam por razões que ninguém compreende totalmente.

As perguntas em falta não são exóticas. São básicas:

Quem está de prevenção quando um agente toma uma decisão errada às 2 da manhã? Não arquiteturalmente. Operacionalmente. Que humano atende o telefone?

Qual é o caminho de recuperação quando a camada de orquestração falha? Não no documento de desenho. Em produção. Com dados em trânsito.

Como se explica a decisão autónoma de um agente a um regulador? Não em teoria. Numa auditoria. Com consequências.

O que acontece ao conhecimento institucional quando se reduz uma equipa de 100 pessoas a um punhado? Não no organograma. No incidente que acontece seis meses depois, quando ninguém se lembra por que o sistema foi construído daquela forma.

Como se diagnostica o que se tem antes de decidir o que substituir? Não com uma avaliação de maturidade num slide. Com honestidade genuína e incómoda sobre o que se compreende e o que não se compreende.

Estas não são objeções à era agêntica. São pré-requisitos para sobreviver a ela.