Translate

domingo, 20 de abril de 2025

Como Construir um Agente de IA sem Criar Mais um "Chatbot Bonitinho"

 

Bellacosa Mainframe como construir um agente de ia

☕ Um Café no Bellacosa Mainframe

Como Construir um Agente de IA sem Criar Mais um "Chatbot Bonitinho"

O Guia Definitivo para um Programador COBOL Padawan Entender por que um AI Agent se Parece Muito Mais com um Sistema Bancário no IBM Z do que com um ChatGPT

"Os iniciantes acreditam que Inteligência Artificial é escolher o melhor modelo. Os veteranos sabem que o modelo é apenas mais um componente da arquitetura."

Durante muitos anos ouvimos que o Mainframe era um ambiente complexo demais para ser compreendido pelos desenvolvedores modernos. Curiosamente, agora estamos vendo exatamente o caminho inverso.

À medida que os chamados AI Agents começam a dominar as discussões sobre Inteligência Artificial, profissionais vindos do mundo web descobrem que construir um agente realmente confiável é muito mais difícil do que simplesmente conectar um LLM a algumas APIs.

Na verdade, quanto mais sofisticado um agente se torna, mais ele começa a lembrar... um sistema corporativo executando sobre IBM Z.

Sim.

Pode parecer exagero.

Mas não é.

Enquanto muitos imaginam que um agente é apenas um ChatGPT "turbinado", quem trabalhou anos com COBOL, CICS, Db2, MQ, JES2, RACF, WLM e z/OS rapidamente percebe algo curioso:

quase todos os conceitos fundamentais dos AI Agents já existem no Mainframe há décadas.

E isso muda completamente a forma como um Programador COBOL Padawan deve enxergar essa nova revolução.

Pegue sua caneca de café.

Hoje vamos desmontar essa arquitetura peça por peça.


O maior erro dos iniciantes

Imagine alguém dizendo:

"Vou construir um banco."

Você pergunta:

— Banco de quê?

Ele responde:

— Ainda não sei.

— Para quem?

— Também não pensei.

— Qual problema resolve?

— Depois vejo.

Parece absurdo.

Mas exatamente isso acontece com inúmeros projetos de IA.

As pessoas começam perguntando:

Qual modelo devo usar?

Quando deveriam perguntar:

Que problema estou resolvendo?

No Mainframe aprendemos isso logo no primeiro projeto COBOL.

Ninguém escreve um programa antes de entender:

  • regra de negócio;

  • layout dos arquivos;

  • usuários;

  • volume;

  • desempenho;

  • segurança;

  • auditoria.

IA não muda essa ordem.


Passo 1 — O propósito vem antes da inteligência

A primeira caixa do diagrama parece simples:

Define Purpose & Scope

Mas ela provavelmente representa mais da metade do sucesso do projeto.

Imagine um agente para bancos.

Objetivo ruim:

"Responder perguntas sobre contas."

Objetivo excelente:

"Auxiliar operadores de produção na investigação inicial de ABENDs batch relacionados a pagamentos, consultando logs, dumps e documentação interna antes do escalonamento para especialistas."

Perceba a diferença.

Agora sabemos:

  • quem usa;

  • quando usa;

  • quais dados possui;

  • quais limitações existem;

  • quando deve parar.

No IBM Z chamamos isso de...

levantamento de requisitos.

Nada mudou.


O Padawan pensa no modelo.

O Mestre pensa no problema.

Existe uma enorme diferença entre estas duas perguntas.

Pergunta do iniciante

Qual é o melhor LLM?

Pergunta do arquiteto

Qual trabalho preciso executar?

São perguntas completamente diferentes.

Porque diferentes tarefas exigem modelos diferentes.

Algumas precisam velocidade.

Outras precisam enorme contexto.

Outras precisam baixo custo.

Outras precisam excelente raciocínio.

Exatamente como escolher entre:

  • COBOL

  • PL/I

  • Assembler

  • Java

  • REXX

Nenhuma linguagem vence todas.


O cérebro não faz tudo sozinho

Uma das maiores ilusões criadas pelo marketing é imaginar o LLM como uma espécie de cérebro universal.

Na prática ele funciona mais como...

...um excelente analista.

Ele raciocina.

Interpreta.

Planeja.

Mas não faz quase nada sozinho.

Imagine um gerente de banco.

Ele decide.

Mas quem movimenta dinheiro?

Quem consulta saldo?

Quem imprime boleto?

Quem abre chamado?

Quem consulta cliente?

São dezenas de sistemas especializados.

O mesmo acontece com IA.


Ferramentas são os CALLs do mundo moderno

Todo COBOL conhece algo parecido.

CALL 'CONSCLI'
CALL 'CALCJURO'
CALL 'ENVIA-MQ'
CALL 'GRAVA-DB2'

O programa principal não faz tudo.

Ele delega.

Nos agentes acontece exatamente igual.

O LLM pensa.

Depois chama ferramentas.

Exemplo:

Consultar clima

↓

Pesquisar banco

↓

Enviar e-mail

↓

Criar ticket

↓

Consultar documentação

↓

Executar SQL

Cada ferramenta representa um pequeno programa especializado.

Na prática...

Estamos reinventando os velhos módulos reutilizáveis.


APIs são os novos Program Calls

Na década de 80:

Programa COBOL chamava outro programa COBOL.

Hoje:

O agente chama uma API REST.

A filosofia continua igual.

Existe apenas uma diferença.

Antes:

CALL "PROG001"

Hoje:

POST /consultar_cliente

Mudou o protocolo.

Não mudou a arquitetura.


MCP lembra muito um Middleware Corporativo

Uma parte interessante do diagrama apresenta o MCP Server.

Muita gente acha complicado.

Mas para um profissional IBM Z isso lembra imediatamente:

  • CICS

  • IMS TM

  • MQ

  • z/OS Connect

  • Enterprise Service Bus

O MCP padroniza como ferramentas são descobertas e utilizadas.

É parecido com um catálogo corporativo.

Em vez de ensinar o agente cada integração individualmente...

Criamos uma camada intermediária.

Isso reduz acoplamento.

O Mainframe faz isso há décadas.


Memória não significa lembrar tudo

Talvez esta seja a maior confusão existente hoje.

Quando alguém fala:

"O agente possui memória."

Muitos imaginam algo parecido com um cérebro humano.

Não é isso.

Existem vários tipos de memória.


Memória de Conversa

Equivale ao contexto atual.

É semelhante ao conteúdo de uma COMMAREA.

Enquanto a transação está ativa...

Ela existe.

Depois desaparece.


Memória de Trabalho

É parecida com Working Storage.

Informações temporárias.

Variáveis.

Resultados intermediários.

Estado atual.

Nada permanente.


Memória Vetorial

Aqui aparece algo realmente novo.

Imagine uma biblioteca.

Você pergunta:

"Mostre tudo relacionado a VSAM."

O sistema encontra:

  • KSDS

  • RRDS

  • ESDS

  • RLS

  • IDCAMS

Mesmo sem procurar exatamente essas palavras.

Ele procura significado.

É diferente de um índice Db2.

É mais parecido com associação de ideias.


Banco Relacional continua existindo

Muitos imaginam que bancos vetoriais substituirão SQL.

Não vão.

Pergunta:

Qual é o saldo da conta?

Resposta precisa.

SQL.

Pergunta:

Quais documentos falam sobre fraude semelhante?

Resposta aproximada.

Banco vetorial.

Cada tecnologia possui seu espaço.


Escolher modelo lembra escolher CPU

Outra caixa interessante é:

Choose LLM.

O Padawan pergunta:

Qual é o melhor?

O veterano responde:

Depende.

Exatamente como escolher processador.

Você não compra um z17 para rodar uma calculadora.

Nem usa um Raspberry Pi para processar milhões de transações financeiras.

Modelos possuem:

  • custo

  • latência

  • contexto

  • precisão

  • velocidade

Tudo é compromisso.


O Prompt virou a nova Especificação Funcional

No início da IA muitos tratavam prompts como frases mágicas.

Hoje sabemos que um bom prompt parece muito mais uma documentação técnica.

Ele define:

Objetivo.

Escopo.

Restrições.

Formato.

Limitações.

Critérios.

Responsabilidades.

Em outras palavras...

É quase uma especificação funcional.


Guardrails são o novo RACF

Esta talvez seja minha comparação favorita.

Um agente sem guardrails é parecido com um usuário SPECIAL no RACF.

Pode fazer qualquer coisa.

E isso é perigoso.

Imagine um agente que possa:

Excluir arquivos.

Enviar e-mails.

Mover dinheiro.

Executar comandos.

Sem controle.

Seria um desastre.

Por isso criamos regras.

Assim como RACF protege datasets...

Os guardrails protegem ferramentas.


Orquestração lembra o JES2

Muitos pensam que um agente simplesmente responde.

Na prática existe uma enorme infraestrutura por trás.

Primeiro chega a solicitação.

Depois ela é classificada.

Depois o sistema decide quais ferramentas usar.

Depois verifica resultados.

Depois tenta novamente se houver erro.

Depois registra tudo.

Isso lembra muito:

JES2.

Schedulers.

Control-M.

OPC.

TWS.

Fluxos batch.

Mudou o nome.

A ideia continua idêntica.


Um agente também faz tratamento de erro

Imagine esta situação.

Ferramenta indisponível.

API fora do ar.

Banco lento.

Resposta inválida.

Timeout.

O que acontece?

Um bom agente precisa decidir.

Tentar novamente?

Trocar ferramenta?

Perguntar ao usuário?

Cancelar?

Escalar para humano?

Quem trabalhou anos corrigindo ABENDs sabe exatamente a importância disso.


O verdadeiro segredo está na observabilidade

Pouca gente fala nisso.

Mas empresas não compram IA porque ela responde bonito.

Compram porque conseguem confiar nela.

Para isso precisamos registrar tudo.

Qual modelo respondeu?

Qual prompt?

Quais ferramentas?

Quanto custou?

Quanto demorou?

Quem autorizou?

Quais documentos consultou?

No Mainframe isso lembra:

SMF.

RMF.

SYSLOG.

JESLOG.

Dump.

Trace.

Sem logs...

Não existe produção.


Testes nunca terminam

Outra excelente observação do diagrama.

Testing & Evals.

Muitos acreditam que basta testar uma vez.

Mas IA aprende.

Modelos mudam.

Ferramentas mudam.

Documentos mudam.

Usuários mudam.

Logo...

O teste nunca acaba.

É um ciclo permanente.

Muito parecido com:

Teste unitário.

Teste integrado.

Teste de regressão.

Teste de performance.

Teste de produção.


O maior erro dos projetos de IA

Hoje vejo centenas de agentes fazendo isto:

Pergunta.

Resposta.

Fim.

Mas empresas reais precisam de muito mais.

Precisam de:

Auditoria.

Segurança.

Escalabilidade.

Versionamento.

Logs.

Controle de acesso.

Custos.

Explicabilidade.

Resiliência.

Recuperação.

Exatamente as características que fizeram o Mainframe sobreviver durante mais de seis décadas.


O Mainframe já conhecia quase tudo isso

Observe esta tabela.

Mundo IAIBM Z
LLMPrograma especialista
PromptEspecificação funcional
FerramentaCALL
APIPrograma remoto
MCPMiddleware
MemóriaVSAM/Db2/Storage
OrquestraçãoJES2 / Scheduler
GuardrailsRACF
ObservabilidadeSMF/RMF
LogsSYSLOG
WorkflowBatch
EstadoCOMMAREA / Working Storage
Aprovação humanaOperador / Change Management

Curiosamente...

A arquitetura moderna está caminhando para conceitos que o Mainframe já dominava.


O verdadeiro diferencial continua sendo Engenharia

Existe uma frase que gosto muito.

"Modelos impressionam. Arquiteturas sobrevivem."

Qualquer pessoa consegue criar um chatbot em poucos minutos.

Criar um agente que opere meses em produção...

É outra história.

Esse agente precisa:

  • resistir a erros;

  • proteger dados;

  • registrar auditoria;

  • controlar custos;

  • explicar decisões;

  • evoluir continuamente.

Isso é Engenharia de Software.

Não Engenharia de Prompt.


O Padawan do futuro

Se você programa COBOL hoje, talvez esteja pensando:

"Onde entro nessa história?"

A resposta é:

Em praticamente tudo.

Porque empresas não querem apenas alguém que saiba conversar com um LLM.

Elas precisam de profissionais capazes de integrar IA aos sistemas que realmente movem o negócio.

E esses sistemas continuam sendo, em grande parte, os que executam em plataformas como IBM Z.

O Programador COBOL Padawan que compreender agentes de IA terá uma vantagem rara: enxergará a IA não como um brinquedo de linguagem, mas como mais um componente de uma arquitetura corporativa robusta. Ele saberá que um bom agente precisa de regras de negócio, integração, segurança, persistência, tratamento de erros e observabilidade — exatamente os pilares que sempre sustentaram as aplicações de missão crítica.


O Café Terminou, mas a Jornada Está Apenas Começando

Quando observamos um diagrama de "How to Build an AI Agent", é fácil acreditar que tudo se resume a oito caixas conectadas por setas. Porém, a realidade é muito mais rica. Cada uma dessas caixas representa disciplinas inteiras: arquitetura, engenharia de software, segurança, infraestrutura, governança de dados, experiência do usuário e operações.

Para o Programador COBOL Padawan, talvez a maior descoberta seja perceber que a revolução da IA não invalida tudo o que foi aprendido no Mainframe. Pelo contrário: ela confirma que os princípios que mantêm bancos, seguradoras e governos funcionando há décadas continuam válidos. O que muda são as ferramentas; os fundamentos permanecem.

No fim das contas, um agente de IA realmente confiável não nasce do modelo mais poderoso, nem do prompt mais elaborado. Ele nasce de uma arquitetura sólida, de decisões bem fundamentadas e da disciplina de engenharia.

E essa sempre foi a maior lição do IBM Z.

Porque, no Bellacosa Mainframe, aprendemos uma verdade que a indústria de IA está redescobrindo apenas agora: inteligência impressiona nas demonstrações; arquitetura confiável sustenta a produção.


Sem comentários:

Enviar um comentário