 |
| Bellacosa Mainframe mcp design patterns |
☕ Um Café no Bellacosa Mainframe
MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)
"Todo desenvolvedor júnior se encanta pelo agente. O desenvolvedor sênior se preocupa com a arquitetura. O arquiteto sabe que um agente inteligente sobre uma arquitetura ruim apenas toma decisões erradas mais rapidamente."
Durante muitos anos nós, programadores, aprendemos que desenvolver software significava criar classes, funções, APIs e bancos de dados.
Depois vieram os microsserviços.
Depois Kubernetes.
Depois Serverless.
Agora chegou a vez da Inteligência Artificial.
Mas existe um erro que praticamente todo iniciante comete.
Ele acredita que construir um sistema baseado em IA significa apenas conectar o ChatGPT a uma API.
Não significa.
Na verdade, isso representa apenas uma pequena parte da arquitetura.
É exatamente aqui que entra um conceito que provavelmente será tão importante quanto REST foi para os sistemas distribuídos:
Model Context Protocol (MCP).
Mas existe uma segunda descoberta que poucos fazem no início da jornada.
O MCP resolve a comunicação.
Os Design Patterns resolvem o problema real.
Hoje vamos entender profundamente por quê.
Pegue seu café.
Porque esta conversa pode mudar completamente sua forma de enxergar agentes inteligentes.
O que realmente é o MCP?
Imagine um programador COBOL chegando ao escritório.
Ele precisa consultar:
CICS
Db2
IMS
RACF
VSAM
MQ
arquivos JCL
documentação
APIs REST
Cada tecnologia possui uma interface diferente.
Agora imagine um engenheiro de IA.
Ele possui exatamente o mesmo problema.
Só que o usuário é um LLM.
O LLM não sabe conversar com Db2.
Não entende CICS.
Nunca ouviu falar em JES2.
Muito menos em um dataset PDS.
Então alguém precisava criar um idioma universal.
Esse idioma recebeu o nome de Model Context Protocol (MCP).
Pense nele como um USB-C.
Você não precisa mais fabricar um cabo diferente para cada dispositivo.
Todos falam o mesmo protocolo.
O mesmo acontece com IA.
Ao invés de ensinar cada modelo a conversar com milhares de APIs diferentes...
Criamos um protocolo único.
MCP não é um Framework
Esse é outro erro comum.
MCP não substitui:
Spring Boot
FastAPI
Express
ASP.NET
Ele também não substitui:
REST
GraphQL
gRPC
Na verdade...
Ele vive acima deles.
Usuário
↓
LLM
↓
MCP Client
↓
MCP Server
↓
REST
SOAP
GraphQL
SQL
MQ
Filesystem
Mainframe
Perceba que o MCP não elimina tecnologias existentes.
Ele apenas organiza o acesso a elas.
O maior erro dos iniciantes
Quase todo mundo faz isso.
"Vou criar um MCP."
Mas ninguém pergunta:
Meu fluxo realmente funciona como?
Essa pergunta vale milhões.
Porque existem dezenas de maneiras diferentes de organizar um sistema baseado em IA.
É exatamente para isso que servem os Design Patterns.
Pense como um arquiteto
Um arquiteto não começa desenhando portas.
Ele pergunta:
Será uma escola?
Hospital?
Shopping?
Casa?
Prédio?
O mesmo vale para MCP.
Não existe um único padrão.
Existe o padrão correto para determinado problema.
Vamos conhecer cada um deles.
Pattern 1 — Local Resource Access
É o padrão mais simples.
Mas também um dos mais utilizados.
Imagine um agente que precisa responder perguntas usando documentos internos.
PDFs.
Excel.
TXT.
CSV.
Imagens.
JCL.
COBOL.
PL/I.
Datasets.
Não faz sentido enviar tudo para a nuvem.
Então o MCP acessa diretamente o sistema de arquivos.
LLM
↓
Servidor MCP
↓
Filesystem
Simples.
Seguro.
Rápido.
Exemplo no Mainframe
Imagine perguntar:
"Liste todos os JOBs que utilizam SORT."
O MCP poderia analisar:
SYS1.PROCLIB
SYS2.PROCLIB
USER.JCL
PRODUCTION.JOBS
Sem copiar absolutamente nada para fora do ambiente z/OS.
Esse padrão é fantástico para ambientes regulados.
Curiosidade
Empresas financeiras dificilmente aceitam que seus documentos internos sejam enviados para provedores externos de IA.
Por isso, o Local Resource Pattern provavelmente será um dos mais utilizados nos próximos anos.
Pattern 2 — Hierarchical MCP
Agora o sistema começou a crescer.
Imagine uma fintech.
Ela possui:
Clientes.
Pagamentos.
PIX.
Cartões.
Fraude.
CRM.
Cobrança.
Tudo misturado.
Um caos.
Então surge um roteador principal.
Agente
↓
Router MCP
↓
Clientes
↓
Pagamentos
↓
PIX
↓
Fraudes
Cada servidor conhece apenas seu domínio.
Exatamente como microsserviços.
Analogia Mainframe
Pense em um Sysplex.
Cada LPAR executa determinadas cargas.
Existe coordenação.
Mas ninguém tenta fazer tudo sozinho.
O mesmo acontece aqui.
Pattern 3 — Event Driven
Esse padrão muda completamente a filosofia.
Nem tudo precisa acontecer imediatamente.
Às vezes basta gerar um evento.
Pedido recebido
↓
MQ
↓
Servidor MCP
↓
Worker
↓
Resposta futura
Isso lembra bastante:
IBM MQ
Kafka
RabbitMQ
Event Streams
Exemplo corporativo
Recebeu uma nota fiscal.
↓
Extrair dados.
↓
Classificar.
↓
Enviar ao ERP.
↓
Gerar relatório.
↓
Enviar e-mail.
Tudo isso pode acontecer sem bloquear o usuário.
Exemplo IBM Z
CICS
↓
MQ
↓
MCP
↓
Análise
↓
Atualiza Db2
↓
Notifica operador
É exatamente a filosofia dos sistemas orientados a eventos.
Pattern 4 — MCP-to-Agent
Agora chegamos onde a IA realmente fica interessante.
Imagine um único agente tentando responder tudo.
Financeiro.
Jurídico.
RH.
Infraestrutura.
Banco de dados.
Não parece uma boa ideia.
Então fazemos exatamente o contrário.
Criamos especialistas.
Supervisor
↓
Especialista COBOL
Especialista Db2
Especialista CICS
Especialista RACF
Especialista MQ
Cada um conhece profundamente sua área.
Depois alguém junta as respostas.
Isso é arquitetura Multi-Agent.
Imagine isso
Usuário pergunta:
"Por que meu JOB terminou com RC=12?"
O supervisor encaminha a pergunta para:
Especialista JCL
Especialista SORT
Especialista Db2
Especialista JES2
Todos analisam simultaneamente.
Depois entregam um diagnóstico consolidado.
Muito mais eficiente.
Pattern 5 — Composite Service
Agora o MCP vira um maestro.
Ele coordena vários serviços.
Consulta Cliente
↓
Consulta Crédito
↓
Consulta Receita
↓
Consulta ERP
↓
Consulta Open Finance
↓
Resposta
Para o usuário parece uma única ferramenta.
Mas internamente dezenas de APIs trabalharam juntas.
Exemplo Mainframe
Abrir uma conta.
O MCP pode chamar:
CICS
Db2
MQ
RACF
z/OS Connect
API do CRM
Tudo automaticamente.
Pattern 6 — Direct API Wrapper
É o mais simples.
Você já possui APIs.
Só precisa expô-las.
REST
↓
MCP
↓
LLM
Não existe necessidade de reinventar nada.
Esse padrão é excelente para:
MVP
Provas de conceito
Hackathons
Integrações rápidas
Comparando todos os padrões
| Pattern | Complexidade | Escala | Quando usar |
|---|---|---|---|
| Local Resource | Muito baixa | Média | Arquivos locais |
| Direct API | Baixa | Alta | APIs existentes |
| Composite | Média | Alta | Integrações |
| Event Driven | Alta | Muito alta | Processamentos longos |
| Hierarchical | Alta | Muito alta | Grandes empresas |
| MCP-to-Agent | Muito alta | Extremamente alta | IA especializada |
Como isso conversa com RAG?
Muita gente confunde.
RAG não substitui MCP.
MCP não substitui RAG.
Eles trabalham juntos.
Imagine:
Pergunta
↓
Agente
↓
RAG procura conhecimento
↓
MCP executa ação
↓
Resposta
Um encontra informação.
O outro executa tarefas.
São complementares.
E onde entra o Prompt Engineering?
Outro mito.
Prompt Engineering não desapareceu.
Na verdade ficou ainda mais importante.
Agora temos:
Prompt do usuário
Prompt do agente
Prompt das ferramentas
Prompt dos especialistas
Prompt do supervisor
É uma arquitetura inteira de prompts.
Observabilidade: o detalhe que todo mundo esquece
Quem respondeu?
Qual ferramenta foi utilizada?
Quanto tempo demorou?
Qual API falhou?
Qual agente tomou determinada decisão?
Sem observabilidade...
Você nunca conseguirá depurar um sistema baseado em IA.
Da mesma forma que usamos:
SMF
RMF
SDSF
JES2
para monitorar o z/OS,
precisaremos monitorar agentes.
Provavelmente surgirão verdadeiros "SDSFs para IA".
Segurança
Este talvez seja o assunto mais importante.
Imagine um agente com acesso irrestrito.
Ele poderia:
Excluir arquivos.
Cancelar JOBs.
Criar usuários.
Alterar tabelas.
Assustador.
Por isso o MCP precisa respeitar princípios como:
Menor privilégio (Least Privilege)
Zero Trust
Autenticação forte
Autorização por função
Auditoria completa
Logs imutáveis
No mundo IBM Z, isso conversa diretamente com RACF, ACF2 e Top Secret.
O futuro: agentes especializados
Hoje temos um único chatbot.
Daqui a alguns anos teremos verdadeiras equipes virtuais.
Imagine um ambiente de desenvolvimento onde coexistem:
um Arquiteto de Software virtual;
um Especialista COBOL;
um DBA Db2;
um Especialista CICS;
um Analista de Segurança RACF;
um Especialista em Performance WLM;
um Engenheiro DevOps;
um Especialista em Observabilidade.
Você faz uma única pergunta, e um agente supervisor distribui automaticamente as tarefas para cada especialista. Essa visão, que parecia ficção científica há poucos anos, já começa a aparecer nas arquiteturas corporativas mais modernas.
Dicas para o Programador Júnior
Se você está começando agora, não tente aprender tudo de uma vez. Construa sua base de forma incremental:
Aprenda primeiro o que é o MCP e como ele expõe ferramentas.
Crie um pequeno servidor MCP acessando arquivos locais.
Envolva uma API REST existente usando o padrão Direct API Wrapper.
Evolua para um Composite Service, orquestrando duas ou três APIs.
Estude filas e processamento assíncrono com IBM MQ, Kafka ou RabbitMQ.
Experimente arquiteturas multiagentes, separando especialistas por domínio.
Documente tudo. Um bom diagrama vale tanto quanto um bom código.
Pense sempre em segurança, observabilidade e governança desde o primeiro dia.
Lembre-se: a melhor arquitetura é aquela que continua simples mesmo quando o sistema cresce.
Curiosidades
☕ O conceito de protocolos padronizados não é novo. Assim como HTTP revolucionou a Web e JDBC padronizou o acesso a bancos de dados, o MCP busca padronizar a comunicação entre modelos de IA e ferramentas.
☕ Muitas empresas estão reutilizando APIs que já existiam há anos. Em vez de reescrever sistemas, apenas criam uma camada MCP sobre elas.
☕ Um servidor MCP pode conversar com sistemas escritos em COBOL, Java, Python, C#, Go ou Node.js. O protocolo não depende da linguagem de implementação.
☕ Ambientes IBM Z são candidatos naturais para o uso de MCP, pois concentram processos críticos, regras de negócio consolidadas e décadas de conhecimento corporativo.
Easter Eggs para os apaixonados por tecnologia
🥚 Easter Egg #1: Se você conhece o padrão Facade da programação orientada a objetos, já entendeu parte da ideia do Composite Service Pattern: esconder a complexidade de vários serviços atrás de uma interface simples.
🥚 Easter Egg #2: O Hierarchical MCP Pattern lembra a organização de um Sysplex: vários componentes especializados coordenados por uma camada superior.
🥚 Easter Egg #3: O Event-Driven Pattern conversa naturalmente com IBM MQ, Kafka e até mesmo com os tradicionais batch triggers do z/OS. O conceito muda, mas a filosofia continua a mesma.
🥚 Easter Egg #4: Um agente supervisor distribuindo tarefas para especialistas lembra muito o escalonamento de workloads feito pelo Workload Manager (WLM): cada recurso executa aquilo para o qual foi projetado.
🥚 Easter Egg #5: Se você percebeu que um servidor MCP funciona como uma espécie de "3270 inteligente" para a IA, parabéns! Em ambos os casos existe uma camada intermediária que traduz comandos e controla o acesso aos sistemas corporativos.
Conclusão
O entusiasmo em torno da Inteligência Artificial faz muita gente acreditar que basta escolher o melhor modelo de linguagem para resolver qualquer problema. A prática mostra o contrário. Modelos excelentes podem fracassar quando são colocados sobre arquiteturas mal planejadas, enquanto modelos mais modestos entregam resultados impressionantes quando sustentados por uma boa engenharia.
O Model Context Protocol (MCP) representa um passo importante nessa evolução porque padroniza a comunicação entre agentes e sistemas. No entanto, o protocolo é apenas a fundação. O verdadeiro diferencial está na escolha do Design Pattern adequado ao fluxo de trabalho, ao domínio de negócio, aos requisitos de segurança e à estratégia de escalabilidade.
Para quem trabalha com IBM Mainframe, a boa notícia é que muitos dos princípios utilizados há décadas — modularização, separação de responsabilidades, processamento assíncrono, governança, auditoria e alta disponibilidade — continuam absolutamente válidos. O cenário mudou, mas os fundamentos permanecem.
No fim das contas, construir soluções com IA não é muito diferente de construir sistemas corporativos de qualidade: o protocolo conecta, a arquitetura organiza e a experiência do engenheiro transforma tecnologia em valor para o negócio.
Porque, como gostamos de dizer aqui no Bellacosa Mainframe:
"A IA pode escrever código em segundos. Mas somente uma boa arquitetura garante que esse código continuará útil daqui a dez anos."
Sem comentários:
Enviar um comentário