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:03

Na tela de um terminal havia uma mensagem:

PROCESSING...

Turing tomou um gole de café.

10:14:08

Nada.

10:14:15

Nada.

10:14:31

Ainda:

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 AGENTES

A ideia era fantástica para processamento assíncrono.

O usuário submete:

AGENT-CONTRACT-ANALYSIS

recebe:

RUN-ID A004821

e pode ir tomar café.

O agente pode executar:

agora
daqui a cinco minutos
durante a madrugada

Não importa tanto.

Mas agora imagine:

CLIENTE
   ↓
TELA
   ↓
"CONSULTAR SALDO"

Ele clicou.

Está esperando.

Temos outro tipo de trabalho.

INTERATIVO

E 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 System

Para 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
↓
OUTPUT

temos algo mais próximo de:

REQUEST
↓
TRANSACTION
↓
PROGRAM
↓
DATA
↓
RESPONSE

Rapidamente.

Milhares ou milhões de vezes.

Uma transação pode:

consultar cliente
alterar pedido
autorizar pagamento
verificar estoque
registrar operação

O 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 resultado

Se isso estiver num processamento batch:

45 segundos

pode ser perfeitamente aceitável.

Se estiver numa tela de atendimento:

45 segundos

pode 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 ms

Excelente.

Agora:

3 segundos

Talvez aceitável.

Agora:

12 segundos

O usuário começa a desconfiar.

Agora:

45 segundos

Talvez já esteja clicando novamente.

Agora:

2 minutos

Ele abriu outra aba.

Agora:

5 minutos

Ele foi fazer café.

O problema não é apenas tecnológico.

É UX.

Portanto precisamos pensar em:

TIME BUDGET

Imagine que nossa experiência tenha:

TOTAL BUDGET = 3 s

Esse 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 ms

Se o agente gastar sozinho:

8 segundos

nã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
money

Agora adicionamos:

PACIÊNCIA HUMANA

Ela também é finita.

Podemos imaginar:

LATENCY BUDGET

como um recurso.

Cada componente gasta um pedaço.

Usuário
  ↓ 100 ms
Gateway
  ↓ 150 ms
Agent
  ↓ 900 ms
Db2
  ↓ 200 ms
CICS
  ↓ 300 ms
Response

Total:

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ínio

Mas numa interação online existe limite.

Podemos estabelecer:

MAX_TOOL_CALLS = 3
MAX_AGENT_TIME = 1500 ms

Se não conseguir concluir:

FALLBACK

Talvez:

"Preciso de uma análise mais profunda.
Posso continuar em segundo plano?"

Agora fazemos uma transformação elegante:

ONLINE
↓
ASYNC

Ou 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
 ↓
RESPONSE

Limite:

2 segundos

Se a tarefa exigir mais:

SLOW PATH

USER
 ↓
SUBMIT
 ↓
RUN-ID
 ↓
QUEUE
 ↓
BACKGROUND AGENT

A interface responde:

Análise aprofundada iniciada.
RUN-ID: A004821

Depois 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
     ↓
TERMINA

Quando o usuário responde:

nova transação

começ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 segundos

ou:

10 minutos

ou:

10 horas.

Seria absurdo manter:

LLM session
thread
Db2 connection
transaction
lock

abertos durante esse tempo.

Melhor:

SAVE STATE
↓
WAITING_APPROVAL
↓
RELEASE RESOURCES

Quando o humano aprovar:

APPROVAL EVENT
↓
RESUME

O 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-ACTION

E terminar a execução corrente.

Quando houver nova interação:

LOAD CONTEXT
↓
CONTINUE

Isso 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 B

Se fizer apenas o primeiro:

A = -100

e cair antes do segundo...

temos problema.

Queremos:

TUDO

ou:

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 WORK

ou UOW.

Exemplo:

BEGIN UOW

UPDATE ACCOUNT-A
UPDATE ACCOUNT-B
INSERT AUDIT

END UOW

Se tudo funcionar:

COMMIT

Se alguma coisa falhar:

ROLLBACK

Para 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 = 1000

O agente executa:

UPDATE

Mas enquanto a transação ainda não confirmou definitivamente suas alterações, estamos dentro da unidade de trabalho.

Quando chegamos ao ponto seguro:

COMMIT

As mudanças tornam-se permanentes conforme a semântica do recurso transacional envolvido.

No universo CICS encontramos o conceito de:

SYNCPOINT

Um ponto de sincronização estabelece uma fronteira importante da unidade de trabalho.

Para nosso agente, a analogia é poderosa.

Antes:

PLANEJAR

Depois:

EXECUTAR

Depois:

VALIDAR

Finalmente:

COMMIT

---

↩️ CAPÍTULO 14 — ROLLBACK: DESFAÇA ANTES QUE ALGUÉM PERCEBA

Imagine:

STEP 1 OK
STEP 2 OK
STEP 3 FAILED

Se tudo pertence à mesma unidade transacional:

ROLLBACK

O 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 = 200

Muito 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 API

Depois:

PAYMENT API

Depois:

CRM API

Depois:

POST SOCIAL MEDIA

Como 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 ACTION

de:

IRREVERSIBLE / EXTERNAL ACTION

Agentes 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. Commit

O 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 externa

ou 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-B

Ambos leem:

STOCK = 1

A 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 X

Enquanto A altera X:

AGENT-B
WAIT

Depois:

AGENT-A
COMMIT
RELEASE LOCK

B pode continuar.

Isso protege consistência.

Mas locks possuem custo.

Quanto mais tempo seguramos um lock:

mais gente espera

Por 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 HELD

NÃ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
↓
COMMIT

Mas cuidado com alterações concorrentes.

Se você leu:

VERSION = 17

pensou 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 = 17

Faz seu processamento.

Ao atualizar:

UPDATE CUSTOMER
WHERE ID = 123
AND VERSION = 17

Se ninguém alterou:

SUCCESS

Se alguém alterou:

0 ROWS UPDATED

Agora sabemos:

Meu contexto ficou velho.

O agente precisa:

RELOAD
REVALIDATE
RETRY

em 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 CUSTOMER

Depois quer:

LOCK ACCOUNT

Mas B já possui ACCOUNT.

Enquanto isso:

AGENT-B
LOCK ACCOUNT

e quer:

LOCK CUSTOMER.

Temos:

A espera B
B espera A

Os 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:

DEADLOCK

nã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:

TIMEOUT

Se uma ferramenta deveria responder em:

500 ms

não faz sentido esperar:

17 minutos

Precisamos estabelecer limites.

DB TIMEOUT........ 1 s
API TIMEOUT....... 2 s
AGENT BUDGET...... 3 s
TOTAL REQUEST..... 5 s

Se ultrapassar:

STOP WAITING

E 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:

FAIL

Segunda:

FAIL

Mil agentes continuam chamando.

FAIL
FAIL
FAIL
FAIL
FAIL

Estamos 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:

CLOSED

Se continua ruim:

OPEN

Isso 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 seconds

pode ser aceitável.

Na tela:

retry 30 seconds

significa:

O usuário está olhando para uma bolinha girando há meio minuto.

Precisamos de políticas diferentes.

Talvez:

FAST RETRY
1 tentativa

Depois:

FALLBACK

ou:

ASYNC CONTINUATION

Cada 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 APPROVAL

Quando chega:

APPROVED

fazemos nova validação.

Porque o mundo pode ter mudado enquanto esperávamos.

RELOAD
REVALIDATE
AUTHORIZE
EXECUTE
COMMIT

Isso é 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,000

Pede aprovação.

Humano responde às 10:20.

Mas agora:

BALANCE = 2,000

O agente não pode simplesmente continuar baseado no snapshot antigo.

Precisamos distinguir:

CONVERSATION CONTEXT

de:

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"
↓
END

Nenhum processo fica preso.

Depois:

INTERAÇÃO 2

APPROVAL EVENT
↓
LOAD STATE
↓
REVALIDATE
↓
CONTINUE
↓
COMMIT
↓
END

Isso é 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     ASYNC

Selecionamos:

A004

Aparece:

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............ NONE

O sistema já percebe:

BUDGET ALMOST EXHAUSTED

Então talvez:

SWITCH TO ASYNC

Essa é a UX que agentes corporativos precisarão.

---

📊 CAPÍTULO 29 — MÉTRICAS DO CICS DOS AGENTES

No SDSF dos agentes medimos:

runs
errors
tokens
tools

No 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 rate

Uma métrica particularmente interessante:

USER ABANDONMENT

Quantos usuários desistiram antes da resposta?

Porque tecnicamente o agente pode estar:

100% SUCCESS

enquanto 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.000

transações simultâneas.

Uma operação que funciona maravilhosamente com:

1 usuário

pode desmoronar com:

5.000 usuários.

Por isso precisamos considerar:

LATENCY
+
THROUGHPUT
+
CONCURRENCY

Uma 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 CASE

mas não:

DELETE CUSTOMER
TRANSFER MONEY
CHANGE RACF

O princípio de least privilege continua valendo.

E operações mais perigosas podem exigir:

HUMAN APPROVAL

ou:

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 APPROVE

MEDIUM RISK
↓
ADDITIONAL VALIDATION

HIGH RISK
↓
HUMAN APPROVAL

Assim 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.5s

3. 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 action

6. Onde estão as fronteiras transacionais?

Defina:

BEGIN
COMMIT
ROLLBACK

7. Existem locks?

Pergunte:

Quanto tempo ficam presos?

8. Existe espera humana?

Se sim:

persist state
release resources
resume later

9. 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 WAIT

Turing aparece.

— Quem está segurando o lock?

O operador procura.

TRANSACTION..... AI42
AGENT........... CUSTOMER-ANALYSIS
LOCK AGE........ 00:17:38

Turing 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 APPROVAL

Silê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íncrono

WLM DOS AGENTES
↓
prioridade e recursos

CICS DOS AGENTES
↓
interação rápida

RACF DOS AGENTES
↓
autoridade

SDSF DOS AGENTES
↓
visibilidade

PF3 DOS AGENTES
↓
interrupção

MAXCC DOS AGENTES
↓
resultado

Cada 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       TOOLS

Ao redor:

SDSF → OBSERVE

PF3 → STOP

MAXCC → VERIFY

CHECKPOINT → RESUME

AUDIT → PROVE

Isso já parece uma arquitetura operacional completa.

---

🧠 CAPÍTULO 36 — O PROGRAMADOR COBOL POSSUI UMA VANTAGEM ESTRANHA

Quando alguém fala:

AI agents

parece que tudo é novo.

Mas um programador COBOL que conhece sistemas transacionais já possui intuições valiosas.

Ele sabe que:

recurso é finito

Sabe que:

lock custa

Sabe que:

transação longa é perigosa

Sabe que:

commit importa

Sabe que:

rollback salva vidas

Sabe que:

usuário não deveria manter programa preso enquanto pensa

Sabe que:

estado precisa sobreviver entre interações

Sabe que:

concorrência cria problemas que não aparecem no teste unitário

Sabe que:

MAXCC=0000

nã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:01

Um usuário pergunta:

Qual é a situação do meu pedido?

O agente recebe.

16:47:01.100

Consulta contexto.

16:47:01.280

Busca pedido.

16:47:01.510

Consulta Db2.

16:47:01.790

Chama modelo.

16:47:02.620

O agente percebe que precisa de uma análise longa.

Olha para seu orçamento:

LATENCY BUDGET
3.0 s

ELAPSED
1.62 s

Antigamente 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 s

Depois:

SUBMIT AGENT-DEEP-ANALYSIS
RUN-ID A009821

O 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 DEPOIS

E entre os dois:

DECIDA.

Talvez essa seja uma das arquiteturas mais importantes para agentes corporativos.

Porque haverá tarefas que precisam responder em:

300 ms

Outras em:

3 segundos

Outras em:

3 minutos

E 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............ SUCCESS

Turing 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