Capítulo 1 — A Crise de Integração de IA e a Ascensão da Arquitetura Agêntica
Primeira postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que o padrão dominante da era 2024 — prompt de sistema longo, um punhado de ferramentas, uma única janela de contexto encarregada de fazer tudo — falha numa sequência reconhecível, e a falha aponta para uma camada de protocolo em direção à qual o campo vinha trabalhando em silêncio.
Por que este capítulo existe
Por aproximadamente dois anos a receita padrão para uma aplicação LLM foi: escreva um prompt de sistema longo, anexe um punhado de ferramentas, chame o resultado de agente. A receita entregou demos. Também, previsivelmente, quebrou conforme a superfície cresceu. Prompts passaram dos seis mil tokens. Inventários de ferramentas passaram dos quarenta. O time remendou, auditou, fez testes de regressão, e em algum momento percebeu que adicionar funcionalidades havia se tornado exponencialmente mais caro do que costumava ser. O diagnóstico não foi preguiça ou engenharia ruim. Foi uma arquitetura que forçava toda preocupação por um único recurso compartilhado — o contexto do modelo — e um problema combinatório mais profundo escondido por baixo.
Este capítulo percorre os modos de falha na ordem em que times de fato os encontram, dá nome a cada um, e então enquadra o escape arquitetural. O escape é uma camada de protocolo que permite que modelos e ferramentas se encontrem sem cola sob medida, e uma disciplina — engenharia de contexto — que trata a visão do modelo como um orçamento gerenciado em vez de um campo de texto livre. Ambas as ideias preparam o resto do livro.
1.1 O agente monolítico e por que seu prompt de sistema eventualmente quebra
A primeira geração de aplicações LLM em produção teve forma arquiteturalmente simples. Um prompt de sistema de vários milhares de tokens descrevia papel, ferramentas, restrições, tom e casos de borda. Funcionava para superfícies estreitas. Conforme o time adicionava funcionalidades um parágrafo de cada vez, o prompt virou o maior artefato único da base de código, editado quase só por adição porque remover qualquer coisa parecia arriscado.
O que esse prompt estava fazendo internamente se entende melhor através da atenção. Um transformer computa pesos de atenção sobre cada token em seu contexto, inclusive cada token do prompt de sistema. Um prompt de seis mil tokens não é lido por cima — ele é mediado contra. Quanto mais longo o prompt, mais a massa de atenção se espalha sobre instruções irrelevantes para o passo atual. O fenômeno tem nomes: diluição de contexto, colisão de instruções, deriva de capacidade. O time observa regressão e não consegue localizar a causa, porque a causa é a interação de três novas regras com uma cláusula adicionada duas sprints atrás.
Uma falha relacionada aparece na camada de ferramentas. Com dez ferramentas o modelo escolhe corretamente; com quarenta, a acurácia de seleção cai, às vezes acentuadamente. O time remenda adicionando linguagem desambiguadora, o que alonga o prompt, o que dilui mais ainda a atenção. O sistema agora está em loop de feedback consigo mesmo.
1.2 Especialização e a curva de manutenção que dobra para o lado errado
Por baixo do problema de prompt mora outro mais profundo. Modelos de fronteira de propósito geral são fortes generalistas, mas desempenho generalista é uma média sobre uma superfície vasta, e médias escondem precipícios. Revisão de contrato jurídico, codificação médica estruturada, conciliação financeira — cada um tem vocabulário interno, regras internas e uma tolerância a erro que o treinamento geral não otimiza. O instinto é especializar via prompt; o custo é mais orçamento de atenção consumido por menos retorno. Especialização genuína quer seu próprio componente com seu próprio contexto focado, e o agente monolítico não tem onde encaixar isso.
Manutenção escala para o mesmo lado errado. Um agente monolítico com cinquenta ferramentas em quatro domínios não tem dez vezes a carga de manutenção de um com cinco ferramentas e um domínio — tem mais, porque cada funcionalidade interage com cada outra através do prompt compartilhado. A velocidade do time é definida pelo custo de manter coerente a superfície existente, não pelo custo de construir capacidade nova. O custo de inferência escala com o comprimento de contexto, então a pressão econômica para encolher o prompt e a pressão de engenharia para crescê-lo puxam em direções opostas.
1.3 O problema de integração N vezes M
Aceite o argumento por decomposição. Agora você tem N componentes carregando modelo e M integrações de ferramenta. Sem um protocolo compartilhado, o custo de integração é N vezes M — cada modelo precisa de código adaptador sob medida para cada ferramenta, com as idiossincrasias de cada modelo multiplicadas pelas idiossincrasias de cada ferramenta no produto cartesiano. Um novo release de modelo significa retestar cada ferramenta. Uma nova ferramenta significa escrever N adaptadores.
A história da computação tem um nome para esse formato e um nome para o conserto. Antes do LSP (2016), todo editor precisava de integração com toda linguagem — editor vezes linguagem. O LSP introduziu um protocolo; a matriz colapsou para custo aditivo. Antes do USB, cada categoria de periférico tinha sua porta própria e cada SO embarcava seus próprios drivers. Depois do USB, um host, um dispositivo, um protocolo compartilhado entre eles. O Model Context Protocol é o mesmo movimento aplicado a modelos e ferramentas. Não elimina adaptadores; padroniza-os. A primeira integração é mais lenta; a centésima é muito mais rápida; a milésima é essencialmente de graça porque o ferramental se acumulou. O jogo todo está na curva cumulativa.
Um protocolo com descoberta também colapsa uma segunda matriz mais silenciosa — a matriz de descrição. O modelo não precisa mais ter cada ferramenta enumerada em seu prompt de sistema no boot; ele pode perguntar ao protocolo "o que está disponível agora?" e receber um catálogo estruturado da fonte autoritativa: o próprio servidor.
1.4 De engenharia de prompt para engenharia de contexto
Uma mudança de vocabulário acompanha a mudança arquitetural. Em 2022-2023 a disciplina era engenharia de prompt — achar fraseados que empurrassem o modelo na direção do comportamento desejado. Em 2025 o prompt era uma entrada entre muitas. O modelo também vê documentos recuperados, descrições de ferramenta, turnos anteriores, resultados de ferramenta, notas de scratchpad, recortes de memória. O que deve estar nesse contexto a cada passo não é mais respondido por fraseado. É respondido por uma arquitetura que decide, por turno, em que o modelo deve estar olhando.
O termo que ficou foi engenharia de contexto. Ela trata a janela de contexto como orçamento gerenciado. Modelos modernos de contexto longo anunciam janelas de um milhão de tokens, mas o desempenho degrada de modo não-linear conforme o contexto enche — o fenômeno às vezes chamado de context rot. Um modelo com um milhão de tokens de contexto com a resposta enterrada nele frequentemente se sai pior do que o mesmo modelo com dez mil tokens cuidadosamente selecionados. O orçamento que importa não é o tamanho da janela; é a densidade de sinal útil dentro do que de fato está em frente ao modelo.
O MCP é, em parte, a infraestrutura que torna a engenharia de contexto possível. O protocolo dá ao host maquinário para perguntar quais ferramentas e quais fontes de dados estão disponíveis, para buscar as relevantes no momento certo, para negociar quais capacidades o modelo pode invocar. O host constrói o contexto dinamicamente, por turno, com base no que a tarefa atual de fato exige.
O que o Capítulo 1 prepara
O diagnóstico vem em três partes: agentes monolíticos falham porque prompts longos diluem atenção; capacidade especializada não pode viver dentro de um prompt compartilhado; por baixo de ambos está o problema de integração N vezes M. Cada modo de falha aponta na mesma direção — uma camada por baixo do modelo que medeia como modelos e ferramentas se encontram, se descrevem, e negociam o que podem fazer. O Capítulo 2 apresenta essa camada: os três papéis que o MCP define, o pequeno conjunto de primitivas conceituais, e o ciclo de vida de sessão que abre com negociação explícita de capacidades.
Próximo — Capítulo 2: Revelando o Model Context Protocol. O que o MCP é, o que a abreviação "USB-C para IA" de fato significa, a divisão em três papéis de Host, Cliente e Servidor, e por que descoberta dinâmica e mensageria bidirecional fazem o MCP se comportar de modo diferente de uma API REST nos casos que importam.
