Capítulo 13 — Frameworks e Integração com Nuvem

Décima terceira postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que ninguém constrói MCP de produção a partir de protocolo cru, a pergunta honesta de 2025–2026 vira sobre qual framework padronizar, e a resposta acaba dependendo menos de funcionalidades do que de em qual nuvem o resto do sistema mora.

Por que este capítulo existe

Quando um time já fiou autenticação, transporte, estado de sessão, retry de erro, logging estruturado, e a dúzia de detalhes menores que separam uma demo de um serviço operável, o que começou como "vamos só falar MCP sobre HTTP" virou um pequeno framework próprio — geralmente pior que os frameworks que já existem. A pergunta de engenharia é em qual dos frameworks públicos padronizar, o que cada um acerta, e como eles se conectam aos serviços de nuvem que mantêm o estado. Este capítulo percorre a paisagem metodicamente: Strands com Amazon Bedrock; os serviços AWS que o cercam para estado e recuperação; o Agent Framework da Microsoft, LangChain e Semantic Kernel como as outras opções de produção; e os padrões de integração nos quais as arquiteturas de referência convergiram. A meta não é coroar um vencedor mas descrever para o que cada framework de fato existe.

13.1 Strands Agents e Amazon Bedrock

Strands é o framework de agente open-source que a AWS lançou em 2025 e que agora roda dentro do Amazon Q, do AWS Support e do assistente do AWS Glue. O enquadramento é deliberado: Strands é dirigido por modelo, o que significa que o loop que decide o que fazer em seguida é o próprio loop de tool-calling do modelo, não um planner-grafo que o framework impõe por cima. O trabalho do framework é tornar esse loop confiável em produção — tratar invocações de tool, gerenciar estado de sessão, plugar servidores MCP como fontes de tool de primeira classe via MCPClient, e rotear tudo pelo catálogo de modelos hospedados do Bedrock. A camada de modelo é plugável — API da Anthropic, OpenAI, Ollama, LiteLLM — mas Bedrock é o padrão e a história de auditoria.

A história multi-agente é onde o Strands ganha sua reputação de produção. Três padrões de composição mapeiam limpo nos formatos de orquestração dos capítulos anteriores: Agents-as-Tools (o formato mais simples, um agente embrulhado como tool que outro agente pode chamar); Swarm (par-a-par com memória de trabalho compartilhada); e Graph (topologia determinística onde o modelo preenche cada nó). Os padrões aninham em produção. O imposto operacional é pago em observabilidade, e o Strands o paga emitindo spans OpenTelemetry para cada invocação de agente, cada chamada de tool, cada chamada de modelo — então uma composição de quatro níveis se reconstrói a partir de logs sem instrumentação por nível. O Bedrock adiciona a história de fronteira de acesso: IAM controla quais modelos um agente dado pode invocar; CloudTrail registra o uso. Bedrock Guardrails tratam filtragem de conteúdo no gateway, Knowledge Bases dão recuperação gerenciada, e AgentCore — o conjunto de primitivas de 2025 da AWS — formaliza preocupações de memória, identidade e runtime para times que querem runtime totalmente gerenciado em vez de auto-hospedado.

13.2 AWS como camada de estado

Um agente que roda por horas e lembra o que aconteceu ontem precisa de armazenamento que sobreviva ao processo. O padrão que assentou em produção: estado de runtime (sessão atual, livro razão de tarefa, chamadas de tool em voo) em DynamoDB para acesso rápido por chave; estado de artefato (documentos gerados, trabalho intermediário) em S3 com estrutura de chave com prefixo de sessão que dá ao mesmo tempo fronteiras IAM naturais e versionamento de graça; estado semântico (memória de longo prazo, conversas anteriores) num store vetorial — OpenSearch Service para memória de trabalho quente, o mais novo S3 Vectors para memória fria ou arquival. A separação de duas camadas entre S3 e DynamoDB não é otimização prematura. Mantém o item DynamoDB abaixo de 400 KB, evita amplificação de leitura a cada passo, e deixa cada camada escalar independentemente.

A escolha de camada de estado determina o modo de falha do sistema inteiro. Um agente cujo estado está só em memória de processo perde tudo no restart. Um agente cuja memória é durável mas cujo índice está fora de sincronia recorda referências a documentos que não consegue mais achar. Deployments em produção tratam isto como contratos de consistência separados: transações DynamoDB para atomicidade de estado, leitura-após-escrita forte no S3 para o contrato de artefato, um pipeline de indexação que publica documentos no S3 antes de fazer upsert dos seus vetores para que a recuperação não aponte para algo que ainda não existe. A fronteira de segurança merece o mesmo cuidado. O próprio guidance da AWS para Strands recomenda credenciais por sessão via STS em vez de reutilizar o papel de runtime para chamadas de tool com dados de usuário final — AgentCore Identity automatiza isto — para que a identidade no nível AWS por trás de uma ação destrutiva seja o usuário final de fato, não um papel de agente compartilhado. Em ambientes regulados essa é a única resposta aceitável.

13.3 Microsoft Agent Framework, LangChain e Semantic Kernel

O lado Microsoft e open-source da paisagem se assentou diferente. O Microsoft Agent Framework chegou no final de 2025 como a fusão explícita do Semantic Kernel e do AutoGen — o modelo de plugin e integração .NET do SK com os padrões multi-agente e DX Python-first do AutoGen. Integração MCP é embutida via MCPStdioTool e MCPStreamableHTTPTool; Azure AI Foundry é a casa hospedada, equivalente ao Bedrock no mundo AWS. A funcionalidade distintiva versus Strands é que o grafo de conversa entre agentes é objeto explícito, replayável — o que importa enormemente para avaliação, porque uma conversa falha pode ser rerodada com um prompt modificado e comparada turno a turno. O custo é mais estrutura do que o Strands impõe; troca certa em deployments maduros, troca errada em trabalho exploratório.

O LangChain em 2026 é animal diferente do LangChain em 2023. A abstração original de chains virou secundária; a superfície primária é LangGraph para orquestração e LangSmith para observabilidade e avaliação. As forças são amplitude — todo modelo, banco de dados e tool parece ter adaptador — e a maturidade de avaliação do LangSmith. A fraqueza que praticantes nomeiam honestamente é área de superfície: as abstrações de alto nível do framework são excelentes para os primeiros noventa por cento do trabalho, e os últimos dez por cento são geralmente feitos descascando camadas até o time entender o que cada uma está fazendo. Times que planejam para essa transição entregam mais rápido que times que brigam com as abstrações. Semantic Kernel segue como o framework para times .NET; o modelo de plugin [KernelFunction] encaixa limpo em hosts de serviço .NET. Um padrão que emergiu entre os três: agente fino, MCP grosso — capacidades moram atrás da fronteira de protocolo, frameworks viram proxies finos, e o mesmo servidor MCP é consumido por Strands na AWS, Microsoft Agent Framework no Azure, e LangChain no laptop de um dev sem trabalho de port. Essa é a trajetória que o protocolo foi desenhado para habilitar.

13.4 Os padrões de integração de produção

Três padrões se assentaram nas arquiteturas de referência de 2025–2026. O padrão gateway-e-camada-de-estado coloca um gateway de modelo gerenciado (Bedrock, AI Foundry, LiteLLM) na frente da camada de modelo e uma camada de estado durável separada atrás. O gateway é onde auth, rate limiting, filtragem de conteúdo e auditoria moram; a camada de estado é onde durabilidade mora. Este padrão é o default de produção; deployments novos deveriam adotá-lo a não ser que tenham razão específica para não, porque times que pulam o gateway e chamam o provedor de modelo diretamente se arrependem dentro de um trimestre. O padrão service mesh MCP trata servidores MCP como microsserviços e os expõe via uma mesh que trata mTLS, retries e circuit breaking — vale o custo só em escala (mais de dez servidores) ou em ambientes regulados que exigem atestação no nível de rede. O padrão managed-everything entrega runtime, memória, identidade e registry de tool a um serviço gerenciado de agente em nuvem (Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder); ganha para automação interna e copilots onde o agente não é o produto primário, e perde para times onde o agente é o produto e as alavancas operacionais importam. Dois padrões que não venceram, e que valem ser nomeados como exemplos negativos: tudo-no-contexto-do-LLM (agentes cuja memória é prompt de sistema crescendo sem parar) e framework-como-orquestrador (DAG rígido com o modelo preenchendo parâmetros de nó). Ambos morrem em produção pelas razões que o Capítulo 9 percorreu, e a lição que o campo absorveu é que o equilíbrio certo entre estrutura de framework e liberdade do modelo se desloca mais para o lado do modelo conforme o modelo fica mais capaz.

O que o Capítulo 13 prepara

Os frameworks e serviços de nuvem deixam times entregar agentes baseados em MCP sem reescrever a pilha de protocolo a cada vez. O que eles não dizem aos times, por si só, é se o sistema resultante de fato funciona — se o agente resolve as tarefas para as quais foi construído, como se comporta sob carga, onde estão os precipícios de desempenho, e como comparar duas arquiteturas competidoras com honestidade. O Capítulo 14 toma a pergunta de frente: percorre o MCP-Universe Benchmark, os dois modos de falha sistêmicos que o benchmark descobriu (degradação de contexto longo e exploração de tool desconhecida), e o lado de throughput onde o gap entre um pool de sessão compartilhado e o padrão ingênuo de sessão por requisição é grosso modo uma ordem de grandeza.

Próximo — Capítulo 14: Benchmarking, Testes e Desempenho. MCP-Universe em servidores reais, as mitigações de contexto longo e tools desconhecidas que funcionam, o gap de dez vezes de throughput entre sessão-por-requisição e pools de sessão compartilhados, e para onde a série vai em seguida.