Capítulo 8 — Layouts Arquiteturais de Deployment

Oitava postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que dois sistemas com lógica de orquestração idêntica acabam se comportando muito diferente em produção, porque a pergunta "onde o modelo de fato roda" é respondida de três jeitos e cada resposta define um teto diferente de latência, custo e segurança.

Por que este capítulo existe

Os Capítulos 6 e 7 especificaram como agentes se coordenam. Ficaram silenciosos sobre uma pergunta que decide tanto do comportamento real do sistema: onde cada agente roda, e como modelos de linguagem, servidores MCP e ferramentas são arrumados pela rede? As decisões arquiteturais deste capítulo tocam cada requisição e cada dólar. Três layouts amplamente distintos emergiram no ecossistema MCP ao longo de 2025 e entrando em 2026, e nenhum dos três é universalmente certo. Cada um é otimizado para uma combinação diferente de restrições, e a escolha tem consequências que engenheiros deveriam saber articular antes de fazê-la.

8.1 O agente de IA reutilizável: modelo empacotado com o servidor

O primeiro layout empacota um modelo de linguagem junto com um servidor MCP e expõe a combinação como uma única capacidade caixa-preta. O cliente chama "revise este pull request" do mesmo jeito que chamaria uma tool; por baixo, um loop agêntico completo roda no lado servidor, invocando o modelo, chamando tools internas, e retornando só a saída final. O padrão emergiu quando organizações construíram agentes especializados — pesquisa, revisão de código, análise financeira — que queriam expor a muitas aplicações host diferentes sem que cada uma tivesse que entender os internals.

As forças são reais. Encapsulamento permite aos autores do agente trocar modelos ou reestruturar a orquestração sem nenhuma mudança visível aos clientes. Reusabilidade entre aplicações host significa que um único agente atende Claude Code, um app empresarial e um chatbot voltado ao cliente pela mesma interface. Os custos são igualmente reais. Opacidade torna o debug difícil: quando o agente toma uma decisão errada, o cliente não consegue ver por quê. Latência se empilha porque o loop do lado servidor roda a cada chamada. E orçamento duplo é estrutural: o operador do agente paga por suas invocações de modelo e o cliente paga pelas suas, e o custo total por interação pode ser maior do que qualquer lado inicialmente percebe.

A variante multi-tenant — um processo de agente servindo muitas organizações cliente — melhora substancialmente a economia operacional amortizando custos fixos entre tenants. Também introduz vazamento de dado entre tenants como modo de falha de primeira classe. Vários incidentes divulgados em 2025 envolveram exatamente isto, e operadores deveriam desenhar tenancy no runtime em vez de confiar que revisão de código pegue vazamentos entre requisições.

8.2 Pureza estrita de MCP: o modelo no cliente

O segundo layout coloca o modelo de linguagem estritamente no cliente. Servidores MCP expõem apenas dados e ferramentas — sem inferência. O host roda o modelo, toma as decisões de orquestração, e chama servidores para reunir contexto e executar ações. A motivação é a justificativa de design original do protocolo: o MCP existe para resolver o problema de integração N vezes M provendo uma interface uniforme entre modelos e ferramentas, e servidores que rodam seus próprios modelos reintroduzem o problema que o protocolo deveria resolver.

As forças são controle e transparência. Toda chamada de modelo é observável à instrumentação do cliente. O cliente escolhe o modelo por requisição, pode cair para outros provedores, e arca com todo custo de modelo diretamente — sem orçamento duplo porque não há segundo modelo na cadeia. Para indústrias reguladas onde logs de auditoria no cliente devem capturar a cadeia completa de raciocínio, pureza estrita satisfaz o requisito sem ambiguidade.

Os custos são igualmente claros. Cada pedaço de inteligência tem que ser reimplementado por cada cliente, o que é fardo real para organizações com muitas aplicações host. Algumas capacidades — pesquisa multi-passo, refinamento iterativo — são desajeitadas de fatorar como tools de tiro único, e expô-las ou empurra orquestração complexa para o cliente ou silenciosamente viola a pureza deixando o servidor rodar seu próprio modelo. E o cliente precisa ser capaz de rodar orquestração, o que na prática significa se apoiar em Strands, LangChain, Semantic Kernel, ou no Microsoft Agent Framework em vez de rolar o loop do zero.

8.3 Híbrido: orquestração do lado cliente com execução do lado servidor

O terceiro layout divide a diferença. O cliente orquestra e roda inferência primária; certos servidores MCP rodam suas próprias invocações de modelo para subtarefas especializadas. O exemplo mais claro é uma ferramenta de pesquisa profunda de longa duração. Um cliente que precisa dobrar um resultado de pesquisa num workflow mais amplo não quer gerenciar cada passo da pesquisa por conta própria; quer chamar "pesquise X e me conte o que encontrou" e receber uma síntese. A pesquisa é multi-passo, multi-fonte, e se beneficia de sua própria orquestração interna.

O padrão híbrido funciona quando a fronteira é desenhada numa costura significativa — uma subtarefa com entradas e saídas claras, autocontida o suficiente para que a inteligência do lado servidor consiga completar sem coordenação do cliente, e especializada o suficiente para que rodá-la como caixa-preta bata rodá-la pelo orquestrador geral. Pesquisa, análise de código, síntese de documento se encaixam no perfil. Conversa geral não.

O custo é complexidade arquitetural. Há agora dois lugares onde inteligência roda, observabilidade tem que cruzar a fronteira, e atribuição de custo se senta entre os dois padrões puros. Uma disciplina útil é limitar o número de servidores inteligentes e manter cada um focado numa capacidade bem definida. Dois ou três é operável; doze vira federação que nenhum time entende. Deployments híbridos também tendem a evoluir para uma das pontas puras do espectro ao longo do tempo, e arquitetos deveriam ser honestos sobre se seu híbrido é design estável ou estado transitório.

O que o Capítulo 8 prepara

Os três capítulos da Parte III percorreram o espaço de design de sistemas multi-agente da perspectiva do mecanismo. O que ainda não cobrem é o substrato por baixo: o contexto que cada invocação de modelo recebe e a memória que persiste entre invocações. A efetividade de um agente depende do que ele consegue ver quando age e do que consegue lembrar sobre o que já fez antes. A janela de contexto é finita. A arquitetura de memória tem que ser projetada. Os padrões de gestão de orçamento de atenção, uso de scratchpad, memória episódica e semântica são o substrato que transforma um conjunto coordenado de agentes em sistema que faz trabalho útil ao longo de horas, dias ou mais.

Próximo — Capítulo 9: Gerenciando o Orçamento de Atenção. Por que uma janela de um milhão de tokens é um valor de teto em vez de ponto de operação, o que come o orçamento, e como MCP, RAG e fine-tuning cada um encaixa em um formato diferente de lacuna.