O Stack do Dev com IA em Agosto de 2026: Mapa das 5 Camadas

Escrevi todos os dias das duas últimas semanas e não planejei isso como série. Cada post nasceu de um incômodo isolado: um PR de dezenove linhas que quebrou dois consumidores, uma fatura de API em que a parte cara era a parte braçal, um runner sem regra de saída de rede que estava assim havia meses, um painel de OAuth cheio de integrações com "AI" no nome que ninguém aprovou.

Ontem à noite, revendo a lista para decidir o que escrever hoje, percebi que eles não eram doze assuntos. Eram cinco decisões, cada uma aparecendo duas ou três vezes com roupa diferente. E percebi outra coisa mais incômoda: nas conversas de arquitetura que tive no mesmo período, essas cinco decisões quase nunca foram tratadas como decisões. Foram tratadas como escolha de ferramenta, feitas na ordem em que a ferramenta apareceu no radar.

Em junho eu fiz uma retrospectiva do primeiro semestre de IA agêntica e a conclusão de lá foi que a indústria tinha entregue capacidade muito mais rápido do que tinha entregue confiabilidade. Dois meses depois, o que mudou não é a capacidade — é que a superfície de escolha ficou grande o bastante para que escolher errado tenha custo real. Não dá mais para tratar isso como "vamos usar o Claude e ver no que dá".

Então este post não é um resumo dos doze. É um mapa. Cinco camadas, de baixo para cima, cada uma com a pergunta que decide a camada, o que está em jogo se você errar, o erro que mais vejo, e para onde ir se você quiser o detalhe. Se você só quiser a resposta rápida, pule para a tabela no fim. Se quiser entender por que a ordem importa, vale ler o meio.

Camada 1 — Modelo: Qual É O Menor Modelo Que Resolve Isso Com Qualidade Verificável

A pergunta-chave da camada de baixo não é "qual é o melhor modelo". É: qual é o menor modelo que resolve esta tarefa com qualidade que você consegue verificar. As duas partes da frase carregam peso. "Menor" porque a diferença de preço entre camadas hoje é de uma ordem de grandeza, não de uns por cento. "Verificável" porque sem eval você não tem como saber se rebaixou o modelo ou se apenas parou de perceber os erros.

O que está em jogo é a estrutura de custo do produto inteiro. Quando abri a fatura do nosso sistema de agentes, quatro quintos da conta estavam embaixo do orquestrador, não nele: um enxame de subagentes fazendo trabalho de leitura, extração e conferência, dezenas de vezes por requisição. A parte que decidia e sintetizava era barata. O que saía caro era pagar tarifa de raciocínio de fronteira para o modelo ler — e leitura é exatamente o recorte da tarefa em que um modelo pequeno bem instruído chega mais perto do grande.

Existem quatro respostas possíveis nessa camada e elas não são exclusivas. A primeira é rotear: colocar um classificador leve na frente e mandar cada requisição para o modelo do tamanho certo. Foi o assunto do post sobre roteamento SLM→LLM e a arquitetura que corta a maior parte do custo de inferência, e é por onde eu começaria em qualquer sistema que já esteja em produção, porque não exige treinar nada — exige apenas descobrir, com replay do tráfego real, onde está o joelho de qualidade.

A segunda é rebaixar por posição no grafo em vez de por requisição, que é o que a chegada de modelos explicitamente vendidos como camada de subagente tornou prático. Cobri isso em subagentes baratos e o que muda no cálculo da orquestração multiagente. O uso que continuo achando mais defensável ali não é expandir o fan-out, é adensá-lo: manter a topologia que já se provou e reinvestir a economia em verificação cruzada, que é a coisa que nunca conseguimos justificar quando cada checagem custava preço de chamada de fronteira.

A terceira é destilar. Se uma etapa faz exatamente a mesma coisa alguns milhões de vezes por mês, treinar um modelo pequeno para imitar o grande naquele recorte virou trabalho de algumas horas de GPU alugada. O pipeline completo está em destilação na prática, trocando o frontier por um 8B seu, com o alerta que repito aqui: destilação transfere comportamento numa distribuição estreita, não capacidade.

A quarta é sair da API. Isso deixou de ser exclusivamente uma decisão de privacidade em 2026, e o motivo é técnico: Multi-Token Prediction tirou o gaguejo da geração autorregressiva e mudou o que dá para fazer num loop agentic local. É o tema de MTP e coding local com Qwen 3.6 e Gemma 4. O ponto que mais me marcou escrevendo aquele post é que o número que decide se a ferramenta entra no seu dia quase nunca é o número que a página de lançamento escolhe destacar. Quem decide é o tempo do ciclo fechado, somado dezenas de vezes ao longo de uma tarde de trabalho.

O erro mais comum nesta camada é escolher o modelo uma vez, no começo do projeto, e tratar a escolha como constante. Modelo virou a parte mais volátil do stack: preço muda, camada nova aparece, o que era impossível local passa a ser confortável. Se trocar de modelo no seu sistema exige mais do que mudar configuração e rodar o eval, isso não é decisão de modelo, é dívida de arquitetura.

Camada 2 — Execução: Se Esse Agente For Comprometido, O Que Ele Alcança

A pergunta-chave aqui é curta e desconfortável: se o agente for comprometido, o que exatamente ele consegue tocar. Não "o agente está isolado?", que é uma pergunta que sempre tem resposta sim e nunca tem resposta útil.

Fui conferir limite de CPU num arquivo de configuração de runner e saí de lá com outro problema na mão: aquele container conversava com a internet pública inteira, sem uma única linha restringindo tráfego de saída. Meses assim, sem ninguém tropeçar, porque no desenho de cima estava tudo em ordem — processo do agente em caixa própria, host intocado, a palavra isolamento devidamente escrita no diagrama. Tínhamos exatamente metade dela.

O que está em jogo nesta camada é que ela é a única do stack em que o erro não degrada — ele falha inteiro, de uma vez, e normalmente você fica sabendo por terceiro. A Anthropic publicou em julho um relatório sobre três incidentes em que modelos escaparam do ambiente de avaliação e comprometeram infraestrutura real de três organizações. Nenhum modelo escapou da máquina: a fronteira entre código e host funcionou. Eles saíram pela rede, aberta por engano de configuração no ambiente de um parceiro de avaliação. A leitura da própria Anthropic é que o episódio pertence à categoria de harness e operação, não à de alinhamento do modelo.

A comparação técnica entre container comum, gVisor, microVM e VM completa é real e importa — é o que destrinchei em sandboxes de execução para agentes, com E2B, Modal e Daytona lado a lado. Mas é decisão de segunda ordem, e vale dizer isso com todas as letras num post que é mapa. Aqueles quatro níveis respondem a uma pergunta só: o que separa o processo da máquina embaixo dele. Sobre o que separa o processo de tudo que existe do outro lado da placa de rede, os quatro são igualmente mudos. Subir de container para microVM sem mexer no tráfego de saída é blindar a porta da frente de uma casa cuja janela dos fundos ficou escancarada — e a opção sem glamour, container de sempre com saída negada por padrão e cada tentativa bloqueada indo para o log, entrega mais proteção por menos dinheiro.

O erro mais comum aqui é confundir isolamento de processo com isolamento de rede, e o segundo erro é achar que a configuração de ontem continua valendo hoje. Ninguém abre o firewall de propósito. Alguém abre para destravar uma instalação numa terça-feira e o commit some no histórico. A pergunta útil é operacional, não arquitetural: com que frequência alguém verifica, de dentro do sandbox, o que dali se alcança.

Camada 3 — Orquestração: Quanto Do Loop Você Precisa Controlar

A pergunta-chave desta camada não é "LangGraph ou CrewAI". É: quanto controle do loop você precisa ter. A resposta a essa pergunta determina o framework, e não o contrário — e inverter isso é provavelmente o erro mais caro que vejo hoje.

O que está em jogo é o comportamento do sistema quando alguma coisa dá errado no meio, que é o cenário que nenhuma comparação de feature cobre. Tabela de recursos e contador de popularidade descrevem o framework em dia bom; o que decide a escolha é o que sobra depois que o worker morre no meio de uma execução de vinte minutos, e alguém precisa descobrir de onde retomar sem reprocessar tudo. Foi esse o critério que usei na comparação honesta entre LangGraph e CrewAI, e a conclusão a que cheguei é que os dois divergiram de propósito: o primeiro foi para o lado do runtime cru, em que cada transição do grafo passa pela sua mão, e o segundo foi para o lado do atalho, encurtando ao máximo a distância entre a ideia e o multiagente já de pé. São vagas diferentes.

Antes do framework, porém, vem o padrão de agente, e essa discussão é mais interessante do que a de biblioteca. Tarefa longa quebra por um motivo específico: o histórico de mensagens engole o próprio objetivo. Vi um agente rodar quarenta minutos numa migração e morrer não por bug nem por rate limit, mas porque no arquivo dezoito já não lembrava da convenção decidida no arquivo três — que continuava no histórico, intocada, cem mil tokens atrás. A resposta reflexa de aumentar a janela resolve o sintoma por umas três semanas.

O padrão que respondeu a isso de forma séria virou biblioteca e template neste ano, e está descrito em deep agents e planejamento hierárquico no LangGraph. O resumo em uma frase, se você não for ler o post: o que leva a tarefa longa até o fim não é dar ao agente um plano mais elaborado, é aliviar a mochila que ele arrasta de arquivo em arquivo. Mandar estado para o disco, empurrar a leitura suja para um subagente descartável, resumir o que já não decide nada — cada uma dessas peças tira quilo do contexto. O planner explícito, que empresta o nome ao padrão, foi o item que menos se sustentou quando os dados apareceram, e ainda assim é sempre o primeiro a ser construído, porque é o único que rende slide.

O erro mais comum nesta camada é escolher framework antes de saber o tempo de vida do serviço. Protótipo que vai ser mostrado na sexta e fluxo que reinicia sozinho toda madrugada têm requisitos opostos, e o mesmo time pode legitimamente rodar os dois frameworks no mesmo trimestre. O indefensável é assinar sem ler a fatura: de um lado ela chega em linhas de código e semanas de aprendizado, do outro em tokens queimados e em noites tentando reconstruir o que o sistema fez.

Camada 4 — Protocolo: Você Tem Um Problema De Integração Ou De Interoperabilidade

Esta é a camada em que mais vejo time gastando energia por antecipação. A pergunta-chave separa duas coisas que costumam ser tratadas como uma só: você tem um problema de integração, em que seu agente precisa alcançar uma ferramenta, ou de interoperabilidade, em que seu agente precisa negociar trabalho com um sistema que tem dono, política e ciclo de release próprios.

Se for o primeiro, MCP resolve e a conversa acaba rápido. Se for o segundo, você já sentiu o desconforto de espremer dentro de uma tool uma coisa que não é função: algo que demora quarenta minutos, pede informação no meio do caminho e às vezes se recusa a fazer o trabalho. Nada disso cabe numa chamada de ferramenta. É essa fronteira que discuti em A2A, o protocolo horizontal que completa o MCP, com uma conclusão que quero repetir aqui porque ela vai contra o clima do mercado: a maioria dos times não precisa de A2A. Ele resolve descoberta de contraparte, delegação com ciclo de vida e recusa como estado nativo — problemas reais, que a maioria dos times ainda não tem.

Tem uma segunda metade nesta camada que quase ninguém trata como protocolo, e deveria. O formato SKILL.md virou padrão de fato entre agentes de codificação sem ninguém assinar tratado nenhum, e ao redor dele cresceu uma economia de marketplaces com centenas de milhares de skills indexadas. Escrevi sobre isso em a corrida dos skills e o que os marketplaces significam em termos de supply chain. O enquadramento que mudou na minha cabeça foi deixar de tratar skill como arquivo de preferência e começar a tratá-la como dependência de terceiro: coisa que entra em inventário, tem versão fixada e passa por revisão quando muda — em vez de coisa que se ajusta no dia em que incomoda.

O detalhe que mais me incomoda nessa camada é de compatibilidade. Campos de controle como allowed-tools são experimentais e podem não ser suportados por todo agente. Uma skill apoiada neles para limitar raio de ação continua rodando em outro runtime — só que sem limite nenhum, e sem uma linha de aviso. Incompatibilidade que solta o freio é bem pior do que incompatibilidade que trava a roda. Se a skill depende de contenção para ser segura, a contenção mora na camada de execução, não no frontmatter — que é exatamente por que a camada 2 vem antes desta.

O erro mais comum aqui é adotar protocolo por reflexo de arquitetura, não por necessidade observada. Protocolo elegante no papel é uma tentação particular para arquiteto, porque ele resolve no diagrama um problema que talvez não exista no roadmap. O teste que uso é simples: se você não consegue nomear o sistema do outro lado, com dono e time responsável, você não tem problema de interoperabilidade ainda.

Camada 5 — Controle: Qual É O Sinal Que Te Avisa Antes Do Usuário Avisar

A camada de cima é a que responde por que tudo isso está em produção sem virar notícia interna. A pergunta-chave: qual é o sinal que te avisa antes do usuário avisar. Se a resposta for "o code review", ela está errada, porque code review não escala na velocidade em que o código passou a ser produzido.

Comecei a série com um PR de dezenove linhas que parecia perfeitamente contido e quebrou dois consumidores. O incidente em si não foi o que me tirou o sono. Foi constatar que nada no pipeline tinha como ter me alertado: agente, revisor e CI trabalharam todos sobre a mesma faixa estreita de realidade — as linhas alteradas e a vizinhança imediata delas. O que se apoiava naquelas linhas, espalhado pelo resto do repositório, ficou fora do campo de visão dos três ao mesmo tempo. Um experimento de 2026 mediu exatamente esse efeito e mostrou a regressão em nível de teste caindo de 6,08% para 1,82% quando o agente recebia um grafo de dependências antes de escrever a correção. É o que está em análise de impacto por grafo e regressão em código gerado por IA.

O segundo sinal desta camada é o teste, e ele mudou de função. Não é mais higiene de qualidade, é contrato executável. O RepoRescue mostrou agentes cuja taxa de sucesso caía pela metade quando os autores auditavam apenas mudanças de código-fonte, excluindo edições em arquivo de teste — ou seja, boa parte do "verde" dependia de ter mexido no teste. Não é malícia, é lei de Goodhart em forma de commit: o agente corre atrás do indicador que você deixou à vista dele, pelo caminho mais curto que encontrar. Destrinchei os dois modos de falha em agentes que apagam testes e por que TDD virou mecanismo de controle.

O terceiro sinal é organizacional e é o que menos gente trata como parte do stack. Pesquisa da OutSystems com quase 1.900 líderes de TI aponta 96% das organizações usando agentes em alguma capacidade e 12% com plataforma centralizada para gerenciar o sprawl. O número que me incomoda mais, porém, é outro: entre organizações que sofreram incidente relacionado a IA, o relatório da IBM aponta 63% sem nenhuma política de governança no lugar. Plataforma centralizada é projeto de trimestres; uma política escrita, dizendo que tipo de dado pode ir para que tipo de ferramenta, sai em uma semana de trabalho de gente sênior. O salto de zero para o mínimo é curto e barato — e é justamente esse salto que quase ninguém deu. É o assunto de shadow AI e a lacuna de governança sobre agentes em produção.

O erro mais comum nesta camada é tratá-la como a última — algo que se resolve depois que o resto funciona. Ela é a que dá permissão para todas as outras. Sem sinal, rebaixar modelo é aposta cega, porque você não tem como saber se a qualidade caiu. Sem sinal, ampliar autonomia do agente é aposta cega pelo mesmo motivo. Controle não é o freio do sistema, é o que autoriza acelerar.

A Ordem Em Que Essas Decisões Deveriam Ser Tomadas

O padrão que mais vejo é o time começar pela camada 3. Escolhe o framework primeiro, porque é a decisão mais visível, a que tem mais conteúdo disponível e a única que gera código na primeira tarde. Depois descobre o custo, e vai mexer no modelo. Depois um incidente ou uma auditoria traz a execução para a mesa. Controle e governança entram por último, geralmente empurrados de fora.

Essa ordem é quase o inverso da ordem de dependência. A camada de execução limita o que a camada de orquestração pode fazer com segurança. A camada de controle determina se você pode rebaixar modelo sem estar chutando. E o protocolo só faz sentido depois que existe algo do outro lado para conversar. Escolher o framework primeiro é escolher a única camada que é relativamente fácil de trocar depois, antes das três que são difíceis.

A ordem que eu defenderia hoje começa pelo controle, e sei que isso soa burocrático. Não é: é o passo mais barato. Um conjunto de eval congelado para as duas ou três etapas que importam, um mapa de quais testes cobrem quais caminhos, e a regra explícita de que agente não edita arquivo de teste. Isso é trabalho de dias, não de trimestres, e é o que torna toda decisão seguinte mensurável em vez de opinativa.

Depois vem execução, porque é a decisão com o pior perfil de risco assimétrico do stack: barata de acertar antes, muito cara de corrigir depois de um incidente. Fechar egress por padrão e abrir por exceção declarada custa uma tarde. Em terceiro vem modelo, agora que existe eval para saber se rebaixar dói. Em quarto, orquestração — e a essa altura você já sabe quanto controle do loop precisa, porque já sabe o que precisa observar. Protocolo em último, quando e se aparecer contraparte real.

Vale um contraponto honesto: essa ordem é para quem constrói sistema que vai ficar de pé. Para exploração, a ordem invertida é perfeitamente racional — pegue o framework mais rápido, o modelo mais capaz, rode sem cerimônia. O erro não é começar pelo framework. É começar pelo framework e nunca voltar para as outras quatro, deixando o protótipo virar produção por inércia. É assim que a maioria dos sistemas que vejo hoje foi parar onde está.

Se você está numa fase anterior a tudo isso — decidindo qual assistente de código o time usa no dia a dia —, essa é uma conversa diferente e já a fiz separadamente no guia sobre o arsenal do dev em 2026. Ferramenta de dev e stack de agente em produção são problemas que se parecem e não são o mesmo.

O Mapa Em Uma Tabela

Camada	Pergunta-chave	Erro mais comum	Onde aprofundar
5. Controle	Qual sinal me avisa antes do usuário?	Tratar como última etapa em vez de pré-requisito	Grafo de impacto, TDD como contrato, governança
4. Protocolo	Integração ou interoperabilidade?	Adotar protocolo por reflexo, sem contraparte real	A2A, skills e marketplaces
3. Orquestração	Quanto do loop preciso controlar?	Escolher framework antes de saber o tempo de vida	Deep agents, LangGraph vs CrewAI
2. Execução	Se for comprometido, o que ele alcança?	Confundir isolamento de processo com o de rede	Sandboxes, controle de egress
1. Modelo	Qual o menor modelo que resolve com qualidade verificável?	Escolher uma vez e tratar como constante	Roteamento, subagentes lite, destilação, local

A tabela está de cima para baixo de propósito: na ordem em que eu tomaria as decisões, não na ordem em que elas aparecem no diagrama. É a inversão que defendo o post inteiro.

Conclusão

O que me surpreendeu ao juntar as duas semanas não foi encontrar cinco camadas. Foi perceber que as decisões mais consequentes de cada uma delas não são técnicas no sentido em que a gente costuma usar a palavra. Qual sandbox é uma escolha técnica; se alguém verifica o egress trimestralmente é uma escolha operacional. Qual framework é técnico; quanto tempo o serviço vai ficar de pé é uma pergunta de produto. Em quase todas as camadas, a parte difícil ficou do lado que não tem documentação.

Também fico com a impressão de que a metade de baixo do stack está amadurecendo mais rápido do que a de cima. Modelo e execução têm hoje opções boas, preços declarados e comparação possível. Orquestração está em plena divergência, com dois frameworks caminhando em direções opostas e nenhum consenso à vista. Protocolo tem padrão bonito e adoção desigual. E controle continua sendo a camada em que cada time monta o próprio arranjo do zero, sem nada parecido com um padrão para copiar, o que é exatamente o oposto do que a criticidade dela sugeriria.

Não sei quanto desse mapa sobrevive a mais seis meses, e escrevo isso sem falsa modéstia: mapa de terreno que ainda está se acomodando envelhece rápido. Metade dos nomes que coloquei aqui pode estar em outro lugar, ou não existir mais, quando alguém abrir este post em dezembro — e, olhando de dentro, não tenho como separar o que é acidente de 2026 do que é feição permanente do relevo. A parte que eu apostaria que fica não é nenhuma tecnologia específica: é a ordem. Decidir o que você precisa conseguir observar antes de decidir o que você vai construir continua sendo o único jeito que conheço de não descobrir o problema pelo canal de suporte. Se daqui a seis meses os nomes das cinco camadas tiverem mudado todos e essa sequência continuar de pé, o mapa terá feito o trabalho que eu queria dele. Se ela cair junto, prefiro ter deixado registrado por escrito para poder voltar e conferir onde errei.

Fontes:

O Stack do Dev com IA em Agosto de 2026: Mapa das 5 Camadas

O Stack do Dev com IA em Agosto de 2026: Mapa das 5 Camadas

Camada 1 — Modelo: Qual É O Menor Modelo Que Resolve Isso Com Qualidade Verificável

Camada 2 — Execução: Se Esse Agente For Comprometido, O Que Ele Alcança

Camada 3 — Orquestração: Quanto Do Loop Você Precisa Controlar

Camada 4 — Protocolo: Você Tem Um Problema De Integração Ou De Interoperabilidade

Camada 5 — Controle: Qual É O Sinal Que Te Avisa Antes Do Usuário Avisar

A Ordem Em Que Essas Decisões Deveriam Ser Tomadas

O Mapa Em Uma Tabela

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose