☕ 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 AI Agents. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta AI Agents. 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."


quarta-feira, 20 de maio de 2026

SKILL.md : O JCL da Inteligência Artificial?




☕ Um Café no Bellacosa Mainframe

SKILL.md

O JCL da Inteligência Artificial?

Como transformar prompts descartáveis em componentes reutilizáveis de IA

"Programadores COBOL nunca escreveram comandos repetidos quando podiam criar uma PROC. O SKILL.md segue exatamente essa filosofia."


O problema do Prompt Engineering

Hoje a maioria das pessoas trabalha assim:

Abre ChatGPT

↓

Escreve um prompt enorme

↓

Recebe resposta

↓

Fecha

↓

No dia seguinte...

Escreve tudo novamente

É praticamente isso.

Imagine um DBA que toda manhã tivesse que escrever novamente o JCL inteiro para executar o RUNSTATS.

Ninguém faria isso.

Criaria uma PROC.

Ou um CLIST.

Ou um REXX.

Ou um Script.

Ou um Pipeline.

Então por que fazemos isso com IA?


O nascimento do SKILL.md

A ideia do SKILL.md é simples.

Em vez de guardar conhecimento na cabeça...

...guardamos conhecimento em arquivos.

Esses arquivos descrevem exatamente:

  • quando executar

  • como executar

  • quais regras seguir

  • quais ferramentas usar

  • qual formato devolver

Ou seja...

não é um prompt.

É um módulo.


Pense como um programador COBOL

No COBOL existe:

COPYBOOK

Você escreve uma vez.

Depois reutiliza em centenas de programas.

O SKILL.md é praticamente o COPYBOOK da IA.


Outro exemplo.

No z/OS temos

PROC JCL

Em vez de copiar:

IEFBR14

DISP

SPACE

DCB

...

criamos

PROC

e chamamos:

//STEP EXEC PROC=BACKUP

O SKILL.md faz exatamente isso.


Em vez de escrever

Analise este código COBOL...

gere documentação...

explique...

crie testes...

faça HTML...

gere JSON...

você apenas chama

/documentar-cobol

E pronto.


O que realmente existe dentro de um SKILL.md?

A imagem resume isso muito bem.

Vamos aprofundar.


1 Nome

name:

É o identificador.

Exemplo

documentar-cobol

ou

analisar-jcl

ou

explicar-vsam

2 Description

Essa talvez seja a parte mais importante.

Ela não serve apenas para humanos.

Serve para a IA descobrir:

"quando devo usar este Skill?"

Exemplo.

Sempre que o usuário enviar um programa COBOL
e pedir documentação.

Observe.

Não é um prompt.

É um gatilho.


3 Instructions

Aqui mora o cérebro.

Exemplo.

1 Leia o código

2 Identifique variáveis

3 Gere fluxograma

4 Explique SQL

5 Explique CICS

6 Gere documentação

7 Gere Markdown

É praticamente um algoritmo.


4 Constraints

Muito importante.

Exemplo.

Nunca invente campos

Nunca altere lógica

Explique apenas o que existe

Sempre preserve comentários

Sem restrições...

a IA improvisa.

Com restrições...

ela fica previsível.


5 Output

Como devolver.

Exemplo.

Markdown

JSON

HTML

Tabela

Mermaid

Ascii Art

PlantUML

Isso elimina enorme parte da inconsistência.


Progressive Disclosure

Essa parte da imagem é excelente.

Ela mostra algo pouco conhecido.

A IA não precisa carregar tudo imediatamente.

Ela faz:

Stage 1

↓

Carrega apenas metadados

Depois

Stage 2

↓

Carrega instruções completas

Depois

Stage 3

↓

Busca scripts externos

Isso reduz consumo de contexto.

É parecido com paginação de memória.

Ou até mesmo:

Demand Paging

no z/OS.

Só carrega quando precisa.


Anatomia

A imagem resume assim:

name

description

instructions

Mas, na prática, um bom Skill costuma ter também:

Examples

References

Templates

Output

Validation

Error Handling

Scripts

Assets

Ou seja...

é quase um pequeno projeto.


Estrutura de diretórios

A imagem mostra algo como

.claude/

skills/

review-pr/

Dentro temos

SKILL.md

scripts/

references/

assets/

Isso é fantástico.

Porque aproxima IA da engenharia de software.

Não existe mais um prompt perdido.

Existe um componente organizado.


Um exemplo para Mainframe

Imagine:

skills/

analisar-cobol/

SKILL.md

copybooks/

templates/

scripts/

Dentro do Skill:

Receba um programa COBOL.

Explique:

Data Division

Working Storage

Linkage

File Section

Procedure Division

CICS

SQL

VSAM

Performance

Sugestões

Checklist

Fluxograma

Sempre igual.

Sempre consistente.


Outro exemplo

Imagine um Skill chamado

JCL Review

Quando alguém envia

//STEP01 EXEC PGM=IDCAMS

automaticamente a IA faz:

✔ verifica DISP

✔ verifica SPACE

✔ verifica UNIT

✔ verifica DCB

✔ verifica GDG

✔ verifica retorno

✔ identifica problemas

✔ sugere melhorias

Sem escrever prompt algum.


Outro exemplo

RACF Auditor

Entrada

Comandos RACF

Saída

Riscos

Boas práticas

Least Privilege

Violação

Explicação

Checklist

Normas IBM

Outro exemplo

Explicar Dump S0C7

Sempre devolvendo

Causa

Registro PSW

Offset

Hex

Instrução COBOL

Correção

Exemplo

Por que isso escala?

Porque agora existe padronização.

Imagine uma empresa.

Hoje.

100 desenvolvedores.

Cada um escreve prompts diferentes.

Resultados diferentes.

Qualidade diferente.

Agora imagine.

Todos usam

review-api

review-cobol

review-java

security

documentation

A empresa inteira produz praticamente no mesmo padrão.


Isso lembra muito...

Quem trabalha em Mainframe provavelmente percebeu.

SKILL.md lembra vários conceitos clássicos:

MainframeMundo IA
PROCSkill
COPYBOOKSkill compartilhado
CLISTSkill
REXXSkill com lógica
ISPF PanelInterface para Skill
JCL ProcedureReutilização
PARMLIBConfiguração
EXITPersonalização
Macro AssemblerTemplate reutilizável

Na verdade...

a filosofia é praticamente a mesma.


Skills × Config × MCP

A imagem também mostra essa diferença.

Skills

São capacidades.

Gerar documentação

Revisar código

Criar testes

Explicar erros

Converter formatos

São executadas sob demanda.


Configs

São comportamentos permanentes.

Exemplo.

Sempre responda em português.

Sempre seja objetivo.

Nunca gere código inseguro.

É equivalente às configurações globais do ambiente.


MCP

É outra camada completamente diferente.

MCP conecta IA a recursos externos.

Por exemplo:

GitHub

Jira

Confluence

PostgreSQL

Oracle

VSCode

Filesystem

AWS

IBM APIs

Enquanto um Skill ensina como pensar, o MCP fornece acesso ao mundo externo.


O futuro: IA Programável

A mensagem mais importante da imagem é esta:

"The shift is happening towards programmable AI systems."

Esse é realmente o movimento que está ganhando força.

A evolução pode ser vista em quatro fases:

2023

Prompt Engineering

2024

Prompt Libraries

2025

AI Agents

2026+

Skills

MCP

Workflows

Memory

Ferramentas

Automação

Cada etapa reduz trabalho manual e aumenta a reutilização e a previsibilidade.


Como isso se aplica ao Bellacosa Mainframe

Esse conceito combina muito com o projeto Bellacosa Mainframe. Em vez de criar prompts longos para cada artigo ou análise, você pode construir uma biblioteca de Skills especializadas, por exemplo:

  • Artigo Bellacosa — gera artigos longos no seu estilo, com curiosidades, história, exemplos, SEO, FAQ e chamadas para ação.

  • Review COBOL — analisa código COBOL com foco em bancos brasileiros, boas práticas, legibilidade e performance.

  • Analisador JCL — valida DISP, SPACE, GDG, retornos, organização dos DDs e oportunidades de melhoria.

  • Explicador CICS — detalha COMMAREA, Channels/Containers, TSQ/TDQ, RESP/RESP2, BMS e tratamento de erros.

  • Gerador de Quiz — cria avaliações com diferentes níveis de dificuldade e gabarito comentado.

  • Criador de Laboratórios — produz exercícios práticos para Hercules, ADCD e ambientes IBM Z.

  • SEO Blogspot — gera meta description, marcadores, slug e estrutura otimizada para mecanismos de busca.

Cada Skill seria reutilizada inúmeras vezes, garantindo consistência em todos os seus conteúdos.


Conclusão

O SKILL.md representa uma mudança importante na forma de trabalhar com IA. O foco deixa de ser escrever prompts elaborados para cada interação e passa a ser a criação de componentes reutilizáveis, documentados e padronizados, muito semelhantes aos princípios que profissionais de mainframe já utilizam há décadas com COPYBOOKs, PROCs, CLISTs, REXX e módulos reutilizáveis.

No fim das contas, a lógica é familiar para qualquer desenvolvedor experiente:

Não copie conhecimento. Encapsule-o. Não repita instruções. Reutilize-as. Não trate a IA como uma calculadora. Trate-a como uma plataforma programável.

Essa mudança aproxima a Inteligência Artificial das boas práticas de engenharia de software e tende a tornar seu uso mais confiável, escalável e sustentável em ambientes corporativos — exatamente como aconteceu com a evolução do desenvolvimento no mundo IBM Z ao longo das últimas décadas.

terça-feira, 21 de abril de 2026

AI Chatbots, AI Agents e Multi-Agent Systems O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Próxima Revolução da Engenharia de Software

 

Bellacosa Mainframe AI chatbos agents e multi-agents systems

☕ Um Café no Bellacosa Mainframe

AI Chatbots, AI Agents e Multi-Agent Systems

O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Próxima Revolução da Engenharia de Software

"Você não está apenas aprendendo Inteligência Artificial. Está descobrindo como os sistemas do futuro serão construídos — e, curiosamente, como eles se parecem muito mais com um IBM Mainframe do que a maioria das pessoas imagina."

Durante muitos anos ouvimos que a Inteligência Artificial substituiria programadores, escreveria software sozinha e transformaria completamente a indústria. Grande parte dessas previsões eram exageradas. O que realmente está acontecendo é muito mais interessante.

A verdadeira revolução não está em criar uma IA que saiba fazer tudo.

Ela está em criar equipes de inteligências artificiais, cada uma especializada em uma função específica, trabalhando em conjunto exatamente como acontece em uma empresa ou, para nossa surpresa, exatamente como acontece dentro de um ambiente IBM z/OS.

Se você é um Programador COBOL Padawan, este é um daqueles momentos em que compreender um conceito novo pode mudar completamente sua maneira de enxergar a tecnologia.

E a boa notícia?

Você já conhece, sem perceber, muitos dos princípios que sustentam essa nova geração de IA.


A primeira ilusão da Inteligência Artificial

Quando o ChatGPT surgiu, muita gente imaginou que havia nascido um cérebro artificial.

Parecia existir uma única inteligência capaz de responder qualquer pergunta.

Na realidade, um chatbot tradicional funciona de maneira relativamente simples.

O fluxo costuma ser:

Usuário

↓

Prompt

↓

LLM

↓

Resposta

O usuário faz uma pergunta.

O modelo analisa os tokens.

Prediz a sequência mais provável.

Entrega uma resposta.

Fim.

Não existe uma equipe trabalhando.

Não existe divisão de tarefas.

Não existe planejamento complexo.

É uma conversa extremamente sofisticada, mas ainda assim linear.


O chatbot é um excelente especialista... mas continua sozinho

Imagine que você pergunte:

"Explique como funciona um arquivo VSAM KSDS."

O chatbot responde.

Agora pergunte:

"Escreva um programa COBOL utilizando CICS, DB2, MQ, autenticação RACF, documentação técnica, casos de teste, scripts DevOps e um pipeline CI/CD."

Ele tentará fazer tudo.

Mas existe um problema.

Está tentando atuar simultaneamente como:

  • Analista de Sistemas

  • Arquiteto

  • DBA

  • Programador COBOL

  • Especialista CICS

  • Especialista MQ

  • Especialista em Segurança

  • Analista de Testes

  • Redator Técnico

  • DevOps

Nenhum profissional faz tudo isso perfeitamente.

Nem um modelo de IA.


Imagine uma empresa com apenas um funcionário

Vamos fazer uma analogia.

Imagine abrir um banco.

Você contrata apenas uma pessoa.

Ela deverá ser:

  • Presidente

  • Caixa

  • Segurança

  • Auditor

  • Contador

  • Analista de Crédito

  • Atendimento

  • TI

  • Limpeza

Parece absurdo.

Mas foi exatamente assim que imaginamos a Inteligência Artificial durante algum tempo.

Uma única IA faria absolutamente tudo.

O problema é que especialização sempre vence generalização quando o assunto é trabalho complexo.


É aqui que nascem os AI Agents

Agora imagine outro cenário.

Você continua tendo uma IA extremamente inteligente.

Mas ela aprende uma habilidade nova.

Ela não apenas responde.

Ela começa a agir.

Ela consegue:

  • planejar

  • pesquisar

  • acessar APIs

  • consultar bancos de dados

  • executar programas

  • validar resultados

  • corrigir erros

  • tentar novamente

Ela passa a perseguir objetivos.

Isso muda completamente o jogo.


Um agente pensa em etapas

Vamos imaginar um pedido simples.

"Analise o desempenho do meu banco DB2."

Um chatbot responderia algo como:

"Verifique índices, RUNSTATS, REORG..."

Um AI Agent faria algo diferente.

Ele poderia executar automaticamente um fluxo como este:

Receber objetivo

↓

Conectar ao catálogo DB2

↓

Ler estatísticas

↓

Analisar índices

↓

Verificar tabelas fragmentadas

↓

Comparar histórico

↓

Gerar relatório

↓

Sugerir melhorias

Observe a diferença.

Ele deixou de responder.

Agora ele trabalha.


O cérebro continua sendo um LLM

Muitas pessoas imaginam que um AI Agent seja um modelo completamente diferente.

Não é.

O cérebro continua sendo um Large Language Model.

A diferença é que agora existe uma arquitetura em volta dele.

Ela adiciona capacidades como:

  • memória

  • ferramentas

  • planejamento

  • execução

  • observação

  • replanejamento

É como instalar diversos periféricos em um computador.

O processador continua sendo o mesmo.

Mas agora ele possui discos, rede, impressoras e dispositivos externos.


Um agente utiliza ferramentas

Pense em você.

Você não resolve tudo apenas pensando.

Você utiliza ferramentas.

No Mainframe você usa:

  • ISPF

  • SDSF

  • TSO

  • DB2 SPUFI

  • File Manager

  • Fault Analyzer

  • Abend-AID

Da mesma forma, um agente utiliza ferramentas digitais.

Ele pode chamar:

  • APIs REST

  • Bancos SQL

  • Python

  • Shell Script

  • GitHub

  • Docker

  • Navegadores

  • Serviços MCP (Model Context Protocol)

O LLM passa a ser apenas o cérebro que decide qual ferramenta utilizar.


Mas a verdadeira revolução ainda estava por vir

Mesmo um agente possui limitações.

Imagine pedir:

"Modernize um sistema COBOL com oito milhões de linhas."

É uma tarefa gigantesca.

Existe muito trabalho.

Então surge uma pergunta natural.

Por que colocar tudo nas costas de um único agente?

Por que não criar uma equipe?

Nasce então o conceito de Multi-Agent Systems.


Bem-vindo ao escritório da Inteligência Artificial

Agora imagine um escritório.

Em vez de uma única IA...

Existem várias.

Cada uma extremamente especializada.

             Orquestrador

      ↓       ↓       ↓

 COBOL     DB2      CICS

      ↓       ↓       ↓

 Segurança   Testes   APIs

             ↓

      Documentação

Pela primeira vez, a IA começa a funcionar como uma empresa.


O papel do Orquestrador

Toda equipe precisa de alguém coordenando.

Na arquitetura Multi-Agent existe normalmente um componente chamado Orchestrator.

Ele funciona como um gerente de projetos.

Recebe um objetivo.

Analisa.

Divide.

Distribui.

Depois reúne os resultados.

Seu trabalho não é escrever código.

Seu trabalho é organizar pessoas...

Ou melhor...

Organizar agentes.


Parece familiar?

Se você trabalha com Mainframe, provavelmente sim.

Veja alguns componentes do z/OS.

  • JES2

  • RACF

  • DB2

  • IMS

  • CICS

  • MQ

  • DFSMS

  • WLM

Nenhum deles faz tudo.

Cada um possui responsabilidades muito claras.

O sistema operacional coordena todos.

Curiosamente, a arquitetura Multi-Agent segue exatamente essa filosofia.


IBM já fazia isso há décadas

Muita gente acredita que Multi-Agent Systems são uma invenção recente.

Na prática, a computação corporativa utiliza esse conceito desde os anos 70.

Pense em uma transação bancária.

Quando um cliente faz um PIX ou consulta saldo, vários subsistemas trabalham em conjunto:

  • CICS recebe a requisição.

  • RACF autentica o usuário.

  • DB2 consulta os dados.

  • MQ envia mensagens para outros sistemas.

  • JES2 agenda tarefas em batch.

  • WLM distribui recursos de CPU.

  • DFSMS gerencia armazenamento.

Nenhum desses componentes conhece todo o sistema.

Cada um é especialista em sua área.

Essa divisão de responsabilidades é um dos pilares da escalabilidade do IBM Z.

Os sistemas multiagentes apenas transportam essa filosofia para o universo da IA.


Um exemplo para um Programador COBOL Padawan

Imagine que um banco deseje transformar um sistema legado em APIs REST.

Um ambiente multiagente poderia funcionar assim:

Agente 1 — Descoberta

Analisa milhões de linhas COBOL.

Identifica programas.

Mapeia COPYBOOKs.


Agente 2 — Banco de Dados

Localiza tabelas DB2.

Descobre relacionamentos.

Analisa índices.


Agente 3 — CICS

Detecta transações.

Analisa COMMAREAs.

Mapeia Channels e Containers.


Agente 4 — Documentação

Produz diagramas.

Cria documentação técnica.

Explica regras de negócio.


Agente 5 — APIs

Transforma programas em serviços REST.

Gera especificações OpenAPI.


Agente 6 — Testes

Cria testes unitários.

Executa validações.

Produz cobertura de testes.


Agente 7 — Segurança

Analisa autenticação.

Detecta vulnerabilidades.

Sugere melhorias.


Observe que ninguém faz tudo.

Cada agente faz apenas aquilo em que é especialista.


O conceito de Inteligência Coletiva

Um dos maiores erros ao estudar IA é imaginar inteligência como algo individual.

Na natureza, muitos organismos demonstram inteligência coletiva.

Formigas.

Abelhas.

Cupins.

Cardumes.

Nenhum indivíduo conhece o plano completo.

Mesmo assim, a colônia produz comportamentos extraordinários.

Os sistemas multiagentes seguem esse princípio.

Cada agente possui conhecimento limitado.

Mas o conjunto resolve problemas extremamente complexos.


Comunicação entre agentes

Surge então outro desafio.

Como essas inteligências conversam?

A resposta depende da arquitetura.

Algumas utilizam mensagens JSON.

Outras empregam filas como Apache Kafka ou RabbitMQ.

Há ainda sistemas baseados em eventos, chamadas REST e protocolos emergentes como o Model Context Protocol (MCP), que facilita o compartilhamento de contexto e ferramentas entre modelos.

Essa comunicação precisa ser eficiente, confiável e segura.

Caso contrário, os agentes passam mais tempo trocando informações do que resolvendo problemas.


Quando os agentes discordam

Outro aspecto fascinante é que agentes podem divergir.

Imagine três especialistas analisando uma consulta SQL.

O primeiro sugere criar um índice.

O segundo afirma que uma reorganização resolveria o problema.

O terceiro recomenda alterar o plano de acesso.

Quem está certo?

Em sistemas avançados, outro agente pode atuar como árbitro, comparar evidências, executar testes e escolher a melhor solução.

Esse mecanismo reduz vieses e melhora a qualidade das decisões.


Mais agentes significam mais inteligência?

Nem sempre.

Adicionar agentes indiscriminadamente pode gerar:

  • custos maiores com tokens;

  • aumento da latência;

  • conflitos de decisão;

  • duplicação de trabalho;

  • dificuldade de coordenação.

Assim como uma empresa com funcionários demais pode se tornar burocrática, um sistema multiagente mal projetado pode ser menos eficiente do que um único agente bem configurado.

Arquitetura continua sendo essencial.


O futuro do desenvolvimento de software

Imagine abrir seu ambiente de desenvolvimento daqui a alguns anos.

Você descreve uma funcionalidade:

"Criar um novo módulo de empréstimos."

Imediatamente, um orquestrador distribui tarefas:

  • um agente conversa com os analistas de requisitos;

  • outro gera o modelo de dados;

  • um terceiro escreve programas COBOL;

  • outro prepara JCLs;

  • um agente cria testes automatizados;

  • outro verifica segurança;

  • outro produz documentação;

  • um último acompanha a implantação.

Você deixa de trabalhar sozinho com uma IA e passa a liderar uma equipe digital de especialistas.

O desenvolvedor torna-se um arquiteto e coordenador, capaz de definir objetivos, validar resultados e integrar soluções.


O Programador COBOL Padawan não está ficando para trás

Existe um mito de que apenas quem desenvolve aplicações em linguagens modernas participará dessa transformação.

Nada poderia estar mais distante da realidade.

Os maiores bancos, seguradoras, empresas aéreas e governos do mundo continuam executando processos críticos em IBM Z. São ambientes ricos em regras de negócio, documentação histórica e sistemas integrados — exatamente o tipo de contexto em que agentes especializados podem gerar enorme valor.

Conhecer COBOL, CICS, JCL, DB2, VSAM e arquitetura de sistemas corporativos passa a ser um diferencial estratégico, porque esses agentes precisam de especialistas humanos para orientar sua evolução, validar decisões e definir políticas de governança.


Uma nova trilha de conhecimento

Se você deseja se preparar para essa nova era, considere construir uma trilha de aprendizado como esta:

  1. Domine os fundamentos de algoritmos e estruturas de dados.

  2. Aprofunde seus conhecimentos em COBOL, JCL, CICS e DB2.

  3. Estude APIs REST e integração entre sistemas.

  4. Aprenda conceitos de Large Language Models e Engenharia de Prompts.

  5. Explore arquiteturas de AI Agents.

  6. Conheça frameworks como LangGraph, CrewAI, AutoGen e OpenAI Agents SDK.

  7. Entenda protocolos de integração como MCP.

  8. Estude observabilidade, segurança e governança para sistemas de IA.

  9. Pratique a orquestração de múltiplos agentes em problemas reais.

  10. Desenvolva a habilidade mais importante de todas: pensar em sistemas, não apenas em programas.


Conclusão

A história da computação sempre caminhou em direção à especialização e à colaboração. Primeiro vieram os programas monolíticos, depois os sistemas distribuídos, os microsserviços e, agora, os Sistemas Multiagentes.

Para o Programador COBOL Padawan, essa não é uma ruptura com o passado, mas uma continuidade natural. Quem compreende como CICS, DB2, MQ, RACF, JES2 e z/OS colaboram para manter milhões de transações funcionando diariamente já possui uma base conceitual surpreendentemente próxima da lógica dos agentes de IA.

A próxima geração de software não será construída por uma única inteligência artificial onisciente. Ela será resultado da cooperação entre diversas inteligências especializadas, coordenadas por arquiteturas capazes de planejar, executar, validar e aprender continuamente.

E talvez a maior ironia dessa revolução seja esta: enquanto muitos acreditam que a IA está inventando uma forma completamente nova de computação, os profissionais de Mainframe podem reconhecer nela um velho conhecido. Há décadas, o IBM Z nos ensina que sistemas robustos nascem da colaboração entre componentes especializados, governados por uma arquitetura sólida e por princípios de engenharia bem estabelecidos.

Você não está apenas estudando Inteligência Artificial. Está ampliando sua visão sobre a evolução da engenharia de software e descobrindo que, no futuro, o profissional mais valioso não será aquele que compete com a IA, mas aquele que sabe construir, coordenar e orientar equipes inteiras de inteligências artificiais para resolver problemas que, sozinho, nenhum modelo conseguiria enfrentar.

quinta-feira, 5 de março de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Três Camadas Fundamentais dos Agentes de IA

 

Bellacosa Mainframe introduz mcp rag e skills para ia

☕ Um Café no Bellacosa Mainframe

MCP vs RAG vs Skills

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Três Camadas Fundamentais dos Agentes de IA

Quando surgiram os primeiros chatbots, a arquitetura era extremamente simples.

Usuário


LLM

Resposta

Tudo dependia exclusivamente do conhecimento aprendido durante o treinamento do modelo.

O problema?

O modelo não conhecia:

  • documentos internos
  • sistemas da empresa
  • banco de dados
  • regras atualizadas
  • aplicações corporativas

Foi então que nasceram três tecnologias que hoje aparecem praticamente em todos os projetos modernos de IA.

Cada uma resolve um problema completamente diferente.


A grande confusão

Muitas pessoas imaginam algo assim:

MCP OU RAG OU Skills

Na realidade é:

            Agent

┌─────────────┐
│ LLM │
└──────┬──────┘

┌───────┼────────┐
│ │ │
RAG MCP Skills

Os três trabalham juntos.


O papel do RAG

RAG significa

Retrieval Augmented Generation

A ideia é extremamente elegante.

Ao invés de confiar apenas na memória do modelo, buscamos informações atualizadas antes da resposta.

Fluxo:

Pergunta



Busca documentos



Seleciona apenas os mais relevantes



Entrega os documentos ao LLM



LLM responde usando esse contexto

O modelo continua sendo o mesmo.

Quem muda é o contexto entregue a ele.


Analogia Mainframe

Imagine um operador perguntando:

Qual é o procedimento correto para recuperação do CICS?

O LLM não precisa decorar isso.

Ele consulta:

  • Manual IBM
  • Wiki interna
  • Procedimentos da empresa
  • Documentação operacional
  • PDFs
  • SharePoint

Depois responde.

Exatamente como um analista faria.


O pipeline do RAG

Pergunta



Embedding



Vector Database



Busca semântica



Top-K documentos



Prompt



LLM



Resposta

Observe que existe um banco vetorial.

Ele não guarda textos.

Guarda representações matemáticas dos textos.


O que são Embeddings?

Um embedding transforma texto em números.

Por exemplo

"COBOL"



[0.27, -0.88, 0.45, ...]

Assim documentos semelhantes ficam próximos matematicamente.

É por isso que o sistema consegue encontrar documentos parecidos mesmo quando a pergunta usa palavras diferentes.


Onde o RAG é excelente?

✔ FAQ

✔ Base de conhecimento

✔ Documentação

✔ Manual IBM

✔ Políticas internas

✔ Catálogo de APIs

✔ Documentação COBOL

✔ Contratos

✔ Wikis

✔ PDFs

✔ Emails

✔ Normas


Limitações do RAG

O RAG apenas recupera conhecimento.

Ele NÃO executa nada.

Ele não:

  • envia emails
  • consulta banco
  • abre chamados
  • cria tickets
  • reinicia servidores

Ele apenas fornece contexto.


Agora entra o MCP

MCP significa

Model Context Protocol

Criado pela Anthropic, rapidamente adotado por diversos frameworks, tornou-se um padrão para conectar LLMs a ferramentas e sistemas externos.

Enquanto o RAG fornece conhecimento, o MCP fornece ação.


Imagine um agente perguntando:

Quanto dinheiro há na conta?

RAG?

Não funciona.

O saldo muda a todo instante.

É preciso consultar o sistema.

Quem faz isso?

MCP.


O fluxo do MCP

Usuário



LLM



MCP Client



MCP Server



Sistema Externo



Resposta



LLM



Usuário

O MCP funciona como um tradutor universal.


Analogia Mainframe

Imagine um adaptador padrão entre IA e:

  • CICS
  • IMS
  • DB2
  • MQ
  • RACF
  • z/OSMF
  • APIs REST
  • SAP
  • Salesforce

Ao invés de cada ferramenta exigir uma integração diferente, todas expõem capacidades por meio de um protocolo comum.

O agente apenas descobre e utiliza essas capacidades.


O que um MCP Server pode oferecer?

Pode disponibilizar ferramentas como:

Consultar Cliente

Consultar Pedido

Executar SQL

Ler Arquivos

Enviar Slack

Criar Ticket

Executar Shell

Executar Python

Consultar GitHub

Pesquisar Web

Ler Calendário

Enviar Email

Tudo padronizado.


Benefícios do MCP

Padronização.

Descoberta automática de ferramentas.

Segurança.

Controle de permissões.

Menos integrações customizadas.

Reutilização.

Interoperabilidade entre diferentes agentes.


O que são Skills?

As Skills ficam em outra camada.

Elas representam comportamento.

São capacidades reutilizáveis.

Imagine uma Skill chamada

Abrir Incidente

Ela pode executar:

Consultar logs



Analisar erro



Consultar CMDB



Criar Ticket



Enviar Slack



Atualizar Dashboard

Tudo encapsulado.


Skill não é Prompt

Muita gente pensa:

Prompt = Skill

Não.

Prompt é apenas instrução.

Skill normalmente contém:

  • regras
  • fluxo
  • ferramentas
  • parâmetros
  • validações
  • memória
  • tratamento de erros
  • lógica de negócio

É praticamente um pequeno aplicativo.


Analogia COBOL

Uma Skill lembra muito um programa COBOL reutilizável.

PAYROLL



Recebe parâmetros



Executa regras



Consulta DB2



Atualiza registros



Retorna resultado

Você não reescreve tudo.

Você apenas chama.


Comparação completa

CaracterísticaRAGMCPSkills
ObjetivoBuscar conhecimentoConectar sistemasExecutar processos
Atua sobreInformaçãoFerramentasFluxos de trabalho
Atualiza dadosSimSimDepende
Executa açõesNãoSimSim
ReutilizaçãoMédiaAltaMuito Alta
Usa LLMSimSimSim
Pode usar banco vetorialSimNãoOpcional

Como tudo trabalha junto?

Imagine um banco.

O usuário pergunta:

Meu cartão foi bloqueado. O que aconteceu?

O agente executa:

Etapa 1 — Skill

Resolver Problema Cartão

Etapa 2 — MCP

Consulta

Sistema de Cartões

Obtém:

Status

Limite

Fraude

Eventos

Etapa 3 — RAG

Consulta

Manual de Bloqueios

Normas BACEN

Políticas internas

Etapa 4 — LLM

Combina

  • dados atuais
  • regras
  • conhecimento
  • contexto

E produz uma resposta clara e fundamentada.


Arquitetura completa

                Usuário


┌──────────┐
│ LLM │
└────┬─────┘

┌─────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Skills RAG MCP
│ │ │
Fluxos Conhecimento Ferramentas
│ │ │
▼ ▼ ▼
Regras Vector DB APIs • DB2 • CICS
Workflows Documentos Git • Slack • ERP
PDFs • Wiki Shell • Python

Um exemplo no universo IBM Z

Suponha que um operador pergunte:

"Por que o JOB PAYROLL001 terminou em ABEND S0C7 e como posso corrigir isso?"

Um agente corporativo pode orquestrar as três camadas:

  1. Skill "Diagnosticar ABEND": coordena todo o fluxo de investigação.
  2. MCP: acessa SDSF para obter o JOBLOG, consulta o catálogo do JES2, lê registros SMF, executa uma consulta no DB2 e busca o código-fonte no Git.
  3. RAG: recupera documentação sobre S0C7, padrões de tratamento de dados numéricos, procedimentos internos da empresa e artigos da IBM.
  4. LLM: cruza os dados operacionais em tempo real com a documentação recuperada e apresenta uma explicação detalhada, indicando a provável causa (por exemplo, um campo NUMERIC contendo caracteres inválidos), os programas afetados e os passos recomendados para correção.

Sem o RAG, o agente não teria acesso às políticas e manuais atualizados. Sem o MCP, ele não conseguiria consultar os sistemas corporativos. Sem a Skill, cada investigação exigiria um novo prompt complexo e inconsistente.


A evolução da arquitetura de IA

A tendência é que agentes corporativos sejam compostos por várias camadas especializadas:

  • LLM: raciocínio e geração de linguagem.
  • Memória: histórico e contexto de longo prazo.
  • RAG: recuperação de conhecimento atualizado.
  • MCP: acesso padronizado a ferramentas e sistemas externos.
  • Skills: automação de processos recorrentes e reutilizáveis.
  • Planejamento: decomposição de objetivos em múltiplas etapas.
  • Observabilidade: logs, métricas, rastreamento e auditoria.

Essa combinação transforma um simples chatbot em um agente corporativo capaz de consultar informações, interagir com sistemas legados, executar processos complexos e aprender com o contexto, aproximando-se do que será o padrão da engenharia de software baseada em IA nos próximos anos.

Resumindo em uma frase

  • 🧠 RAG responde à pergunta: "O que o agente precisa saber?"
  • 🔌 MCP responde: "Com quais sistemas o agente pode conversar?"
  • ⚙️ Skills respondem: "O que o agente sabe fazer de forma consistente e reutilizável?"

Quando essas três camadas trabalham em conjunto, surgem agentes capazes de ir muito além de uma conversa: eles compreendem o contexto, acessam o mundo externo e executam tarefas reais, representando a base da próxima geração de aplicações inteligentes.


quinta-feira, 28 de agosto de 2025

AI Agents : Quando um Programador Descobre que um LLM é Apenas o EXEC PGM...

 

Bellacosa Mainframe apresenta ai agents

☕ Um Café no Bellacosa Mainframe

AI Agents sem Mistérios para Programadores COBOL

Quando um Programador Descobre que um LLM é Apenas o EXEC PGM... e que o Verdadeiro Sistema Inteligente é Quase um z/OS Inteiro Rodando nos Bastidores

"O computador do futuro não será aquele que responde perguntas. Será aquele que entende objetivos."


Introdução

Durante muitos anos, o mundo da Inteligência Artificial parecia incrivelmente simples.

Você fazia uma pergunta.

A IA respondia.

Fim da história.

Foi exatamente assim que milhares de pessoas conheceram ferramentas como ChatGPT, Claude, Gemini e outras.

Mas existe um detalhe que quase ninguém percebe logo no início.

Isso é apenas a superfície do iceberg.

É semelhante ao primeiro contato de um estudante com COBOL.

Ele escreve:

DISPLAY "HELLO WORLD".
STOP RUN.

Executa.

Funciona.

Ele acredita que já sabe COBOL.

Até descobrir que aquele pequeno programa roda dentro de um universo composto por JCL, JES2, WLM, RACF, VSAM, Db2, CICS, IMS, MQ, Storage, TCP/IP, Catálogos, APF, IPL, RMF, SMF e dezenas de outros componentes.

Nesse momento acontece o mesmo choque que muitos profissionais têm quando descobrem os AI Agents.

Eles percebem que um LLM não é o sistema.

É apenas uma peça.

A arquitetura verdadeira é muito maior.

Pegue seu café.

Hoje vamos fazer uma viagem pelo data center da Inteligência Artificial, utilizando exemplos que qualquer programador COBOL consegue visualizar.

Como diria o Guia do Mochileiro das Galáxias:

"Não entre em pânico."

Porque, no final deste artigo, você perceberá que AI Agents lembram muito mais um ambiente IBM Z do que um simples chatbot.


O Grande Engano

A maioria das pessoas imagina uma IA funcionando assim:

Pergunta

↓

LLM

↓

Resposta

Parece mágico.

Mas também parece extremamente limitado.

Agora imagine um banco.

Um cliente entra numa agência.

Ele pergunta:

"Qual meu saldo?"

Será que o caixa sabe?

Não.

Ele consulta dezenas de sistemas.

Da mesma forma funciona um AI Agent.

Na realidade o fluxo é parecido com isto:

Usuário

↓

Planejamento

↓

Memória

↓

Ferramentas

↓

APIs

↓

Banco de dados

↓

Execução

↓

Validação

↓

Nova decisão

↓

Resposta

Perceba uma coisa interessante.

O LLM aparece apenas uma vez.

Todo o restante do trabalho acontece ao redor dele.


O LLM é Apenas um Programa COBOL

Esta talvez seja a analogia mais importante deste artigo.

Imagine um programa COBOL.

Ele faz cálculos.

Manipula arquivos.

Atualiza banco.

Executa regras.

Mas sozinho ele não consegue:

  • abrir sessão

  • controlar segurança

  • acessar MQ

  • gerenciar memória

  • iniciar tarefas

  • distribuir carga

  • monitorar CPU

Quem faz isso?

O ambiente.

No IBM Z esse ambiente chama-se:

  • z/OS

  • JES2

  • RACF

  • WLM

  • CICS

  • Db2

  • MQ

  • USS

  • TCP/IP

No universo da IA acontece exatamente a mesma coisa.

O GPT, Claude ou Gemini são apenas o "programa COBOL".

O verdadeiro sistema inteligente é todo o restante.


Primeira Camada

Model & Intelligence Foundation

Toda construção começa pela fundação.

Na IA essa fundação é formada pelos modelos.

GPT.

Claude.

Gemini.

Llama.

Mistral.

Qwen.

DeepSeek.

São os motores de raciocínio.

Mas há um detalhe curioso.

Nenhum deles conhece sua empresa.

Nenhum conhece seu sistema COBOL.

Nenhum sabe o conteúdo do seu Db2.

Eles precisam aprender isso durante a execução.

É aqui que entram vários conceitos modernos.


Embeddings

O Índice VSAM da Inteligência Artificial

Imagine um arquivo KSDS.

Você procura:

Cliente 123456

O índice localiza rapidamente.

Embeddings fazem algo parecido.

Só que ao invés de procurar números...

eles procuram significado.

Por exemplo.

ABEND S0C7

Data Exception

Erro Decimal

Campo Numérico Inválido

São frases diferentes.

Mas possuem praticamente o mesmo significado.

Os embeddings transformam tudo isso em coordenadas matemáticas.

Assim a IA consegue encontrar conhecimento sem depender das palavras exatas.

É quase um VSAM KSDS semântico.


RAG

Quando a IA Aprende a Consultar a Documentação

Imagine perguntar:

Como funciona o módulo FINA230?

O LLM responde:

"Não faço ideia."

Mas o agente não para por aí.

Ele faz exatamente o que um analista faria.

Consulta:

  • Wiki

  • SharePoint

  • PDFs

  • GitHub

  • COBOL

  • CICS

  • JCL

  • Documentação

Depois lê tudo.

Somente então responde.

Isso chama-se:

Retrieval Augmented Generation

Ou simplesmente:

RAG.

Na prática:

Pergunta

↓

Pesquisar

↓

Ler

↓

Entender

↓

Responder

É como aquele programador veterano que nunca responde de memória.

Primeiro ele abre a documentação.


Mixture of Experts

Imagine um CPD.

Existe:

Especialista COBOL

Especialista CICS

Especialista Db2

Especialista RACF

Especialista MQ

Especialista Storage

Especialista Linux

Especialista Cloud

Seria inteligente colocar apenas um deles para resolver tudo?

Claro que não.

Os modelos Mixture of Experts funcionam exatamente assim.

Cada parte do cérebro possui especialistas.

Dependendo da pergunta...

o agente consulta apenas quem realmente entende daquele assunto.

Resultado?

Mais rapidez.

Menor custo.

Maior qualidade.


Segunda Camada

Agent Cognitive Engine

Aqui acontece a transformação.

O chatbot vira agente.


Memória

Existe um mito curioso.

As pessoas acreditam que IA lembra tudo.

Na verdade existem vários tipos de memória.

Curto prazo.

Sessão.

Longo prazo.

Conhecimento persistente.

É parecido com:

WORKING-STORAGE

↓

TSQ

↓

VSAM

↓

Db2

Cada uma possui finalidade diferente.


Planejamento

Um chatbot responde perguntas.

Um agente cria planos.

Exemplo.

Você escreve:

"Atualize todos os servidores."

Um chatbot responde:

"Aqui está um tutorial."

Um agente responde:

Inventariar servidores

↓

Separar ambientes

↓

Validar acesso

↓

Executar Ansible

↓

Verificar erros

↓

Rollback se necessário

↓

Gerar relatório

↓

Enviar e-mail

Percebe a diferença?

Ele pensa como um gerente de projetos.


Self Reflection

Um dos recursos mais fascinantes.

Depois de responder...

o agente pergunta para si mesmo:

Isso faz sentido?

Existe erro?

Posso melhorar?

Esqueci alguma etapa?

Existe risco?

É quase um Code Review automático.

Imagine um compilador COBOL que, após gerar o objeto, ainda revisasse a lógica inteira antes da execução.


Contexto Dinâmico

Programadores experientes sabem.

Resolver um problema depende do contexto.

O mesmo SQL pode ser excelente numa aplicação.

E péssimo em outra.

Agentes mantêm contexto durante toda a conversa.

Isso reduz inconsistências.


Terceira Camada

Autonomous Decision Layer

Agora entramos na parte que assusta muita gente.

Tomada de decisão.

Mas calma.

Não significa "IA fazendo tudo sozinha".

Significa tomar pequenas decisões baseadas em objetivos.


Objetivos

Toda ação começa por um objetivo.

Resolver incidente

↓

Encontrar causa

↓

Corrigir

↓

Documentar

Sem objetivo.

Não existe agente.

Existe apenas um chatbot.


Planejamento Hierárquico

Problemas gigantes são quebrados em partes menores.

Assim como um grande sistema COBOL.

Sistema

↓

Módulos

↓

Programas

↓

Parágrafos

↓

Sentenças

Gestão de Risco

Um bom agente nunca pergunta apenas:

"Posso executar?"

Ele pergunta:

"Devo executar?"

Exemplo.

Excluir banco?

↓

Existe backup?

↓

Produção?

↓

Rollback?

↓

Janela?

↓

Autorização?

Isso lembra muito RACF.

Nem tudo que é possível deve ser permitido.


Quarta Camada

Interaction & Communication

Aqui nasce a colaboração.

Agentes modernos conversam.

Não apenas com humanos.

Mas também entre si.


Linguagem Natural

Chega de decorar comandos.

Você escreve normalmente.

Como se estivesse conversando com um colega.


Multimodalidade

Texto.

Imagem.

PDF.

Planilha.

Vídeo.

Áudio.

Código.

Tudo pode fazer parte da mesma conversa.

Imagine enviar:

  • Dump

  • SYSOUT

  • Print do SDSF

  • Código COBOL

  • SQLCODE

Tudo ao mesmo tempo.

O agente entende.


Human in the Loop

Esse conceito é fantástico.

Algumas decisões continuam humanas.

Por exemplo.

Excluir cliente VIP?

O agente para.

Pergunta.

Espera autorização.

Isso evita desastres.


Quinta Camada

Multi-Agent Collaboration

Agora imagine um departamento inteiro.

Existe um agente para cada função.

Financeiro

RH

Compras

Jurídico

DevOps

COBOL

Segurança

Cloud

Todos trabalham juntos.

É praticamente uma empresa digital.


Swarm Intelligence

Inspirado em:

abelhas

formigas

cupins

Nenhum indivíduo conhece o plano completo.

Mesmo assim...

a colônia constrói estruturas gigantescas.

Agentes modernos usam exatamente esse princípio.


Negociação

Imagine.

Agente Financeiro diz:

"Sem orçamento."

Jurídico responde:

"Contrato precisa ser alterado."

DevOps:

"Deploy permitido apenas domingo."

COBOL:

"Programa depende do módulo antigo."

Todos discutem.

Depois apresentam uma única decisão.


Sexta Camada

Environment & Tool Connectivity

Este é o ponto que diferencia um chatbot de um verdadeiro agente.

Ferramentas.

Sem ferramentas.

Ele apenas conversa.

Com ferramentas.

Ele trabalha.

Pode acessar:

  • GitHub

  • Jenkins

  • Jira

  • ServiceNow

  • SAP

  • Salesforce

  • APIs

  • REST

  • GraphQL

  • SQL

  • Bancos Vetoriais

  • Kubernetes

  • Docker

  • Ansible

  • Mainframe

  • z/OSMF

É como um operador de produção que possui acesso ao painel inteiro do data center.


Digital Twins

Antes de alterar produção...

simule.

Antes de executar...

teste.

Antes de migrar...

valide.

Digital Twins fazem exatamente isso.

Criam um ambiente virtual.

Executam milhares de cenários.

Somente depois permitem a mudança.

Parece familiar?

É exatamente a filosofia dos ambientes de Desenvolvimento, Homologação, QA e Produção.


O Que a Imagem Não Mostra

A arquitetura apresentada é excelente, mas alguns pilares são tão importantes quanto os mostrados.

Segurança

Nenhum agente corporativo deveria operar sem:

  • RACF (ou equivalente)

  • autenticação

  • autorização

  • gestão de segredos

  • criptografia

  • auditoria

Sem isso, um agente pode se tornar um enorme risco.

Observabilidade

Assim como um administrador z/OS utiliza RMF, SMF e SDSF para entender o comportamento do sistema, agentes precisam registrar:

  • logs

  • métricas

  • chamadas de ferramentas

  • consumo de tokens

  • latência

  • falhas

  • decisões

Sem observabilidade, fica impossível descobrir por que um agente tomou determinada decisão.

Governança

Quem aprovou?

Qual modelo foi utilizado?

Quais documentos fundamentaram a resposta?

Qual ferramenta foi acionada?

Essas perguntas são essenciais em bancos, seguradoras e órgãos públicos.


AI Agents e o IBM Mainframe: A Analogia Definitiva

Se tivéssemos que desenhar um agente para um programador COBOL, ele seria algo assim:

Mundo dos AI AgentsMundo IBM Mainframe
LLMPrograma COBOL
PromptJCL ou parâmetros de execução
MemóriaVSAM, Db2, TSQ, contexto da sessão
PlanejamentoScheduler, Workflow, JCL
FerramentasCICS, MQ, APIs, utilitários
ComunicaçãoMQ, TCP/IP, REST, eventos
MultiagentesRegiões CICS e serviços especializados
Tomada de decisãoRegras de negócio + automação
SegurançaRACF
ObservabilidadeRMF, SMF, SDSF
Ambientez/OS

Essa comparação ajuda a entender por que tantas empresas tradicionais estão interessadas em agentes: elas já operam sistemas distribuídos e altamente orquestrados há décadas.


Curiosidades

☕ Curiosidade 1

O termo Agentic AI ganhou enorme destaque a partir de 2024, quando empresas perceberam que apenas conversar com um LLM não gerava tanto valor quanto automatizar fluxos completos de trabalho.

☕ Curiosidade 2

Muitos agentes modernos utilizam RAG, mas nem todo sistema com RAG é um agente. Um agente normalmente combina memória, planejamento, ferramentas e tomada de decisão.

☕ Curiosidade 3

Os primeiros conceitos de agentes inteligentes surgiram muito antes dos LLMs, em pesquisas sobre Inteligência Artificial Distribuída, Sistemas Multiagentes (MAS) e Arquiteturas BDI (Belief-Desire-Intention), desenvolvidas nas décadas de 1980 e 1990.

☕ Curiosidade 4

Alguns sistemas corporativos já utilizam "agentes supervisores", responsáveis por acompanhar outros agentes, detectar desvios e solicitar intervenção humana quando necessário.


Dicas para Quem Está Começando

  1. Aprenda primeiro como funciona um LLM antes de estudar agentes.

  2. Entenda RAG e bancos vetoriais; eles são a principal ponte entre IA e conhecimento corporativo.

  3. Estude APIs REST e ferramentas de integração, pois um agente útil precisa agir sobre sistemas reais.

  4. Familiarize-se com orquestração de workflows e automação, usando conceitos semelhantes aos schedulers do mundo mainframe.

  5. Não ignore segurança, auditoria e governança; em ambientes corporativos, elas são tão importantes quanto o próprio modelo.


Easter Eggs do Bellacosa ☕

🥚 Easter Egg #1 — O Guia do Mochileiro da IA

Assim como o número 42 representa a resposta para a vida, o universo e tudo mais, muitos projetos de IA descobrem que a resposta para quase qualquer problema complexo é... "depende do contexto".

🥚 Easter Egg #2 — A Estrela da Morte

Construir um agente poderoso sem mecanismos de segurança é como construir a Estrela da Morte sem proteger a exaustão térmica: impressiona à primeira vista, mas basta uma pequena falha para comprometer toda a operação.

🥚 Easter Egg #3 — O Mestre Jedi do Mainframe

O verdadeiro Mestre Jedi não é aquele que conhece todos os prompts. É aquele que sabe quando usar um LLM, quando consultar um RAG, quando delegar a outro agente e quando chamar um ser humano para decidir.


Conclusão

Durante décadas, os profissionais de mainframe aprenderam que um programa COBOL nunca vive isolado. Ele faz parte de um ecossistema cuidadosamente orquestrado por z/OS, JES2, CICS, Db2, MQ, RACF, WLM e inúmeras outras tecnologias que trabalham em conjunto para entregar disponibilidade, segurança e desempenho.

Os agentes de IA seguem exatamente essa filosofia. O modelo de linguagem é apenas o ponto de partida. O verdadeiro diferencial está na combinação de memória, planejamento, ferramentas, protocolos de comunicação, colaboração entre agentes, governança e integração com o mundo real.

Em outras palavras, estamos deixando a era dos chatbots para entrar na era dos ecossistemas cognitivos. Assim como um programa COBOL isolado jamais substituiria um data center inteiro, um LLM isolado não representa o futuro da Inteligência Artificial. O futuro pertence a arquiteturas capazes de compreender objetivos, coordenar especialistas, utilizar ferramentas, aprender com a experiência e operar de forma segura e auditável.

Para quem já domina a lógica dos grandes ambientes IBM Z, essa evolução não é um salto para o desconhecido. É apenas uma nova forma de aplicar princípios que o mundo mainframe aperfeiçoa há décadas: modularidade, integração, confiabilidade, controle e colaboração. O programador COBOL que entender essa ponte perceberá que a próxima geração de sistemas inteligentes não substitui sua experiência — ela amplia seu alcance, transformando conhecimento técnico em uma força multiplicadora para resolver problemas cada vez mais complexos.

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