 |
| Bellacosa Mainframe e os loops agentes de ia e o cobol na confusao |
☕ Um Café no Bellacosa Mainframe
O Paciente Loop: Patrick Jane, COBOL e o Mistério dos Agentes de IA que Nunca Conferem se Fizeram a Coisa Certa
Existe uma cena imaginária que poderia perfeitamente abrir um episódio de The Mentalist.
Uma grande empresa acaba de colocar em produção seu novíssimo sistema de Inteligência Artificial. Há telas gigantes na sala de operações, dashboards coloridos, gráficos, APIs, modelos generativos, agentes, bancos vetoriais, cloud, Kubernetes e uma quantidade respeitável de palavras em inglês sendo pronunciadas por minuto.
O diretor anuncia orgulhoso:
— Nosso agente agora trabalha sozinho.
Patrick Jane, sentado no canto da sala, mexe distraidamente em uma xícara de chá.
Ele olha para o monitor.
Olha para o diretor.
Olha novamente para o monitor.
E pergunta:
— Como vocês sabem que ele fez a coisa certa?
Silêncio.
O arquiteto responde:
— Porque a execução terminou com sucesso.
Jane sorri.
— Eu não perguntei se terminou. Perguntei se estava certo.
Nesse momento começa o episódio.
E talvez comece também uma das discussões mais importantes da atual engenharia de Inteligência Artificial.
Porque estamos descobrindo que o maior problema dos agentes de IA não é necessariamente a inteligência.
É o loop.
Ou, mais precisamente, a ausência dele.
Bem-vindo ao café.
Pegue uma cadeira, abra uma sessão TSO imaginária, coloque ===> diante de você e venha investigar comigo um dos crimes arquiteturais mais interessantes da era da Inteligência Artificial.
A primeira pista: durante muito tempo nós confundimos resposta com solução
Quem está começando em COBOL aprende cedo uma coisa aparentemente simples.
Um programa recebe dados.
Processa.
Produz uma saída.
Algo semelhante a:
ENTRADA
↓
PROGRAMA COBOL
↓
SAÍDA
Imagine nosso programa clássico.
IDENTIFICATION DIVISION.
PROGRAM-ID. CALCSAL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-SALARIO PIC 9(7)V99.
01 WS-BONUS PIC 9(7)V99.
01 WS-TOTAL PIC 9(8)V99.
PROCEDURE DIVISION.
COMPUTE WS-TOTAL = WS-SALARIO + WS-BONUS
DISPLAY 'TOTAL: ' WS-TOTAL
STOP RUN.
Entrou salário.
Entrou bônus.
Calculamos.
Terminamos.
Durante décadas esse modelo mental funcionou muito bem.
Depois chegaram os grandes modelos de linguagem.
E começamos praticamente da mesma forma.
PROMPT
↓
LLM
↓
RESPOSTA
Escrevemos:
Explique um programa COBOL que lê um arquivo VSAM.
O modelo responde.
Nós lemos.
Se estiver errado, corrigimos o prompt.
Ele responde novamente.
Nós verificamos outra vez.
E assim sucessivamente.
Pare por alguns segundos e observe o que aconteceu.
Existe um loop:
PROMPT
↓
MODELO
↓
RESPOSTA
↓
VOCÊ VERIFICA
↓
VOCÊ CORRIGE
↓
NOVO PROMPT
Quem está executando o loop?
Você.
A Inteligência Artificial não possui necessariamente um processo próprio de verificação nesse cenário.
Ela gera.
Você avalia.
Ela tenta.
Você confere.
Ela erra.
Você corrige.
O ser humano é o scheduler, o monitor, o operador e o mecanismo de recovery.
Patrick Jane provavelmente observaria:
— Interessante. Vocês chamaram a máquina de agente autônomo, mas existe um humano escondido atrás dela fazendo todo o trabalho de controle.
Touché.
Prompt Engineering não morreu. Apenas deixou de ser toda a história
Por alguns anos houve quase uma obsessão com Prompt Engineering.
Qual o melhor prompt?
Quantas instruções?
Qual temperatura?
Devemos dizer "pense passo a passo"?
Devemos fornecer exemplos?
Devemos criar personas?
Tudo isso continua importante.
Mas existe uma mudança arquitetural maior acontecendo.
A pergunta deixou de ser apenas:
Como consigo uma boa resposta?
E passou a ser:
Como construo um sistema capaz de alcançar um objetivo, verificar se o alcançou e corrigir a própria trajetória quando necessário?
Essa diferença parece pequena.
Não é.
É aproximadamente a diferença entre escrever um programa COBOL isolado e administrar uma cadeia inteira de processamento bancário.
Conheça o suspeito principal: o Execution Loop
Podemos representar um agente moderno de maneira simplificada assim:
OBJETIVO
↓
DESCOBRIR
↓
PLANEJAR
↓
EXECUTAR
↓
VERIFICAR
↓
MELHORAR
└──────────→ NOVO CICLO
A postagem original fala em cinco grandes estágios.
Dependendo da literatura ou framework, os nomes mudam. Você encontrará variações como:
Plan
Execute
Observe
Evaluate
Improve
ou:
Discover
Plan
Execute
Verify
Iterate
Não se prenda aos nomes.
Observe o princípio.
O sistema não considera a geração de uma resposta como o final do trabalho.
Ele pergunta:
Funcionou?
Essa simples pergunta transforma tudo.
Primeiro estágio: descobrir
Imagine um gerente chegando para nosso agente e dizendo:
Corrija os clientes com problema.
Um agente ingênuo poderia imediatamente começar a alterar registros.
Um agente bem projetado deveria primeiro investigar.
Que clientes?
Qual problema?
Qual sistema?
Produção ou homologação?
Qual janela de processamento?
Existe autorização?
Quais tabelas podem ser modificadas?
Qual política regulatória se aplica?
Qual é a definição de sucesso?
Isso é Discover.
Antes de agir, compreender.
Um programador COBOL conhece isso melhor do que imagina.
Quando recebemos uma manutenção dizendo:
O batch está errado.
Não abrimos imediatamente o editor e começamos a trocar IF por EVALUATE.
Investigamos.
Consultamos o SYSOUT.
Verificamos o RC.
Lemos o dump.
Observamos os datasets.
Procuramos alterações recentes.
Consultamos o log.
Descobrimos o contexto.
Em outras palavras:
fazemos investigação antes de execução.
Patrick Jane aprovaria.
Segundo estágio: planejar
Depois de compreender o problema, o agente precisa decidir o que fazer.
Suponha que a tarefa seja:
Localize transações duplicadas e gere um relatório.
Um plano poderia ser:
1. Identificar fonte dos dados.
2. Consultar transações.
3. Determinar chave de duplicidade.
4. Agrupar ocorrências.
5. Validar os resultados.
6. Gerar relatório.
7. Conferir totais.
8. Entregar.
Observe algo importantíssimo.
Planejamento não é execução.
Parece óbvio, mas muitos sistemas agentic misturam os dois.
O agente começa chamando APIs enquanto ainda está tentando descobrir o problema.
Isso é como um programador entrar em produção com UPDATE antes de executar o SELECT.
Quem trabalha em ambiente corporativo sentiu um pequeno arrepio lendo essa frase.
Exatamente.
Terceiro estágio: executar
Agora o agente começa a trabalhar.
Pode consultar banco.
Pode chamar uma API.
Pode executar código.
Pode buscar documentos.
Pode criar arquivos.
Pode usar ferramentas.
Pode disparar outros agentes.
Nesse momento deixamos de falar apenas sobre LLM.
Passamos a falar sobre sistema agentic.
Isso é crucial.
Um Large Language Model sozinho é um mecanismo probabilístico de geração.
Um agente normalmente combina modelo com alguma estrutura de execução:
LLM
+
TOOLS
+
MEMÓRIA
+
REGRAS
+
CONTEXTO
+
ORQUESTRAÇÃO
Agora começamos a chegar a algo muito mais interessante.
Quarto estágio: verificar
Aqui está a pista que resolve boa parte do caso.
Imagine que pedimos:
Gere um programa COBOL que calcule juros.
A IA escreve 150 linhas perfeitamente formatadas.
Pode até ficar bonito.
Isso significa que está certo?
Não.
Precisamos compilar.
Código gerado
↓
Compilador
↓
RC?
Suponhamos:
MAXCC = 12
Fim do mistério.
O programa estava errado.
Mas imagine algo ainda mais perigoso.
Ele compila.
MAXCC = 0
Está correto?
Também não necessariamente.
Compilação comprova principalmente que o código respeitou regras sintáticas e semânticas esperadas pelo compilador.
Ainda precisamos testar.
COMPILAÇÃO
↓
UNIT TEST
↓
TESTES FUNCIONAIS
↓
VALIDAÇÃO DE REGRA
↓
SEGURANÇA
↓
PERFORMANCE
Somente então podemos aumentar nossa confiança.
Aqui está uma lição gigantesca:
Um resultado tecnicamente executável não é necessariamente um resultado correto.
Isso vale para COBOL.
Vale para SQL.
Vale para IA.
Vale para praticamente toda engenharia.
Evaluation Gap: o buraco entre "fiz" e "está certo"
Esse problema recebe um nome interessante:
Evaluation Gap.
O agente executa a tarefa.
Mas ninguém mede o resultado.
Imagine:
AGENTE
↓
EXECUTA
↓
SUCESSO
Qual é a definição de sucesso?
"Não deu erro"?
Perigoso.
Imagine um agente responsável por classificar dez mil documentos.
Ele processa todos.
Nenhuma exceção.
Nenhum timeout.
Nenhuma API falhou.
Operacionalmente:
100% de sucesso.
Mas depois descobrimos que 17% dos documentos foram classificados incorretamente.
Tecnicamente funcionou.
Business-wise fracassou.
Esse é o Evaluation Gap.
Um programador mainframe já conhece isso pelo Return Code
Aqui temos uma deliciosa ironia histórica.
O mundo da IA está redescobrindo conceitos que profissionais de processamento empresarial utilizam há décadas.
Considere:
//STEP01 EXEC PGM=PROGA
//STEP02 EXEC PGM=PROGB,COND=(4,LT)
Ou estruturas modernas de scheduler baseadas no resultado de etapas anteriores.
A lógica fundamental é:
EXECUTA
↓
VERIFICA RESULTADO
↓
DECIDE O PRÓXIMO PASSO
É exatamente a essência do loop agentic.
Naturalmente, IA adiciona uma dimensão probabilística e interpretativa muito maior.
Mas arquiteturalmente existe parentesco.
Não estamos inventando o conceito de controle.
Estamos aplicando controle a sistemas capazes de raciocínio probabilístico.
Single-Agent Loop: nosso investigador solitário
Agora chegamos a uma decisão arquitetural importante.
Usamos um agente?
Ou vários?
Comecemos pelo agente único.
AGENTE
│
┌────┴────┐
↓ ↓
Planeja Executa
↓
Verifica
↓
Corrige
Ele controla todo o ciclo.
Para muitas tarefas isso é excelente.
Imagine um agente encarregado de analisar JCL.
Ele recebe:
JOB
↓
PROC
↓
DD statements
↓
SYSOUT
Analisa.
Identifica problemas.
Explica.
Confere novamente.
Entrega a resposta.
Não precisamos de quinze agentes discutindo DISP=(NEW,CATLG,DELETE).
Um agente bem instruído pode resolver.
Essa arquitetura oferece enorme vantagem:
simplicidade.
Menos componentes.
Menor latência.
Menor custo.
Menos pontos de falha.
Mais facilidade de debugging.
E essa última palavra deveria estar escrita em letras douradas em todo projeto de IA corporativa.
Fleet Loop: quando Red John aparece
Mas existem casos maiores.
Imagine um agente encarregado de modernizar uma aplicação bancária COBOL com 8 milhões de linhas.
Agora nossa investigação cresceu.
Precisamos compreender COBOL.
JCL.
Db2.
CICS.
VSAM.
Regras de negócio.
APIs.
Segurança.
Testes.
Arquitetura.
Documentação.
Performance.
Talvez um único agente possa tentar.
Mas surge outra possibilidade.
Uma Fleet, ou frota de agentes especializados.
ORQUESTRADOR
│
┌────────────────┼───────────────┐
↓ ↓ ↓
COBOL Agent DB2 Agent CICS Agent
│ │ │
└────────────────┼───────────────┘
↓
TEST AGENT
↓
EVALUATOR
Agora cada agente possui responsabilidade específica.
É quase uma equipe virtual.
O orquestrador é o JES da festa
Para um iniciante COBOL, podemos fazer uma analogia divertida.
Imagine o orquestrador como algo entre um scheduler, JES e gerente de processamento.
Ele não necessariamente executa todo o trabalho.
Ele determina:
quem trabalha;
quando trabalha;
com quais informações;
em qual sequência;
e o que acontece depois.
ORCHESTRATOR
↓
AGENT COBOL
↓
AGENT DB2
↓
TEST AGENT
↓
EVALUATOR
Sem orquestrador, uma frota de agentes pode virar uma reunião corporativa às 16h de sexta-feira.
Todo mundo fala.
Ninguém sabe quem decide.
E misteriosamente surge outra reunião.
Role Specialization Gap
Esse é outro problema citado.
Você cria cinco agentes.
Mas todos fazem praticamente a mesma coisa.
Um analisa.
Outro também analisa.
Outro revisa a análise.
Outro "supervisiona".
Outro analisa a revisão.
Parabéns.
Você inventou burocracia digital.
Especialização precisa significar fronteiras claras.
Por exemplo:
Maker → produz
Checker → verifica
Security → procura vulnerabilidades
Performance → analisa eficiência
Orchestrator → decide fluxo
Isso é melhor.
Temos separação de responsabilidades.
Um conceito antiquíssimo da engenharia de software reaparece.
Separation of Concerns.
Maker e Checker: uma das melhores ideias para IA empresarial
Se eu tivesse que selecionar uma arquitetura simples para ensinar a um iniciante, escolheria:
MAKER
↓
CHECKER
O Maker faz.
O Checker confere.
Por exemplo:
Agent A:
"Gere SQL."
Agent B:
"Verifique o SQL."
Melhor ainda:
Agent A
gera SQL
↓
database sandbox
↓
execution result
↓
Agent B
avalia
Aqui aparece um princípio fundamental:
sempre que possível, substitua opinião por evidência.
Em vez de perguntar ao segundo LLM:
Esse código parece correto?
Execute.
Compile.
Teste.
Compare.
Meça.
Observe.
Isso aumenta enormemente a confiabilidade.
Open Loop: Patrick Jane solto na cena do crime
Loops abertos são interessantes porque permitem exploração.
Imagine:
Descubra por que nosso processamento ficou 40% mais lento.
O agente pode explorar várias hipóteses.
CPU?
↓
I/O?
↓
Db2?
↓
Locks?
↓
WLM?
↓
Dataset?
↓
Rede?
↓
Mudança recente?
Ele não conhece previamente o caminho.
Investiga.
Formula hipóteses.
Descarta.
Testa.
Reformula.
É uma abordagem quase investigativa.
E muito parecida com The Mentalist.
Jane entra em uma sala e começa a observar detalhes aparentemente insignificantes.
Um copo deslocado.
Uma janela aberta.
Uma pessoa olhando para o relógio.
Uma contradição.
Um perfume.
Nenhuma pista isolada fornece a resposta.
O valor aparece quando diferentes sinais são combinados.
Um agente exploratório faz algo conceitualmente semelhante.
Mas o Open Loop possui um monstro escondido: custo
Imagine o agente dizendo:
Vou investigar mais uma hipótese.
Depois:
Mais uma.
Depois:
Talvez outra.
Depois:
Encontrei algo interessante. Vou aprofundar.
Depois:
Talvez exista uma abordagem alternativa.
Duas horas depois:
TOKENS: ☠☠☠☠☠
CUSTO: ☠☠☠☠☠
RESULTADO: "AINDA INVESTIGANDO"
Esse é o problema de loops excessivamente abertos.
Sem critério de parada, exploração vira desperdício.
Precisamos de limites.
Por exemplo:
máximo 5 hipóteses
máximo 3 tentativas
máximo 50.000 tokens
timeout 10 minutos
confidence > 95%
stop when test passes
A palavra-chave é:
budget.
Agentes precisam de orçamento.
Não apenas monetário.
Tempo.
Tokens.
Chamadas de API.
CPU.
Ferramentas.
Tentativas.
Closed Loop: o mundo confortável do batch
Agora entramos em terreno familiar ao mainframe.
Loops fechados possuem passos bem definidos.
RECEBER
↓
VALIDAR
↓
PROCESSAR
↓
CONFERIR
↓
GRAVAR
↓
FINALIZAR
Isso é previsível.
E previsibilidade é ouro em ambientes corporativos.
Especialmente quando estamos falando de:
pagamentos,
folha salarial,
liquidação,
contabilidade,
regulatório,
processamento financeiro.
Ninguém quer um agente criativo decidindo:
Hoje vou experimentar uma maneira diferente de calcular a folha.
Não.
Obrigado.
Volte para homologação.
Entretanto, loops fechados também possuem um problema
Rigidez.
Imagine que uma API mudou.
O fluxo continua:
Passo 1
Passo 2
Passo 3
Passo 4
Mas Passo 3 não funciona mais.
Um workflow extremamente rígido pode repetir o erro indefinidamente.
Por isso aparece uma arquitetura extremamente interessante:
exploração aberta + execução fechada.
PROBLEMA
↓
OPEN LOOP
investiga soluções
↓
DECISÃO
↓
CLOSED LOOP
executa solução controlada
↓
VALIDAÇÃO
Essa combinação provavelmente será uma das estruturas mais úteis da IA corporativa.
Memory Gap: o agente com amnésia
Imagine conversar hoje com um agente.
Você explica durante quarenta minutos seu sistema.
Ele entende.
Amanhã você retorna.
— Então, sobre aquele problema do CICS...
Agente:
— Qual problema?
Pronto.
Temos um consultor que sofre amnésia todas as manhãs.
Não escala.
Por isso sistemas agentic precisam de memória.
Mas "memória" não significa simplesmente jogar todas as conversas anteriores dentro do prompt.
Isso seria caro, lento e eventualmente impossível.
Precisamos de camadas.
MEMÓRIA DE CURTO PRAZO
contexto da execução
MEMÓRIA DE TRABALHO
informações relevantes da tarefa
MEMÓRIA PERSISTENTE
dados entre sessões
BASE DE CONHECIMENTO
documentação externa
Um mainframer pode imaginar algo como:
WORKING-STORAGE
+
VSAM
+
DB2
+
LOG
Não é uma equivalência técnica perfeita, evidentemente.
Mas ajuda a compreender a ideia.
Context não é Memory
Aqui existe uma sutileza importante.
Contexto é aquilo que o modelo consegue considerar na execução atual.
Memória é um mecanismo capaz de preservar e recuperar informações úteis através das execuções.
Imagine uma biblioteca.
Contexto é a pilha de livros atualmente sobre sua mesa.
Memória é a biblioteca inteira e o catálogo que permite encontrar novamente os livros relevantes.
Essa distinção será cada vez mais importante.
Connectors: as mãos do agente
Um modelo sem ferramentas sabe falar.
Um agente equipado com conectores consegue agir.
Imagine:
LLM
│
├── Gmail
├── Calendar
├── Git
├── Database
├── Mainframe
├── API
├── Files
└── Monitoring
Isso muda completamente sua natureza.
Perguntar:
Qual é o saldo do cliente?
é uma tarefa linguística + acesso a dados.
Perguntar:
Transfira R$ 500.
é uma ação.
E ação exige controles muito mais fortes.
Autorização.
Auditoria.
Identidade.
Permissão.
Limites.
Confirmação.
Rollback.
É aí que Agentic AI deixa de ser brinquedo e entra no território da engenharia empresarial séria.
Automations: o agente começa a trabalhar sem ser chamado
Outro building block fundamental são automações.
Podemos ter:
EVENTO
↓
TRIGGER
↓
AGENTE
↓
LOOP
Exemplo:
Um job termina com RC=12.
O monitor detecta.
Um agente recebe SYSOUT.
Analisa.
Compara com incidentes anteriores.
Sugere causa.
Consulta documentação.
Cria resumo.
Encaminha para operador.
Agora temos algo muito próximo de AIOps agentic.
A regra de ouro: autonomia não significa ausência de controle
Talvez este seja um dos maiores equívocos atuais.
Algumas pessoas imaginam uma escala assim:
MAIS AUTONOMIA = MAIS EVOLUÇÃO
Nem sempre.
Em aplicações empresariais, talvez a melhor equação seja:
AUTONOMIA
+
OBSERVABILIDADE
+
LIMITES
+
VALIDAÇÃO
+
AUDITORIA
=
CONFIANÇA
Um agente completamente autônomo, porém impossível de auditar, pode ser menos útil que um agente limitado e extremamente previsível.
Human-in-the-Loop continua vivo
Existe também um ponto onde o humano deve permanecer.
Imagine:
Agente detecta
fraude provável
↓
Confidence 62%
↓
AÇÃO IRREVERSÍVEL?
↓
SIM
↓
HUMAN REVIEW
Isso não significa fracasso da automação.
Significa arquitetura responsável.
Um sistema maduro sabe quando continuar sozinho.
E sabe quando chamar alguém.
Curiosidade: Agentic AI está redescobrindo sistemas de controle
Existe algo fascinante em toda essa discussão.
Muito antes de LLMs, engenharia já estudava sistemas baseados em feedback.
Termostato.
Piloto automático.
Controladores industriais.
Sistemas de navegação.
Automação fabril.
Todos trabalham aproximadamente com:
ESTADO DESEJADO
↓
AÇÃO
↓
MEDIÇÃO
↓
ERRO
↓
CORREÇÃO
Agentic AI adiciona capacidades linguísticas e cognitivas poderosas ao princípio.
Mas o DNA do loop é antigo.
Easter Egg nº 1 — PROC LOOP
Imagine um agente COBOL escrito como se fosse um episódio de The Mentalist:
PROCEDURE DIVISION.
1000-INVESTIGATE.
PERFORM 2000-DISCOVER
PERFORM 3000-PLAN
PERFORM 4000-EXECUTE
PERFORM 5000-VERIFY
IF WS-RESULTADO = 'OK'
PERFORM 9000-SHIP
ELSE
PERFORM 6000-IMPROVE
GO TO 1000-INVESTIGATE
END-IF.
STOP RUN.
Alguns veteranos COBOL acabaram de franzir a testa por causa daquele GO TO.
Sim.
Foi proposital.
O easter egg era fazer um mainframer sentir uma pequena perturbação na Força.
Easter Egg nº 2 — Red John era um Open Loop
Patrick Jane passou anos investigando Red John.
Hipótese.
Pista.
Nova hipótese.
Suspeito.
Erro.
Nova pista.
Outro suspeito.
Mais investigação.
Tecnicamente poderíamos dizer que a série inteira possui um gigantesco:
OPEN INVESTIGATION LOOP
com um critério final:
RED JOHN IDENTIFIED = TRUE
Talvez Bruno Heller tenha criado Agentic Television antes de isso virar buzzword.
Uma arquitetura agentic para analisar um Abend
Agora vamos juntar tudo em um exemplo muito próximo do universo mainframe.
Recebemos:
JOB ABC123
ABEND S0C7
Nosso agente entra em ação.
Primeiro ele descobre contexto.
Qual STEP?
Qual programa?
Qual offset?
Qual dump?
Houve mudança recente?
Depois planeja.
1 localizar mensagem
2 identificar programa
3 mapear offset
4 localizar campo
5 verificar dados
6 buscar histórico
Executa.
Consulta SYSOUT.
Obtém dump.
Lê listing.
Verifica copybook.
Cruza layout.
Então avalia.
A hipótese realmente explica o S0C7?
Se não explicar:
ITERATE
Formula outra hipótese.
Por exemplo:
Campo numericamente inválido.
Ou redefinição incorreta.
Ou arquivo com layout inesperado.
Ou COMP-3 corrompido.
Quando encontra evidência suficiente:
VERIFY = PASS
Entrega diagnóstico.
Veja como isso é muito superior a simplesmente perguntar a um chatbot:
O que é S0C7?
Uma coisa é explicar o conceito.
Outra coisa é investigar o incidente.
Essa diferença resume boa parte da passagem de Generative AI para Agentic AI.
Passo a passo para construir seu primeiro loop mental
Se você é iniciante, não tente começar criando quinze agentes, quatro bancos vetoriais, Kubernetes, três modelos e um nome grego para o orquestrador.
Comece pequeno.
Use esta sequência como seu mapa:
Defina um objetivo mensurável. "Explicar JCL" é vago; "identificar possíveis erros em um JOB e apontar evidências" é melhor. Em seguida, determine quais ferramentas o agente realmente precisa, estabeleça como ele saberá que terminou, crie uma etapa independente de validação, defina limites de custo e tentativas, registre cada decisão, teste primeiro com casos conhecidos, introduza memória apenas quando houver necessidade real, adicione novos agentes somente quando existir uma especialização justificável e mantenha ações críticas sob autorização explícita até possuir evidências suficientes de confiabilidade.
Essa ordem é menos glamourosa.
E muito mais segura.
Observabilidade: porque até Patrick Jane precisava de pistas
Se um agente falhar e você não conseguir descobrir por quê, possui um problema grave.
Precisamos observar:
INPUT
DECISION
MODEL CALL
TOOL CALL
RESULT
EVALUATION
RETRY
COST
DURATION
FINAL OUTPUT
Isso é tracing agentic.
Um sistema empresarial precisa conseguir responder:
Por que esse agente tomou essa decisão?
Talvez não consigamos reconstruir todo fenômeno interno do modelo.
Mas podemos registrar o contexto operacional disponível:
instruções;
dados recuperados;
ferramentas utilizadas;
resultados;
scores;
retries;
políticas aplicadas.
Quem vem do mainframe sabe o valor disso.
SMF existe por um motivo.
SYSLOG existe por um motivo.
JESMSGLG existe por um motivo.
Auditoria existe por um motivo.
Quando algo explode às 03:17 da madrugada, "a IA decidiu" não será uma explicação aceitável.
A arquitetura que eu escolheria para uma empresa
Não escolheria simplesmente "Single Agent" ou "Fleet".
Escolheria de acordo com risco e complexidade.
Para tarefas pequenas:
Single Agent
↓
Tool
↓
Verifier
Para tarefas grandes:
ORCHESTRATOR
│
┌──────────────┼──────────────┐
↓ ↓ ↓
COBOL DB2 CICS
│ │ │
└──────────────┼──────────────┘
↓
MAKER
↓
CHECKER
↓
QUALITY GATE
↓
┌─────────┴─────────┐
↓ ↓
PASS FAIL
↓ ↓
SHIP ITERATE
Agora temos algo reconhecível para qualquer profissional de engenharia.
Pipeline.
Quality gate.
Especialização.
Auditoria.
Retry.
Observabilidade.
Controle.
O curioso encontro entre Mainframe e IA
Talvez a parte mais divertida dessa história seja perceber quanto do futuro se parece com o passado.
Estamos falando de:
jobs,
queues,
orchestration,
retries,
return codes,
logs,
resource limits,
authorization,
transaction boundaries,
checkpoint,
recovery,
audit trail.
Um mainframer poderia olhar para boa parte dessa arquitetura e perguntar:
— Vocês passaram três anos inventando nomes novos para coisas que fazemos desde 1978?
Não exatamente.
Mas...
também não estaria completamente errado.
A novidade fundamental está na possibilidade de incluir mecanismos probabilísticos capazes de interpretar linguagem, contexto, intenção e informação não estruturada dentro desses loops.
O velho mundo determinístico ganha um novo componente cognitivo.
E chegamos ao verdadeiro segredo
A discussão frequentemente fica presa a modelos.
Qual é maior?
Qual possui mais parâmetros?
Qual benchmark vence?
Qual raciocina melhor?
Essas perguntas importam.
Mas quando chegamos a produção, surgem outras muito mais difíceis.
O que acontece quando o modelo erra?
Como detectamos?
Quem corrige?
Quantas vezes pode tentar?
Quando deve desistir?
Quando chama um humano?
Como registramos?
Como recuperamos?
Como evitamos repetir o mesmo erro amanhã?
Como garantimos que dois agentes não executem ações conflitantes?
Como impedimos um loop infinito?
Como controlamos custo?
Como testamos?
É aí que começa a verdadeira Loop Engineering.
O último interrogatório
Voltemos à nossa sala.
O diretor continua orgulhoso.
— Nosso agente é extremamente inteligente.
Patrick Jane termina seu chá.
— Inteligência não é o que me preocupa.
— Então o que preocupa?
Jane aponta para o dashboard.
— Quando ele erra, quem percebe?
O diretor hesita.
— O usuário.
Jane sorri.
— Então vocês ainda não construíram um agente.
— Construímos o quê?
— Um estagiário muito rápido.
Silêncio.
Fim do episódio.
O diagnóstico final
Durante a primeira fase da IA generativa, tentamos criar respostas melhores.
Durante a segunda, demos ferramentas aos modelos.
Durante a terceira, começamos a transformar modelos em agentes.
Agora entramos numa fase mais madura.
Precisamos transformar agentes em sistemas confiáveis.
E sistemas confiáveis exigem loops.
DISCOVER
↓
PLAN
↓
EXECUTE
↓
OBSERVE
↓
EVALUATE
↓
IMPROVE
↓
REPEAT
Mas repare numa última sutileza.
O objetivo não é repetir infinitamente.
O objetivo é saber quando parar.
Um bom loop possui critérios de entrada.
Critérios de qualidade.
Limites.
Feedback.
Recovery.
Auditoria.
E condição de saída.
Isso é engenharia.
☕ A última xícara
Talvez daqui a alguns anos a palavra "agente" nem seja tão importante.
Talvez simplesmente chamemos tudo isso de software.
Afinal, microsserviços já foram novidade.
Cloud já foi novidade.
APIs já foram novidade.
DevOps já foi novidade.
Containers já foram novidade.
Com o tempo, tecnologias extraordinárias tornam-se infraestrutura.
Agentic AI provavelmente seguirá caminho semelhante.
E quando isso acontecer, os sistemas vencedores não serão necessariamente aqueles com o maior número de agentes ou com o modelo mais impressionante.
Serão aqueles que conseguirem responder consistentemente às perguntas que Patrick Jane faria logo ao entrar na sala:
O que aconteceu?
Por que aconteceu?
Como você sabe?
Quem verificou?
O que fará se estiver errado?
E existe uma sexta pergunta, aquela que talvez seja a mais importante de todas:
Quando o loop termina?
Porque gerar uma resposta é fácil.
Executar uma tarefa é mais difícil.
Verificar o resultado é ainda mais difícil.
Corrigir-se sem destruir nada é engenharia.
E fazer tudo isso repetidamente, com custo controlado, memória, segurança, rastreabilidade, qualidade e possibilidade de intervenção humana...
isso já não é apenas Inteligência Artificial.
É engenharia de sistemas empresariais com inteligência dentro do loop.
E talvez essa seja a verdadeira revolução que estava escondida diante de nós o tempo inteiro.
READY
RUN AGENT
DISCOVER...
PLAN...
EXECUTE...
VERIFY...
QUALITY GATE FAILED.
ITERATING...
Patrick Jane olha para o terminal 3270.
Sorri discretamente.
E diz:
— Agora sim. Pelo menos ele sabe que errou.
