Do copiloto à fábrica de software: a arquitetura que vai definir a era dos agentes de IA
Por que o modelo deixou de ser a arquitetura e como contexto, ferramentas, segurança, evals e governança formam a plataforma operacional dos agentes de IA.
Sua empresa comprou licenças de copilotos. Os desenvolvedores geram código mais rápido. A primeira demonstração de um agente impressionou a liderança.
Então alguém fez a pergunta que separa uma demonstração de uma capacidade empresarial:
Como colocamos isso em produção sem multiplicar risco, custo e complexidade?
O agente precisa entender o contexto da empresa, encontrar as ferramentas certas, operar com credenciais limitadas, executar em um ambiente controlado, recuperar-se de falhas, registrar suas ações e provar que o resultado ficou melhor — não apenas diferente.
Nesse momento, o problema deixa de ser “qual modelo responde melhor?” e passa a ser “qual sistema permite que modelos trabalhem de forma confiável?”.
Essa é a mudança que está acontecendo agora. O mercado está saindo da fase de colocar IA no IDE e entrando na fase de construir uma plataforma operacional para agentes.
Minha tese é simples:
O modelo deixou de ser a arquitetura. A vantagem está migrando para o sistema construído ao redor dele.
1. Como chegamos até aqui
Não foi uma virada instantânea. Foi uma progressão de abstrações.
| Fase | Experiência dominante | O humano fazia | A IA fazia |
|---|---|---|---|
| 2023 | Chat | formulava perguntas | produzia respostas |
| 2024 | Copiloto | escrevia e revisava código | sugeria trechos |
| 2025 | Coding agent | definia tarefas | alterava arquivos, testava e abria PRs |
| 2026 | Agent platform | define intenção, limites e métricas | executa fluxos completos dentro de uma plataforma |
Essa linha do tempo é uma simplificação. As fases coexistem e amadurecem em velocidades diferentes. Mas ela revela uma mudança importante: a unidade de valor deixou de ser a resposta e passou a ser o trabalho concluído.
Um chatbot pode explicar como corrigir um bug. Um coding agent pode corrigir o bug. Uma plataforma de agentes precisa permitir que ele reproduza a falha, encontre o contexto, altere o sistema, execute testes, observe métricas, peça aprovação quando necessário e deixe uma trilha auditável.
O salto não é apenas de inteligência. É de responsabilidade operacional.
Dados de 2026 mostram que empresas maiores avançaram mais rapidamente da experimentação para a escala: segundo a pesquisa global da McKinsey, a parcela das grandes organizações que escalou agentes em pelo menos uma função passou de 27% para 40%, enquanto organizações menores permaneceram em 22%.
O ponto relevante não é a corrida pelo número. É a pergunta:
O que as empresas precisam construir entre o protótipo e a escala?
2. O modelo é o cérebro. O harness é o corpo.
Imagine contratar a pessoa mais inteligente do mundo e colocá-la em uma sala vazia.
Ela não conhece seu negócio. Não possui documentos, sistemas, credenciais ou ferramentas. Não sabe quais decisões exigem aprovação. Não consegue observar o resultado do próprio trabalho.
Inteligência sem ambiente produz potencial, não operação.
Um agente funciona da mesma forma. O modelo raciocina, mas precisa de uma estrutura que transforme intenção em execução. Essa estrutura costuma ser chamada de agent harness.
A analogia cérebro-corpo ajuda a começar:
- o modelo interpreta, planeja e decide;
- o harness fornece contexto, memória, ferramentas, execução e feedback.
Mas a analogia começa a quebrar aqui: em sistemas reais, não existe um único “corpo”. Há componentes independentes, políticas transversais e, muitas vezes, vários modelos e agentes cooperando.
Uma definição mais precisa é:
Agent harness é a camada de software que organiza o ciclo de execução de um agente, conecta modelos a contexto e ferramentas, preserva estado, impõe limites e coleta feedback operacional.
A própria AWS passou a descrever essa camada como responsável por orquestração, execução de ferramentas, janela de contexto, persistência de estado, recuperação de falhas e isolamento de sessões no AgentCore harness.
Modelo mental da plataforma
INTENÇÃO E ESPECIFICAÇÃO
│
▼
ORQUESTRAÇÃO DO AGENTE
plano · estado · memória
│
┌─────────────┼─────────────┐
▼ ▼ ▼
CONTEXTO MODELOS FERRAMENTAS
dados · regras roteamento MCP · APIs
│ │ │
└─────────────┼─────────────┘
▼
EXECUÇÃO CONTROLADA
sandbox · identidade · políticas
│
▼
FEEDBACK E CONTROLE
evals · logs · métricas · auditoria
Se retirar o modelo, não há raciocínio. Se retirar o restante, não há sistema confiável.
3. Pare antes de continuar
Considere este cenário:
Um agente recebe a tarefa “corrija a queda de conversão no checkout”. Ele encontra uma mudança aparentemente segura, altera o código, executa os testes existentes e publica a correção.
Os testes passam. A conversão piora.
O que faltou?
Provavelmente não foi capacidade de escrever código. Pode ter faltado:
- uma especificação mensurável do resultado esperado;
- acesso ao contexto de produto;
- um ambiente isolado com dados representativos;
- testes que cubram o comportamento real;
- comparação de métricas antes e depois;
- uma política que exija aprovação para publicar;
- capacidade de rollback.
Esse caso revela o novo gargalo: agentes tornam a execução barata, mas aumentam o valor de especificação, contexto e feedback.
4. A batalha muda do melhor modelo para o melhor sistema
Modelos continuarão importantes. Haverá diferenças de raciocínio, latência, custo, contexto e especialização.
Mas tratá-los como a arquitetura inteira cria três problemas.
Primeiro, modelos evoluem rapidamente. Uma aplicação fortemente acoplada a um único fornecedor transforma avanço tecnológico em projeto de migração.
Segundo, nenhuma escolha vence em todas as tarefas. O modelo adequado para planejamento pode não ser o melhor para execução de código, visão, latência baixa ou custo previsível.
Terceiro, o comportamento em produção depende do conjunto. Um modelo excelente com contexto ruim, ferramenta perigosa e avaliação fraca continua sendo um sistema ruim.
O objetivo não é fingir que todos os modelos são iguais. É impedir que a arquitetura dependa de uma igualdade que não existe.
Uma plataforma madura separa:
- capacidade cognitiva: qual modelo usar para cada tarefa;
- capacidade operacional: como contexto, ferramentas e execução são fornecidos;
- controle: como políticas, identidade, observabilidade e avaliação são aplicadas.
Esse desacoplamento permite trocar ou combinar modelos sem reconstruir todo o sistema ao redor deles.
5. Estamos construindo um “Kubernetes dos agentes”?
A comparação aparece porque a história parece familiar.
Containers padronizaram a unidade de execução, mas não resolveram sozinhos descoberta, escalabilidade, recuperação, configuração, rede e políticas. Kubernetes ganhou espaço ao organizar essas necessidades em uma camada de controle.
Com agentes, observamos algo parecido:
| Containers | Agentes |
|---|---|
| imagem e processo | modelo, instruções e habilidades |
| scheduler | roteador e orquestrador |
| service discovery | descoberta de agentes e ferramentas |
| configuração e secrets | contexto, identidade e credenciais |
| health checks | evals, métricas e verificação de resultado |
| namespaces e políticas | isolamento, escopo e governança |
A analogia é útil porque destaca a necessidade de um control plane.
Mas ela também tem limite. Containers executam software majoritariamente determinístico. Agentes interpretam contexto, geram planos e escolhem ações de maneira probabilística. A plataforma precisa governar não apenas recursos computacionais, mas também intenção, evidência e comportamento.
Portanto, não estamos simplesmente esperando “um Kubernetes para agentes”. Estamos construindo uma categoria mais ampla: plataformas de execução, coordenação e governança para trabalho probabilístico.
6. Os vendors já convergem para a mesma categoria
Quando fornecedores diferentes começam a resolver o mesmo conjunto de problemas, vale prestar atenção na categoria que está nascendo.
A AWS combina harness gerenciado, isolamento, memória, identidade, gateway e observabilidade no AgentCore. O harness é desacoplado do modelo e pode exportar a orquestração para código quando o caso exige customização.
O Google Cloud posiciona o Gemini Enterprise Agent Platform como lugar central para construir, escalar, governar e otimizar frotas de agentes. A proposta inclui runtime, memória, identidade, gateway, simulação, observabilidade e suporte a MCP e A2A.
A OpenAI apresenta o Frontier como uma plataforma empresarial para operar agentes conectados a sistemas de registro, com identidade própria, acesso limitado, observabilidade e governança.
As implementações e os níveis de abertura são diferentes. A convergência conceitual, porém, é clara:
modelo
+ contexto
+ ferramentas
+ execução
+ identidade
+ segurança
+ observabilidade
+ avaliação
= plataforma de agentes
Não escolha um fornecedor pela quantidade de caixas no diagrama. Pergunte:
- Consigo trocar modelos e componentes sem refazer o produto?
- Como identidade e autorização são aplicadas em cada ação?
- O que é observável e auditável?
- Como testo o agente antes e depois de uma mudança?
- Onde o agente executa e qual é seu limite de dano?
- Qual parte da arquitetura fica presa ao fornecedor?
7. Agent-first SDLC: quando escrever código deixa de ser o gargalo
Em uma experiência publicada pela OpenAI, uma equipe construiu um produto com aproximadamente um milhão de linhas, cerca de 1.500 pull requests e nenhuma linha escrita manualmente. A estimativa foi de um décimo do tempo de desenvolvimento manual.
Esse resultado não deve ser tratado como benchmark universal. Foi um experimento realizado em um ambiente preparado para agentes, com investimento em documentação, isolamento, ferramentas, observabilidade e regras arquiteturais.
E esse é justamente o aprendizado.
O ganho não veio apenas de um modelo gerando código. Veio de tornar o sistema legível e operável pelo agente.
Quando a geração de código acelera, outros gargalos ficam visíveis:
- O que exatamente precisa ser construído?
- Como o agente encontrará a fonte correta de verdade?
- Como saberemos que o resultado está certo?
- Quais limites arquiteturais não podem ser violados?
- Quem assume a decisão quando existe ambiguidade?
O papel do engenheiro sobe de abstração. Menos tempo digitando cada implementação; mais tempo desenhando ambientes, contratos, limites e loops de feedback.
Isso não elimina engenharia. Torna engenharia disciplinada ainda mais valiosa.
8. Context Engineering supera Prompt Engineering
Um prompt melhor pode corrigir uma interação. Um contexto melhor melhora uma classe inteira de interações.
Context Engineering é o trabalho de decidir:
- quais informações o agente recebe;
- quando elas entram na janela de contexto;
- qual fonte possui autoridade;
- como o conhecimento é atualizado;
- como relevância e permissões são preservadas;
- como o agente descobre detalhes sem carregar tudo de uma vez.
Há um trade-off importante. Contexto insuficiente produz decisões cegas. Contexto excessivo ocupa a janela, aumenta custo e torna o sinal difícil de encontrar.
A imagem mental correta não é uma enciclopédia entregue de uma vez. É um mapa com rotas progressivas.
Na experiência de harness engineering, uma instrução monolítica falhou. A equipe passou a usar um arquivo curto como índice para uma base versionada de arquitetura, planos, especificações e padrões. O agente começa pequeno e aprofunda apenas o que a tarefa exige.
Para uma empresa, isso significa transformar conhecimento disperso em ativos legíveis por humanos e agentes: documentação versionada, contratos, catálogos de dados, decisões arquiteturais e regras verificáveis.
9. MCP embaixo, A2A em cima
Se cada agente precisar de uma integração exclusiva para cada ferramenta, a arquitetura não escala.
O Model Context Protocol (MCP) padroniza como aplicações de IA descobrem e utilizam dados, recursos e ferramentas. Ele não substitui autenticação, autorização ou segurança, mas reduz o acoplamento entre o raciocínio e as integrações. Para uma introdução mais detalhada, veja nosso artigo MCP: a ponte entre a IA e o mundo real.
Em 2026, a Anthropic doou o MCP à Linux Foundation, sob a Agentic AI Foundation, reforçando a direção de um padrão aberto e neutro.
O Agent2Agent Protocol (A2A) trabalha em outro nível: descoberta, comunicação e coordenação entre agentes. A Linux Foundation informou que o protocolo superou 150 organizações apoiadoras no primeiro ano.
O modelo mental é:
MCP: agente ↔ ferramentas, dados e recursos
A2A: agente ↔ agente
MCP não elimina APIs. A2A não elimina orquestração. Protocolos reduzem integrações exclusivas, mas a empresa ainda precisa decidir identidade, políticas, semântica e responsabilidade.
10. Segurança: controle o blast radius, não apenas a intenção
Um chatbot que responde errado pode confundir alguém. Um agente com acesso a produção pode apagar dados, alterar configurações ou expor informações.
O risco possui duas dimensões:
RISCO = probabilidade de falha × impacto possível
Melhorar o modelo e adicionar filtros reduz a probabilidade. Limitar credenciais, rede, arquivos e ferramentas reduz o impacto possível — o blast radius.
Esse segundo componente precisa ser arquitetural.
A Anthropic descreve três superfícies de defesa em sua experiência de contenção de agentes: o modelo, o ambiente de execução e o conteúdo externo acessado. A empresa também relata que aprovações humanas constantes criaram fadiga, reforçando a necessidade de limites técnicos persistentes.
Uma arquitetura segura combina:
- identidade própria para cada agente;
- credenciais temporárias e com menor privilégio;
- políticas avaliadas a cada ação;
- sandbox, container ou máquina virtual conforme o risco;
- controle de filesystem e saída de rede;
- aprovação humana em decisões sensíveis, não em cada clique;
- logs imutáveis e trilha de auditoria;
- rollback e limites de custo.
O objetivo não é dar acesso total e torcer para o agente se comportar. É tornar ações indesejadas tecnicamente difíceis ou impossíveis.
11. Evals são os testes automatizados dos agentes
Software tradicional possui uma expectativa relativamente estável: a mesma entrada, sob as mesmas condições, tende a produzir a mesma saída.
Agentes são probabilísticos. Uma alteração de modelo, prompt, contexto ou ferramenta pode melhorar um caso e piorar outro.
Sem evals, a equipe descobre regressões em produção ou por impressão subjetiva.
Uma avaliação útil começa com três perguntas:
- Qual comportamento queremos medir?
- Que evidência demonstra sucesso ou falha?
- Qual mudança é significativa o suficiente para bloquear uma versão?
Um conjunto maduro combina:
- resultado: a tarefa foi concluída corretamente?
- trajetória: o agente usou ferramentas e dados permitidos?
- segurança: houve tentativa de ação proibida ou vazamento?
- eficiência: custo, latência e quantidade de passos ficaram aceitáveis?
- robustez: pequenas variações de entrada preservam o comportamento?
Evals não provam que um agente nunca falhará. Assim como testes automatizados, elas reduzem incerteza, detectam regressões e tornam mudanças comparáveis.
O erro comum é avaliar apenas a resposta final. Um agente pode chegar à resposta correta usando uma fonte errada, uma credencial excessiva ou um caminho caro. Em produção, como ele chegou importa tanto quanto o resultado.
12. Da automação isolada à AI Software Factory
Quando agentes participam de especificação, implementação, teste, revisão, segurança, documentação, deploy e operação, já não estamos falando de uma ferramenta no IDE.
Estamos falando de uma AI Software Factory: um sistema em que humanos definem intenção e julgamento, enquanto agentes executam parcelas crescentes do ciclo de entrega dentro de limites verificáveis.
O fluxo deixa de ser:
humano escreve → ferramenta sugere → humano conclui
e se aproxima de:
humano especifica
↓
agentes planejam, implementam, testam e revisam
↓
plataforma verifica políticas, evidências e métricas
↓
humano decide onde julgamento é necessário
Build ou buy?
Agentes de código também reduzem o custo de construir componentes internos. Isso torna “build” competitivo em situações nas quais a empresa antes compraria uma ferramenta genérica.
Mas código barato não significa operação barata.
| Construir | Comprar |
|---|---|
| maior adaptação ao domínio | implantação inicial mais rápida |
| controle de arquitetura e dados | operação parcialmente transferida |
| possibilidade de reduzir lock-in | padrões e integrações prontas |
| exige segurança, suporte e evolução próprios | exige aceitar limites e dependências do fornecedor |
Escolha construir quando o fluxo representa diferenciação, o domínio exige controle e existe capacidade operacional para manter a solução. Compre quando a função é commodity, o tempo importa mais que a diferenciação e o fornecedor entrega uma base madura de governança.
Na prática, a arquitetura mais saudável tende a ser híbrida: comprar fundações úteis, manter interfaces abertas e construir o que carrega vantagem específica do negócio.
13. A escada de maturidade
Antes de anunciar uma “empresa agentic”, descubra em qual degrau você está.
| Nível | Capacidade | Pergunta para avançar |
|---|---|---|
| L0 | ChatGPT individual | Como proteger dados e criar política de uso? |
| L1 | Copilotos | Como medir adoção e resultado? |
| L2 | Coding agents | Como fornecer contexto e feedback confiáveis? |
| L3 | Agentes + MCP | Como padronizar ferramentas, identidade e permissões? |
| L4 | Enterprise harness | Como operar agentes com evals, isolamento e observabilidade? |
| L5 | AI Software Factory | Como redesenhar o SDLC para humanos e agentes? |
| L6 | Agentic enterprise | Como governar múltiplos fluxos e agentes entre áreas? |
Pular degraus costuma produzir um protótipo sofisticado apoiado sobre processos frágeis.
A lacuna é visível nos dados. Em uma pesquisa com mais de 500 líderes empresariais e de tecnologia nos Estados Unidos, a Deloitte encontrou 52% preparados em visão e estratégia, mas apenas 21% preparados em processos de negócio.
Estratégia sem processo produz apresentações. Autonomia exige fundações.
A arquitetura que eu recomendaria
Eu começaria por uma Enterprise AI Execution Platform pequena, evolutiva e orientada a protocolos.
Seus princípios seriam:
- Model-agnostic: modelos são componentes roteáveis, não a fundação inteira.
- Protocol-first: ferramentas e agentes usam interfaces abertas sempre que fizer sentido.
- Context-first: conhecimento confiável, versionado e progressivamente descoberto.
- Evaluation-first: toda automação relevante nasce com critérios de sucesso.
- Secure execution: identidade, menor privilégio, isolamento e auditoria por padrão.
- Observable by design: custo, latência, trajetória e resultado são visíveis.
- Human judgment at the right layer: pessoas decidem intenção, exceções e risco; não aprovam mecanicamente cada passo.
Comece por um fluxo de alto valor e fronteira clara. Mapeie o processo de ponta a ponta. Defina a métrica. Identifique dados e ferramentas. Limite o blast radius. Construa evals. Só depois aumente a autonomia.
A McKinsey chega a recomendação semelhante para a base de dados: selecionar fluxos de alto impacto, modernizar a arquitetura de forma evolutiva e criar uma camada controlada de execução que aplique regras empresariais.
Se você lembrar apenas disso
- Agentes deslocam o valor da geração de respostas para a conclusão de trabalho.
- O modelo raciocina; o harness fornece contexto, ferramentas, execução e feedback.
- O novo gargalo é especificação, contexto, avaliação e governança.
- MCP conecta agentes a ferramentas; A2A conecta agentes a agentes.
- Segurança exige limitar o impacto possível, não apenas confiar na boa intenção.
- Evals transformam comportamento probabilístico em algo comparável e operável.
- A vantagem não está em parecer agentic. Está em construir uma plataforma que produza resultado com controle.
Teste seu entendimento
Sem voltar ao texto, tente responder:
- Por que trocar o modelo não resolve um problema de contexto ruim?
- Qual é a diferença operacional entre MCP e A2A?
- O que você mediria para detectar que um agente “acertou pelo caminho errado”?
- Quando aprovação humana por ação pode aumentar, em vez de reduzir, o risco?
- Qual capacidade separa um coding agent de uma AI Software Factory?
Desafio de transferência
Escolha um processo real da sua empresa — atendimento, cobrança, compras, engenharia ou operações.
Desenhe uma primeira versão da plataforma respondendo:
- Qual resultado o agente deve produzir?
- De qual contexto ele precisa?
- Quais ferramentas pode usar?
- Que identidade e permissões terá?
- Onde executará?
- Como será avaliado?
- Qual ação exige aprovação?
- Como você limita e recupera uma falha?
Se essas respostas ainda não existem, o problema não é falta de um modelo mais inteligente. É falta da arquitetura que transforma inteligência em operação.
Sobre a Nexify
A Nexify constrói produtos e plataformas de inteligência artificial conectados ao negócio, com engenharia, segurança e foco em resultados operacionais. Sem hype: contexto, arquitetura e execução.
Fale com a Nexify
Quer aplicar IA conectada ao seu negócio?
Agende um diagnóstico com nosso time de engenharia.