Design da cadeia de ferramentas de AI Agent: de ferramentas isoladas a um ecossistema

Na semana passada, um colega me perguntou: o seu Agent consegue se conectar ao mesmo tempo a CRM, banco de dados, repositório de código e sistema de e-mail? Eu disse: claro que consegue. Só que cada sistema exige uma camada de adaptação própria: o CRM chama a API do Salesforce, o banco conecta no PostgreSQL, o repositório conversa com o GitHub e o e-mail passa por SMTP. Ele riu depois de ouvir isso: então quantos adaptadores você escreveu?

Eu contei. Doze.

Cada adaptador levou, em média, meio dia de depuração. Alguns levaram mais.

Então ele fez a pergunta que ficou martelando: por que não deixar o Agent aprender a chamar essas ferramentas sozinho, em vez de você escrever manualmente cada conexão?

Para ser sincero, essa pergunta me travou por um instante.

Uma pesquisa de 2026 mostra que 84% dos desenvolvedores usam vários recursos de programação com IA ao mesmo tempo. Mas, quando o seu Agent precisa entrar de fato no ambiente de produção de uma empresa, por trás dessa combinação de ferramentas aparece outra dor bem concreta: você precisa escrever uma camada de adaptação sob medida para cada sistema externo.

É exatamente esse o problema que o protocolo MCP, ou Model Context Protocol, tenta resolver. Uma analogia simples: antes, cada dispositivo tinha seu próprio conector de carregamento; agora existe o padrão USB. Você desenvolve uma vez e reutiliza em vários dispositivos.

Neste artigo, quero conversar sobre alguns pontos centrais do design da cadeia de ferramentas de AI Agent: a lógica de evolução de “chamada de ferramenta isolada” para “ecossistema de ferramentas”, o que o protocolo MCP realmente resolve, como pensar a escolha de frameworks populares e quais armadilhas aparecem na adoção empresarial.

Se você está construindo um sistema de Agent, ou está em dúvida entre “qual framework escolher” e “como projetar a interface das ferramentas”, este artigo deve trazer algumas pistas práticas.

Capítulo 1: a essência da cadeia de ferramentas — por que evoluir de “chamada de ferramenta” para “ecossistema de ferramentas”

1.1 Arquitetura em três camadas: o esqueleto do Agent

Vamos começar por uma base: a arquitetura de um Agent costuma ter três camadas.

A camada mais baixa é a camada de Model, ou seja, a capacidade de raciocínio do modelo grande: GPT-5, Claude 3.7, Gemini 2.0 e assim por diante. Essa parte já está praticamente comoditizada. A diferença entre fornecedores costuma estar mais em preço e velocidade do que na natureza da capacidade.

A camada intermediária é chamada de Agent Harness. Algumas pessoas também a chamam de “sistema operacional do Agent”. Ela cuida de três coisas: orquestração de ferramentas, gestão de estado e passagem de contexto. Usando uma analogia: a camada de Model é o motor; o Harness é a transmissão. Mesmo com um motor forte, se a transmissão for mal projetada, o carro não anda bem.

A camada superior é a camada de Skills, ou seja, a base de conhecimento profissional e os fluxos de trabalho do Agent. Um Agent financeiro tem Skills de verificação de conformidade; um Agent de atendimento tem uma biblioteca de roteiros; um Agent de engenharia tem normas de revisão de código. É aqui que surge a diferenciação: dois Agents podem usar o mesmo Model, mas, se as Skills forem diferentes, o comportamento será completamente diferente.

O design da cadeia de ferramentas acontece principalmente na camada de Harness.

1.2 A dificuldade real de uma ferramenta isolada

Eu já caí nessa armadilha: no começo, usei ferramentas embutidas do LangChain para colocar no ar um Agent simples de perguntas e respostas. Depois, os requisitos ficaram mais complexos: era preciso conectar o ERP interno da empresa, o sistema de BI e um banco de dados privado.

Na época, o LangChain tinha mais de 600 ferramentas embutidas. Mas adivinhe: nenhum sistema interno da empresa estava coberto.

Não teve jeito. Tive que escrever por conta própria. A primeira ferramenta customizada foi relativamente tranquila. Mas, quando cheguei à quinta e depois à décima, alguns problemas começaram a aparecer.

Primeiro problema: definições de ferramentas dispersas.

O Schema de parâmetros, o tratamento de erros e os registros de log de cada ferramenta ficavam espalhados por arquivos diferentes. Para reutilizar uma ferramenta em outro projeto de Agent, era preciso copiar e colar código, trocar nomes de parâmetros e mexer na lógica de captura de exceções.

Segundo problema: o estado não era compartilhável.

O Agent chamava a ferramenta de CRM para buscar informações de um cliente e, no passo seguinte, chamava a ferramenta de e-mail para enviar uma mensagem de follow-up. Só que a ferramenta de e-mail não recebia o endereço retornado pela ferramenta de CRM. Era preciso transmitir o estado manualmente no programa principal do Agent.

Terceiro problema: ninguém gerenciava o ciclo de vida.

Quando uma ferramenta era atualizada, quais Agents ainda usavam a versão antiga? Ninguém sabia. Quando uma ferramenta caía, quais Agents seriam afetados em cascata? Também ninguém sabia.

E isso nem era o pior. O pior era que, a cada novo sistema externo, era preciso escrever outra camada de adaptação. Os doze adaptadores do começo nasceram exatamente assim.

1.3 Ecossistema de ferramentas: da “oficina manual” à “industrialização”

Que problema o ecossistema de ferramentas resolve? Em uma frase: transforma “ferramentas” em “serviços”.

No modelo tradicional, uma ferramenta é um trecho de código acoplado a um Agent específico. No modelo de ecossistema, uma ferramenta é um serviço independente, com sua própria API, versão e documentação. O Agent chama a ferramenta como chamaria um microsserviço.

Aqui aparecem alguns ganhos centrais:

Interface padronizada. O protocolo MCP define um formato de dados e uma forma de chamada unificados. Você escreve um MCP Server, e qualquer framework com suporte a MCP consegue chamá-lo diretamente: LangChain, CrewAI, AutoGen ou até um Agent Harness escrito por você.

Mecanismo de reutilização. A empresa cria internamente uma biblioteca de MCP Servers: um CRM Server, um ERP Server, um Mail Server. Um novo projeto de Agent quer conectar no CRM? Basta uma linha de configuração, sem reescrever a camada de adaptação.

Capacidade de governança. A ferramenta passa a ter ciclo de vida independente: gestão de versões, auditoria de chamadas e monitoramento de desempenho. Quando alguma ferramenta dá problema, fica claro onde olhar.

Composabilidade. A camada de Skills pode combinar várias ferramentas em um fluxo de trabalho. Por exemplo, a Skill “tratamento de reclamação de cliente” encadeia consulta ao CRM + criação de ticket + notificação por e-mail. Por baixo, são três ferramentas independentes; por cima, é um processo de negócio.

Outra analogia: antes você tinha uma oficina manual, fazendo cada pedido do zero; agora existe uma biblioteca de peças padronizadas, e o trabalho é montar.

Capítulo 2: protocolo MCP — o “padrão USB” dos AI Agents

2.1 O que é MCP, afinal?

MCP significa Model Context Protocol. Foi proposto pela Anthropic no fim de 2024 e, em 2026, já se tornou um padrão dominante para cadeias de ferramentas de Agent.

A definição oficial: um padrão aberto para conectar AI Agents a sistemas externos e fontes de dados.

Em linguagem direta: MCP define uma “especificação de descrição de ferramentas” e um “protocolo de chamada”. Quando um Agent quer chamar uma ferramenta, ele não precisa conhecer a implementação concreta. Basta ler o arquivo de descrição MCP, que contém nome da ferramenta, Schema de parâmetros, formato de retorno e requisitos de permissão.

Isso se parece muito com o padrão USB. USB define o formato da interface, a tensão e o protocolo de transmissão de dados. Fabricantes de mouse não precisam escrever um driver para cada computador; basta seguir o padrão USB. Fabricantes de computador não precisam criar uma interface para cada mouse; basta oferecer uma porta USB.

Com MCP, a lógica é a mesma: o fornecedor da ferramenta, ou você mesmo, segue o padrão MCP e escreve um MCP Server; o fornecedor do framework de Agent segue o padrão MCP e implementa um MCP Client. Quando os dois lados se conectam, a chamada funciona.

2.2 As três “primitivas” do MCP

O MCP define três primitivas centrais, correspondentes a diferentes donos do controle:

Tools, controladas pelo modelo. São ferramentas chamadas ativamente pelo Agent, como “consultar banco de dados” ou “enviar e-mail”. O Agent decide quando chamar cada Tool conforme a necessidade da tarefa.

Resources, controlados pela aplicação. São informações que fontes externas expõem ao Agent, como “base de conhecimento da empresa” ou “cadastro do cliente”. O Agent não chama ativamente; esses Resources são enviados ou indexados no contexto do Agent.

Prompts, controlados pelo usuário. São modelos de instrução definidos previamente pelo usuário, como “escreva um e-mail comercial formal em português”. O usuário escolhe um Prompt, e o Agent executa a tarefa correspondente.

A distinção entre essas três primitivas é, no fundo, uma divisão de controle: Tools são decididas pelo próprio Agent, Resources pelo sistema externo e Prompts pelo usuário.

2.3 Os problemas reais que MCP resolve

Eu comparei o antes e depois de usar MCP. Algumas dores realmente desapareceram.

Dor 1: explosão de adaptadores.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Antes: um adaptador por sistema externo; doze sistemas, doze conjuntos de código.
Agora: um MCP Server por sistema externo; o Agent só configura o MCP Client para chamar. Os doze Servers podem ser compartilhados por vários Agents, aumentando a reutilização.

Dor 2: quebra de contexto.

Antes: os dados retornados pela ferramenta de CRM não chegavam à ferramenta de e-mail.
Agora: MCP define um mecanismo unificado de passagem de Context. O pool de contexto do Agent pode ser lido e escrito pelas ferramentas: a ferramenta de CRM grava o e-mail do cliente, e a ferramenta de e-mail lê diretamente desse pool.

Dor 3: definições de ferramentas confusas.

Antes: cada ferramenta definia seu Schema de parâmetros de um jeito; algumas usavam JSON Schema, outras TypeScript interface, outras apenas comentários.
Agora: MCP exige um Schema compatível com OpenAPI 3.1. O formato e a validação ficam unificados, e a definição de ferramenta vira documentação padronizada.

Dor 4: dificuldade de implantação privada.

Antes: para sistemas internos de uma empresa, não existia adaptador pronto no mercado; era preciso escrever tudo.
Agora: MCP Server pode ser implantado de forma privada. A empresa cria uma biblioteca interna de MCP Servers, sem depender de fornecedores externos, mantendo os dados sob controle.

2.4 Estado do ecossistema MCP em 2026

Até abril de 2026, alguns números do ecossistema MCP:

• Na organização modelcontextprotocol do GitHub, já existem 150+ MCP Servers open source
• Os principais frameworks de Agent já oferecem suporte a MCP: LangChain, CrewAI, AutoGen, Semantic Kernel e OpenClaw
• O MCP Registry mantido oficialmente pela Anthropic reúne ferramentas, bancos de dados, APIs, sistemas de arquivos e outras categorias

Mas existe um problema que precisa ser encarado: MCP tem vulnerabilidades de segurança.

No início de 2026, a Infosecurity Magazine divulgou que o protocolo MCP tinha falhas sistêmicas de design, com risco potencial sobre 150M de downloads. As vulnerabilidades específicas incluem limites ambíguos de permissão em chamadas de ferramenta e a possibilidade de um MCP Server malicioso roubar dados de contexto do Agent.

Vou detalhar isso no capítulo de segurança. Por enquanto, fica o ponto: MCP não é uma solução perfeita. Antes de usar, é preciso fazer uma avaliação de segurança.

2.5 Boas práticas de MCP, a partir dos tropeços

Depois de mais de meio ano usando MCP, caí em alguns buracos e resumi três práticas.

Primeira: quanto mais clara a definição da ferramenta, melhor.

MCP exige OpenAPI Schema, mas muita gente escreve de forma vaga. Por exemplo, um parâmetro com description “ID do cliente” não diz se é o ID interno do CRM ou um número externo. O Agent passa o parâmetro errado, a ferramenta retorna vazio, e o Agent conclui que o cliente não existe.

Meu hábito hoje: a description de cada parâmetro explicita origem, formato e exemplo. Algo como: “ID do cliente: identificador interno único no sistema CRM, formato CUST-XXXXX, exemplo CUST-00123”.

Segunda: desenhe os limites de permissão antes.

Na primitiva Tools do MCP, o Agent pode chamar a ferramenta autonomamente. Mas nem toda ferramenta deve ser chamada assim. Uma operação como “excluir registro de cliente” não deve ter permissão autônoma.

Ao projetar um MCP Server, separe primeiro as operações que podem ser chamadas autonomamente daquelas que exigem confirmação humana. As primeiras viram Tools; as segundas viram Resources, se forem somente leitura, ou Prompts, se precisarem de acionamento do usuário.

Terceira: logs de chamada são obrigatórios.

A cadeia de chamada do MCP é Agent → MCP Client → MCP Server → sistema externo. Há duas camadas no meio, e, quando algo quebra, é difícil investigar.

Uso OpenTelemetry para rastreamento distribuído. Cada chamada registra um trace completo: horário em que o Agent iniciou, parâmetros, tempo de processamento do Server, retorno e exceções. Para investigar problemas, olhar trace é muito mais rápido do que adivinhar pelo código.

Capítulo 3: escolha de framework — qual cadeia de ferramentas combina com o seu cenário

3.1 Matriz comparativa dos frameworks principais

Aqui vai direto ao ponto, com uma comparação das diferenças centrais:

Desdobrando alguns eixos:

Curva de aprendizado. LangGraph é o mais íngreme, com muitos conceitos: grafo de estado, nós, arestas, ramificações condicionais. Leva cerca de uma semana para pegar bem. CrewAI é o mais suave: você define alguns papéis de Agent, atribui tarefas e consegue rodar em meio dia. AutoGen fica no meio; o modelo de colaboração por conversa é intuitivo, mas há muitos parâmetros de configuração.

Maturidade em produção. A família LangChain é veterana, com comunidade grande e muitos problemas já descobertos. CrewAI é estável, mas simplifica funcionalidades e sofre em cenários complexos. AutoGen teve problemas de estabilidade nas primeiras versões; em 2026 melhorou bastante, mas ainda não é a melhor escolha para produção de alta concorrência.

Suporte a MCP. LangChain e LangGraph têm a integração MCP mais completa, cobrindo as três primitivas: Tools, Resources e Prompts. CrewAI e AutoGen suportam chamadas básicas de Tools, mas Resources e Prompts exigem uma camada de adaptação própria.

Quantidade de ferramentas embutidas. LangChain tem 600+ ferramentas, cobrindo APIs e bancos de dados populares. CrewAI tem cerca de 20, focadas em cenários comuns. AutoGen não traz uma biblioteca pronta de ferramentas; você define tudo manualmente.

3.2 Framework de decisão para escolha

Na escolha de framework, não existe “o melhor”; existe “o mais adequado”. Eu uso quatro perguntas para decidir.

Pergunta 1: seu Agent é de tarefa única ou de colaboração multi-Agent?

Tarefa única: CrewAI ou LangChain dão conta.
Colaboração multi-Agent: LangGraph, com orquestração por grafo de estado, ou AutoGen, com colaboração conversacional. O modo Crew do CrewAI também faz multi-Agent, mas a capacidade de orquestração é mais fraca.

Pergunta 2: você precisa de protótipo rápido ou implantação de produção?

Protótipo rápido: CrewAI, rodando em meio dia e bom para demonstração.
Produção: LangGraph, com gestão de estado rigorosa e observabilidade completa via LangSmith. CrewAI também pode ir para produção, mas tende a não sustentar cenários muito complexos.

Pergunta 3: qual é a stack técnica da sua equipe?

Python como base: LangChain, CrewAI, AutoGen e OpenClaw servem.
.NET / ecossistema Microsoft: Semantic Kernel, com integração nativa a Azure e Visual Studio.
JavaScript / TypeScript: LangChain tem versão JS, embora o ecossistema seja menor que o da versão Python.

Pergunta 4: quantos sistemas externos você precisa conectar?

Menos de 5 sistemas: ferramentas embutidas do framework + algumas ferramentas customizadas; não é preciso pensar em MCP.
Mais de 5 sistemas: recomendo usar MCP. A integração MCP do LangChain é a mais completa; com CrewAI, você talvez precise escrever uma camada de adaptação.

3.3 Estratégia de combinação: 84% dos desenvolvedores usam múltiplas ferramentas

A pesquisa citada no começo dizia que 84% dos desenvolvedores usam vários recursos de programação com IA ao mesmo tempo. Aqui a questão não é escolher um framework e pronto; é combinar.

Já usei uma combinação: LangGraph, para a orquestração central, + CrewAI, para execução de tarefas.

O cenário era este: um sistema de Agent tinha várias etapas: análise de requisitos, desenho da solução, geração de código e validação por testes. O LangGraph cuidava do fluxo de estado geral, de requisitos → design → código → testes. Dentro de cada etapa, o CrewAI executava rapidamente, porque seu modelo de papéis e tarefas funciona bem para colaboração paralela em uma fase.

A lógica dessa combinação: LangGraph cuida do esqueleto, com grafo de estado, ramificações condicionais e recuperação de exceções; CrewAI cuida da musculatura, com colaboração leve entre múltiplos papéis em uma fase. O esqueleto usa um framework maduro; a musculatura usa um framework leve. Cada um faz o que faz melhor.

Outra combinação comum: IDE Agent para o trabalho diário + Agent de terminal para problemas difíceis.

O IDE Agent fica no VSCode ou JetBrains e ajuda no dia a dia: escrever código, refatorar, consultar documentação. O Agent de terminal roda como processo independente e lida com problemas complexos, como depurar chamadas entre serviços ou investigar gargalos de performance. Os dois compartilham uma biblioteca de ferramentas por MCP. A ferramenta usada pelo IDE Agent também fica disponível para o Agent de terminal.

Capítulo 4: caminho de evolução de ferramenta isolada para ecossistema

Vou usar minha própria evolução como exemplo, dividida em quatro estágios.

4.1 Primeiro estágio: protótipo em um único framework

No início, escolhi CrewAI. O motivo era simples: documentação curta, exemplos claros e execução em meio dia.

Naquele momento, o requisito era simples: um Agent de atendimento que consultasse uma base de conhecimento e respondesse perguntas frequentes. As ferramentas embutidas do CrewAI eram suficientes: uma Search Tool para buscar na base e uma Response Tool para responder.

O objetivo desse estágio: colocar para rodar e validar que o Agent resolve um problema real. Não pensar em arquitetura, expansão nem MCP. Fazer o protótipo e mostrar ao gerente de produto.

O tropeço: usei a configuração padrão do CrewAI e só depois descobri que alguns parâmetros tinham valores default inadequados ao meu caso. Por exemplo, o parâmetro top_k da busca na base de conhecimento retornava 5 resultados por padrão. Minha base era pequena; 3 resultados bastavam. Com mais resultados, o Agent se confundia. Levei um bom tempo depurando até descobrir que o parâmetro estava escondido no fundo do arquivo de configuração.

Lição: configuração padrão de framework não é necessariamente ótima. Ajuste conforme o cenário. No estágio de protótipo, leia a documentação; não economize onde não deve.

4.2 Segundo estágio: desenvolvimento de ferramentas customizadas

Depois que o protótipo rodou, entrou um novo requisito: o Agent precisava consultar informações de clientes no CRM.

CrewAI não tinha ferramenta embutida para nosso CRM. Tive que escrever uma. A primeira ferramenta customizada levou meio dia: definir Schema de parâmetros, escrever a chamada de API, tratar exceções e adicionar logs.

A primeira até foi tranquila. Depois vieram novos requisitos: consultar ERP, consultar relatórios de BI, enviar e-mail, criar ticket…

Quando cheguei à quinta ferramenta customizada, comecei a perceber o problema:

Código duplicado. A lógica de tratamento de exceções, formato de logs e validação de parâmetros era parecida em todas as ferramentas, mas ficava espalhada em arquivos diferentes. Para reutilizar, era preciso copiar e colar, depois trocar nomes de parâmetros.

Definições confusas. Algumas ferramentas usavam JSON Schema para parâmetros; outras usavam TypeScript interface; outras estavam documentadas em comentários. O formato era inconsistente, e o Agent errava parâmetros com facilidade.

Depuração difícil. Quando o Agent chamava uma ferramenta e recebia resultado vazio, não ficava claro se a ferramenta caiu, se o parâmetro estava errado ou se o sistema externo não tinha dados. Era preciso olhar logs da ferramenta, mas os logs estavam espalhados em vários arquivos. A investigação era lenta.

O ponto de virada desse estágio foi pensar: “será que dá para unificar a interface das ferramentas?“

4.3 Terceiro estágio: introdução do MCP

Ao ler a documentação do LangChain, vi a introdução ao MCP e decidi testar.

Primeiro passo: reescrever as cinco ferramentas customizadas existentes no formato de MCP Server.

MCP exige Schema compatível com OpenAPI 3.1. Gastei dois dias nisso: transformei JSON Schemas e comentários em formato padronizado, acrescentei exemplos de parâmetros, exemplos de retorno e definição de códigos de erro.

Segundo passo: integrar o MCP Client ao Agent Harness.

Nessa parte, o LangChain já tinha uma implementação pronta de MCP Client, e algumas linhas de configuração bastaram. Mas CrewAI não tinha. Precisei escrever por conta própria uma camada de adaptação de MCP Client, o que levou três dias.

Terceiro passo: validar reutilização.

Um novo projeto de Agent precisava consultar CRM. Configurei diretamente o MCP Server já existente, em uma linha de código, sem reescrever lógica de adaptação e sem alterar Schema de parâmetros. A reutilização realmente funcionou.

O ganho desse estágio: as cinco ferramentas viraram MCP Servers. Nos projetos de Agent seguintes, bastava configurar chamadas. A taxa de reutilização subiu, e o custo de manutenção caiu.

Mas houve custo: dois dias para reescrever e três dias para adaptar o MCP Client do CrewAI. Cinco dias no total, mais do que os dois dias e meio que eu gastaria escrevendo cinco ferramentas customizadas.

Equilíbrio de investimento e retorno: se existe apenas um projeto de Agent, MCP não compensa; o custo de reescrita é maior que o ganho. Se existem vários projetos de Agent, MCP vale a pena; a reutilização dilui o custo inicial.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Minha decisão naquele momento: haveria mais projetos de Agent no futuro, então o investimento em MCP valia.

4.4 Quarto estágio: construção do ecossistema de ferramentas

Depois de introduzir MCP, comecei a construir uma biblioteca interna de MCP Servers.

Primeiro passo: classificação das ferramentas.

Classifiquei as ferramentas existentes por domínio de negócio: CRM, com consulta e atualização de clientes; ERP, com consulta de pedidos e estoque; notificações, com e-mail, SMS e tickets. Cada categoria ganhou um diretório de MCP Server.

Segundo passo: gestão de versões.

Cada MCP Server recebeu uma versão, como v1.0, v1.1 e v2.0. Ao chamar, o Agent especifica a versão, evitando mudanças de comportamento quando a ferramenta é atualizada. Usei Git para gerenciar versões, com um branch por versão.

Terceiro passo: monitoramento de chamadas.

Adicionei OpenTelemetry Tracing, registrando a cadeia completa de cada chamada MCP. O painel de monitoramento mostra frequência de chamadas, latência média, taxa de exceções e ranking de ferramentas com falhas. Quando uma ferramenta dá problema, fica claro onde está.

Quarto passo: governança de permissões.

A operação “excluir registro de cliente” não foi exposta como Tool; ficou disponível apenas como Resource, em modo somente leitura. O Agent pode consultar clientes autonomamente; excluir clientes exige confirmação humana.

O objetivo desse estágio: sair de uma “biblioteca de ferramentas” para um “sistema de governança de ferramentas”. A ferramenta deixa de ser só código e passa a ter ciclo de vida, monitoramento e limites de permissão.

4.5 Quinto estágio: colaboração multi-Agent, onde ainda não cheguei

O próximo passo planejado é: Agent único → orquestração multi-Agent.

Aqui, o modo de grafo de estado do LangGraph é a solução dominante. Vários nós de Agent usam um grafo de estado para definir condições de transição, lógica de ramificação e recuperação de exceções.

Na cadeia de ferramentas, a colaboração multi-Agent traz dois novos problemas:

Compartilhamento de ferramentas vs isolamento de permissões.

Vários Agents compartilham o mesmo MCP Server, mas cada um tem suas próprias permissões. Por exemplo, Agent A pode consultar CRM, Agent B pode consultar ERP, mas um não pode chamar as ferramentas do outro.

O design dos limites de permissão do MCP é pré-requisito aqui. Se isso foi feito no quarto estágio, o quinto já pode reutilizar.

Passagem de estado.

Agent A chama o CRM e obtém o e-mail do cliente. Agent B precisa usar esse e-mail para enviar uma mensagem. Como transmitir o estado?

O pool de estado do LangGraph é compartilhado por todos os nós de Agent. O mecanismo de contexto do MCP também permite transmitir estado entre ferramentas. Combinando os dois, a passagem de estado funciona.

Ainda estou pesquisando essa parte, então não vou expandir por enquanto.

Capítulo 5: adoção empresarial — do conceito à produção

5.1 Cenário financeiro: linha de processamento de sinistros

Um amigo de um banco criou, em 2026, um Agent para sinistros de seguro.

Cenário: o cliente envia um pedido de sinistro, e o Agent automatiza o processamento: consulta apólice, consulta registros médicos, calcula o valor de indenização, gera relatório de sinistro e notifica o cliente.

Design da cadeia de ferramentas:

• MCP Server de consulta de apólice: conecta ao sistema central de seguros
• MCP Server de registros médicos: conecta a interfaces de dados hospitalares
• MCP Server de motor de cálculo: usa a base interna de regras de indenização
• MCP Server de notificação: e-mail + SMS + push no APP

Arquitetura:

LangGraph gerencia o fluxo de estado, de solicitação → consulta de apólice → consulta médica → cálculo → relatório → notificação, e cada nó chama MCP Servers internamente.

Ganho:

O tempo médio de processamento de sinistros caiu de 3 dias para 8 horas. A taxa de intervenção humana caiu de 40% para 15%. A maior parte dos sinistros padronizados passou a ser tratada automaticamente pelo Agent; só casos complexos vão para revisão humana.

Armadilha encontrada:

Auditoria de conformidade. Em cenários financeiros, cada chamada de ferramenta precisa deixar um registro auditável. Eles adicionaram uma camada de auditoria ao MCP Server: cada chamada registra horário, chamador, parâmetros, retorno e ID do auditor.

Garantia de SLA. O Agent de sinistros tinha requisito de SLA: P99 de resposta <872ms, limiar de nível três definido pelo SITS2026. Eles otimizaram a performance dos MCP Servers com cache de dados de apólice, chamada assíncrona da interface médica e pré-cálculo de indenizações.

5.2 Cenário de atendimento: ecossistema de ferramentas para Voice Agent

Em 2026, a penetração de AI Agent no atendimento chegou a 72%.

Uma empresa de atendimento inteligente criou um Voice Agent: o cliente liga, e o Agent resolve diretamente, sem transferir para um humano.

Design da cadeia de ferramentas:

• CRM MCP Server: consulta informações do cliente e histórico de pedidos
• Pedido MCP Server: consulta status do pedido e informações de logística
• Ticket MCP Server: cria tickets de pós-venda e consulta andamento
• Base de conhecimento MCP Server: consulta documentação de produto e FAQ

Arquitetura:

O Voice Agent usa Semantic Kernel, integrado ao Azure Speech Services, com MCP Client conectado a quatro Servers.

Dados de desempenho:

• Tempo médio de resposta: 500ms
• Taxa de resolução autônoma: 85%, com o Agent resolvendo diretamente a dúvida do cliente e 15% sendo transferidos para humanos
• Tempo de tratamento após intervenção humana: 30% menor que no atendimento totalmente humano

Ponto técnico:

Velocidade de resposta é central. Voice Agent não pode deixar o cliente esperando demais. Os MCP Servers dessa empresa usam cache local: dados de consulta frequente, como FAQ de produtos populares, ficam na memória do Agent. Ao chamar MCP, ele consulta primeiro o cache; se não houver acerto, só então chama o sistema externo.

5.3 Cenário industrial: Agent de inspeção de equipamentos

Um amigo em uma empresa de manufatura criou um Agent de inspeção de equipamentos.

Cenário: equipamentos de fábrica são inspecionados periodicamente. O Agent coleta dados de sensores automaticamente, avalia o estado do equipamento, gera relatório de inspeção e, em caso de anomalia, abre uma ordem de manutenção.

Design da cadeia de ferramentas:

• Sensor MCP Server: conecta à plataforma de dados IoT
• Arquivo de equipamento MCP Server: consulta histórico de manutenção
• Manutenção MCP Server: cria ordem de manutenção e notifica técnicos
• Relatório MCP Server: gera e arquiva relatórios de inspeção

Arquitetura:

CrewAI atua como corpo principal do Agent, estruturando a tarefa de inspeção, e o MCP Client chama quatro Servers.

Ganho:

A eficiência da inspeção subiu 40%: uma inspeção manual de 2 horas caiu para 45 minutos com o Agent. A taxa de omissão caiu de 5% para 1%, porque o Agent coleta dados automaticamente e não esquece sensores.

Armadilha encontrada:

Formatos de dados IoT bagunçados. Sensores de equipamentos diferentes tinham formatos variados: alguns JSON, outros CSV, outros protocolos binários proprietários. O Sensor MCP Server deles criou uma camada de adaptação de formato, convertendo tudo para JSON antes de entregar ao Agent.

5.4 Elementos comuns na adoção empresarial

Esses cenários têm algo em comum: começar pequeno, a partir de uma dor concreta.

O Agent financeiro não queria “revolucionar o processo de sinistros”; queria “reduzir o tempo de processamento”. O Agent de atendimento não queria “substituir todos os atendentes”; queria “aumentar a taxa de resolução autônoma”. O Agent industrial não queria “automatizar a fábrica inteira”; queria “otimizar a etapa de inspeção”.

O consenso de 2026 é que a expectativa de ROI de Agents precisa voltar ao terreno racional. Não é “mudar tudo”, e sim “resolver um problema específico”.

Alguns fatores-chave de adoção:

Fator 1: SLA claro.

O Agent financeiro tinha SLA, P99 <872ms; o Agent de atendimento tinha SLA, média <500ms. O design da cadeia de ferramentas do Agent precisa sustentar o SLA. Cache, assincronia e pré-cálculo são meios para isso.

Fator 2: auditoria e conformidade.

Em cenários financeiros e de atendimento, cada chamada de ferramenta precisa deixar registro. Adicionar uma camada de auditoria ao MCP Server é padrão.

Fator 3: começar pequeno.

Não comece com um grande sistema de Agent. Escolha primeiro um cenário específico, crie um Agent único, valide o ganho e só então expanda.

Fator 4: ciclo de 3 a 6 meses.

Levar Agent para produção não é uma tarefa de uma semana. O projeto do amigo no setor financeiro levou 6 meses do protótipo à produção. O projeto de atendimento levou 4 meses. O industrial, 3 meses. A expectativa precisa ser razoável.

Capítulo 6: segurança e governança — as “linhas vermelhas” da cadeia de ferramentas

6.1 Alerta sobre vulnerabilidades de segurança do MCP

Esta parte precisa ser dita com seriedade. MCP não é uma solução perfeita; vulnerabilidades foram divulgadas no início de 2026.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

O relatório da Infosecurity Magazine apontou que o protocolo MCP tinha falhas sistêmicas de design, com risco potencial sobre 150M de downloads.

Vulnerabilidade 1: limites ambíguos de permissão em chamadas de ferramenta.

Na primitiva Tools do MCP, o Agent pode chamar ferramentas autonomamente. Mas o protocolo em si não define limites de permissão. Um MCP Server malicioso pode expor operações perigosas, como “excluir todos os dados”, e o Agent pode chamá-las sem perceber.

Vulnerabilidade 2: vazamento de dados de contexto.

O mecanismo de contexto do MCP permite que todas as ferramentas leiam e escrevam. Um MCP Server malicioso pode ler dados de contexto do Agent, incluindo entrada do usuário e informações sensíveis retornadas por outras ferramentas.

Vulnerabilidade 3: ataque de supply chain.

MCP Servers open source podem conter código malicioso. Um desenvolvedor baixa um MCP Server do GitHub e usa sem auditoria; esse Server malicioso pode roubar dados ou adulterar resultados.

6.2 Princípios de design seguro para cadeias de ferramentas

Ao usar MCP, adicionei três camadas de proteção.

Primeira camada: clareza de intenção.

A definição de ferramenta MCP precisa explicar claramente “o que esta ferramenta faz” e “quais riscos existem”. Uso o campo description do OpenAPI para escrever uma nota de segurança em cada ferramenta.

Por exemplo, para a ferramenta “excluir registro de cliente”, a description diz: “Exclui registros de cliente no CRM. A operação é irreversível e exige confirmação humana. A permissão precisa ser revisada antes da chamada.”

Antes de chamar a ferramenta, o Agent lê a description e entende o risco. Então decide se pode chamar autonomamente ou se deve encaminhar para confirmação humana.

Segunda camada: isolamento de estado.

O pool de contexto do MCP, por padrão, poderia ser lido e escrito por todas as ferramentas. Nessa parte, implementei isolamento. Cada MCP Server tem uma área de contexto independente e não pode ler nem escrever a área de outros Servers.

Os dados retornados pela ferramenta de CRM só podem ser lidos pela ferramenta de CRM e pela ferramenta de e-mail. Outras ferramentas, como manutenção, não podem ler. Dados sensíveis não se espalham.

Terceira camada: observabilidade em primeiro lugar.

Cada chamada MCP registra um trace completo: chamador, parâmetros, retorno e exceções. OpenTelemetry Tracing é configuração padrão.

Quando há problema, os logs de trace localizam rapidamente a causa. Em auditorias de segurança, os logs de trace servem como evidência.

6.3 Framework de governança empresarial

Uma biblioteca interna de MCP Servers precisa de governança.

Governança 1: gestão do ciclo de vida.

Cada MCP Server tem número de versão, data de lançamento, responsável e lista de dependências. Quando uma ferramenta é atualizada, passa por fluxo de revisão. Não é aceitável publicar uma versão nova de qualquer jeito.

Ao chamar, o Agent bloqueia a versão. Não há atualização automática, evitando mudanças súbitas de comportamento.

Governança 2: auditoria de chamadas.

Cada chamada MCP registra logs de auditoria: horário, chamador, parâmetros, retorno e auditor. Em cenários financeiros, isso é requisito de conformidade.

Governança 3: monitoramento de SLA.

Tempo de resposta, taxa de exceções e disponibilidade dos MCP Servers são monitorados continuamente. Quando o SLA não é atingido, há alerta + degradação automática, por exemplo alternando para um Server reserva.

Governança 4: matriz de permissões.

Matriz entre papel do Agent e permissões de ferramenta. Agent A pode chamar ferramentas de CRM; Agent B não. Outra matriz cruza tipo de operação e permissão: operações de “consulta” podem ser chamadas autonomamente pelo Agent; operações de “exclusão” exigem confirmação humana.

Eu gerencio esse framework de governança em um documento: uma página por MCP Server, com histórico de versões, matriz de permissões, requisitos de auditoria, metas de SLA e responsável.

Conclusão

Depois de tudo isso, alguns pontos centrais fecham a conversa.

1. O design da cadeia de ferramentas é a linha divisória entre Agent como “brinquedo” e Agent como “ferramenta de produtividade”.

Na fase de protótipo, uma ferramenta isolada basta. Na fase de produção, um ecossistema de ferramentas é necessário. Sem ecossistema, o Agent resolve talvez 20% dos cenários; com ecossistema, pode chegar a 80%.

2. MCP está se tornando o “padrão USB” dos sistemas de IA, e vale investir em aprendizado.

Em 2026, o ecossistema MCP amadureceu, e os frameworks principais já oferecem suporte. Mas MCP não é perfeito: há vulnerabilidades de segurança, e é preciso avaliar antes de usar. Avalie ganhos, como reutilização e governança, contra custos, como reescrita e segurança.

3. A escolha de framework depende do cenário; combinar, e não escolher um só, é o padrão de 2026.

LangGraph é adequado para produção complexa, CrewAI para protótipos rápidos, AutoGen para conversas multi-Agent. Quando um único framework não basta, combine. É isso que os 84% dos desenvolvedores estão fazendo.

4. A adoção empresarial exige pragmatismo: começar pequeno e atacar uma dor real.

O Agent financeiro entrou pelo processo de sinistros; o Agent de atendimento entrou pelo cenário de voz; o Agent industrial entrou pela inspeção. A expectativa de ROI volta ao racional: ciclo de 3 a 6 meses, SLA e auditoria como padrão.

Recomendações práticas

Se você está construindo um sistema de Agent, algumas recomendações:

Se você está no primeiro protótipo de Agent:

Escolha CrewAI e rode em meio dia. Use ferramentas embutidas + poucas ferramentas customizadas. Não pense em MCP por enquanto; primeiro valide que o Agent resolve um problema real.

Se você precisa de colaboração multi-Agent:

LangGraph + MCP é uma escolha sólida. LangGraph gerencia o fluxo de estado; MCP gerencia a reutilização de ferramentas. O custo de investimento é médio e o ganho se dilui no longo prazo.

Se você já tem ferramentas isoladas, mas os requisitos estão ficando complexos:

Planeje uma biblioteca de MCP Servers. Reescrever ferramentas customizadas como MCP Servers tem custo inicial alto, mas a reutilização posterior dilui esse custo. Condição: você precisa ter vários projetos de Agent para que a reutilização valha.

Se você mira produção empresarial:

Use como referência os casos de finanças, atendimento e manufatura. SLA claro, auditoria e conformidade, começar pequeno e ciclo de 3 a 6 meses. Governança de segurança vem antes; o design dos limites de permissão das ferramentas é pré-requisito.