 |
| Bellacosa Mainframe e as ligações dos agentes de ia |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
⚡ ALAN TURING E O CICS DOS AGENTES — QUANTO TEMPO UM HUMANO ACEITA OLHAR PARA PROCESSING...?
CICS, agentes de IA, transações online, latência, contexto, pseudo-conversationalidade, concorrência, locks, timeout, Db2, commit, rollback, syncpoint, idempotência, circuit breakers, human-in-the-loop — e o dia em que Alan Turing descobriu que uma inteligência artificial pode pensar durante cinco minutos, desde que não exista um cliente olhando para a ampulheta.
🎬 PRÓLOGO — O HUMANO ESTAVA ESPERANDO
Alan Turing entrou no CPD.
O relógio marcava:
10:14:03Na tela de um terminal havia uma mensagem:
PROCESSING...Turing tomou um gole de café.
10:14:08Nada.
10:14:15Nada.
10:14:31Ainda:
PROCESSING...O jovem programador COBOL apareceu.
— Bom dia, professor.
Turing apontou para a tela.
— O que está acontecendo?
— O agente está pensando.
— Há quanto tempo?
— Trinta segundos.
— E o usuário?
— Esperando.
Turing levantou uma sobrancelha.
— Existe uma diferença enorme entre um agente trabalhar durante trinta segundos e obrigar um ser humano a esperar trinta segundos.
O pequeno robô apareceu.
— Mas eu estou realizando uma análise muito sofisticada!
Turing respondeu:
— Parabéns.
Apontou para o terminal.
— O cliente acabou de fechar a janela.
Silêncio.
Do fundo do CPD, alguém murmurou:
Bem-vindo ao online.
🏛️ CAPÍTULO 1 — JES2 E CICS VIVEM EM UNIVERSOS DIFERENTES
No artigo anterior construímos o:
JES2 DOS AGENTESA ideia era fantástica para processamento assíncrono.
O usuário submete:
AGENT-CONTRACT-ANALYSISrecebe:
RUN-ID A004821e pode ir tomar café.
O agente pode executar:
agora
daqui a cinco minutos
durante a madrugadaNão importa tanto.
Mas agora imagine:
CLIENTE
↓
TELA
↓
"CONSULTAR SALDO"Ele clicou.
Está esperando.
Temos outro tipo de trabalho.
INTERATIVOE sistemas interativos possuem uma característica brutal:
EXISTE UM HUMANO MEDINDO O TEMPO.
Não com cronômetro.
Com impaciência.
⚡ CAPÍTULO 2 — CICS NASCEU PARA O MUNDO ONLINE
CICS significa:
Customer Information Control SystemPara o programador COBOL iniciante, uma forma útil de pensar nele é:
Um ambiente transacional capaz de executar aplicações online com grande volume de usuários e transações.
Em vez de:
JOB
↓
PROCESSA 2 HORAS
↓
OUTPUTtemos algo mais próximo de:
REQUEST
↓
TRANSACTION
↓
PROGRAM
↓
DATA
↓
RESPONSERapidamente.
Milhares ou milhões de vezes.
Uma transação pode:
consultar cliente
alterar pedido
autorizar pagamento
verificar estoque
registrar operaçãoO usuário envia uma solicitação.
CICS identifica a transação.
Executa o programa associado.
O programa acessa recursos.
Produz resposta.
E termina.
Parece muito com aquilo que agentes terão de fazer quando forem colocados dentro de aplicações interativas.
🤖 CAPÍTULO 3 — O AGENTE SAIU DA FILA E ENTROU NA TELA
Imagine:
Usuário:
"Analise este cliente e diga se existe alguma inconsistência."Nosso agente precisa:
receber contexto
consultar dados
talvez chamar ferramentas
raciocinar
produzir resultadoSe isso estiver num processamento batch:
45 segundospode ser perfeitamente aceitável.
Se estiver numa tela de atendimento:
45 segundospode parecer uma eternidade.
Essa é uma mudança fundamental.
Não basta perguntar:
O agente consegue executar?
Precisamos perguntar:
O agente consegue executar dentro do orçamento de tempo da experiência humana?
⏱️ CAPÍTULO 4 — LATÊNCIA VIROU EXPERIÊNCIA
Suponha:
AGENT RESPONSE TIME = 800 msExcelente.
Agora:
3 segundosTalvez aceitável.
Agora:
12 segundosO usuário começa a desconfiar.
Agora:
45 segundosTalvez já esteja clicando novamente.
Agora:
2 minutosEle abriu outra aba.
Agora:
5 minutosEle foi fazer café.
O problema não é apenas tecnológico.
É UX.
Portanto precisamos pensar em:
TIME BUDGETImagine que nossa experiência tenha:
TOTAL BUDGET = 3 sEsse orçamento precisa ser dividido.
API............. 200 ms
CICS............ 300 ms
Db2............. 400 ms
Agent........... 1500 ms
Formatting...... 100 ms
Network......... 200 ms
Safety margin... 300 msSe o agente gastar sozinho:
8 segundosnão adianta o restante ser rápido.
💰 CAPÍTULO 5 — TEMPO TAMBÉM É ORÇAMENTO
No WLM dos agentes falamos de:
tokens
CPU
API calls
moneyAgora adicionamos:
PACIÊNCIA HUMANAEla também é finita.
Podemos imaginar:
LATENCY BUDGETcomo um recurso.
Cada componente gasta um pedaço.
Usuário
↓ 100 ms
Gateway
↓ 150 ms
Agent
↓ 900 ms
Db2
↓ 200 ms
CICS
↓ 300 ms
ResponseTotal:
1.65 sÓtimo.
Mas se o agente decidir:
Vou consultar mais oito ferramentas...
nosso orçamento desaparece.
Autonomia precisa respeitar tempo.
🚦 CAPÍTULO 6 — O AGENTE PRECISA SABER QUANDO PARAR DE PENSAR
Aqui aparece uma consequência interessante.
Um agente pode teoricamente melhorar sua resposta fazendo:
mais buscas
mais chamadas
mais validações
mais raciocínioMas numa interação online existe limite.
Podemos estabelecer:
MAX_TOOL_CALLS = 3
MAX_AGENT_TIME = 1500 msSe não conseguir concluir:
FALLBACKTalvez:
"Preciso de uma análise mais profunda.
Posso continuar em segundo plano?"Agora fazemos uma transformação elegante:
ONLINE
↓
ASYNCOu seja:
CICS encontra JES2.
O usuário recebe resposta rápida.
O trabalho longo continua depois.
🔄 CAPÍTULO 7 — FAST PATH E SLOW PATH
Essa arquitetura é extremamente útil para agentes.
FAST PATH
Tente resolver imediatamente.
USER
↓
AGENT
↓
TOOLS
↓
RESPONSELimite:
2 segundosSe a tarefa exigir mais:
SLOW PATH
USER
↓
SUBMIT
↓
RUN-ID
↓
QUEUE
↓
BACKGROUND AGENTA interface responde:
Análise aprofundada iniciada.
RUN-ID: A004821Depois o usuário recebe resultado.
Assim não transformamos uma transação online em um batch disfarçado.
Essa frase merece moldura:
Não transforme processamento batch em transação online apenas porque agora existe uma interface bonita na frente.
🧠 CAPÍTULO 8 — CICS APRENDEU A NÃO FICAR CONVERSANDO PARA SEMPRE
Aqui entra um conceito delicioso para nossa analogia:
PSEUDO-CONVERSATIONALIDADE.
Imagine um programa conversacional ingênuo.
O usuário recebe uma tela.
Enquanto pensa durante dois minutos, o programa continua ocupando recursos.
PROGRAMA
↓
ENVIA TELA
↓
ESPERA USUÁRIO
↓
ESPERA...
↓
ESPERA...Isso não escala bem.
A filosofia pseudo-conversational do CICS é diferente.
Simplificando:
Usuário envia
↓
Transação executa
↓
Salva contexto necessário
↓
Envia tela
↓
TERMINAQuando o usuário responde:
nova transaçãocomeça.
O contexto necessário é recuperado.
Isso é brilhante.
Porque:
esperar o humano não significa manter o programa executando.
Soa familiar?
Exatamente o que discutimos com agentes esperando aprovação.
💤 CAPÍTULO 9 — NÃO DEIXE O AGENTE ACORDADO ESPERANDO O HUMANO
Imagine:
AGENT:
"Posso enviar o pagamento?"Agora precisa de human-in-the-loop.
O usuário pode responder em:
10 segundosou:
10 minutosou:
10 horas.Seria absurdo manter:
LLM session
thread
Db2 connection
transaction
lockabertos durante esse tempo.
Melhor:
SAVE STATE
↓
WAITING_APPROVAL
↓
RELEASE RESOURCESQuando o humano aprovar:
APPROVAL EVENT
↓
RESUMEO velho conceito pseudo-conversational encontra o workflow moderno.
Décadas separadas.
Mesmo princípio:
Persista contexto; libere recurso.
📦 CAPÍTULO 10 — CONTEXTO NÃO É CONEXÃO
Essa distinção merece atenção.
Para continuar uma conversa, o agente precisa de contexto.
Mas contexto não significa manter todos os recursos físicos ou lógicos presos.
Podemos persistir:
RUN-ID
USER-ID
CUSTOMER-ID
CURRENT-STATE
APPROVAL-STATUS
LAST-RESULT
NEXT-ACTIONE terminar a execução corrente.
Quando houver nova interação:
LOAD CONTEXT
↓
CONTINUEIsso permite escala.
O mesmo usuário pode voltar depois.
O mesmo agente pode continuar.
Sem deixar uma transação pendurada eternamente.
🔐 CAPÍTULO 11 — UMA TRANSAÇÃO PRECISA DE FRONTEIRAS
Agora chegamos a uma palavra importantíssima:
TRANSAÇÃO.
Suponha que nosso agente faça:
1. Debitar conta A
2. Creditar conta BSe fizer apenas o primeiro:
A = -100e cair antes do segundo...
temos problema.
Queremos:
TUDOou:
NADA.Essa é uma das ideias centrais do processamento transacional.
Uma unidade lógica de trabalho precisa possuir fronteiras claras.
🧱 CAPÍTULO 12 — UNIT OF WORK
Podemos chamar uma sequência de alterações relacionadas de:
UNIT OF WORKou UOW.
Exemplo:
BEGIN UOW
UPDATE ACCOUNT-A
UPDATE ACCOUNT-B
INSERT AUDIT
END UOWSe tudo funcionar:
COMMITSe alguma coisa falhar:
ROLLBACKPara agentes isso é vital.
Porque agentes podem executar várias ferramentas.
Precisamos saber:
Quais ações pertencem à mesma unidade de consistência?
✅ CAPÍTULO 13 — COMMIT: AGORA É PARA VALER
Imagine:
OLD BALANCE = 1000O agente executa:
UPDATEMas enquanto a transação ainda não confirmou definitivamente suas alterações, estamos dentro da unidade de trabalho.
Quando chegamos ao ponto seguro:
COMMITAs mudanças tornam-se permanentes conforme a semântica do recurso transacional envolvido.
No universo CICS encontramos o conceito de:
SYNCPOINTUm ponto de sincronização estabelece uma fronteira importante da unidade de trabalho.
Para nosso agente, a analogia é poderosa.
Antes:
PLANEJARDepois:
EXECUTARDepois:
VALIDARFinalmente:
COMMIT↩️ CAPÍTULO 14 — ROLLBACK: DESFAÇA ANTES QUE ALGUÉM PERCEBA
Imagine:
STEP 1 OK
STEP 2 OK
STEP 3 FAILEDSe tudo pertence à mesma unidade transacional:
ROLLBACKO sistema desfaz alterações ainda não confirmadas, conforme os recursos participantes e suas capacidades transacionais.
Conceitualmente:
BEFORE:
A = 100
B = 200
TEMP:
A = 50
B = ???
ERROR
ROLLBACK
AFTER:
A = 100
B = 200Muito melhor que:
A = 50
B = 200
¯\_(ツ)_/¯🤖 CAPÍTULO 15 — MAS AGENTES CHAMAM COISAS QUE NÃO SABEM DAR ROLLBACK
Aqui começa a diversão.
Db2 pode participar de mecanismos transacionais sofisticados.
Mas o agente talvez chame:
EMAIL APIDepois:
PAYMENT APIDepois:
CRM APIDepois:
POST SOCIAL MEDIAComo fazemos:
ROLLBACK EMAIL?
Não fazemos.
O e-mail já saiu.
Como:
ROLLBACK TWEET?
Podemos apagar, talvez.
Mas alguém já viu.
Isso nos obriga a distinguir:
TRANSACTIONAL ACTIONde:
IRREVERSIBLE / EXTERNAL ACTIONAgentes tornam essa distinção absolutamente crítica.
⚠️ CAPÍTULO 16 — NÃO ENVIE O E-MAIL ANTES DO COMMIT
Velha sabedoria de sistemas corporativos ganha nova vida.
Imagine:
1. Atualizar pedido
2. Enviar confirmação
3. CommitO e-mail sai.
Depois o commit falha.
Cliente recebe:
Pedido confirmado!
Sistema:
PEDIDO NÃO EXISTE.Excelente.
😂
Talvez devamos estruturar:
1. Validar
2. Atualizar
3. Commit
4. Disparar ação externaou usar mecanismos adequados de mensageria e padrões transacionais para garantir processamento confiável.
O princípio é:
Pense cuidadosamente sobre o momento em que efeitos externos se tornam visíveis.
🔒 CAPÍTULO 17 — LOCKS: O AGENTE NÃO ESTÁ SOZINHO
Imagine dois agentes:
AGENT-A
AGENT-BAmbos leem:
STOCK = 1A pensa:
Posso vender.
B pensa:
Posso vender.
A vende.
B vende.
Parabéns.
Vendemos duas unidades de algo que só existia uma vez.
Bem-vindo à:
CONCORRÊNCIA.
Precisamos coordenar acesso a dados compartilhados.
Uma das ferramentas clássicas são locks.
🔐 CAPÍTULO 18 — O LOCK É A PLAQUINHA “ESTOU USANDO”
Simplificando brutalmente:
AGENT-A
LOCK RECORD XEnquanto A altera X:
AGENT-B
WAITDepois:
AGENT-A
COMMIT
RELEASE LOCKB pode continuar.
Isso protege consistência.
Mas locks possuem custo.
Quanto mais tempo seguramos um lock:
mais gente esperaPor isso transações online devem ser curtas.
Agora imagine um agente segurando lock e pensando:
"Hmmm...
vou consultar a internet...
vou perguntar ao modelo...
vou analisar 47 PDFs..."Enquanto isso:
LOCK HELDNÃO.
💀 CAPÍTULO 19 — NUNCA DEIXE O LLM PENSAR SEGURANDO O LOCK
Essa merece uma placa no CPD.
NÃO SEGURE LOCK ENQUANTO ESPERA UM LLM.
Se possível, estruture:
READ
↓
RELEASE
↓
THINK
↓
VALIDATE CURRENT STATE
↓
SHORT TRANSACTION
↓
UPDATE
↓
COMMITMas cuidado com alterações concorrentes.
Se você leu:
VERSION = 17pensou durante três segundos e voltou...
talvez agora seja:
VERSION = 19.Precisamos detectar isso.
🧮 CAPÍTULO 20 — OPTIMISTIC CONCURRENCY
Uma estratégia possível é controle otimista.
Você lê:
CUSTOMER
VERSION = 17Faz seu processamento.
Ao atualizar:
UPDATE CUSTOMER
WHERE ID = 123
AND VERSION = 17Se ninguém alterou:
SUCCESSSe alguém alterou:
0 ROWS UPDATEDAgora sabemos:
Meu contexto ficou velho.
O agente precisa:
RELOAD
REVALIDATE
RETRYem vez de sobrescrever silenciosamente informação nova.
Isso combina muito bem com agentes porque eles podem gastar tempo significativo fora do banco tomando decisões.
💥 CAPÍTULO 21 — DEADLOCK: DOIS ROBÔS EDUCADOS DEMAIS
Imagine:
AGENT-A
LOCK CUSTOMERDepois quer:
LOCK ACCOUNTMas B já possui ACCOUNT.
Enquanto isso:
AGENT-B
LOCK ACCOUNTe quer:
LOCK CUSTOMER.Temos:
A espera B
B espera AOs dois podem ficar esperando para sempre sem intervenção.
Isso é um deadlock clássico.
Sistemas de banco detectam e resolvem situações desse tipo escolhendo uma vítima para rollback.
Nosso agente precisa entender:
DEADLOCKnão como:
O universo me odeia.
Mas como:
Minha transação foi escolhida para rollback; preciso decidir se é seguro tentar novamente.
⏰ CAPÍTULO 22 — TIMEOUT É UMA POLÍTICA, NÃO UMA TRAGÉDIA
Outro conceito essencial:
TIMEOUTSe uma ferramenta deveria responder em:
500 msnão faz sentido esperar:
17 minutosPrecisamos estabelecer limites.
DB TIMEOUT........ 1 s
API TIMEOUT....... 2 s
AGENT BUDGET...... 3 s
TOTAL REQUEST..... 5 sSe ultrapassar:
STOP WAITINGE então decidir:
retry?
fallback?
async?
error?Timeout é uma proteção.
Sem timeout, uma dependência lenta pode consumir recursos indefinidamente.
🔌 CAPÍTULO 23 — CIRCUIT BREAKER: PARE DE BATER NA PORTA
Imagine uma API quebrada.
Primeira chamada:
FAILSegunda:
FAILMil agentes continuam chamando.
FAIL
FAIL
FAIL
FAIL
FAILEstamos atacando um sistema que já está doente.
Circuit breaker usa a analogia de um disjuntor.
CLOSED
Chamadas passam.
Muitas falhas aparecem.
OPEN
Paramos temporariamente de chamar.
Depois:
HALF-OPEN
Testamos algumas chamadas.
Se voltou:
CLOSEDSe continua ruim:
OPENIsso protege tanto o consumidor quanto o serviço problemático.
🔁 CAPÍTULO 24 — RETRY ONLINE É MAIS PERIGOSO DO QUE PARECE
No batch:
retry after 30 secondspode ser aceitável.
Na tela:
retry 30 secondssignifica:
O usuário está olhando para uma bolinha girando há meio minuto.
Precisamos de políticas diferentes.
Talvez:
FAST RETRY
1 tentativaDepois:
FALLBACKou:
ASYNC CONTINUATIONCada retry consome o orçamento de latência.
Não pense apenas:
Quantas tentativas posso fazer?
Pergunte:
Quantas tentativas cabem antes de a experiência humana morrer?
👤 CAPÍTULO 25 — HUMAN-IN-THE-LOOP É UMA TRANSAÇÃO CONVERSACIONAL
Imagine:
AGENT:
"Detectei alteração de limite para R$ 50.000.
Autoriza?"O agente não deveria:
BEGIN TRANSACTION
LOCK CUSTOMER
WAIT HUMAN 2 HOURS😂
Deveria:
VALIDATE
↓
SAVE REQUEST
↓
RELEASE RESOURCES
↓
WAIT APPROVALQuando chega:
APPROVEDfazemos nova validação.
Porque o mundo pode ter mudado enquanto esperávamos.
RELOAD
REVALIDATE
AUTHORIZE
EXECUTE
COMMITIsso é extremamente importante.
A aprovação humana não congela o universo.
🧠 CAPÍTULO 26 — CONTEXTO VELHO É UM MONSTRO SILENCIOSO
Às 10:00 o agente analisa:
BALANCE = 10,000Pede aprovação.
Humano responde às 10:20.
Mas agora:
BALANCE = 2,000O agente não pode simplesmente continuar baseado no snapshot antigo.
Precisamos distinguir:
CONVERSATION CONTEXTde:
CURRENT BUSINESS STATE.Antes de ação crítica:
REVALIDATE.
Esse princípio vale ouro.
📜 CAPÍTULO 27 — PSEUDO-CONVERSATIONALIDADE PARA AGENTES
Podemos desenhar um padrão.
INTERAÇÃO 1
USER REQUEST
↓
AGENT EXECUTES
↓
NEEDS APPROVAL
↓
SAVE STATE
↓
RETURN "WAITING APPROVAL"
↓
ENDNenhum processo fica preso.
Depois:
INTERAÇÃO 2
APPROVAL EVENT
↓
LOAD STATE
↓
REVALIDATE
↓
CONTINUE
↓
COMMIT
↓
ENDIsso é praticamente uma versão moderna da filosofia pseudo-conversational.
O programa não fica esperando.
O estado espera.
Que frase bonita:
O processo termina; o estado permanece.
🖥️ CAPÍTULO 28 — COMO SERIA O “CICS DOS AGENTES”?
Imagine:
AI TRANSACTION MONITOR
──────────────────────────────────────────────
TRAN AGENT USER ELAPSED STATE
A001 CUSTOMER U104 0.4s EXEC
A002 FRAUD U992 0.8s EXEC
A003 SUPPORT U441 1.2s LLM
A004 CREDIT U827 2.8s TOOL
A005 CONTRACT U221 4.9s ASYNCSelecionamos:
A004Aparece:
TRANSACTION.... A004
AGENT.......... CREDIT
USER........... U827
LATENCY BUDGET. 3.0s
ELAPSED........ 2.8s
LLM............ 1.4s
DB2............ 0.3s
API............ 0.7s
OTHER.......... 0.4s
CURRENT STATE.. TOOL_CALL
LOCKS.......... 0
UOW............ NONEO sistema já percebe:
BUDGET ALMOST EXHAUSTEDEntão talvez:
SWITCH TO ASYNCEssa é a UX que agentes corporativos precisarão.
📊 CAPÍTULO 29 — MÉTRICAS DO CICS DOS AGENTES
No SDSF dos agentes medimos:
runs
errors
tokens
toolsNo mundo interativo precisamos enfatizar:
p50 latency
p95 latency
p99 latency
timeout rate
abandonment rate
retry rate
lock wait
Db2 time
LLM time
tool time
async conversion rateUma métrica particularmente interessante:
USER ABANDONMENTQuantos usuários desistiram antes da resposta?
Porque tecnicamente o agente pode estar:
100% SUCCESSenquanto metade dos clientes fechou a página antes de receber o resultado.
MAXCC 0000.
Negócio 0012.
😂
📈 CAPÍTULO 30 — THROUGHPUT TAMBÉM IMPORTA
Não basta responder rapidamente uma transação.
Precisamos responder rapidamente:
10
100
1.000
10.000transações simultâneas.
Uma operação que funciona maravilhosamente com:
1 usuáriopode desmoronar com:
5.000 usuários.Por isso precisamos considerar:
LATENCY
+
THROUGHPUT
+
CONCURRENCYUma aplicação transacional é um exercício de equilíbrio.
🚪 CAPÍTULO 31 — O AGENTE NÃO DEVERIA TER ACESSO ILIMITADO À TRANSAÇÃO
RACF volta à história.
Nosso agente de atendimento talvez possa:
READ CUSTOMER
READ ORDERS
CREATE CASEmas não:
DELETE CUSTOMER
TRANSFER MONEY
CHANGE RACFO princípio de least privilege continua valendo.
E operações mais perigosas podem exigir:
HUMAN APPROVALou:
STEP-UP AUTHORIZATION.CICS não substitui RACF.
Assim como velocidade não substitui segurança.
🛡️ CAPÍTULO 32 — VELOCIDADE NÃO JUSTIFICA REMOVER CONTROLES
Uma tentação perigosa:
Aprovação humana demora. Vamos remover.
Não.
Talvez o fluxo precise ser melhor projetado.
Por exemplo:
LOW RISK
↓
AUTO APPROVEMEDIUM RISK
↓
ADDITIONAL VALIDATIONHIGH RISK
↓
HUMAN APPROVALAssim usamos risco para definir o caminho.
Não removemos segurança apenas para melhorar latência.
🧰 CAPÍTULO 33 — PASSO A PASSO PARA PROJETAR UMA TRANSAÇÃO COM AGENTE
Antes de colocar IA numa tela interativa, responda:
1. Qual é o orçamento total de latência?
2s?
5s?
10s?2. Quanto o agente pode consumir?
TOTAL = 3s
AGENT = 1.5s3. Quais ferramentas ele pode chamar?
Evite permitir chamadas ilimitadas.
4. Existe fallback?
model smaller?
cached result?
rule engine?
async continuation?5. Quais operações alteram estado?
Liste:
INSERT
UPDATE
DELETE
external action6. Onde estão as fronteiras transacionais?
Defina:
BEGIN
COMMIT
ROLLBACK7. Existem locks?
Pergunte:
Quanto tempo ficam presos?
8. Existe espera humana?
Se sim:
persist state
release resources
resume later9. O contexto precisa ser revalidado?
Quase sempre para operações críticas.
10. Retry é seguro?
Pense em idempotência.
11. Existe timeout?
Sempre deveria existir alguma política de limite.
12. O trabalho pode virar assíncrono?
Essa pergunta pode salvar sua UX.
🥚 EASTER EGG — O LOCK MAIS CARO DA HISTÓRIA
São 14:32.
O painel começa a ficar vermelho.
DB2 LOCK WAIT
DB2 LOCK WAIT
DB2 LOCK WAIT
DB2 LOCK WAITTuring aparece.
— Quem está segurando o lock?
O operador procura.
TRANSACTION..... AI42
AGENT........... CUSTOMER-ANALYSIS
LOCK AGE........ 00:17:38Turing quase derruba o café.
— Dezessete minutos?!
— Sim.
— O que ele está fazendo?
Abrem o trace.
STEP 1 DB2 UPDATE
STEP 2 CALL LLM
STEP 3 WEB SEARCH
STEP 4 ANALYZE 47 PDFs
STEP 5 WAIT HUMAN APPROVALSilêncio absoluto no CPD.
Turing pergunta:
— Ele está esperando aprovação humana segurando um lock de Db2?
O jovem programador responde baixinho:
— Tecnicamente...
O administrador Db2 levanta lentamente da cadeira.
Do outro lado da sala, o administrador RACF fecha a porta.
O pequeno robô tenta se esconder atrás do rack.
Turing aponta para a tela:
ROLLBACK.Depois escreve no quadro:
NÃO FAÇA ISSO.
Fim do easter egg.
🧬 CAPÍTULO 34 — NOSSA ARQUITETURA ESTÁ GANHANDO VIDA
Agora temos:
JES2 DOS AGENTES
↓
trabalho assíncronoWLM DOS AGENTES
↓
prioridade e recursosCICS DOS AGENTES
↓
interação rápidaRACF DOS AGENTES
↓
autoridadeSDSF DOS AGENTES
↓
visibilidadePF3 DOS AGENTES
↓
interrupçãoMAXCC DOS AGENTES
↓
resultadoCada conceito responde a uma pergunta.
🏰 CAPÍTULO 35 — O SISTEMA OPERACIONAL CONCEITUAL DOS AGENTES
Turing desenha:
HUMANO
│
▼
┌───────────────┐
│ REQUEST / TASK│
└───────┬───────┘
│
┌────────┴────────┐
│ │
▼ ▼
INTERATIVO ASSÍNCRONO
│ │
▼ ▼
┌───────┐ ┌───────┐
│ CICS │ │ JES2 │
└───┬───┘ └───┬───┘
│ │
└────────┬────────┘
▼
WLM
│
▼
RACF
│
▼
AGENT
│
┌─────────┼─────────┐
▼ ▼ ▼
LLM Db2 TOOLSAo redor:
SDSF → OBSERVE
PF3 → STOP
MAXCC → VERIFY
CHECKPOINT → RESUME
AUDIT → PROVEIsso já parece uma arquitetura operacional completa.
🧠 CAPÍTULO 36 — O PROGRAMADOR COBOL POSSUI UMA VANTAGEM ESTRANHA
Quando alguém fala:
AI agentsparece que tudo é novo.
Mas um programador COBOL que conhece sistemas transacionais já possui intuições valiosas.
Ele sabe que:
recurso é finitoSabe que:
lock custaSabe que:
transação longa é perigosaSabe que:
commit importaSabe que:
rollback salva vidasSabe que:
usuário não deveria manter programa preso enquanto pensaSabe que:
estado precisa sobreviver entre interaçõesSabe que:
concorrência cria problemas que não aparecem no teste unitárioSabe que:
MAXCC=0000não necessariamente significa que o cliente ficou feliz.
Tudo isso será extraordinariamente útil no mundo dos agentes.
☕ EPÍLOGO — PROCESSING...
O relógio marca:
16:47:01Um usuário pergunta:
Qual é a situação do meu pedido?
O agente recebe.
16:47:01.100Consulta contexto.
16:47:01.280Busca pedido.
16:47:01.510Consulta Db2.
16:47:01.790Chama modelo.
16:47:02.620O agente percebe que precisa de uma análise longa.
Olha para seu orçamento:
LATENCY BUDGET
3.0 s
ELAPSED
1.62 sAntigamente ele continuaria.
Mais ferramentas.
Mais buscas.
Mais raciocínio.
Mais espera.
Mas agora aprendeu.
Responde:
Encontrei seu pedido. A situação básica está normal. Uma análise detalhada exige mais tempo; vou processá-la em segundo plano e avisá-lo quando terminar.
Tempo total:
2.1 sDepois:
SUBMIT AGENT-DEEP-ANALYSIS
RUN-ID A009821O trabalho entra no nosso:
JES2 DOS AGENTES.O WLM classifica.
O RACF limita.
O SDSF observa.
O checkpoint preserva.
E o usuário continua sua vida.
Turing toma um gole de café.
— Agora você entendeu.
O robô pergunta:
— Entendi o quê?
— Que inteligência não significa responder tudo imediatamente.
— Então o que significa?
— Saber também quando uma tarefa deixou de ser uma transação e virou um job.
O jovem COBOL olha para o quadro.
Ali estava escrita toda a história:
CICS
↓
RESPONDA AGORA
JES2
↓
TRABALHE DEPOISE entre os dois:
DECIDA.Talvez essa seja uma das arquiteturas mais importantes para agentes corporativos.
Porque haverá tarefas que precisam responder em:
300 msOutras em:
3 segundosOutras em:
3 minutosE algumas podem levar:
3 horas.O erro será tentar tratar todas da mesma maneira.
Um agente realmente operacional precisa entender:
tempo,
contexto,
concorrência,
consistência,
risco,
custo,
e expectativa humana.
O futuro da IA empresarial talvez não seja simplesmente:
agentes cada vez mais inteligentes.
Talvez seja:
agentes inteligentes o bastante para saber quanto tempo podem ocupar uma transação.
No terminal:
TRANSACTION AI01
RESPONSE TIME.... 1.82s
DB2 TIME......... 0.21s
LLM TIME......... 0.93s
LOCK WAIT........ 0.00s
UOW.............. COMMITTED
ASYNC JOB........ NONE
STATUS............ SUCCESSTuring olha para o programador.
— E agora?
O programador responde:
— Agora café.
Turing concorda.
Porque até num sistema online existe uma transação que jamais deveria sofrer timeout.
EXEC CICS
START
TRANSID('CAFE')
END-EXEC.READY
