--- title: "Do copiloto à fábrica de software: a arquitetura que vai definir a era dos agentes de IA" slug: "do-copiloto-a-fabrica-de-software" meta_description: "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." cover_image: "/assets/blog/do-copiloto-a-fabrica-de-software.png" published_at: "2026-08-31" tags: - Inteligência Artificial - Agentes de IA - Arquitetura - Engenharia de Software author: name: "Marcelo Bueno" role: "Founder, Nexify" avatar: "/assets/founders/marcelo.png" --- # Do copiloto à fábrica de software: a arquitetura que vai definir a era 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.** ![O modelo de IA cercado pelas camadas de contexto, ferramentas, segurança e avaliação que formam a arquitetura](/assets/blog/campanha-agentes/post-01-modelo-nao-e-arquitetura.png) ## 1. Como chegamos até aqui ![Linha do tempo de 2023 a 2026: chat, copiloto, coding agent e plataforma de agentes](/assets/blog/campanha-agentes/post-02-evolucao-2023-2026.png) 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](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), 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. ![Modelo como cérebro conectado ao harness modular de contexto, memória, ferramentas, sandbox e feedback](/assets/blog/campanha-agentes/post-03-harness.png) 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](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-harness-generally-available/). ### Modelo mental da plataforma ```text 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 ![Comparação entre um ótimo modelo em uma base fraca e um modelo apoiado por contexto, segurança e evals](/assets/blog/campanha-agentes/post-04-melhor-sistema.png) 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”? ![Control plane de agentes com orquestração, identidade, políticas e avaliações](/assets/blog/campanha-agentes/post-05-kubernetes-agentes.png) 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 ![Diferentes vendors convergindo para uma arquitetura comum de plataforma de agentes](/assets/blog/campanha-agentes/post-06-vendors.png) Quando fornecedores diferentes começam a resolver o mesmo conjunto de problemas, vale prestar atenção na categoria que está nascendo. A [AWS](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-harness-generally-available/) 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](https://cloud.google.com/blog/products/ai-machine-learning/the-new-gemini-enterprise-one-platform-for-agent-development) 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](https://openai.com/business/frontier/) 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: ```text 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 ![Código acelerado enquanto especificação, contexto e feedback se tornam os novos gargalos](/assets/blog/campanha-agentes/post-07-agent-first-sdlc.png) 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](https://openai.com/index/harness-engineering/). 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: 1. O que exatamente precisa ser construído? 2. Como o agente encontrará a fonte correta de verdade? 3. Como saberemos que o resultado está certo? 4. Quais limites arquiteturais não podem ser violados? 5. 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 ![Comparação entre entregar uma enciclopédia ao agente e fornecer um mapa progressivo do contexto](/assets/blog/campanha-agentes/post-08-context-engineering.png) 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 ![MCP conectando agentes a ferramentas e dados, e A2A conectando agentes entre si](/assets/blog/campanha-agentes/post-09-mcp-a2a.png) 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](/blog/mcp-ponte-entre-ia-e-mundo-real/). Em 2026, a Anthropic [doou o MCP à Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-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](https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year) no primeiro ano. O modelo mental é: ```text 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 ![Camadas de contenção de risco: identidade, menor privilégio, sandbox, políticas e auditoria](/assets/blog/campanha-agentes/post-10-seguranca.png) 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: ```text 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](https://www.anthropic.com/engineering/how-we-contain-claude): 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 ![Avaliação do resultado e da trajetória seguida pelo agente](/assets/blog/campanha-agentes/post-11-evals.png) 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: 1. Qual comportamento queremos medir? 2. Que evidência demonstra sucesso ou falha? 3. 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 ![Comparação build versus buy mostrando que código barato não elimina custos de operação](/assets/blog/campanha-agentes/post-12-software-factory.png) 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: ```text humano escreve → ferramenta sugere → humano conclui ``` e se aproxima de: ```text 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 ![Escada de maturidade de L0 Chat a L6 Agentic Enterprise](/assets/blog/campanha-agentes/post-13-maturidade.png) 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](https://www.deloitte.com/us/en/about/press-room/deloitte-survey-examines-ai-readiness-agentic-ai-success.html). 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: 1. **Model-agnostic:** modelos são componentes roteáveis, não a fundação inteira. 2. **Protocol-first:** ferramentas e agentes usam interfaces abertas sempre que fizer sentido. 3. **Context-first:** conhecimento confiável, versionado e progressivamente descoberto. 4. **Evaluation-first:** toda automação relevante nasce com critérios de sucesso. 5. **Secure execution:** identidade, menor privilégio, isolamento e auditoria por padrão. 6. **Observable by design:** custo, latência, trajetória e resultado são visíveis. 7. **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](https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/building-the-foundations-for-agentic-ai-at-scale) 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: 1. Por que trocar o modelo não resolve um problema de contexto ruim? 2. Qual é a diferença operacional entre MCP e A2A? 3. O que você mediria para detectar que um agente “acertou pelo caminho errado”? 4. Quando aprovação humana por ação pode aumentar, em vez de reduzir, o risco? 5. 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.