 |
| Bellacosa Mainframe concorrencia e questoes de dados quem é relevante |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🗄️ ALAN TURING E O Db2 DOS AGENTES — QUANDO DUAS IAs ESTÃO CERTAS EM REALIDADES DIFERENTES
Db2, agentes de IA, COBOL, SQL, ACID, transações, isolamento, locks, MVCC, dirty read, non-repeatable read, phantom read, lost update, optimistic concurrency, timestamps, versionamento, commit, rollback, contexto, temporalidade, proveniência, RAG — e o dia em que Alan Turing descobriu que uma inteligência artificial pode estar absolutamente certa sobre uma realidade que deixou de existir três segundos atrás.
🎬 PRÓLOGO — AS DUAS INTELIGÊNCIAS ESTAVAM CERTAS
Alan Turing entrou no CPD.
Dois pequenos agentes estavam discutindo.
O primeiro gritava:
— O cliente possui R$ 10.000!
O segundo respondia:
— Não! Ele possui R$ 2.000!
Turing olhou para o programador COBOL.
— Qual deles está errado?
— Um dos dois, obviamente.
Turing tomou um gole de café.
— Tem certeza?
Na tela havia:
AGENT-A
READ TIME..... 10:00:01
BALANCE....... 10000.00Na outra:
AGENT-B
READ TIME..... 10:00:04
BALANCE....... 2000.00Entre as duas leituras:
10:00:03
WITHDRAWAL.... 8000.00
COMMIT........ OKSilêncio.
O jovem programador coçou a barba imaginária que todo programador mainframe adquire depois de alguns anos.
Turing perguntou novamente:
— Qual inteligência artificial estava errada?
O pequeno robô respondeu:
— Nenhuma.
— Exatamente.
E escreveu no quadro:
DADOS NÃO EXISTEM FORA DO TEMPO.
A primeira lição daquele dia seria desagradavelmente simples:
Ler um dado não significa possuir a verdade. Significa possuir uma observação feita em determinado momento e sob determinadas condições.
Bem-vindo ao Db2 dos Agentes.
🗄️ CAPÍTULO 1 — O BANCO DE DADOS NÃO É UM ARMÁRIO
Para quem está começando em COBOL, é tentador imaginar banco de dados como um enorme armário.
Existe uma gaveta:
CUSTOMERDentro dela:
CUSTOMER_ID
NAME
BALANCE
STATUS
CREDIT_LIMITO programa pergunta:
SELECT BALANCE
FROM CUSTOMER
WHERE CUSTOMER_ID = 12345;Db2 responde:
10000.00Pronto.
Verdade encontrada.
Só que não.
Em um sistema corporativo real, enquanto você lê 10000.00, outras coisas podem estar acontecendo.
Um caixa eletrônico pode sacar dinheiro.
Uma API pode registrar pagamento.
Um programa COBOL pode alterar o limite.
Outro agente pode atualizar o cadastro.
Um batch pode consolidar movimentos.
Uma transação CICS pode estar executando naquele exato instante.
O banco de dados não é uma fotografia imóvel.
É uma cidade viva.
🧠 CAPÍTULO 2 — LER NÃO É COMPREENDER
Imagine que nosso agente recebe:
CUSTOMER_ID = 12345
BALANCE = 10000E conclui:
Cliente possui recursos suficientes para uma compra de R$ 8.000.
Matematicamente:
10000 >= 8000Correto.
Mas talvez exista:
PENDING_PAYMENT = 5000ou:
AVAILABLE_BALANCE = 3000ou uma regra dizendo:
ACCOUNT_STATUS = BLOCKEDO dado isolado estava correto.
A interpretação estava incompleta.
Esse problema é enorme para agentes.
LLMs são extraordinariamente bons em transformar informações em linguagem e relações.
Mas não devemos confundir:
DADOcom:
SIGNIFICADO DO DADO.Um agente corporativo precisa conhecer:
semântica;
origem;
unidade;
validade;
relacionamento;
regras de negócio;
temporalidade.
BALANCE = 10000 sem contexto pode ser praticamente inútil.
📚 CAPÍTULO 3 — O COPYBOOK JÁ TENTAVA NOS AVISAR
Programadores COBOL convivem com isso há décadas.
Veja:
01 WS-CUSTOMER.
05 WS-CUSTOMER-ID PIC 9(09).
05 WS-BALANCE PIC S9(11)V99 COMP-3.
05 WS-STATUS PIC X.O layout explica a representação.
Mas ainda não explica completamente o significado.
O que significa:
WS-STATUS = 'B'?
Blocked?
Bankrupt?
Business?
Batman?
😂
Sem documentação, regra de negócio ou conhecimento do sistema, temos apenas um byte.
É por isso que sistemas antigos frequentemente possuem algo valiosíssimo:
CONHECIMENTO SEMÂNTICO.
Está espalhado por:
copybooks
programas COBOL
DDL
stored procedures
documentação
regras
manuais
pessoasPara um agente entender dados corporativos, não basta entregar tabelas.
Precisamos entregar contexto.
⏰ CAPÍTULO 4 — O DADO TEM IDADE
Turing escreve:
VALUE = 10000Depois pergunta:
— Quando?
O programador responde:
— Como assim?
Turing acrescenta:
VALUE = 10000
READ_AT = 10:00:01Agora temos algo muito mais interessante.
Porque:
10:00:01 → 10000
10:00:03 → withdrawal 8000
10:00:04 → 2000O dado envelheceu em três segundos.
Chamaremos informalmente isso de:
DATA FRESHNESS.
Ou frescor do dado.
Para algumas informações:
3 segundosé praticamente tempo real.
Para outras:
3 segundosé perigosamente velho.
Temperatura média anual?
Sem problema.
Saldo bancário antes de autorizar pagamento?
Problema.
🕰️ CAPÍTULO 5 — TODA DECISÃO POSSUI UMA JANELA TEMPORAL
Nosso agente faz:
10:00:01 READ CUSTOMER
10:00:02 CALL LLM
10:00:04 SEARCH DOCUMENT
10:00:07 ANALYZE
10:00:09 DECIDEEle tomou uma decisão às:
10:00:09baseado em informação obtida às:
10:00:01.Temos oito segundos de diferença.
Em alguns processos isso é irrelevante.
Em outros é enorme.
Podemos imaginar:
DECISION AGE = DECISION_TIME - DATA_READ_TIMENesse caso:
8 segundos.Uma arquitetura de agentes deveria perguntar:
Quanto tempo uma observação continua válida para esta decisão?
Isso é tão importante quanto o timeout discutido no CICS dos Agentes.
⚛️ CAPÍTULO 6 — ACID ENTRA NA SALA
Quando falamos de bancos transacionais, encontramos a famosa sigla:
ACID
Ela representa quatro propriedades conceituais:
A — Atomicity
C — Consistency
I — Isolation
D — DurabilityVamos traduzi-las para nosso pequeno robô.
⚛️ CAPÍTULO 7 — ATOMICIDADE: TUDO OU NADA
Imagine transferência:
Conta A: -100
Conta B: +100Não queremos:
Conta A: -100
Conta B: ERRORA unidade lógica precisa ser tratada de forma coerente.
Ou todas as alterações da unidade de trabalho são confirmadas, ou as alterações não confirmadas precisam ser revertidas conforme a transação e os recursos envolvidos.
Conceitualmente:
BEGIN
DEBIT A
CREDIT B
COMMITSe ocorrer problema:
ROLLBACKNosso agente precisa entender que ações relacionadas não podem ser tratadas como frases independentes de uma conversa.
🧭 CAPÍTULO 8 — CONSISTÊNCIA: NÃO QUEBRE AS REGRAS DO UNIVERSO
Consistência significa que as operações devem respeitar as regras e invariantes estabelecidas pelo sistema.
Por exemplo:
STOCK >= 0ou:
ORDER must reference valid CUSTOMERou regras implementadas em aplicações, constraints, triggers e outros mecanismos.
O agente pode dizer:
Parece razoável.
Db2 responde:
Não perguntei se parece razoável.
😂
O sistema possui regras.
Inteligência probabilística não substitui integridade transacional.
🧱 CAPÍTULO 9 — ISOLAMENTO: AQUI COMEÇA A DIVERSÃO
Agora chegamos ao ponto central.
Imagine duas transações:
TX-A
TX-Bexecutando simultaneamente.
Queremos controlar o quanto uma transação pode perceber dos efeitos da outra enquanto ambas estão em andamento.
Isso é parte do problema de:
ISOLATION.
Sem isolamento adequado, concorrência pode produzir resultados surpreendentes.
E agentes multiplicam esse problema porque podemos ter:
10 agentes
100 agentes
1.000 agentestomando decisões simultaneamente.
💾 CAPÍTULO 10 — DURABILIDADE: COMMIT NÃO É PROMESSA DE BAR
Quando uma transação é confirmada com sucesso, esperamos que seu resultado persistente sobreviva conforme as garantias oferecidas pelo sistema.
Ou seja:
COMMITnão deveria significar:
Acho que gravei.
Significa que a alteração alcançou o ponto de confirmação definido pelo sistema transacional.
Para agentes corporativos isso importa muito.
O agente precisa diferenciar:
PLANNEDde:
EXECUTEDe:
COMMITTED.São estados diferentes.
👻 CAPÍTULO 11 — DIRTY READ: O FANTASMA QUE AINDA PODE DESAPARECER
Imagine:
TX-A:
UPDATE ACCOUNT
SET BALANCE = 2000Mas ainda não houve commit.
Outra transação consegue observar essa alteração sob condições que permitam leitura não confirmada.
Depois A faz:
ROLLBACK.A informação que B viu desapareceu.
B tomou decisão sobre algo que nunca se tornou estado confirmado.
É a ideia de:
DIRTY READ.
Para um agente, isso pode ser especialmente perigoso.
Ele pode gerar uma explicação brilhante baseada em uma alteração que será desfeita segundos depois.
🔁 CAPÍTULO 12 — NON-REPEATABLE READ: EU JURO QUE ERA 10.000
Agente A lê:
BALANCE = 10000Agente B altera:
BALANCE = 2000
COMMITA lê novamente:
BALANCE = 2000A mesma consulta lógica produziu valores diferentes durante a execução da atividade.
O pequeno robô olha para Turing:
— Professor, o banco mentiu para mim!
— Não.
— Mas mudou!
— Exatamente.
O mundo mudou.
Essa é uma distinção filosófica e técnica importante:
Mudança não é inconsistência.
Às vezes o sistema está funcionando perfeitamente.
A realidade simplesmente evoluiu.
👥 CAPÍTULO 13 — PHANTOM READ: APARECEU OUTRO CLIENTE
Imagine:
SELECT COUNT(*)
FROM ORDERS
WHERE STATUS = 'PENDING';Resultado:
10Outra transação insere novo pedido pendente.
Você executa novamente.
11Apareceu uma nova linha que satisfaz o predicado da consulta.
O conjunto observado mudou.
É o tipo de fenômeno associado ao famoso:
PHANTOM.
Para agentes que fazem análises sobre conjuntos de dados, isso importa bastante.
O agente pode perguntar:
Quantas solicitações aguardam aprovação?
A resposta pode envelhecer antes de terminar a frase.
💥 CAPÍTULO 14 — LOST UPDATE: DOIS AGENTES ESTAVAM CERTOS
Temos:
STOCK = 10Agent-A lê:
10Agent-B lê:
10.A decide vender 3.
Calcula:
10 - 3 = 7B decide vender 4.
Calcula:
10 - 4 = 6.A grava:
7B grava:
6.A atualização de A pode ser efetivamente perdida dependendo da forma como a aplicação implementa a concorrência.
O valor correto deveria refletir ambas as operações:
3.Dois agentes.
Duas contas matematicamente corretas.
Resultado corporativo errado.
Esse é um dos melhores exemplos de por que:
INTELIGÊNCIA NÃO RESOLVE CONCORRÊNCIA.
🔒 CAPÍTULO 15 — LOCKS: RESERVANDO UM PEDAÇO DA REALIDADE
Uma abordagem tradicional para coordenar concorrência utiliza locks.
Simplificando:
AGENT-A
LOCK ROWAgora B precisa esperar dependendo da operação, isolamento e mecanismos envolvidos.
A altera.
UPDATE
COMMITLock liberado.
B continua.
Isso pode proteger consistência.
Mas lembra do CICS dos Agentes?
Locks possuem custo.
Se o agente fizer:
LOCK CUSTOMER
CALL LLM
SEARCH WEB
READ 50 PDFs
ASK HUMAN
WAIT 20 MINUTESo DBA provavelmente surgirá atrás dele segurando um manual do Db2 como arma contundente.
☠️ CAPÍTULO 16 — NÃO PENSE SEGURANDO O LOCK
Nossa regra retorna:
NÃO DEIXE O LLM PENSAR SEGURANDO LOCKS DESNECESSÁRIOS.
Uma arquitetura possível:
READ
↓
CAPTURE VERSION
↓
RELEASE TRANSACTIONAL RESOURCES
↓
THINK
↓
REVALIDATE
↓
SHORT UPDATE TRANSACTION
↓
COMMITMas agora aparece uma pergunta:
Como sabemos se o dado mudou enquanto o agente pensava?
Excelente.
Entramos no próximo monstro.
🔢 CAPÍTULO 17 — VERSIONAMENTO
Imagine tabela conceitual:
CUSTOMER
────────────────────────
ID 12345
BALANCE 10000
VERSION 17O agente lê:
VERSION = 17.Vai pensar.
Enquanto isso outra transação altera o registro.
Agora:
VERSION = 18.Nosso agente retorna e tenta atualizar.
Em vez de simplesmente:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000
WHERE CUSTOMER_ID = 12345;podemos usar uma estratégia de concorrência otimista:
UPDATE CUSTOMER
SET CREDIT_LIMIT = 5000,
VERSION = VERSION + 1
WHERE CUSTOMER_ID = 12345
AND VERSION = 17;Se:
ROWS UPDATED = 1ótimo.
Se:
ROWS UPDATED = 0alguma coisa mudou.
Pare.
Releia.
Reavalie.
optimistic CAPÍTULO 18 — OPTIMISTIC CONCURRENCY
O nome vem da ideia:
Provavelmente ninguém vai alterar isto enquanto estou trabalhando.
Em vez de manter um lock durante todo o raciocínio, registramos a versão observada.
Depois verificamos se ainda é a mesma.
Fluxo:
READ VERSION 17
↓
THINK
↓
CHECK VERSION
↓
┌───────┐
│ │
17 18
│ │
▼ ▼
UPDATE STALE
RELOADIsso combina muito bem com agentes.
Por quê?
Porque raciocínio de IA pode levar tempo e envolver recursos externos.
Não queremos manter uma transação aberta durante todo esse período.
🥖 CAPÍTULO 19 — O PÃO DE QUEIJO DA CONCORRÊNCIA
Turing coloca um pão de queijo sobre a mesa.
Diz ao Agent-A:
— Quantos existem?
— Um.
Agent-A vira para consultar o LLM sobre a composição nutricional do pão de queijo.
Agent-B chega.
Come o pão de queijo.
Agent-A volta.
— Decidi com 98,7% de confiança que devo comer o pão de queijo.
Turing aponta para o prato vazio.
Agent-A:
ERROR:
RESOURCE NOT FOUND😂
Essa é concorrência otimista explicada no café.
Você não precisa segurar o pão durante quinze minutos.
Mas antes de mordê-lo:
VERIFIQUE SE ELE AINDA EXISTE.
📸 CAPÍTULO 20 — SNAPSHOT: UMA FOTOGRAFIA DA REALIDADE
Às vezes queremos que uma operação trabalhe sobre uma visão consistente dos dados.
Conceitualmente, podemos imaginar:
SNAPSHOT @ 10:00:00O agente analisa aquela visão.
Mesmo que o mundo continue mudando, sabemos:
Esta análise corresponde à realidade observada naquele ponto ou contexto transacional.
Isso é extremamente útil.
Mas exige honestidade.
O resultado deveria dizer algo como:
ANALYSIS-AS-OF:
2026-09-27T10:00:00e não:
CURRENT STATE.Se os dados eram de dez minutos atrás, não chame de “agora”.
🕰️ CAPÍTULO 21 — “AS OF” PODE SER TÃO IMPORTANTE QUANTO O VALOR
Imagine um relatório:
RISK SCORE = 72Pergunta:
— Baseado em quê?
Resposta:
CUSTOMER DATA..... 10:00
PAYMENTS........... 09:58
CREDIT BUREAU...... 08:00
CRM................ yesterdayAgora entendemos muito melhor o resultado.
Para agentes, deveríamos considerar metadados como:
SOURCE
READ_AT
VALID_AT
VERSION
TRANSACTION_ID
RUN_IDIsso cria:
PROVENIÊNCIA TEMPORAL.
Não basta saber de onde veio.
Precisamos saber de quando veio.
🤖 CAPÍTULO 22 — O RAG TAMBÉM POSSUI RELÓGIO
Agora chegamos a algo delicioso.
RAG:
Retrieval-Augmented GenerationEm termos simples:
PERGUNTA
↓
BUSCA INFORMAÇÃO
↓
ENTREGA CONTEXTO AO MODELO
↓
MODELO RESPONDEFantástico.
Mas imagine recuperar:
POLITICA-CREDITO-2024.PDFquando existe:
POLITICA-CREDITO-2026.PDF.O modelo pode interpretar perfeitamente o documento errado.
A resposta pode ser:
linguisticamente excelente
logicamente coerente
tecnicamente obsoleta.Isso é assustador.
📚 CAPÍTULO 23 — EMBEDDING NÃO SABE QUE A NORMA FOI REVOGADA
Busca semântica responde:
Este documento é parecido com sua pergunta.
Ela não necessariamente responde:
Este documento continua válido hoje.
Essas são perguntas diferentes.
Um sistema RAG corporativo pode precisar considerar:
EFFECTIVE_FROM
EFFECTIVE_TO
VERSION
STATUS
SUPERSEDED_BY
SOURCE
AUTHORITYImagine:
DOC A
Similarity = 0.97
Status = EXPIREDe:
DOC B
Similarity = 0.91
Status = ACTIVE.Qual deveria ganhar?
Não necessariamente A.
A relevância semântica é apenas uma dimensão.
🧭 CAPÍTULO 24 — VERDADE TAMBÉM PRECISA DE PROVENIÊNCIA
Nosso agente afirma:
O limite do cliente é R$ 20.000.
Pergunte:
SOURCE?Depois:
WHEN?Depois:
VERSION?Depois:
COMMITTED?Depois:
AUTHORIZED SOURCE?Uma resposta corporativa forte deveria conseguir produzir evidências.
Por exemplo:
VALUE......... 20000
SOURCE........ DB2.CUSTOMER_LIMIT
KEY........... 12345
READ_AT....... 10:42:03
VERSION....... 882
RUN-ID........ A004821Agora temos algo auditável.
🪪 CAPÍTULO 25 — O RUN-ID ENCONTRA O DATA VERSION
No JES2 dos Agentes criamos:
RUN-ID.Agora podemos relacionar:
RUN-ID A004821com:
CUSTOMER VERSION 882
DOCUMENT VERSION 17
RULESET VERSION 42
MODEL VERSION XIsso responde uma pergunta extremamente importante:
Qual realidade o agente viu quando tomou esta decisão?
Sem isso, uma auditoria futura pode encontrar dados diferentes e perguntar:
— Como a IA chegou nessa conclusão absurda?
Talvez não fosse absurda.
Talvez os dados fossem outros naquele momento.
🧪 CAPÍTULO 26 — REPRODUZIR UMA DECISÃO DE IA É MAIS DIFÍCIL
Com programa COBOL determinístico:
INPUT X
+
PROGRAM VERSION Y
=
OUTPUT Zfrequentemente temos comportamento bastante reproduzível.
Com agente:
PROMPT
MODEL
TOOLS
DATA
DOCUMENTS
TIMING
CONVERSATION
POLICYtodos podem influenciar.
Portanto registrar apenas:
PROMPTnão basta.
Podemos precisar registrar referências para:
RUN-ID
MODEL VERSION
PROMPT VERSION
TOOL VERSION
DATA VERSION
DOCUMENT VERSION
POLICY VERSION
TIMESTAMPS
RESULTIsso é observabilidade encontrando governança de dados.
SDSF encontra Db2.
🔄 CAPÍTULO 27 — REVALIDATE BEFORE COMMIT
Aqui está uma regra poderosa.
Nosso agente:
READ
↓
THINK
↓
DECIDEAntes de alterar algo importante:
REVALIDATEDepois:
COMMIT.Fluxo completo:
READ STATE V17
↓
ANALYZE
↓
PROPOSE ACTION
↓
CHECK CURRENT STATE
↓
V17?
│
├─ YES → EXECUTE → COMMIT
│
└─ NO → RELOAD → REASON AGAINEssa talvez seja uma das regras mais importantes de todo o artigo.
NÃO CONFIE CEGAMENTE NO SNAPSHOT QUE INICIOU O RACIOCÍNIO.
👤 CAPÍTULO 28 — HUMAN-IN-THE-LOOP PIORA O PROBLEMA TEMPORAL
Imagine:
10:00
Agent recommends paymentHumano recebe:
Approve?Vai almoçar.
Volta:
13:30Clica:
APPROVE.O agente não deveria simplesmente continuar a operação planejada três horas e meia atrás.
Precisa:
RELOAD
REVALIDATE
REAUTHORIZE
EXECUTETalvez o saldo mudou.
Talvez o cliente foi bloqueado.
Talvez a regra mudou.
Talvez outro operador já resolveu.
A aprovação humana confirma intenção.
Não necessariamente confirma que o estado antigo continua válido.
🚨 CAPÍTULO 29 — STALE CONTEXT
Vamos dar nome ao monstro:
STALE CONTEXT.
O contexto ficou velho.
Exemplo:
AGENT CONTEXT
CUSTOMER_STATUS = ACTIVE
READ_AT = 10:00Agora:
CURRENT DATABASE
CUSTOMER_STATUS = BLOCKED
UPDATED_AT = 10:03.Às 10:05 o agente ainda carrega:
ACTIVE.Isso não é hallucination.
Não é necessariamente erro do LLM.
É contexto obsoleto.
Essa distinção é importantíssima.
🧯 CAPÍTULO 30 — NEM TODO ERRO DE IA É ERRO DA IA
Quando um agente produz resposta incorreta, investigue:
MODEL?
PROMPT?
RETRIEVAL?
DATA?
TIMING?
TOOL?
CACHE?
VERSION?Talvez o modelo tenha raciocinado corretamente sobre dados ruins.
Talvez os dados fossem bons, mas velhos.
Talvez a ferramenta tenha retornado cache.
Talvez a consulta tenha usado uma réplica com defasagem.
Talvez o documento recuperado estivesse revogado.
“IA errou” pode ser diagnóstico preguiçoso.
Precisamos descobrir:
EM QUAL CAMADA A REALIDADE SE DESVIOU?
🗃️ CAPÍTULO 31 — CACHE É UMA MÁQUINA DO TEMPO
Cache melhora desempenho.
No CICS dos Agentes adoramos isso.
Em vez de consultar Db2:
20 mspodemos obter:
2 ms.Fantástico.
Mas existe preço.
O dado pode estar:
STALE.Imagine:
CACHE TTL = 5 minutesPara:
COUNTRY CODEtalvez ótimo.
Para:
AVAILABLE BALANCEtalvez terrível.
Portanto:
Cache não é simplesmente performance. É uma decisão sobre quanto passado aceitamos apresentar como presente.
🎯 CAPÍTULO 32 — FRESHNESS BUDGET
No CICS tínhamos:
LATENCY BUDGET.Agora podemos imaginar:
FRESHNESS BUDGET.Por exemplo:
PRODUCT DESCRIPTION..... 24h
CUSTOMER ADDRESS........ 5m
ACCOUNT BALANCE......... 1s
FRAUD STATUS............ 0s / revalidateNão são números universais.
São decisões de negócio e arquitetura.
Mas o conceito é poderoso:
Quão velho este dado pode estar antes de deixar de ser aceitável?
📊 CAPÍTULO 33 — O PAINEL DO Db2 DOS AGENTES
Imagine nosso painel operacional:
RUN-ID......... A004821
AGENT.......... CREDIT-ANALYSIS
DATA SOURCES
────────────────────────────────────────
CUSTOMER VERSION 882 AGE 0.4s
BALANCE VERSION 991 AGE 0.1s
CRM VERSION 441 AGE 2m
CREDIT-RULES VERSION 42 AGE 3d
RAG-DOC VERSION 17 AGE 4h
DECISION AGE.................. 2.8s
STALE SOURCES................. 0
OPEN TRANSACTION.............. NO
LOCKS HELD.................... 0
REVALIDATION REQUIRED......... YESAgora estamos falando.
O operador consegue enxergar não apenas:
O QUE O AGENTE ESTÁ FAZENDO?mas:
QUAL REALIDADE ELE ESTÁ VENDO?🧰 CAPÍTULO 34 — CHECKLIST PARA AGENTES QUE TOMAM DECISÕES SOBRE DADOS
Antes de colocar um agente corporativo em produção, pergunte:
1. Qual é a fonte oficial?
Db2?
API?
RAG?
cache?2. O dado possui timestamp?
Saiba quando foi observado.
3. Existe versão?
Use versionamento quando necessário.
4. Qual é o freshness budget?
Defina tolerância.
5. O agente mantém transação aberta enquanto pensa?
Evite.
6. Existem locks?
Minimize duração.
7. Pode haver concorrência?
Presuma que sim.
8. Existe optimistic concurrency?
Considere version checking.
9. A ação precisa ser revalidada?
Para ações críticas, quase certamente.
10. O RAG conhece validade documental?
Não use apenas similaridade.
11. Existe proveniência?
Registre origem.
12. Podemos reconstruir a decisão?
Associe dados, versões e RUN-ID.
13. O humano pode demorar para aprovar?
Revalide depois da aprovação.
14. O cache é permitido?
Defina TTL de acordo com semântica.
15. O resultado informa “as of”?
Quando relevante, deveria.
🥚 EASTER EGG — O AGENTE QUE ESTAVA 100% CERTO
02:14 da madrugada.
Telefone toca.
— Produção.
O operador atende.
— Temos problema.
— Qual?
— A IA aprovou uma operação que deveria ter recusado.
Abrem o trace.
RUN-ID A008817Modelo respondeu corretamente.
Prompt correto.
Regra correta.
RACF correto.
Nenhuma hallucination.
Turing chega carregando café.
— Mostre os dados.
CUSTOMER_STATUS = ACTIVE— Quando foram lidos?
Silêncio.
Procuram.
CACHE READ:
01:43:02Turing olha o relógio.
02:14.Consulta Db2:
CUSTOMER_STATUS = BLOCKED
UPDATE TIME = 01:44:11O agente estava usando uma informação de 31 minutos atrás.
O jovem programador diz:
— Então a IA errou.
Turing responde:
— Não.
Aponta para o cache.
— Nós entregamos o passado e perguntamos sobre o presente.
Silêncio.
No fundo do CPD, o DBA sorri.
Finalmente não era culpa do banco.
🧬 CAPÍTULO 35 — NOSSO MAINFRAME DOS AGENTES ESTÁ FICANDO INTERESSANTE
Agora nossa arquitetura conceitual possui:
RACF
↓
QUEM PODE?PF3
↓
POSSO PARAR?SDSF
↓
O QUE ESTÁ FAZENDO?MAXCC
↓
FUNCIONOU?WLM
↓
QUEM RECEBE RECURSOS?JES2
↓
QUEM COMEÇA E QUANDO?CICS
↓
QUANTO TEMPO O HUMANO PODE ESPERAR?E agora:
Db2
↓
QUAL REALIDADE O AGENTE ESTÁ VENDO?Isso muda tudo.
🏰 CAPÍTULO 36 — O SISTEMA OPERACIONAL CONCEITUAL DOS AGENTES
Turing desenha novamente:
HUMANO
│
▼
┌─────────────┐
│ REQUEST │
└──────┬──────┘
│
┌────────┴────────┐
│ │
▼ ▼
CICS JES2
responda agora trabalhe depois
│ │
└────────┬────────┘
▼
WLM
│
RACF
│
▼
AGENT
│
┌────────────┼────────────┐
▼ ▼ ▼
LLM Db2 TOOLS
│
▼
CURRENT REALITY?Ao redor:
SDSF
OBSERVE
CHECKPOINT
RESUME
PF3
STOP
MAXCC
VERIFY
RUN-ID
IDENTIFY
VERSION
VALIDATE
TIMESTAMP
WHEN?O mainframe não está apenas nos ensinando como executar agentes.
Está nos ensinando a fazê-los sobreviver à realidade corporativa.
👴 CAPÍTULO 37 — O PROGRAMADOR COBOL JÁ VIU ESSE FILME
O mundo de IA está descobrindo:
agents
tool calls
state
concurrency
context
workflowO programador COBOL olha e pensa:
Vocês descobriram processamento corporativo.
😂
Porque ele já viveu:
CICS
Db2
JES2
MQ
RACF
WLM
COMMIT
ROLLBACK
LOCK
RESTARTClaro que agentes introduzem problemas novos.
Modelos probabilísticos.
Context windows.
Embeddings.
RAG.
Tool selection.
Autonomia.
Mas muitos monstros operacionais são antigos.
E nós já temos cicatrizes deles.
☕ EPÍLOGO — QUAL REALIDADE VOCÊ ESTÁ VENDO?
Fim da tarde.
O pequeno agente recebe:
CUSTOMER_ID = 12345Consulta:
BALANCE = 10000
VERSION = 882
READ_AT = 17:42:01Começa análise.
Enquanto pensa:
17:42:02
WITHDRAWAL = 8000
COMMIT
VERSION = 883O agente termina:
17:42:04Antigamente responderia:
Operação aprovada. O cliente possui R$ 10.000.
Mas agora aprendeu.
Antes de agir:
CHECK VERSION 882Db2 responde:
CURRENT VERSION = 883.O robô para.
Relê.
BALANCE = 2000.Reavalia.
Resultado:
DECISION = DENIED
REASON = INSUFFICIENT FUNDSTuring sorri.
— Muito bem.
O agente pergunta:
— Minha primeira análise estava errada?
Turing responde:
— Não.
— Então por que não usei?
— Porque ela estava correta para uma realidade que não existia mais.
O programador COBOL olha para o terminal.
Na tela:
RUN-ID........ A004821
READ VERSION.. 882
CURRENT....... 883
CONTEXT....... STALE
REVALIDATION.. REQUIRED
ACTION........ REEVALUATED
STATUS........ COMMITTEDTuring termina o café.
Antes de sair, escreve no quadro:
UMA IA NÃO PRECISA APENAS SABER A RESPOSTA.
Abaixo:
PRECISA SABER DE QUANDO É A RESPOSTA.
E finalmente:
SELECT
VALUE,
VERSION,
TIMESTAMP
FROM
REALITY
WHERE
NOW = NOW;O programador observa.
— Professor...
— Sim?
— Essa tabela não existe.
Turing sorri.
— Ainda.
No fundo do CPD, o DBA grita:
— E NEM INVENTA DE CRIAR EM PRODUÇÃO!
O pequeno robô fecha o terminal.
COMMIT;E todos foram tomar café.
Porque no mainframe, no Db2 e no mundo dos agentes, existe uma verdade que sobrevive a qualquer geração tecnológica:
Uma decisão só é tão confiável quanto os dados, o contexto e o instante da realidade sobre os quais ela foi construída.
READY
Sem comentários:
Enviar um comentário