Quando comecei a construir o sistema de automação de suporte no meu último projeto, me deparei com um problema que suspeito que muitos engenheiros de IA acabam encontrando: o sistema precisava fazer coisas demais, e toda abordagem que eu tentava piorava a situação.
O fluxo de trabalho era genuinamente complexo. Os tickets de suporte recebidos precisavam ser lidos e classificados. Problemas urgentes tinham que acionar notificações imediatas para a equipe certa. Relatórios de bugs precisavam criar cards na ferramenta de gerenciamento de projetos. Perguntas de rotina precisavam ser roteadas para uma fila, e tipos específicos de tickets precisavam ir para squads específicos. Cada um desses passos tocava uma plataforma diferente, uma API diferente, um formato de dado diferente.
Meu primeiro instinto foi construir um agente grande que gerenciasse tudo. Essa abordagem durou cerca de duas semanas antes de colapsar sob seu próprio peso. Cada edição de prompt para melhorar a classificação quebrava a lógica de notificação. Cada mudança de API se propagava por uma função monolítica que era difícil de testar e ainda mais difícil de entender. Eu precisava de uma arquitetura diferente.
MCP — Model Context Protocol — acabou sendo a ferramenta certa. Aqui está o que construí e por que o design distribuído tornou tudo mais sustentável.
Por que o MCP se encaixa nesse problema
O insight central por trás do MCP é que agentes de IA funcionam melhor quando suas ferramentas são bem definidas e combináveis. Em vez de um agente com acesso a tudo, você define servidores MCP focados — cada um responsável por um domínio de integração específico — e deixa o agente orquestrador decidir quais ferramentas chamar.
Para um fluxo de automação de suporte, isso se mapeia naturalmente:
- Um servidor MCP é dono da integração com a plataforma de suporte (leitura de tickets, atualização de status, movimentação para filas)
- Um servidor MCP é dono das notificações (mensagens no Slack, alertas para equipes)
- Um servidor MCP é dono do gerenciamento de projetos (criação de bug cards, atribuição de issues)
- O agente de IA lê tickets por um servidor e coordena respostas pelos outros
Essa separação me permitiu testar cada servidor de forma independente, atualizar a integração com o Slack sem tocar na lógica de triagem, e raciocinar claramente sobre o que cada peça era responsável.
Construindo o servidor MCP de triagem
O servidor da plataforma de suporte é onde os tickets entram no sistema. Ele expõe tanto recursos (dados de tickets que o agente pode ler) quanto ferramentas (ações que o agente pode tomar). As constantes de schema tipadas do SDK do MCP são a chave para fazer isso certo:
Usar as constantes de schema tipadas (ListResourcesRequestSchema, CallToolRequestSchema, etc.) é importante — elas fornecem segurança de tipo adequada para roteamento e validação de resposta. No início da minha prototipagem eu usava handlers baseados em strings, o que funcionava, mas perdia as informações de tipo e tornava a depuração mais difícil.
Recursos expõem a fila de tickets como dados legíveis:
Ferramentas expõem as ações que o agente precisa executar após tomar uma decisão de triagem:
O servidor de notificações
O servidor de notificações do Slack segue o mesmo padrão — os mesmos schemas tipados, escopo focado. Seu trabalho é simples: enviar a mensagem certa para o canal certo quando algo precisa de atenção humana.
O agente de triagem: SDK Anthropic conectando tudo
O agente que une tudo usa o SDK da Anthropic para raciocínio e o SDK do MCP para conectar-se aos servidores. Para esse tipo de tarefa de classificação e roteamento, o claude-haiku-4-5-20251001 foi a escolha certa de modelo — rápido, preciso para classificação estruturada e econômico o suficiente para rodar em cada ticket recebido.
As definições de ferramentas que o agente vê vêm dos servidores MCP. No sistema de produção, escrevi uma camada adaptadora que traduz o ListToolsResponse do MCP para o formato de definição de ferramentas da Anthropic — os schemas são compatíveis, é principalmente renomeação de campos. O agente escolhe qual ferramenta chamar com base na sua análise; o servidor MCP valida a entrada e a executa.
O que a arquitetura possibilitou
Após a refatoração, algumas coisas melhoraram visivelmente.
Os testes se tornaram viáveis. Cada servidor MCP pôde ser testado em isolamento com dados simulados. O agente de triagem pôde ser testado com um servidor MCP simulado que retornava respostas previsíveis. Antes da refatoração, testar exigia subir o sistema inteiro.
A iteração de prompts não quebrou integrações. Quando quis melhorar a precisão da classificação do agente para tickets técnicos adjacentes à cobrança, só editei o prompt de triagem. A lógica de notificação do Slack e o servidor de gerenciamento de projetos não foram afetados.
Os modos de falha se tornaram localizados. Quando a API de gerenciamento de projetos teve uma interrupção, a triagem e as notificações continuaram funcionando. O agente registrou que a criação do bug card falhou e seguiu em frente. Um design monolítico teria sido muito mais difícil de tornar resiliente dessa forma.
A desvantagem é a complexidade inicial — configurar três servidores separados com seu próprio transporte e inicialização é mais código repetitivo do que um serviço único. Mas para um fluxo de trabalho que roda continuamente e precisa evoluir conforme as necessidades da equipe mudam, esse investimento se pagou rapidamente.
O padrão prático
Se você está construindo um fluxo de automação de suporte multiplataforma, aqui está a abordagem que eu recomendaria:
- Desenhe um limite ao redor de cada sistema externo. Cada limite se torna um servidor MCP.
- Mantenha cada servidor focado — recursos expõem os dados que o agente precisa ler, ferramentas expõem as ações que ele pode tomar. Não deixe um servidor fazer tudo.
- Use as constantes de schema tipadas (
ListToolsRequestSchema,CallToolRequestSchema) desde o início. A segurança de tipo compensa quando você está depurando por que uma chamada de ferramenta retornou o formato errado. - Escolha o tamanho do modelo deliberadamente. Para classificação estruturada em categorias conhecidas, um modelo menor e mais rápido geralmente é a escolha certa. Reserve o raciocínio mais pesado para fluxos onde o agente precisa sintetizar respostas novas.
O sistema de automação de suporte do qual isso resultou lidou com tráfego de produção, e a arquitetura aguentou sob carga real. O ponto forte real do MCP é que ele oferece uma maneira principiada de dar aos agentes de IA acesso a sistemas externos sem transformar seu código em um emaranhado de chamadas de API misturadas com lógica de prompt. Essa separação vale o custo de configuração.