☕ UM CAFÉ NO BELLACOSA MAINFRAME
☕ ALAN TURING ENTRA NO CPD — O MAPA DOS AGENTES DE IA EXPLICADO POR UM MAINFRAMER
De currículo invisível, PF3 e SDSF até WLM, JES2, CICS, Db2, MQ e IMS — nove conversas sobre agentes de inteligência artificial que acabaram revelando que alguns dos problemas mais modernos da computação possuem parentes muito antigos.
🎬 PRÓLOGO — EU NÃO ESTAVA ESCREVENDO UMA SÉRIE
Existe uma coisa curiosa em escrever durante muitos anos.
Às vezes você pensa que está escrevendo artigos independentes.
Um assunto aparece.
Você investiga.
Escreve.
Publica.
Toma outro café.
Algumas semanas depois aparece outra pergunta.
Outro artigo.
Outro café.
Até que um dia você olha para trás e percebe:
Espere um pouco...
Esses textos estão conversando entre si.
Foi exatamente o que aconteceu com uma sequência de artigos que comecei a construir usando Alan Turing como nosso visitante imaginário dentro de um CPD.
No começo, a pergunta parecia relativamente simples:
Como devemos preparar pessoas para trabalhar com inteligência artificial?
Depois apareceu outra:
Como será a interface de um agente que não apenas responde, mas executa ações?
E outra:
Como descobriremos o que esse agente está fazendo?
Depois:
Quem decide qual agente é mais importante?
Quem coloca o trabalho para executar?
Como controlamos uma transação?
Onde guardamos o estado?
Como agentes conversam sem depender uns dos outros?
Como organizamos memória e contexto?
Quando percebi, Alan Turing já estava andando pelo corredor do CPD acompanhado de alguns velhos conhecidos:
ISPF
SDSF
WLM
JES2
CICS
Db2
MQ
IMSE foi aí que apareceu a hipótese que une esta série inteira:
Talvez alguns dos problemas que estamos descobrindo agora nos agentes de IA sejam novos em implementação, escala e comportamento — mas não necessariamente novos como problemas de engenharia.
O mainframe passou décadas resolvendo problemas como:
IDENTIDADE
AUTORIZAÇÃO
EXECUÇÃO
PRIORIDADE
OBSERVABILIDADE
TRANSAÇÃO
ESTADO
MENSAGERIA
RECUPERAÇÃO
AUDITORIA
CONCORRÊNCIA
DEPENDÊNCIASNaturalmente:
JES2 não é um framework de agentes.
SDSF não é observabilidade de LLM.
WLM não é um scheduler de prompts.
CICS não é LangGraph.
Db2 não é memória de IA.
MQ não é protocolo mágico entre agentes.
IMS não foi inventado para armazenar a infância digital de um robô.
😂
A comparação é conceitual.
E justamente por isso ela é tão interessante.
Este artigo é o mapa dessa viagem.
🧠 CAPÍTULO 1 — O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL
Antes de construir o agente, precisamos construir quem vai trabalhar com ele
👉 ALAN TURING E O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL
Nossa viagem começa antes da arquitetura.
Começa nas pessoas.
Existe uma tentação enorme diante de qualquer revolução tecnológica:
NOVA TECNOLOGIA
↓
NOVO CURSO
↓
NOVA FERRAMENTA
↓
CERTIFICADO
↓
PRONTOMas nunca foi tão simples.
Quem viveu várias gerações da informática sabe disso.
Aprender COBOL não significava apenas conhecer:
MOVE
PERFORM
IF
EVALUATEO programador acabava aprendendo silenciosamente muitas outras coisas:
decomposição de problemas;
leitura de documentação;
disciplina operacional;
análise de impacto;
debugging;
responsabilidade sobre dados;
relacionamento com usuários;
conhecimento do negócio;
avaliação de riscos.
Existe, portanto, um currículo formal e outro quase invisível.
Com IA acontece algo semelhante.
Prompt engineering pode ser útil.
Conhecer modelos também.
Mas trabalhar seriamente com IA começa a exigir algo muito maior:
IA
│
├── pensamento crítico
├── validação
├── segurança
├── privacidade
├── conhecimento de domínio
├── avaliação de resultados
├── automação
├── ética
├── governança
└── capacidade de perguntarEste primeiro artigo estabelece o fundamento humano da série.
Antes de perguntar:
O que o agente pode fazer?
precisamos perguntar:
Quem saberá dizer se aquilo que ele fez está correto?
Esse detalhe acompanhará todos os capítulos seguintes.
🤖 CAPÍTULO 2 — A UX DOS AGENTES
Quando PF3 voltou para salvar a inteligência artificial
Então demos autonomia à máquina.
E imediatamente apareceu outro problema.
Um chatbot responde.
Um agente age.
Essa diferença parece pequena até colocarmos ferramentas nas mãos dele.
Imagine:
USUÁRIO
↓
OBJETIVO
↓
AGENTE
├── consulta arquivos
├── chama API
├── pesquisa banco
├── altera documento
├── envia mensagem
└── executa processoDe repente a interface precisa responder perguntas que o velho chatbot não precisava responder:
O QUE ESTÁ FAZENDO?
POR QUE ESTÁ FAZENDO?
QUAL ETAPA ESTÁ EXECUTANDO?
POSSO PARAR?
POSSO DESFAZER?
QUEM AUTORIZOU?
O QUE JÁ FOI ALTERADO?E eis que aparece nosso velho amigo:
PF3O PF3 torna-se uma metáfora perfeita para interruptibilidade.
O artigo também traz RACF para a conversa por meio do princípio de menor privilégio.
Se um agente precisa ler relatórios:
READpor que entregar:
ALTER
DELETE
CONTROL?
Não entregue uma bazuca para matar um mosquito.
E jamais resolva problemas de autorização usando a filosofia:
DÊ ACESSO A TUDO
↓
DEPOIS A GENTE VÊQuatro décadas de segurança corporativa já ensinaram como essa história termina.
O capítulo estabelece uma nova regra:
Autonomia sem controle não é sofisticação. É risco operacional.
🔭 CAPÍTULO 3 — O SDSF DOS AGENTES
Não basta o robô trabalhar. Precisamos enxergar o que está acontecendo.
👉 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS O ROBÔ ESTÁ FAZENDO?
Agora o agente está trabalhando.
Maravilha.
Só existe uma pequena pergunta:
O que ele está fazendo?
Quem trabalhou com batch conhece uma rotina quase instintiva:
SUBMIT
↓
SDSF
↓
ST
↓
JOB
↓
OUTPUTNão ficamos olhando para o terminal durante quinze minutos vendo:
Working...Queremos estado.
Queremos evidência.
Queremos saber onde o processamento está.
A documentação da IBM confirma exatamente essa função histórica do SDSF: monitorar e controlar processamento, visualizar jobs e seus outputs e permitir ações como hold, release e cancel.
Transportando o princípio para agentes:
AGENTE FINANCEIRO
OBJETIVO:
Consolidar relatório mensal
STATUS:
Executando
ETAPA 1 — localizar arquivos OK
ETAPA 2 — validar período OK
ETAPA 3 — consultar Db2 OK
ETAPA 4 — reconciliar valores RUNNING
ETAPA 5 — gerar relatório WAITING
ETAPA 6 — enviar relatório APPROVALEsse talvez seja um dos conceitos mais importantes da série.
Autonomia aumenta a necessidade de observabilidade.
Quanto menos diretamente o humano controla cada passo, mais importante se torna enxergar o estado da execução.
⚖️ CAPÍTULO 4 — O WLM DOS AGENTES
Quando descobrimos que nem todo trabalho possui a mesma importância
👉 ALAN TURING E O WLM DOS AGENTES
Agora temos outro problema.
Imagine mil agentes querendo trabalhar simultaneamente.
Um está:
resumindo newsletterOutro:
processando fraude bancáriaOutro:
gerando imagemOutro:
atendendo cliente VIPOutro:
fechando folha de pagamentoTodos deveriam receber os mesmos recursos?
Evidentemente não.
Bem-vindo ao velho problema de workload management.
No z/OS, WLM trabalha justamente com classes de serviço, metas de desempenho e importância relativa do trabalho. Quando todos os objetivos não podem ser satisfeitos simultaneamente, essa importância participa das decisões de gerenciamento dos recursos.
Nos agentes podemos imaginar:
AGENT WORKLOAD
│
├── CRITICAL
│ └── fraude
│
├── HIGH
│ └── atendimento
│
├── NORMAL
│ └── relatórios
│
└── DISCRETIONARY
└── indexação históricaE aparece outra ideia fundamental:
Agentes competirão por recursos.
Tokens custam.
GPU custa.
CPU custa.
APIs possuem limites.
Bancos possuem capacidade.
Pessoas disponíveis para aprovação humana também são um recurso limitado.
O problema deixa de ser:
O agente consegue executar?
e passa a ser:
Qual trabalho merece recursos primeiro?
Alan Turing acaba de conhecer o WLM.
🏭 CAPÍTULO 5 — O JES2 DOS AGENTES
Alguém precisa receber, organizar e despachar o trabalho
👉 ALAN TURING E O JES2 DOS AGENTES
Temos prioridades.
Temos recursos.
Temos agentes.
Agora alguém precisa organizar a bagunça.
No mundo batch, JES recebe jobs, mantém trabalhos em filas, encaminha jobs para execução e administra seus outputs. É exatamente assim que a própria documentação introdutória do z/OS descreve suas funções fundamentais.
Conceitualmente:
SUBMISSÃO
↓
FILA
↓
CLASSIFICAÇÃO
↓
DESPACHO
↓
EXECUÇÃO
↓
RESULTADOAgora substitua JOB por TASK:
TASK-8472
OBJETIVO = analisar contratos
PRIORIDADE = HIGH
AGENTE = LEGAL-07
STATUS = WAITINGComeçamos a perceber que um ecossistema corporativo de agentes precisará responder:
Quem recebeu a tarefa?
Onde ela está?
Quem executará?
Está esperando?
Está rodando?
Falhou?
Pode reiniciar?
Existe dependência?
Qual resultado produziu?Não significa transformar JES2 em orquestrador de LLM.
Significa reconhecer que gerenciamento do ciclo de vida do trabalho é um problema antigo.
⚡ CAPÍTULO 6 — O CICS DOS AGENTES
Quando inteligência encontra transação
👉 ALAN TURING E O CICS DOS AGENTES
Até aqui nossos agentes estavam realizando trabalho.
Mas empresas não vivem apenas de trabalho.
Vivem de transações.
Comprar.
Vender.
Reservar.
Cancelar.
Transferir.
Atualizar.
Consultar.
Registrar.
CICS existe justamente no universo de processamento transacional. Uma transação dispara programas associados, pode envolver diversos programas e recursos, e muitas instâncias podem executar concorrentemente.
Agora imagine um agente recebendo:
Resolva o problema deste cliente.
Ele talvez precise:
CONSULTAR PEDIDO
↓
CONSULTAR PAGAMENTO
↓
VALIDAR ENTREGA
↓
CALCULAR CRÉDITO
↓
ATUALIZAR CADASTRONão estamos mais falando apenas de linguagem.
Estamos mexendo no estado real do negócio.
Aqui surge uma fronteira essencial:
PENSAR
≠
AGIRe:
GERAR UMA RESPOSTA
≠
EXECUTAR UMA TRANSAÇÃOQuando um agente atravessa essa fronteira, entram em cena concorrência, integridade, autorização, recuperação e consistência.
O simpático chatbot acabou de entrar em produção.
Agora a brincadeira ficou séria.
🗄️ CAPÍTULO 7 — O DB2 DOS AGENTES
Quando o agente descobriu que memória também precisa de COMMIT
👉 ALAN TURING E O DB2 DOS AGENTES
Um agente sem estado vive eternamente no presente.
Para realizar trabalhos complexos ele precisa guardar coisas.
Por exemplo:
objetivos
tarefas
resultados
aprovações
clientes
documentos
eventos
checkpoints
estado do workflowMas guardar informação introduz um problema:
Quando uma mudança se torna definitiva?
O velho Db2 imediatamente levanta a mão.
No Db2, uma unidade de trabalho representa uma sequência recuperável de operações; COMMIT confirma as mudanças e ROLLBACK pode desfazer alterações ainda não confirmadas.
Isso produz uma analogia poderosa para agentes.
Imagine:
LER
↓
ANALISAR
↓
PROPOR ALTERAÇÃO
↓
VALIDAR
↓
APROVAÇÃO
↓
COMMITSe algo falhar:
ROLLBACKMas existe uma pegadinha deliciosa.
Nem tudo no mundo possui rollback.
Se o agente:
ENVIAR EMAILnão existe:
ROLLBACK EMAILque retire a mensagem da cabeça de quem leu.
😂
Portanto sistemas de agentes precisam distinguir ações reversíveis de ações irreversíveis.
O Db2 nos ensina algo maior que SQL:
Estado precisa possuir fronteiras de consistência.
📨 CAPÍTULO 8 — O MQ DOS AGENTES
Mensagem enviada não significa destinatário disponível
👉 ALAN TURING E O MQ DOS AGENTES — MENSAGEM ENVIADA NÃO SIGNIFICA CONVERSA SÍNCRONA
Então nossos agentes começaram a conversar.
E imediatamente alguém inventou:
AGENTE A
↓
AGENTE B
↓
AGENTE CParece maravilhoso.
Até o agente B ficar indisponível.
Ou lento.
Ou ocupado.
Ou reiniciar.
Ou o agente C morar em outro ambiente.
É exatamente aqui que décadas de mensageria corporativa começam a parecer extremamente atuais.
IBM MQ permite que aplicações se comuniquem através de mensagens e filas, inclusive executando em momentos, velocidades e locais diferentes. Produtor e consumidor podem ficar desacoplados.
Portanto:
AGENTE A
↓
MENSAGEM
↓
FILA
↓
AGENTE BA existência da fila muda completamente a arquitetura.
O produtor não precisa necessariamente ficar parado olhando para o consumidor.
Podemos construir sistemas:
ASSÍNCRONOS
RESILIENTES
DESACOPLADOS
DISTRIBUÍDOSMas surgem novos problemas:
ordenação
duplicidade
correlação
persistência
retry
dead letter
idempotência
timeoutA IBM também documenta que filas mantêm mensagens até que aplicações possam recuperá-las e que consumidores e produtores podem operar desacoplados.
De repente, multiagentes deixam de parecer uma reunião de robôs conversando.
Começam a parecer...
sistemas distribuídos.
Bem-vindo ao inferno.
Tem café na entrada.
🌳 CAPÍTULO 9 — O IMS DOS AGENTES
Quando Alan Turing descobriu que encontrar um filho é fácil se você souber quem é o pai
👉 ALAN TURING E O IMS DOS AGENTES — QUANDO O MUNDO VIROU UMA ÁRVORE
Finalmente chegamos ao IMS.
E aparece uma pergunta fascinante:
Toda memória precisa ser representada como tabela?
Não.
IMS trabalha historicamente com modelo hierárquico.
Temos relações:
ROOT
│
├── CHILD
│ ├── CHILD
│ └── CHILD
│
└── CHILDNa terminologia oficial do IMS, segmentos possuem relações parent/child; um segmento pode inclusive ser filho de um segmento e pai de outro.
Isso oferece uma metáfora extraordinariamente útil para determinados tipos de contexto de agentes.
Imagine:
CLIENTE
│
├── PEDIDOS
│ ├── PEDIDO 8472
│ │ ├── ITENS
│ │ ├── PAGAMENTO
│ │ └── ENTREGA
│ └── PEDIDO 9011
│
├── CONTRATOS
│
└── ATENDIMENTOSContexto frequentemente possui relações naturais.
A própria IBM explica uma diferença fundamental: numa base hierárquica IMS, segmentos ao longo de um caminho hierárquico já possuem relações implícitas com pais e filhos, enquanto no modelo relacional relacionamentos normalmente são construídos explicitamente por joins.
Isso não significa:
Vamos substituir vector databases por IMS!
Calma.
😂
A lição é mais interessante:
A forma como representamos conhecimento influencia profundamente a maneira como conseguimos navegar por ele.
E assim chegamos da execução à memória.
🗺️ CAPÍTULO 10 — AGORA OLHE PARA O MAPA INTEIRO
Depois dos nove artigos, podemos finalmente enxergar a arquitetura escondida.
┌───────────────────────────────────────┐
│ CURRÍCULO INVISÍVEL │
│ Quem está preparado para trabalhar? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ UX / PF3 / RACF │
│ Como controlar autonomia? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ SDSF │
│ O que está acontecendo? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ WLM │
│ Qual trabalho é mais importante? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ JES2 │
│ Quem recebe e despacha o trabalho? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ CICS │
│ Como executar ações de negócio? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ Db2 │
│ Como manter estado consistente? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ MQ │
│ Como componentes conversam? │
└──────────────────┬────────────────────┘
↓
┌───────────────────────────────────────┐
│ IMS │
│ Como organizar e navegar contexto? │
└───────────────────────────────────────┘Agora a série revela algo que talvez não estivesse completamente evidente quando escrevemos o primeiro artigo.
Não estamos mais discutindo simplesmente:
INTELIGÊNCIA ARTIFICIAL
Estamos discutindo:
SISTEMAS DE INTELIGÊNCIA ARTIFICIAL
Essa diferença é gigantesca.
🧩 CAPÍTULO 11 — O AGENTE DEIXOU DE SER O CENTRO
Durante algum tempo olhamos para IA assim:
PROMPT
↓
LLM
↓
RESPOSTASó que um sistema corporativo real começa a parecer muito mais com:
USUÁRIO
│
↓
OBJETIVO
│
↓
ORQUESTRADOR
│
┌──────────────┼──────────────┐
↓ ↓ ↓
AGENTE A AGENTE B AGENTE C
│ │ │
└──────────────┼──────────────┘
↓
TOOLS
┌──────────────┼──────────────┐
↓ ↓ ↓
DB MQ API
│
↓
ESTADOE ao redor disso precisamos:
IDENTIDADE
AUTORIZAÇÃO
OBSERVABILIDADE
AUDITORIA
PRIORIZAÇÃO
RECUPERAÇÃO
LIMITES
CHECKPOINTS
APROVAÇÕES
MENSAGERIA
TRANSAÇÕESO LLM continua importante.
Mas ele passa a ser um componente da arquitetura.
Essa talvez seja a evolução mais importante de toda a série.
🧙 CAPÍTULO 12 — TURING FAZ A PERGUNTA ERRADA
Alan Turing olha para nosso jovem programador COBOL.
E pergunta:
— Então finalmente construímos uma máquina que pensa?
O programador olha para o CPD.
Olha para:
SDSF
WLM
JES2
CICS
DB2
MQ
IMSDepois olha para o pequeno agente trabalhando no terminal.
E responde:
— Não sei.
Turing fica surpreso.
— Depois de tudo isso?
— Talvez a pergunta tenha mudado.
— Como assim?
O programador pega uma caneta.
E escreve no quadro:
CAN MACHINES THINK?Risca.
Embaixo escreve:
CAN MACHINES WORK
SAFELY,
RELIABLY,
OBSERVABLY
AND
RESPONSIBLY?Turing olha.
Sorri.
🦖 CAPÍTULO 13 — O MAINFRAME NÃO PREVIU A IA
E precisamos deixar uma coisa muito clara.
O mainframe não previu os LLMs.
JES2 não é ancestral tecnológico direto de agentes.
WLM não administra pensamentos.
CICS não executa raciocínio.
Db2 não possui consciência.
MQ não faz robôs fofinhos conversarem.
IMS não é cérebro artificial.
O valor da comparação está em outro lugar.
Durante décadas sistemas corporativos precisaram responder:
Quem pode executar?
O que pode executar?
Quando executará?
Com qual prioridade?
Sobre quais recursos?
Como sabemos que terminou?
O que acontece quando falha?
Como desfazemos mudanças?
Como componentes se comunicam?
Como reconstruímos o que aconteceu?
Essas perguntas reaparecem quando agentes deixam o laboratório e começam a operar sistemas reais.
Não copiamos a solução.
Reaproveitamos o conhecimento de engenharia.
🥚 EASTER EGG — O PROGRAMA QUE JÁ ESTAVA RODANDO
Turing caminha até o último terminal do CPD.
Na tela existe apenas:
READYEle digita:
WHOA máquina responde:
TURINGEle pergunta:
STATUSResposta:
ACTIVETuring sorri.
— Interessante.
O programador COBOL pergunta:
— O quê?
— Passamos nove capítulos tentando descobrir como controlar agentes inteligentes.
— Sim.
Turing aponta para o CPD.
— E vocês passaram cinquenta anos construindo sistemas para controlar humanos, programas, jobs, transações e mensagens.
Silêncio.
O operador do outro lado da sala grita:
— JOB ABENDOU!
Turing pergunta:
— S0C7?
— S0C7!
Turing pega seu café.
— Algumas coisas realmente nunca mudam.
😂
☕ EPÍLOGO — TALVEZ O FUTURO TENHA CHEIRO DE CPD
Existe uma tendência natural na tecnologia de acreditar que tudo começou ontem.
Cada nova geração cria novas palavras.
Novos frameworks.
Novos diagramas.
Novas abstrações.
E muitas delas realmente representam avanços extraordinários.
Mas engenharia também possui memória.
Quando vejo agentes de IA discutindo:
orchestration
observability
workload
state
messaging
transactions
authorization
checkpoints
recoveryé impossível para quem viveu mainframe não sentir um estranho déjà-vu.
Não porque sejam as mesmas tecnologias.
Não são.
Mas porque computadores continuam enfrentando alguns problemas fundamentais:
TRABALHO PRECISA SER ORGANIZADO.
RECURSOS SÃO FINITOS.
ESTADO PRECISA SER PROTEGIDO.
FALHAS ACONTECEM.
MENSAGENS SE PERDEM.
SISTEMAS FICAM INDISPONÍVEIS.
USUÁRIOS COMETEM ERROS.
PROGRAMAS COMETEM ERROS.
AUTOMAÇÃO AMPLIFICA ERROS.E agora acrescentamos uma criatura nova:
AGENTES PODEM ESCOLHER A PRÓXIMA AÇÃO.Isso muda muita coisa.
Mas não apaga setenta anos de engenharia de sistemas.
Talvez faça justamente o contrário.
Torne esse conhecimento ainda mais valioso.
Por isso esta série não é apenas sobre Alan Turing.
Não é apenas sobre mainframe.
E nem sequer é apenas sobre inteligência artificial.
É sobre algo muito mais antigo:
COMO CONSTRUÍMOS SISTEMAS NOS QUAIS PODEMOS CONFIAR?
Começamos ensinando pessoas.
Depois demos autonomia à máquina.
Criamos formas de observá-la.
Priorizamos seu trabalho.
Organizamos suas filas.
Controlamos suas transações.
Protegemos seu estado.
Permitimos que conversasse com outros sistemas.
Finalmente começamos a organizar sua memória.
E talvez este seja apenas o começo.
Porque no fundo do CPD existe uma porta.
Turing acabou de encontrá-la.
Na porta existe uma pequena placa:
AGENTS
AUTHORIZED PERSONNEL ONLYEle olha para nós.
— Vamos?
O programador COBOL suspira.
Salva tudo.
Confere o spool.
E responde:
— Só depois do café.
☕
Bellacosa Mainframe
