O verdadeiro gargalo dos teus agentes não é o modelo: é a memória que nunca lhes construíste
A McKinsey acabou de te prometer entrega de software 24 horas por dia.
Em "Rewiring software delivery for the agentic era" descrevem um mundo onde o sprint de duas semanas se comprime num sprint diário, os agentes executam de noite enquanto dormes, e as equipas de oito a doze pessoas dão lugar a pequenos pods que supervisionam. Uma promessa bonita, e o diagnóstico de fundo está certo quase sempre. Mas, como quase todas as promessas bonitas de consultora, salta a parte aborrecida: a razão pela qual os teus agentes ainda não fazem o turno da noite não é o modelo que usam. É que nunca lhes construíste uma memória.
Não escrevo isto do lugar do consultor que desenha o operating model, mas do de quem opera a plataforma onde estes agentes aterram. Já fiz DevOps e turnos de piquete às três da manhã que chegue para saber uma coisa: um agente autónomo de noite é exactamente a mesma coisa que um engenheiro de piquete acabado de entrar. Brilhante, incansável e completamente inútil se ninguém deixou por escrito como o sistema funciona de verdade. O modelo dá-lhe um cérebro. O que lhe falta não é cérebro.
O modelo não é o gargalo; o contexto que falta, sim
Pensa no que um agente precisa mesmo para lançar uma alteração contra os teus sistemas sem partir nada. Não precisa de ser mais inteligente. Precisa de saber o que significa «cliente de risco» no teu setor. Precisa de saber qual dos seis passos daquele processo de devolução nunca pode ser saltado. Precisa de saber porque é que aquele serviço foi construído de uma maneira tão estranha — e que foi por causa de um incidente do trimestre passado que acabou com a decisão de nunca fazer retentativas automáticas contra aquele endpoint.
Nada disto vive nos pesos do modelo. Vive na cabeça de três pessoas, num fio de Slack que ninguém vai encontrar, num Confluence parado há um ano, num ticket de Jira fechado e num post-mortem que ninguém releu. O modelo mais potente do planeta, sem esse contexto, é uma contratação no primeiro dia, sem onboarding. Dá-lhe o melhor cérebro do mercado: se não sabe como a tua empresa funciona, vai adivinhar. E um agente que adivinha em produção não é produtividade: é dívida.
As quatro condições da McKinsey são, na verdade, uma só
O artigo enumera quatro condições para os agentes funcionarem: uma visão de negócio clara do que construir, um ambiente técnico padrão com frameworks comuns e arquitetura modular, uma estrutura padrão do requisito ao código para que as entradas sejam previsíveis, e os stakeholders a manterem-se envolvidos em toda a cadeia de valor.
Quatro caixas. Mas olha-as de perto: apontam todas para o mesmo sítio. Não são quatro requisitos independentes; são quatro faces de um único substrato. As quatro tratam de tornar o contexto da tua organização legível e fiável ao ponto de uma máquina poder raciocinar sobre ele. A visão clara é contexto sobre o quê. O ambiente padrão é contexto sobre o como. A estrutura do requisito ao código é contexto num formato que o agente consegue consumir sem interpretar. E os stakeholders envolvidos são a garantia de que esse contexto não se dessincroniza da realidade a meio da semana. A McKinsey vende uma lista de verificação; na trincheira é uma coisa só, e tem nome.
O knowledge graph é a camada de memória da IA
É aqui que o artigo diz a coisa verdadeiramente interessante, e é a que deves levar para casa. As empresas à frente estão a construir knowledge graphs que funcionam como uma camada de memória de IA ao longo de todo o ciclo de vida do software, um por domínio: ligam o feedback dos clientes, os registos de decisões de arquitetura, os documentos de design, os tickets, a atividade no GitHub, os relatórios de incidentes e as regras de conformidade.
A palavra-chave é ligar. Um sistema de RAG sobre um wiki — de que já falei para quem integra LLMs — devolve-te o parágrafo cujas palavras combinam com a pergunta. Útil, mas plano. Uma camada de memória a sério sabe outra coisa: sabe que este incidente despoletou aquele registo de decisão, que restringe este serviço, cujo responsável escreveu aquela regra de conformidade. O valor não está nos nós, está nas arestas. A diferença entre as duas coisas é a diferença entre um agente que te cita o wiki e um que respeita as tuas cicatrizes.
E esta é exatamente a camada que defendi ser o fosso: o modelo torna commodity os 80% fáceis, e a diferenciação muda-se para o sistema que o rodeia. A memória de como a tua empresa funciona de verdade é a parte desse sistema que nenhum fornecedor de modelos te pode vender, porque não a tem.
Já codificámos conhecimento tribal antes, e chamámos-lhe infrastructure as code
Se isto te soa familiar, é porque nós, os que viemos das operações, já fizemos este gesto várias vezes. Cada salto rumo à autonomia, sem exceção, foi o mesmo: pegar em conhecimento que vivia na cabeça de um engenheiro sénior e codificá-lo para que uma máquina pudesse agir sobre ele.
Os runbooks à mão passaram a remediação automática. Os passos de deploy que só um sabia passaram a uma pipeline de CI/CD. O «pergunta à Maria, que é ela que sabe como a produção está montada» passou a infrastructure as code. E eis o detalhe de que toda a gente se esquece: a pipeline não começou a correr sozinha porque as ferramentas ficaram inteligentes. Começou a correr sozinha quando escrevemos o que a Maria sabia. Agentes a lançar software de noite são exatamente essa lição, um andar acima. O agente executa sem supervisão até exatamente ao ponto que o seu contexto permite, e nem um passo mais. O substrato não é magia nova; é conhecimento tribal, finalmente escrito numa forma que uma máquina consegue percorrer.
A entrega 24 horas é o prémio, não o objetivo
É por isso que a cadência diária que a McKinsey vende é real, mas vem depois do substrato, não antes. A execução noturna funciona até onde a memória do agente o deixa avançar sozinho; passada essa linha, ele para e espera por um humano. Por isso a métrica que importa não é «os agentes conseguem correr de noite», mas até onde o agente chega antes de embater numa pergunta a que só uma pessoa pode responder — e cada uma dessas paragens é um bug de contexto na tua camada de memória, não uma falha do modelo.
Aqui tens de me deixar conceder o contra-argumento forte, porque é bom: «os modelos melhoram a cada trimestre, as janelas de contexto crescem — o próximo modelo não vai comer tudo isto?». Em parte, sim. Parte do andaime de hoje será absorvida: modelos melhores precisam menos de que os leves pela mão, e janelas maiores engolem mais documentos de uma vez. Mas uma janela de contexto não é uma memória. Colar o wiki inteiro no prompt não faz com que o modelo saiba qual o passo que nunca se salta; faz com que leia uma pilha de texto talvez contraditório, e adivinhe. Saber exige curadoria, verificação, frescura e resolução de conflitos: decidir qual de duas fontes que se contradizem é a verdade válida hoje. Isto é critério, é um humano que o faz, e é trabalho de engenharia permanente. O modelo é alugado, e idêntico para o concorrente em frente. A memória curada de como a tua empresa funciona de verdade é a parte que ninguém pode alugar.
O que eu faria este trimestre se fosse o teu CTO
Cinco apostas concretas, porque um diagnóstico sem ação é só uma opinião bonita:
- Descobre onde vive de verdade o teu contexto. Antes de comprares qualquer «fábrica de agentes», faz o inventário incómodo: quanto do conhecimento de que um agente precisaria para lançar código vive só em cabeças, em fios de Slack e num wiki desatualizado? Essa resposta é o teu gargalo. Não o modelo.
- Constrói a memória de UM domínio, não da empresa toda. O knowledge graph de todo o ciclo de vida de uma vez é um projeto que morre em comité. Escolhe um domínio com dor real, liga-lhe os registos de decisão, os tickets, os incidentes e as regras de conformidade, e põe um agente a raciocinar sobre isso. Aprende aí antes de escalar.
- Padroniza o caminho do requisito ao código. É a condição da McKinsey que move mesmo o ponteiro. Se cada funcionalidade entra num formato diferente, o agente adivinha; se entra numa estrutura previsível, executa. Entradas reproduzíveis antes de saídas autónomas.
- Integra a conformidade na memória, não no fim. As regras de risco, jurídicas e de segurança têm de ser nós que o agente lê enquanto constrói, não uma porta que alguém abre quando já está tudo feito. Um controlo que vive no grafo melhora a rastreabilidade e a completude; um controlo que vive num PDF é um gargalo com rosto humano.
- Mede a autonomia pela distância que o agente percorre sozinho. Esquece a «percentagem de código escrito por IA». A métrica honesta é quantos passos um agente encadeia antes de precisar de um humano — e tratar cada paragem como um bug de contexto que se corrige no substrato, não como um teto do modelo.
A linha que defendo é a de sempre, e aqui a IA ilustra-a da forma mais literal que alguma vez vi: não substitui o engenheiro, alavanca-o. Alguém tem de decidir qual de duas fontes contraditórias é a verdade, qual o passo que nunca se salta, quando um conhecimento expirou. Esse trabalho — construir e manter a memória de como a tua empresa funciona de verdade — não é o modelo que o faz. É um engenheiro com critério. E quanto mais autónomos queres os teus agentes, mais precisas deles, não menos.
A McKinsey vende o destino: agentes a lançar software enquanto dormes. Tem razão em que é possível. O que o slide te poupa é que o motor barato e intercambiável nunca foi o problema. O problema, como sempre, é o carro todo à volta — e desta vez a peça mais difícil de construir chama-se memória.
Estás a tentar levar os teus agentes da demo à produção e o que se dessincroniza é o contexto, não o modelo? Fala com um CTO sobre montar o squad nearshore que te constrói a camada de memória, não só o que liga o agente.
