☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta IA Agêntica. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IA Agêntica. Mostrar todas as mensagens

quinta-feira, 9 de julho de 2026

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

 

Bellacosa Mainframe ai agents sem misterios

☕ Um Café no Bellacosa Mainframe

AI Agents sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que a Nova Revolução da Inteligência Artificial Parece Muito Mais um Sistema Bancário do IBM Z do que um Chatbot

"No Mainframe aprendemos uma lição que o mercado de IA está redescobrindo apenas agora: inteligência nunca esteve em uma única aplicação. Ela sempre surgiu da integração disciplinada entre diversos componentes especializados."


Durante os últimos anos, muito se falou sobre GPT, Llama, Claude, Gemini, DeepSeek e inúmeros outros modelos de linguagem. Para quem observa de fora, parece que a evolução da Inteligência Artificial consiste simplesmente em criar modelos cada vez maiores.

Mas existe uma mudança silenciosa acontecendo.

A próxima revolução não é sobre modelos.

É sobre arquitetura.

E essa talvez seja a melhor notícia que um programador COBOL pode receber.

Enquanto boa parte da indústria acredita que a IA nasceu em 2022, profissionais de Mainframe podem olhar para praticamente qualquer diagrama moderno de AI Agents e dizer:

"Curioso... já vi algo muito parecido funcionando em bancos há décadas."

Obviamente, as tecnologias são diferentes.

Os problemas também.

Mas os princípios da engenharia permanecem surpreendentemente familiares.


A maior ilusão sobre IA

Quando alguém pensa em Inteligência Artificial normalmente imagina algo assim:

Usuário
     │
     ▼
   ChatGPT
     │
     ▼
 Resposta

Isso funciona.

Mas isso não é um agente.

É apenas uma conversa.

Um verdadeiro AI Agent parece muito mais com isto:

Objetivo

↓

Planejamento

↓

Memória

↓

Recuperação de Conhecimento

↓

Raciocínio

↓

Ferramentas

↓

Execução

↓

Avaliação

↓

Nova decisão

Perceba um detalhe extremamente importante.

O modelo de linguagem aparece apenas como um componente.

Ele deixou de ser o protagonista.

Passou a ser apenas uma peça do sistema.

Isso muda completamente a forma de pensar.


Curiosidade nº 1

Os primeiros grandes sistemas corporativos já funcionavam como "agentes", embora ninguém utilizasse esse nome.

Pense em um processamento bancário.

O cliente solicita uma transferência.

O programa COBOL não resolve tudo sozinho.

Ele:

  • consulta o Db2;

  • verifica limites;

  • conversa com CICS;

  • envia mensagens MQ;

  • registra auditoria;

  • grava logs;

  • dispara novos processos.

No final, dezenas de componentes participaram daquela simples operação.

A IA Agêntica está redescobrindo exatamente esse conceito.


O verdadeiro cérebro do agente

Existe uma frase interessante na Engenharia de Software:

"Software complexo não é construído escrevendo funções enormes.

É construído coordenando pequenas funções muito bem organizadas."

Com agentes acontece exatamente isso.

O LLM não controla tudo.

Quem controla é a arquitetura.

Imagine um maestro.

O maestro não toca violino.

Não toca piano.

Não toca trompete.

Mas coordena todos.

O Agent Runtime faz exatamente isso.


Easter Egg nº 1

Se você já escreveu um PERFORM UNTIL em COBOL, já entende melhor um AI Agent do que imagina.

Veja:

PERFORM UNTIL PROCESSO-CONCLUIDO

    LER-DADOS

    VALIDAR

    PROCESSAR

    EXECUTAR

    VERIFICAR-RESULTADO

END-PERFORM

Agora compare com um agente moderno:

Observe

↓

Think

↓

Evaluate

↓

Execute

↓

Observe novamente

São praticamente o mesmo padrão arquitetural.

A única diferença é que agora algumas decisões são tomadas por modelos estatísticos.


Memória não significa banco de dados

Outro erro muito comum.

Quando falamos em memória, muita gente pensa imediatamente em um banco de dados.

Não é isso.

Os agentes modernos possuem diversos tipos de memória.

Isso lembra bastante a organização interna de um programa COBOL.


Working Memory

Equivale às variáveis da Working-Storage.

01 WS-NOME.

01 WS-SALDO.

01 WS-CPF.

Essas informações existem apenas durante o processamento.

Quando o programa termina...

Desaparecem.


Episodic Memory

Guarda experiências anteriores.

Imagine um operador que lembra:

"Ontem essa API ficou indisponível."

Ou:

"O cliente sempre prefere receber PDF."

Essa memória melhora decisões futuras.


Procedural Memory

Talvez seja a mais interessante.

Ela não guarda conhecimento.

Guarda procedimentos.

Exatamente como um programador COBOL.

Você talvez não memorize todos os comandos do SORT.

Mas sabe quando utilizá-los.

Esse conhecimento é procedural.


Easter Egg nº 2

Uma PROCEDURE DIVISION inteira pode ser vista como uma forma primitiva de memória procedural.

Isso mostra que COBOL sempre foi muito mais sofisticado do que muitos imaginam.


O MCP explicado para quem conhece Mainframe

Muita gente acredita que MCP é uma IA.

Não é.

Também não é um banco.

Nem um framework.

MCP é um protocolo.

Pense nele como:

  • JDBC

  • ODBC

  • MQ

  • TCP/IP

  • HTTP

  • REST

Seu trabalho é padronizar comunicação.

Nada mais.

Nada menos.

Sem ele, cada ferramenta precisaria conversar de uma forma diferente.

Com ele:

LLM

↓

MCP

↓

GitHub

↓

SAP

↓

Jira

↓

Mainframe

↓

Banco

↓

Filesystem

Tudo segue uma mesma linguagem.


Curiosidade nº 2

O sucesso do TCP/IP não aconteceu porque era o protocolo mais rápido.

Aconteceu porque todo mundo resolveu falar a mesma língua.

MCP caminha exatamente nessa direção.


Ferramentas são os novos EXEC CICS

Existe uma comparação extremamente divertida.

No COBOL temos:

EXEC SQL

CALL

EXEC CICS

LINK

XCTL

MQPUT

MQGET

Na IA temos:

Tool()

API()

Database()

Search()

Filesystem()

Email()

Calendar()

O conceito é idêntico.

A lógica continua sendo apenas um orquestrador.


O ciclo infinito da inteligência

A figura mostra algo fantástico.

O agente nunca para de observar.

Ele vive em um ciclo permanente.

Observar

↓

Interpretar

↓

Planejar

↓

Executar

↓

Observar novamente

Isso lembra outro velho conhecido.

O monitor CICS.

Recebe transação

↓

Processa

↓

Envia resposta

↓

Espera próxima transação

É um ciclo eterno.


Easter Egg nº 3

O famoso laço de controle OODA (Observe, Orient, Decide, Act), criado pelo estrategista militar John Boyd, é frequentemente comparado ao ciclo de agentes modernos.

Curiosamente, muitos sistemas transacionais corporativos já implementavam ciclos semelhantes muito antes da popularização da IA.


O agente não pensa sozinho

Esta talvez seja a maior descoberta da IA moderna.

Pensar custa caro.

Consultar custa barato.

Por isso surgiu o RAG.

Ao invés de decorar tudo...

O agente consulta.

Isso lembra muito um programa COBOL.

Um sistema bancário não possui todos os clientes em memória.

Ele consulta o Db2.

Sempre que necessário.


Curiosidade nº 3

Quanto maior o agente, menos ele depende da memória interna.

Parece contraditório.

Mas faz sentido.

Grandes sistemas preferem consultar fontes oficiais do que confiar apenas na memória.

Os bancos fazem isso há décadas.


Planejamento lembra um velho conhecido...

JCL.

Antes do programa executar:

STEP001

↓

STEP002

↓

STEP003

↓

STEP004

Tudo já foi planejado.

Os agentes fazem exatamente isso.

Antes de responder.

Eles decompõem o problema.


Easter Egg nº 4

O conceito moderno chamado Task Decomposition é praticamente o equivalente filosófico ao particionamento de um grande JOB em múltiplos STEP's reutilizáveis.


O maior erro de um iniciante

Quem está começando em IA normalmente pergunta:

"Qual é o melhor modelo?"

Essa pergunta equivale a perguntar:

"Qual é o melhor compilador COBOL?"

Não é a pergunta correta.

A pergunta correta seria:

Como toda a arquitetura foi construída?


O verdadeiro diferencial

Os agentes realmente impressionantes possuem:

✔ memória

✔ ferramentas

✔ planejamento

✔ logs

✔ recuperação

✔ auditoria

✔ monitoramento

✔ controle

✔ validação

✔ observabilidade

Parece familiar?

Claro.

É exatamente assim que sistemas críticos são construídos.


Curiosidade nº 4

Os bancos nunca confiaram apenas no programa COBOL.

Sempre confiaram na arquitetura inteira.

A IA está aprendendo essa mesma lição.


O papel da avaliação

Uma diferença enorme entre um chatbot simples e um agente corporativo está na etapa de avaliação.

Depois de executar uma ação, o agente pergunta:

  • A API respondeu?

  • O banco confirmou?

  • O arquivo foi criado?

  • O usuário recebeu?

  • O resultado faz sentido?

No Mainframe fazemos isso desde sempre.

IF SQLCODE = ZERO

IF FILE-STATUS = "00"

IF RETURN-CODE = ZERO

A validação é parte da lógica.

Nunca um detalhe.


Easter Egg nº 5

Um dos padrões mais modernos em agentes é chamado Reflection.

Depois de responder...

O agente analisa sua própria resposta.

Curiosamente, isso lembra bastante um programador experiente revisando o próprio código antes do code review.


Observabilidade: a grande esquecida

Um agente sem logs é como um programa batch sem SYSOUT.

Quando algo dá errado...

Ninguém sabe por quê.

Por isso arquiteturas modernas utilizam:

  • Telemetria

  • Métricas

  • Traces

  • Logs

  • Auditoria

  • Eventos

No IBM Z temos equivalentes extremamente maduros:

  • SMF

  • RMF

  • SYSLOG

  • SDSF

  • JESMSGLG

  • JESYSMSG

Mais uma vez, o Mainframe já praticava esses conceitos há muito tempo.


A verdadeira autonomia

Existe uma frase que merece ser lembrada.

Um agente não é inteligente porque executa muitas ações.

Ele é inteligente porque sabe quando não executar.

Essa é a diferença entre automação e autonomia responsável.

É por isso que governança, políticas de acesso, autenticação, autorização e auditoria são componentes indispensáveis em ambientes corporativos.


O maior Easter Egg de todos

Talvez o aspecto mais curioso dessa nova geração de IA seja perceber que muitos dos conceitos considerados "inovadores" já existiam, com outros nomes, no universo Mainframe.

IA AgênticaIBM Z / Mainframe
Working MemoryWorking-Storage
Procedural MemoryProcedure Division
Tool CallingEXEC CICS / EXEC SQL / CALL
PlannerJCL / Scheduler
RetrievalDb2 / VSAM / IMS
ReflectionValidação de RC, SQLCODE, FILE STATUS
OrchestratorCICS, JES2, Control-M, OPC
ObservabilitySMF, RMF, SDSF, SYSLOG
Agent RuntimeMonitor transacional + lógica de negócio
GovernanceRACF, SAF, Auditoria

É claro que não são tecnologias equivalentes em implementação, mas os princípios arquiteturais apresentam paralelos notáveis.


Conselho final para um Padawan COBOL

Se você acredita que a Inteligência Artificial substituirá completamente os profissionais de Mainframe, talvez esteja olhando apenas para a superfície.

Os melhores arquitetos de agentes precisarão entender muito mais do que prompts. Eles precisarão dominar orquestração, governança, integração, confiabilidade, observabilidade, recuperação de falhas e regras de negócio — exatamente os pilares sobre os quais os grandes sistemas IBM Z foram construídos ao longo de décadas.

Enquanto muitos enxergam um AI Agent como um "chatbot com ferramentas", um programador COBOL experiente reconhece algo muito mais profundo: um ecossistema de componentes cooperando de forma disciplinada para atingir um objetivo comum.

No fim das contas, a grande lição é quase poética. A indústria da IA está descobrindo que inteligência não nasce de um modelo gigantesco, mas da engenharia cuidadosa que conecta memória, planejamento, raciocínio, execução, auditoria e controle. E para quem passou anos desenvolvendo aplicações críticas em bancos, seguradoras e governos, isso soa surpreendentemente familiar.

Como diria um velho Mestre Jedi do IBM Z:

"Os modelos impressionam nas demonstrações. Mas são as arquiteturas bem projetadas que sobrevivem por décadas."


domingo, 13 de outubro de 2024

MCP Design Patterns: O Manual Definitivo para Construir Agentes de IA Inteligentes (e por que Arquitetura Vale Muito Mais que Prompt)

 

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

PatternComplexidadeEscalaQuando usar
Local ResourceMuito baixaMédiaArquivos locais
Direct APIBaixaAltaAPIs existentes
CompositeMédiaAltaIntegrações
Event DrivenAltaMuito altaProcessamentos longos
HierarchicalAltaMuito altaGrandes empresas
MCP-to-AgentMuito altaExtremamente altaIA 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:

  1. Aprenda primeiro o que é o MCP e como ele expõe ferramentas.

  2. Crie um pequeno servidor MCP acessando arquivos locais.

  3. Envolva uma API REST existente usando o padrão Direct API Wrapper.

  4. Evolua para um Composite Service, orquestrando duas ou três APIs.

  5. Estude filas e processamento assíncrono com IBM MQ, Kafka ou RabbitMQ.

  6. Experimente arquiteturas multiagentes, separando especialistas por domínio.

  7. Documente tudo. Um bom diagrama vale tanto quanto um bom código.

  8. 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."

 

segunda-feira, 19 de fevereiro de 2024

IA Agêntica: Muito Além do ChatGPT — Como Pensar Como um Arquiteto de Sistemas Inteligentes

 

Bellacosa Mainframe e a ia agentica

☕ Um Café no Bellacosa Mainframe

IA Agêntica: Muito Além do ChatGPT — Como Pensar Como um Arquiteto de Sistemas Inteligentes

"O futuro da programação não será escrever mais código. Será ensinar agentes inteligentes a escrever, colaborar e tomar decisões com responsabilidade."

Durante muitos anos, aprender programação significava dominar uma linguagem.

Depois vieram os frameworks.

Depois a nuvem.

Depois DevOps.

Depois Containers.

Depois Kubernetes.

Agora estamos entrando em uma nova fase.

A era da IA Agêntica (Agentic AI).

Se você é um programador júnior, principalmente vindo do mundo corporativo, talvez esteja pensando:

"Isso é só mais um nome bonito para ChatGPT?"

A resposta é um enorme não.

Estamos diante de uma mudança comparável ao nascimento da Internet ou da computação em nuvem.

Hoje não estamos ensinando computadores apenas a responder perguntas.

Estamos ensinando computadores a trabalhar.

E isso muda absolutamente tudo.

Pegue seu café.

Hoje vamos entender como funciona a arquitetura dos agentes inteligentes.


O que realmente é IA Agêntica?

Um chatbot responde.

Um agente resolve problemas.

Existe uma enorme diferença.

Imagine que você diga:

"Meu programa COBOL está com erro."

Um chatbot provavelmente responderá:

"Mostre o código."

Um agente faria algo completamente diferente.

Ele poderia:

  • localizar o programa no Git

  • abrir o histórico de alterações

  • identificar quem modificou

  • executar os testes

  • consultar o banco de dados

  • pesquisar documentação IBM

  • comparar versões

  • sugerir correções

  • criar um Pull Request

  • pedir sua aprovação

  • atualizar o Jira

Percebe?

Ele não apenas conversa.

Ele trabalha.

É exatamente por isso que chamamos essa nova geração de Agentes de IA.


Um agente é como um operador de Mainframe

Quem trabalha com IBM Z entende isso muito rápido.

Imagine um operador experiente do z/OS.

Ele observa:

  • JOBs

  • filas JES2

  • consumo de CPU

  • logs

  • CICS

  • DB2

  • RACF

  • Storage

Depois toma decisões.

Um agente faz exatamente isso.

A diferença é que ele faz isso em segundos.


Os 12 pilares da IA Agêntica

Esses conceitos aparecem em praticamente todas as arquiteturas modernas.

Não importa se você usa:

  • OpenAI

  • Claude

  • Gemini

  • Microsoft Copilot

  • Amazon Bedrock

  • IBM watsonx

  • LangGraph

  • CrewAI

  • AutoGen

Todos utilizam praticamente os mesmos fundamentos.

Vamos entender cada um.


1. MCP — O USB-C da Inteligência Artificial

Durante anos cada ferramenta criou sua própria API.

Cada integração era diferente.

Hoje existe o MCP.

Model Context Protocol.

Pense nele como o USB-C.

Você conecta qualquer dispositivo.

Na IA acontece o mesmo.

O agente conversa com GitHub.

Depois Jira.

Depois Slack.

Depois PostgreSQL.

Depois SAP.

Depois IBM Z.

Tudo utilizando um mesmo protocolo.

Para quem é desenvolvedor isso significa menos código, menos manutenção e muito mais reutilização.


Curiosidade

O MCP está se tornando para a IA o que HTTP foi para a Internet.

Estamos assistindo ao nascimento de um novo padrão mundial.


2. O Loop do Agente

Todo agente vive preso em um ciclo.

Perceber

↓

Planejar

↓

Executar

↓

Observar

↓

Aprender

↓

Repetir

Isso parece simples.

Mas é exatamente como um ser humano trabalha.

Imagine um DBA.

Ele percebe uma lentidão.

Analisa índices.

Planeja um REORG.

Executa.

Observa.

Se não resolveu, tenta novamente.

O agente faz exatamente isso.


Dica Bellacosa

Se seu agente apenas responde perguntas...

Ele ainda não é um verdadeiro agente.


3. Ferramentas

Essa talvez seja a maior surpresa para quem está começando.

Modelos de IA não fazem quase nada sozinhos.

Eles apenas pensam.

Quem realmente trabalha são as ferramentas.

Exemplos:

  • executar SQL

  • enviar e-mails

  • criar PDFs

  • chamar APIs

  • consultar banco

  • executar JCL

  • abrir chamados

  • gerar gráficos

Sem ferramentas...

O agente é apenas um excelente escritor.


Analogia

Imagine um excelente mecânico.

Sem ferramentas.

Ele continua sabendo consertar motores.

Mas não consegue fazer nada.


4. O Orquestrador

Agora imagine uma empresa.

Existe um gerente.

Ele não faz tudo.

Ele distribui trabalho.

Na IA esse gerente chama-se Orquestrador.

Ele recebe um objetivo.

Depois decide quem fará cada parte.

É praticamente um Scrum Master misturado com um arquiteto de software.


Exemplo

Recebe:

"Atualize toda documentação do sistema."

Ele divide.

Agente Git.

Agente Markdown.

Agente UML.

Agente Testes.

Agente QA.

Cada especialista resolve sua parte.


5. Subagentes

Você provavelmente sabe um pouco de tudo.

Mas conhece alguém que sabe muito de DB2.

Outro domina RACF.

Outro conhece CICS.

Outro é especialista em COBOL.

Os agentes funcionam exatamente assim.

Cada um possui uma especialidade.

Isso reduz erros.

Aumenta qualidade.

E melhora desempenho.


Easter Egg

Isso lembra muito os personagens de um RPG.

Cada classe possui habilidades específicas.

Um Guerreiro não lança magia.

Um Mago não usa armadura pesada.

Na IA acontece exatamente igual.


6. Memória

Sem memória não existe inteligência.

Existe apenas repetição.

Os agentes possuem vários tipos de memória.

Curto prazo

Lembram da conversa atual.

Longo prazo

Lembram de dias, meses ou anos.

Memória Vetorial

Guardam conhecimento por similaridade.

Memória Episódica

Lembram do que aconteceu.

Memória Semântica

Lembram conceitos.


Imagine perguntar:

Continue aquele artigo sobre COBOL.

Sem memória...

O agente pergunta:

"Qual artigo?"

Com memória...

Ele continua exatamente de onde parou.


Curiosidade

Nos próximos anos veremos agentes com memória de meses ou até anos de interação.

Será algo semelhante a um colega de trabalho.


7. Grounding

Esse talvez seja o conceito mais importante de todos.

Grounding significa:

Responder usando fatos.

Não imaginação.

Imagine perguntar:

"Quantos JOBs estão em HOLD?"

Sem grounding:

"Talvez existam 12."

Com grounding:

Consulta SDSF.

Depois responde.

Muito mais seguro.


RAG não é Grounding

Muita gente confunde.

RAG é apenas uma técnica.

Grounding é um conceito muito maior.

Pode utilizar:

  • APIs

  • sensores

  • bancos

  • documentos

  • logs

  • arquivos

  • sistemas ERP


8. Guardrails

Imagine um carro sem freios.

Bonito.

Rápido.

Perigoso.

Guardrails são os freios da IA.

Eles impedem ações inadequadas.

Por exemplo:

❌ apagar banco

❌ excluir usuários

❌ enviar PIX

❌ alterar produção

Sem autorização.


Analogia Mainframe

Guardrails lembram muito o RACF.

Nem todo usuário pode fazer tudo.


9. Sandboxing

Nunca execute código desconhecido diretamente na produção.

Jamais.

Primeiro teste.

Depois valide.

Depois publique.

Sandbox é exatamente isso.

Uma área isolada.


Exemplo

O agente gera um script Python.

Antes de executá-lo:

Sandbox.

Se funcionar...

Produção.


Curiosidade

Grande parte das plataformas modernas de IA executa código em ambientes isolados justamente para evitar impactos em sistemas reais.


10. Human in the Loop

A IA ajuda.

Mas a decisão final continua sendo humana.

Imagine:

"Excluir 40 milhões de registros."

Você realmente deixaria uma IA fazer isso automaticamente?

Provavelmente não.

Ela sugere.

Você aprova.


Empresas adoram isso

Porque reduz riscos.

E mantém governança.


11. Janela de Contexto

Todo modelo possui limite.

Imagine uma mesa.

Quanto maior a mesa...

Mais documentos você consegue abrir.

Quanto menor...

Menos informações cabem.

A janela de contexto funciona exatamente assim.

Hoje alguns modelos trabalham com centenas de milhares de tokens.

Isso permite analisar:

  • livros

  • projetos

  • documentação

  • códigos enormes


Dica Bellacosa

Mais contexto não significa necessariamente melhor resposta.

Contexto ruim gera respostas ruins.


12. Sistemas Multiagentes

Chegamos ao nível mais avançado.

Imagine uma empresa inteira.

Cada funcionário faz uma parte.

O gerente coordena tudo.

Os agentes fazem exatamente isso.

Existe:

Agente Financeiro.

Agente Jurídico.

Agente Marketing.

Agente Segurança.

Agente DevOps.

Agente DBA.

Todos colaborando.


Como isso pode funcionar no IBM Mainframe?

Imagine um incidente em produção.

09:42.

CPU dispara.

O que acontece?

O orquestrador entra em ação.

Ele chama:

✔ Agente RMF

Analisa desempenho.

✔ Agente JES2

Verifica JOBs.

✔ Agente DB2

Analisa SQL.

✔ Agente CICS

Verifica transações.

✔ Agente RACF

Confirma segurança.

✔ Agente Documentação

Consulta procedimentos.

✔ Agente DevOps

Prepara correção.

Tudo isso em paralelo.

Em poucos segundos.

É praticamente um NOC inteiro trabalhando simultaneamente.


A profissão do futuro

Durante décadas existiram:

Programadores.

Depois vieram:

Arquitetos.

Depois:

DevOps.

Agora começa a surgir uma nova profissão.

Engenheiro de Agentes de IA (AI Agent Engineer).

Esse profissional não escreve apenas código.

Ele projeta equipes inteiras de agentes.

Define:

  • ferramentas

  • memória

  • protocolos

  • segurança

  • comunicação

  • colaboração

  • aprovação humana

É uma mistura de desenvolvedor, arquiteto, analista de negócios e engenheiro de software.


Dicas para quem está começando

Se você deseja entrar no universo da IA Agêntica, siga uma trilha sólida de aprendizado:

  1. Domine lógica de programação antes de depender da IA.

  2. Aprenda Python, pois é a linguagem mais usada para orquestrar agentes.

  3. Entenda APIs REST e GraphQL para conectar ferramentas.

  4. Estude bancos relacionais e vetoriais.

  5. Aprenda Git e GitHub para colaboração.

  6. Conheça Docker para criar ambientes isolados (sandbox).

  7. Estude conceitos de segurança, autenticação e autorização.

  8. Explore RAG, MCP, LangGraph, CrewAI e AutoGen.

  9. Pratique com pequenos agentes antes de construir sistemas complexos.

  10. Nunca esqueça que a IA amplia o conhecimento existente; ela não substitui fundamentos de arquitetura, algoritmos e boas práticas.


Curiosidades

  • 🤖 Um único agente pode utilizar dezenas de ferramentas diferentes durante uma única tarefa.

  • 🧠 Memórias vetoriais não armazenam frases exatamente como um banco SQL; elas representam significados em espaços matemáticos de alta dimensão.

  • ⚙️ Muitos agentes modernos já executam ciclos autônomos de planejamento, correção e replanejamento antes de apresentar uma resposta.

  • 🌐 O conceito de múltiplos agentes trabalhando em conjunto lembra sistemas distribuídos e arquiteturas de microsserviços, mas aplicado ao raciocínio.

  • 🏢 Empresas estão criando "equipes digitais", nas quais agentes especializados colaboram com profissionais humanos em atividades de engenharia, atendimento, operações e análise de dados.


Easter Eggs para os apaixonados por tecnologia

🥚 Easter Egg #1 – O operador invisível
Se você trabalhou com operadores de console no z/OS, talvez perceba que um agente moderno se comporta como um operador experiente que nunca dorme, nunca esquece um procedimento e consulta toda a documentação antes de agir.

🥚 Easter Egg #2 – Os Vingadores da IA
Um sistema multiagente lembra uma equipe de super-heróis: cada membro possui um poder específico, mas as missões realmente complexas só são resolvidas quando todos atuam juntos sob uma boa liderança.

🥚 Easter Egg #3 – A ponte entre o legado e o futuro
Quem domina COBOL, CICS, DB2, JCL e RACF já entende conceitos como especialização, governança, filas, transações e segurança. Surpreendentemente, esses mesmos princípios aparecem nas arquiteturas mais modernas de IA Agêntica. O legado não está ficando para trás; ele está servindo de base para construir a próxima geração de sistemas inteligentes.


Conclusão

A IA Agêntica não representa apenas uma evolução dos chatbots; ela inaugura uma nova forma de construir software. Em vez de aplicações que apenas respondem comandos, passamos a projetar ecossistemas de agentes capazes de perceber eventos, planejar estratégias, utilizar ferramentas, colaborar entre si, aprender com experiências anteriores e operar dentro de regras rígidas de segurança e governança.

Para o programador júnior, essa é uma oportunidade extraordinária. Quem aprender desde cedo conceitos como MCP, memória, grounding, orquestração, subagentes, guardrails e sistemas multiagentes estará preparado para desenvolver as soluções que definirão a próxima década da engenharia de software.

No fim das contas, a tecnologia muda, as ferramentas evoluem e os modelos ficam cada vez mais poderosos. Porém, um princípio permanece inalterado desde os primeiros computadores até os modernos agentes inteligentes: bons sistemas nascem de boas arquiteturas. E compreender esses doze pilares é o primeiro passo para deixar de apenas usar IA e começar a construir, de forma consciente e profissional, a inteligência que moverá as empresas do futuro.

"Na computação, quem entende apenas as ferramentas acompanha as tendências. Quem entende os princípios constrói o futuro." — Bellacosa Mainframe

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...