Bellacosa Mainframe e o funcionamento dos processos na ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

📮 ALAN TURING E O JES2 DOS AGENTES — QUEM DECIDE QUANDO A INTELIGÊNCIA ARTIFICIAL COMEÇA A TRABALHAR?

JES2, filas, submissão, scheduling, dependências, execução assíncrona, checkpoints, restart, retry, idempotência, dead-letter queues, workflows, agentes de IA, COBOL, JCL, Db2, CICS, MQ — e o dia em que Alan Turing descobriu que uma inteligência artificial também pode passar a madrugada inteira esperando o predecessor terminar.

---

🎬 PRÓLOGO — O AGENTE ESTAVA PRONTO

Alan Turing chegou ao CPD às 05:47.

O café ainda estava sendo preparado.

O operador examinava algumas telas.

O jovem programador COBOL dormia sobre um manual.

E um pequeno robô permanecia parado diante da porta da sala de processamento.

Turing olhou para ele.

— Algum problema?

— Nenhum.

— Está quebrado?

— Não.

— Sem recursos?

— Temos recursos.

— RACF?

— Autorizado.

— WLM?

— Classe STANDARD. Capacidade disponível.

— Então por que não está trabalhando?

O robô respondeu:

— Estou esperando.

Turing levantou uma sobrancelha.

— Esperando o quê?

O robô mostrou seu workflow:

AGENT-MONTHLY-REPORT

STATUS........ WAITING
PREDECESSOR... AGENT-CLOSE-ACCOUNTING
SCHEDULE...... AFTER 06:00
INPUT......... MONTH-END-FILE
CHECKPOINT.... NONE

Turing sorriu.

— Finalmente.

O programador acordou.

— Finalmente o quê?

— Vocês descobriram que estar apto a executar não significa que chegou a hora de executar.

Ele apontou para o terminal.

— Abra o JES2.

---

🏛️ CAPÍTULO 1 — O COMPUTADOR PRECISA RECEBER TRABALHO

Para um iniciante, parece natural pensar:

PROGRAMA
   ↓
EXECUTA

Mas em ambientes corporativos existe algo antes disso.

Precisamos dizer ao sistema:

Existe trabalho para fazer.

No universo batch do mainframe, isso historicamente envolve o conceito de job.

Um job representa uma unidade de trabalho submetida ao sistema.

Por exemplo:

//PAYROLL JOB ...
//STEP01  EXEC PGM=READTIME
//STEP02  EXEC PGM=CALCPAY
//STEP03  EXEC PGM=REPORT

Você não precisa ficar sentado diante do terminal esperando cada instrução terminar.

O job pode ser submetido.

Depois o sistema administra sua execução.

Essa diferença parece pequena.

Mas é gigantesca.

Temos:

INTERATIVO
Humano solicita
Humano espera
Resultado retorna

e:

ASSÍNCRONO
Humano/sistema submete
Trabalho entra no ambiente
Humano pode ir embora
Sistema executa depois
Resultado fica disponível

Agentes de IA inevitavelmente entrarão profundamente nesse segundo mundo.

---

📮 CAPÍTULO 2 — JES2 NÃO É SIMPLESMENTE “UM PROGRAMA QUE RODA JCL”

Vamos corrigir uma simplificação comum.

JCL é a linguagem usada para descrever muitos jobs batch no z/OS.

JES2 — Job Entry Subsystem 2 — participa da administração desse trabalho.

Pense no fluxo conceitual:

SUBMISSÃO
    ↓
  JES2
    ↓
ENTRADA / FILAS
    ↓
EXECUÇÃO
    ↓
OUTPUT

O job entra.

Recebe identidade.

É colocado nas estruturas apropriadas.

Espera quando necessário.

Executa quando elegível e quando os recursos necessários estão disponíveis.

Produz output.

Pode ser acompanhado operacionalmente.

Perceba que isso já parece muito com aquilo que precisamos para agentes.

---

🤖 CAPÍTULO 3 — UM AGENTE TAMBÉM PODE SER SUBMETIDO

Imagine uma aplicação corporativa.

Alguém pede:

Analise os 82 mil contratos da empresa e gere um relatório.

Não faz sentido manter uma página aberta mostrando:

PROCESSANDO...

durante seis horas.

Seria melhor transformar isso em uma unidade assíncrona:

SUBMIT AGENT

Ela recebe:

AGENT....... CONTRACT-ANALYSIS
RUN-ID...... A004821
OWNER....... LEGAL
CLASS....... BATCH
PRIORITY.... STANDARD
STATUS...... QUEUED

O usuário recebe:

Solicitação recebida.

RUN-ID: A004821

E pode continuar trabalhando.

O agente executará quando apropriado.

Acabamos de separar:

SUBMETER

de:

EXECUTAR

Essa separação é fundamental para sistemas escaláveis.

---

🪪 CAPÍTULO 4 — TODO TRABALHO PRECISA DE IDENTIDADE

No mainframe, quando submetemos um job, identidade importa.

Algo semelhante será indispensável para agentes.

Não basta:

AGENT-REPORT

porque ele pode estar executando mil vezes.

Precisamos distinguir:

AGENT-REPORT
RUN A0001

de:

AGENT-REPORT
RUN A0002

Assim podemos perguntar:

Quem solicitou?
Quando?
Com quais parâmetros?
Qual versão?
Qual modelo?
Quais ferramentas?
Qual estado?
Qual resultado?

Imagine:

AGENT....... REPORT
RUN-ID...... A000471
REQUESTER... VAGNER
SUBMITTED... 06:14:22
STATUS...... QUEUED
CLASS....... STANDARD

O RUN-ID começa a desempenhar papel conceitualmente parecido com um JOBID.

Não são tecnicamente a mesma coisa.

Mas a ponte mental é excelente.

---

🚉 CAPÍTULO 5 — SUBMETIDO NÃO SIGNIFICA EXECUTANDO

Essa é uma das primeiras coisas que o programador batch aprende.

Você submete.

SUB

E isso não significa:

CPU imediatamente!

O job pode estar aguardando.

Nos agentes:

SUBMITTED
    ↓
QUEUED
    ↓
ELIGIBLE
    ↓
STARTING
    ↓
RUNNING
    ↓
COMPLETED

Ou:

RUNNING
   ↓
WAITING

Ou:

RUNNING
   ↓
FAILED

Ou:

RUNNING
   ↓
PAUSED

Isso nos leva a uma ideia essencial:

ESTADO.

O agente não está simplesmente:

ON

ou:

OFF

Ele percorre um ciclo de vida.

---

🚦 CAPÍTULO 6 — QUEM DECIDE QUANDO COMEÇA?

Agora chegamos à pergunta do milhão.

Temos:

500 agentes submetidos

Todos autorizados.

Todos válidos.

Todos querem executar.

Quem começa?

Aqui entram várias dimensões.

prioridade
classe
horário
dependências
capacidade
recursos
quota
SLO
deadline
políticas

Nosso artigo anterior sobre WLM já discutiu:

Quem merece recursos?

Agora aparece uma pergunta anterior:

Quem está elegível para entrar em execução?

Isso é scheduling.

---

⏰ CAPÍTULO 7 — NEM TODO TRABALHO DEVE COMEÇAR AGORA

Imagine um agente:

AGENT-BACKUP

Ele poderia executar às 14:00.

Mas talvez seja melhor:

02:00

Outro:

AGENT-DAILY-REPORT

deve começar:

AFTER 23:59

Outro:

AGENT-MONTH-END

somente:

LAST BUSINESS DAY

Outro:

AGENT-INVOICE

depois que:

SALES-CLOSE

terminar.

Portanto scheduling não significa apenas:

RODE ÀS 18:00.

Pode significar:

execute quando
tempo
+
dependências
+
recursos
+
políticas
forem satisfeitos

---

🔗 CAPÍTULO 8 — DEPENDÊNCIAS: O AGENTE NÃO VIVE SOZINHO

Imagine este fluxo:

FECHA-VENDAS
     ↓
CONSOLIDA-DADOS
     ↓
GERA-RELATÓRIO
     ↓
VALIDA
     ↓
DISTRIBUI

O terceiro não pode executar antes do segundo.

O segundo depende do primeiro.

Temos um workflow.

Em sistemas modernos isso frequentemente é representado como um grafo.

Por exemplo:

        A
       / \
      B   C
       \ /
        D
        |
        E

B e C podem executar depois de A.

D só pode executar quando ambos terminarem.

E depende de D.

Isso é um DAG quando o grafo é direcionado e não possui ciclos.

Directed Acyclic Graph.

Uma estrutura extremamente comum em orquestração de workflows.

---

🧙 CAPÍTULO 9 — O JCL JÁ ENSINAVA DEPENDÊNCIA DENTRO DO JOB

Considere:

//STEP01 EXEC PGM=EXTRACT
//STEP02 EXEC PGM=TRANSFORM
//STEP03 EXEC PGM=REPORT

Existe uma ordem natural.

Mas também podemos condicionar execução.

Conceitualmente:

SE STEP01 FUNCIONOU
    EXECUTA STEP02

e depois:

SE STEP02 FUNCIONOU
    EXECUTA STEP03

Isso não é muito diferente da lógica de workflows modernos.

Podemos imaginar:

AGENT STEP 1
Extract data

AGENT STEP 2
Analyze data

AGENT STEP 3
Generate report

AGENT STEP 4
Human approval

AGENT STEP 5
Send report

De repente o velho batch começa a parecer surpreendentemente moderno.

---

🔀 CAPÍTULO 10 — O AGENTE PODE ESCOLHER CAMINHOS

Aqui surge uma diferença interessante.

Um workflow tradicional pode ser relativamente previsível.

A → B → C

Um agente pode decidir:

A
↓
Preciso de informação?
├── SIM → B → Search
└── NÃO → C

Depois:

Resultado suficiente?
├── SIM → D
└── NÃO → Search novamente

Isso significa que o workflow pode ser parcialmente dinâmico.

Por isso precisamos distinguir:

ORQUESTRAÇÃO

de:

RACIOCÍNIO DO AGENTE

A infraestrutura pode impor limites.

O agente escolhe ações dentro desses limites.

---

🎼 CAPÍTULO 11 — ORQUESTRAÇÃO: O MAESTRO NÃO TOCA TODOS OS INSTRUMENTOS

Imagine uma orquestra.

O maestro não toca:

violino
piano
trompete
bateria

simultaneamente.

Ele coordena.

Um orquestrador de agentes pode coordenar:

AGENT-RESEARCH
AGENT-CODE
AGENT-SECURITY
AGENT-REVIEW

Por exemplo:

RESEARCH
    ↓
CODE
    ↓
SECURITY
    ↓
REVIEW

Ou:

             ┌→ SECURITY ─┐
CODE ────────┤            ├→ REVIEW
             └→ TEST ─────┘

O orquestrador decide:

quando iniciar
quando esperar
quando repetir
quando falhar
quando cancelar

Isso é muito diferente de simplesmente chamar um chatbot.

---

💥 CAPÍTULO 12 — E SE O AGENTE FALHAR NO PASSO 87?

Imagine:

100 passos

O agente executa:

1
2
3
...
86
87

E então:

💥

Erro.

Temos duas possibilidades.

Estratégia A

VOLTA PARA O PASSO 1

Parabéns.

Você acaba de desperdiçar horas e dinheiro.

Estratégia B

RESTART FROM CHECKPOINT

Agora entramos em território extremamente familiar ao mainframe.

---

💾 CAPÍTULO 13 — CHECKPOINT: MARQUE ONDE CHEGOU

Checkpoint significa guardar estado suficiente para permitir continuação ou recuperação.

Imagine:

STEP 10
CHECKPOINT

STEP 20
CHECKPOINT

STEP 30
CHECKPOINT

Se falhar no 27:

RESTART
FROM CHECKPOINT 20

Em agentes:

CHECKPOINT
run_id=A004821
step=20
documents_processed=42000
cursor=42001
state=VALID

Depois de uma falha:

RESUME A004821

O sistema sabe de onde continuar.

Isso pode economizar:

tempo
tokens
API calls
CPU
dinheiro

---

♻️ CAPÍTULO 14 — RESTART NÃO É SIMPLESMENTE “RODE DE NOVO”

Aqui mora um monstro.

Imagine um agente fazendo:

STEP 1
Ler pedido

STEP 2
Cobrar cartão

STEP 3
Atualizar banco

STEP 4
Enviar e-mail

Ele cobra o cartão.

Depois cai.

Você simplesmente reinicia.

STEP 1
STEP 2

Parabéns.

Você pode cobrar novamente.

Por isso precisamos falar de:

IDEMPOTÊNCIA.

---

🧮 CAPÍTULO 15 — IDEMPOTÊNCIA: EXECUTAR DUAS VEZES SEM FAZER BESTEIRA

Uma operação idempotente pode ser repetida sem alterar o resultado além do efeito pretendido.

Exemplo simples:

SET STATUS = 'PAID'

Executar duas vezes continua deixando:

STATUS = PAID

Mas:

ADD 100 TO BALANCE

executado duas vezes produz efeito duplicado.

Em integrações modernas podemos usar:

IDEMPOTENCY-KEY

Por exemplo:

PAYMENT-ID = 918273

Antes de processar:

Já processei PAYMENT-ID 918273?

Se sim:

NÃO REPETIR.

Para agentes com capacidade de executar ações externas, isso é fundamental.

---

📨 CAPÍTULO 16 — MENSAGEM TAMBÉM PODE SER TRABALHO

Agora entre no mundo da mensageria.

Um sistema coloca:

MESSAGE

em uma fila.

Outro sistema consome.

PRODUCER
    ↓
   QUEUE
    ↓
CONSUMER

O produtor não precisa esperar o consumidor terminar.

Isso permite desacoplamento.

MQ já ensina essa filosofia há décadas.

E agentes podem funcionar da mesma maneira.

USER
 ↓
TASK QUEUE
 ↓
AGENT WORKER
 ↓
RESULT QUEUE

Isso é especialmente útil para processamento assíncrono.

---

☠️ CAPÍTULO 17 — DEAD-LETTER QUEUE: O CEMITÉRIO DAS MENSAGENS PROBLEMÁTICAS

Imagine uma tarefa que sempre falha.

TRY 1 → FAIL
TRY 2 → FAIL
TRY 3 → FAIL
TRY 4 → FAIL

Não podemos repetir eternamente.

Senão criamos:

RETRY
RETRY
RETRY
RETRY
RETRY

até o Sol explodir.

Depois de determinado limite:

MOVE TO DLQ

DLQ:

DEAD-LETTER QUEUE.

É uma fila para mensagens ou tarefas que não puderam ser processadas normalmente.

Agora alguém pode investigar.

RUN-ID...... A004821
ERROR....... INVALID DOCUMENT
RETRIES..... 5
STATUS...... DEAD-LETTER

Isso é muito melhor que perder silenciosamente a tarefa.

---

🔥 CAPÍTULO 18 — RETRY PRECISA TER CÉREBRO

Já discutimos retry storm no WLM dos agentes.

Aqui ele volta.

Nunca pense:

FAIL
↓
RETRY IMMEDIATELY FOREVER

Prefira políticas.

TRY 1
↓
WAIT 1s

TRY 2
↓
WAIT 2s

TRY 3
↓
WAIT 4s

TRY 4
↓
WAIT 8s

Isso é exponential backoff.

Acrescente jitter para evitar milhares de agentes retornando exatamente no mesmo instante.

E estabeleça:

MAX-RETRIES

Depois disso:

FAIL
ESCALATE
DLQ

Máquinas precisam saber desistir.

---

🧠 CAPÍTULO 19 — “ESPERANDO” PRECISA EXPLICAR O MOTIVO

No nosso SDSF dos agentes, aprendemos que:

WAITING

é pouco informativo.

Agora podemos ser específicos:

WAITING_TIME

WAITING_PREDECESSOR

WAITING_RESOURCE

WAITING_APPROVAL

WAITING_RATE_LIMIT

WAITING_RETRY

WAITING_EVENT

Veja a diferença.

Antes:

AGENT REPORT
WAITING

Agora:

AGENT REPORT
WAITING_PREDECESSOR

PREDECESSOR:
AGENT ACCOUNTING-CLOSE

SINCE:
05:47:12

O operador finalmente sabe por que o robô está sentado tomando café.

---

📅 CAPÍTULO 20 — EVENTO PODE SER MAIS IMPORTANTE QUE HORÁRIO

Nem todo processamento deveria ser:

EXECUTE 22:00

Talvez devesse ocorrer quando:

arquivo chegou

ou:

mensagem apareceu

ou:

pedido foi aprovado

ou:

saldo caiu abaixo do limite

Temos:

TIME-DRIVEN

versus:

EVENT-DRIVEN

Um agente moderno pode acordar porque:

EVENT
↓
TRIGGER
↓
AGENT RUN

Exemplo:

NEW CONTRACT UPLOADED
        ↓
AGENT-CONTRACT-REVIEW

Isso evita polling desnecessário.

---

💤 CAPÍTULO 21 — AGENTE PARADO NÃO PRECISA CONSUMIR UMA THREAD ETERNAMENTE

Imagine um workflow esperando aprovação humana por três dias.

Seria absurdo manter:

process
thread
connection
memory

presos durante três dias.

Melhor persistir o estado:

RUN-ID........ A00123
STATE......... WAITING_APPROVAL
CHECKPOINT.... SAVED

E liberar recursos.

Quando a aprovação chegar:

EVENT APPROVED

o workflow é retomado.

Essa é uma característica importante de sistemas assíncronos duráveis.

Esperar não deveria necessariamente significar ficar executando enquanto espera.

---

🏷️ CAPÍTULO 22 — O JES2 DOS AGENTES PRECISA DE UMA FILA VISÍVEL

Vamos imaginar nosso painel.

AI JOB ENTRY SYSTEM
────────────────────────────────────────────────────────

RUN-ID    AGENT          CLASS       STATE
A00471    FRAUD          CRITICAL    EXEC
A00472    REPORT         STANDARD    INPUT
A00473    ARCHIVE        BACKGROUND  QUEUED
A00474    CONTRACT       BATCH       EXEC
A00475    MONTH-END      BATCH       WAIT-PRED
A00476    SUPPORT        INTERACT    WAIT-RETRY

Selecionamos:

A00475

E vemos:

AGENT........ MONTH-END
OWNER........ FINANCE
SUBMITTED.... 05:41:22
CLASS........ BATCH
STATUS....... WAITING_PREDECESSOR

PREDECESSOR:
ACCOUNTING-CLOSE

SCHEDULE:
AFTER 06:00

CHECKPOINT:
NONE

RETRIES:
0

Agora temos algo operacionalmente útil.

---

🧙 CAPÍTULO 23 — TURING DESENHA O CICLO DO TRABALHO

Turing pega o giz.

Escreve:

CRIAR
  ↓
SUBMETER
  ↓
CLASSIFICAR
  ↓
COLOCAR NA FILA
  ↓
VERIFICAR ELEGIBILIDADE
  ↓
AGENDAR
  ↓
EXECUTAR
  ↓
CHECKPOINT
  ↓
CONCLUIR

Mas adiciona:

            ┌──── FAIL ────┐
            ↓              │
         RETRY             │
            ↓              │
       CHECKPOINT?         │
       ↙         ↘         │
     SIM         NÃO       │
      ↓           ↓        │
   RESUME      RESTART     │
      │           │        │
      └───────────┴────────┘

E depois:

MAX RETRIES EXCEEDED
        ↓
       DLQ
        ↓
 HUMAN / AUTOMATED REVIEW

O jovem COBOL observa.

— Isso está começando a parecer um sistema operacional para robôs.

Turing responde:

— Exatamente.

---

🏰 CAPÍTULO 24 — JES2 E WLM NÃO RESPONDEM À MESMA PERGUNTA

Aqui precisamos evitar outra simplificação.

Não diga:

JES2 = WLM

São papéis diferentes.

Pedagogicamente podemos pensar:

JES2

Ajuda a administrar a entrada e o fluxo de jobs.

Pergunta:

Que trabalho existe e onde ele está no ciclo?

WLM

Gerencia workloads segundo objetivos e políticas de serviço.

Pergunta:

Como devemos administrar recursos para cumprir objetivos?

No nosso mundo dos agentes:

JES2 DOS AGENTES
↓
submissão
fila
elegibilidade
scheduling
output
estado

enquanto:

WLM DOS AGENTES
↓
classe
objetivo
prioridade
capacidade
concorrência
throttling

Os dois trabalham juntos.

---

🔐 CAPÍTULO 25 — E O RACF?

Também continua lá.

Antes de executar:

AGENT wants TOOL-X

precisamos saber:

AUTHORIZED?

Portanto nossa arquitetura começa a ficar interessante:

         TASK
          ↓
        JES2
          ↓
       ELIGIBLE?
          ↓
         WLM
          ↓
     RESOURCE?
          ↓
        RACF
          ↓
    AUTHORIZED?
          ↓
       EXECUTE

Não interprete literalmente essa ordem como arquitetura interna do z/OS.

Estamos construindo uma analogia didática.

Mas ela é poderosa.

Cada componente responde a uma pergunta diferente.

---

🛑 CAPÍTULO 26 — E O PF3?

O agente começou.

Depois percebemos:

ELE ESTÁ FAZENDO BESTEIRA.

Precisamos:

PAUSE
CANCEL
STOP

Nosso PF3 conceitual.

Portanto:

JES2
Quem entra?

WLM
Quem recebe recursos?

RACF
Quem pode fazer?

SDSF
O que está fazendo?

PF3
Posso parar?

MAXCC
Funcionou?

Estamos montando uma espécie de mainframe mental para governança de agentes.

---

🔄 CAPÍTULO 27 — O CHECKPOINT DOS AGENTES NÃO É APENAS UM NÚMERO

Em agentes complexos, talvez precisemos guardar:

workflow state
completed steps
pending steps
tool results
references
cursor
approvals
business identifiers
retry count

Mas cuidado.

Não precisamos necessariamente persistir tudo que passou pela “cabeça” do modelo.

Devemos persistir estado operacional necessário para retomar a execução.

Essa distinção importa.

O objetivo é:

RESUMABILITY

não:

GRAVAR CADA PENSAMENTO PARA SEMPRE

Além de desnecessário, isso pode criar problemas de privacidade, segurança e custo.

---

📦 CAPÍTULO 28 — OUTPUT TAMBÉM PRECISA DE CICLO DE VIDA

O agente terminou.

Excelente.

E agora?

Resultado:

REPORT.PDF

ou:

JSON

ou:

DATABASE UPDATE

ou:

MESSAGE

ou:

EMAIL DRAFT

Precisamos registrar:

onde está
quem pode acessar
quanto tempo guardar
qual versão
qual execução produziu

No batch tradicional, output sempre foi parte importante da operação.

Nos agentes também será.

Uma resposta na tela não é suficiente para workflows empresariais.

Precisamos de proveniência.

---

🔎 CAPÍTULO 29 — PROVENIÊNCIA: QUEM PRODUZIU ISSO?

Imagine encontrar:

RELATORIO-FINAL.PDF

Perguntas:

Qual agente gerou?
Qual execução?
Qual modelo?
Quais documentos foram usados?
Qual versão do workflow?
Quem solicitou?
Quem aprovou?
Quando?

Podemos guardar:

OUTPUT-ID..... O88271
RUN-ID........ A004821
AGENT......... CONTRACT-ANALYSIS
VERSION....... 3.8
CREATED....... 14:22:01
APPROVED-BY... USER72

Isso conecta:

OUTPUT

à:

EXECUÇÃO

e à:

AUDITORIA.

---

⚠️ CAPÍTULO 30 — EXACTLY ONCE É MAIS DIFÍCIL DO QUE PARECE

Em sistemas distribuídos, uma pergunta aparentemente simples:

Essa tarefa executou exatamente uma vez?

pode se tornar surpreendentemente difícil.

Imagine:

AGENT
↓
API
↓
ACTION EXECUTED

Mas a resposta da API se perde.

O agente pensa:

Falhou.

E repete.

Só que a primeira operação tinha funcionado.

Temos:

DUPLICATE ACTION

Por isso sistemas robustos combinam estratégias como:

idempotency keys
deduplication
transactional boundaries
persistent state
acknowledgements

O importante para o COBOL iniciante é compreender:

retry não é inocente.

Sempre pergunte:

O que acontece se este passo executar duas vezes?

Essa pergunta vale ouro.

---

🧰 CAPÍTULO 31 — CHECKLIST PARA PROJETAR UM AGENTE ASSÍNCRONO

Antes de colocar um agente em produção, pergunte:

1. Como ele é submetido?

API?
evento?
horário?
mensagem?
humano?

2. Como recebe identidade?

RUN-ID?
CORRELATION-ID?

3. Qual fila recebe?

CRITICAL?
STANDARD?
BACKGROUND?

4. Quando fica elegível?

horário?
evento?
predecessor?

5. Quais dependências existem?

A → B → C?

6. Como detectamos falha?

timeout?
return status?
business validation?

7. Pode tentar novamente?

MAX-RETRIES?
BACKOFF?

8. A operação é idempotente?

Essa pergunta merece ser repetida.

9. Existe checkpoint?

RESUME FROM WHERE?

10. O que acontece depois das tentativas?

DLQ?
ESCALATION?
HUMAN REVIEW?

11. Onde fica o output?

arquivo?
banco?
fila?
objeto?

12. Como auditamos?

quem?
quando?
o quê?
resultado?

Se você consegue responder essas perguntas, já está pensando muito além de:

“Vou fazer um chatbot.”

---

🥚 EASTER EGG — O JOB QUE ESPEROU 27 ANOS

São 03:14.

O operador percebe algo estranho.

RUN-ID..... A000001
STATE...... WAITING_PREDECESSOR
AGE........ 27 YEARS

Turing olha.

— Vinte e sete anos?

O operador confirma.

— Qual predecessor?

Abrem os detalhes:

PREDECESSOR:
Y2K-FINAL-CLEANUP

Silêncio.

O jovem COBOL pergunta:

— E esse predecessor?

O operador procura.

NOT FOUND

Turing olha para o pequeno robô.

— Quem criou isso?

— Um consultor.

— Onde está?

— Aposentado.

— Documentação?

— Não encontramos.

O programador COBOL fecha os olhos.

Do fundo do CPD vem a voz ancestral:

Conhecimento tribal...

O administrador do JES2 toma um gole de café.

— Cancela?

Turing responde:

— Não.

— Por quê?

— Primeiro descubra o que ele faria se finalmente executasse.

Excelente conselho para qualquer sistema legado.

---

🧠 CAPÍTULO 32 — O PROGRAMADOR COBOL JÁ TEM VANTAGEM CONCEITUAL

Talvez um jovem desenvolvedor veja:

workflow orchestration
async processing
job scheduling
queues
retries
checkpoints

como ideias modernas.

O programador mainframe olha e pensa:

Já vi parentes dessas criaturas.

Batch ensinou:

trabalho pode esperar

JCL ensinou:

trabalho possui etapas

JES ensinou:

trabalho precisa entrar e ser administrado

SDSF ensinou:

execução precisa ser visível

RACF ensinou:

execução precisa de autoridade

WLM ensinou:

recursos precisam de política

Restart ensinou:

falha não deveria obrigar tudo a começar novamente

Mensageria ensinou:

produtor e consumidor não precisam trabalhar simultaneamente

Os agentes estão adicionando uma coisa extraordinária:

DECISÃO DINÂMICA

Mas eles não apagaram os problemas antigos.

Pelo contrário.

Tornaram alguns deles ainda mais importantes.

---

🏗️ CAPÍTULO 33 — NOSSO “SISTEMA OPERACIONAL DOS AGENTES”

Agora conseguimos desenhar a arquitetura completa desta série.

                USUÁRIO / EVENTO
                       │
                       ▼
                 ┌───────────┐
                 │ SUBMISSÃO │
                 └─────┬─────┘
                       │
                       ▼
              ┌─────────────────┐
              │ JES2 DOS AGENTES│
              │ filas/schedule  │
              └────────┬────────┘
                       │
                       ▼
                ┌────────────┐
                │    WLM     │
                │ prioridade │
                └─────┬──────┘
                      │
                      ▼
                ┌────────────┐
                │    RACF    │
                │ autoridade │
                └─────┬──────┘
                      │
                      ▼
                  ┌───────┐
                  │ AGENTE│
                  └───┬───┘
                      │
          ┌───────────┼────────────┐
          ▼           ▼            ▼
         LLM         APIs         TOOLS
          │           │            │
          └───────────┼────────────┘
                      │
                      ▼
                 SISTEMAS

Em volta:

SDSF
↓
OBSERVABILIDADE

PF3
↓
INTERRUPÇÃO

CHECKPOINT
↓
RECUPERAÇÃO

MAXCC
↓
RESULTADO

AUDIT
↓
EVIDÊNCIA

Agora temos algo muito maior que um chatbot.

Temos uma plataforma operacional para trabalho autônomo.

---

☕ EPÍLOGO — INTELIGÊNCIA TAMBÉM PRECISA DE UM SCHEDULER

Às 06:01 o painel finalmente mudou.

AGENT-MONTHLY-REPORT

STATUS........ ELIGIBLE
PREDECESSOR... COMPLETE
SCHEDULE...... SATISFIED
RESOURCE...... AVAILABLE
AUTHORIZATION. OK

Depois:

STATUS........ EXECUTING

O pequeno robô levantou da cadeira.

— Finalmente!

Turing sorriu.

— Você estava esperando há quanto tempo?

— Quatorze minutos.

— E morreu?

— Não.

— Perdeu inteligência?

— Não.

— O relatório deixou de ser importante?

— Não.

— Então esperar foi um problema?

O robô pensou.

— Não.

Turing apontou para o CPD.

Outros agentes estavam:

QUEUED
WAITING_EVENT
WAITING_PREDECESSOR
WAITING_APPROVAL
EXECUTING
RETRYING
COMPLETED

Nenhum precisava ocupar todos os recursos simplesmente porque existia.

Esse talvez seja um dos maiores erros que cometeremos ao imaginar agentes de IA:

confundir autonomia com execução permanente.

Um agente autônomo não precisa ficar acordado 24 horas consumindo recursos.

Pode existir como estado persistente.

Pode dormir.

Pode esperar.

Pode acordar quando chega um evento.

Pode continuar de um checkpoint.

Pode aguardar outro processo.

Pode receber uma tarefa e executá-la horas depois.

Pode falhar e ser reiniciado.

Pode ultrapassar o limite de retries e ser enviado para investigação.

Pode terminar e deixar evidências.

É exatamente aí que a inteligência artificial deixa de parecer um brinquedo conversacional e começa a se comportar como workload empresarial.

Turing pega o giz pela última vez.

Escreve:

RACF
QUEM PODE?

Depois:

PF3
POSSO PARAR?

Depois:

SDSF
O QUE ESTÁ FAZENDO?

Depois:

MAXCC
FUNCIONOU?

Depois:

WLM
QUEM RECEBE RECURSOS?

Finalmente:

JES2
QUEM COMEÇA — E QUANDO?

O programador COBOL observa o quadro.

— Professor, cada tecnologia moderna de agentes parece estar reinventando alguma coisa que o CPD já precisava resolver.

Turing toma um gole de café.

— Não exatamente.

— Não?

— Estamos aumentando drasticamente o poder do trabalhador.

Ele aponta para o robô.

— Mas os problemas de administrar trabalho continuam existindo.

Essa talvez seja a chave.

O agente pode entender linguagem natural.

Pode planejar.

Pode escolher ferramentas.

Pode consultar documentos.

Pode executar APIs.

Pode escrever código.

Pode conversar com outros agentes.

Mas alguém ainda precisa decidir:

quando ele acorda,

quando começa,

do que depende,

quanto pode repetir,

onde salva seu estado,

como continua depois de uma falha,

o que acontece quando não consegue terminar,

e quem consegue descobrir onde diabos ele foi parar.

Inteligência não elimina engenharia operacional.

Na verdade, quanto maior a autonomia...

mais importante ela se torna.

No canto da tela:

AGENT-MONTHLY-REPORT

STEP.......... 4/12
STATUS........ EXECUTING
CHECKPOINT.... CP003
MAX-RETRIES... 3
TRACE......... 7F82A91C

Turing observa.

— Agora sim.

O jovem COBOL pergunta:

— Agora podemos ir tomar café?

Turing aponta para outro painel:

AGENT-PAYROLL
STATE: WAITING_PREDECESSOR

PREDECESSOR:
AGENT-MONTHLY-REPORT

— Depois que o predecessor terminar.

O programador olha para o robô.

O robô olha para o programador.

Ambos puxam uma cadeira.

READY

E a fila continuava andando.