✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Filas. Mostrar todas as mensagens

segunda-feira, 11 de setembro de 2023

📨 ALAN TURING E O MQ DOS AGENTES — A MENSAGEM CHEGOU DUAS VEZES

Bellacosa Mainframe e as mensagens em ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

📨 ALAN TURING E O MQ DOS AGENTES — A MENSAGEM CHEGOU DUAS VEZES

IBM MQ, agentes de IA, mensageria, filas, producers, consumers, delivery semantics, acknowledgements, commit, rollback, duplicate delivery, idempotência, ordering, correlation ID, message ID, poison messages, backout queues, dead-letter queues, retry, persistence, request/reply, COBOL, CICS, Db2 — e o dia em que Alan Turing descobriu que uma mensagem pode chegar duas vezes sem que ninguém tenha cometido o mesmo erro duas vezes.

🎬 PRÓLOGO — MAS EU JÁ FIZ ISSO!

03:17 da madrugada.

O telefone toca.

Nunca existe boa notícia às 03:17.

O operador atende.

— Produção.

Silêncio.

Depois:

— Temos dois pagamentos iguais.

O operador abre o terminal.

PAYMENT-ID.... P88271
VALUE......... 850.00
STATUS........ PROCESSED

Outra linha:

PAYMENT-ID.... P88271
VALUE......... 850.00
STATUS........ PROCESSED

O pequeno agente aparece na tela.

— Não fui eu!

Alan Turing entra no CPD carregando uma caneca de café.

— Interessante defesa.

— Professor, eu processei a mensagem uma única vez!

O operador consulta os logs.

03:16:51 GET MESSAGE
03:16:52 PROCESS PAYMENT
03:16:52 DB2 COMMIT OK
03:16:52 ...
03:16:53 AGENT RESTART
03:16:54 GET MESSAGE

Turing aponta para o intervalo.

— O que aconteceu entre o commit e a confirmação do consumo da mensagem?

Silêncio.

O administrador MQ olha para o administrador Db2.

O administrador Db2 olha para o programador COBOL.

O programador COBOL olha para o robô.

O robô olha para a porta.

Turing sorri.

— Acho que encontramos nosso próximo capítulo.

No quadro escreve:

PROCESSAR UMA MENSAGEM E CONFIRMAR QUE ELA FOI PROCESSADA NÃO SÃO NECESSARIAMENTE O MESMO EVENTO.

Bem-vindo ao MQ dos Agentes.

📨 CAPÍTULO 1 — MENSAGERIA COMEÇA COM UMA IDEIA MUITO SIMPLES

Imagine dois programas.

PROGRAMA-A

precisa pedir alguma coisa para:

PROGRAMA-B

Uma possibilidade seria A chamar B diretamente.

A ───────────────► B

Mas isso cria algumas dependências.

B precisa estar disponível.

A talvez precise esperar.

A precisa saber onde B está.

Se B estiver sobrecarregado, A sofre junto.

Mensageria introduz um intermediário.

A
│
▼
QUEUE
│
▼
B

A produz uma mensagem.

B consome depois.

Temos dois papéis clássicos:

PRODUCER

CONSUMER.

O producer produz.

O consumer consome.

No meio:

QUEUE.

Simples.

Até produção começar.

📬 CAPÍTULO 2 — UMA FILA É UMA CAIXA POSTAL

Para o programador COBOL iniciante, imagine uma caixa postal.

O remetente coloca:

PEDIDO 12345

na caixa.

Ele não precisa esperar o funcionário responsável aparecer.

Depois o consumidor pega a mensagem.

PUT
↓
QUEUE
↓
GET

No universo IBM MQ podemos imaginar conceitualmente operações como:

MQPUT

MQGET.

O produtor coloca.

O consumidor recupera.

Isso permite:

desacoplamento
processamento assíncrono
absorção de picos
integração entre plataformas
resiliência

Nosso agente pode agora receber trabalho através de mensagens.

🤖 CAPÍTULO 3 — O AGENTE VIROU CONSUMIDOR

Imagine:

CUSTOMER.EVENTS

recebendo:

CUSTOMER_UPDATED

Nosso agente escuta essa fila.

Chega:

CUSTOMER_ID = 12345
EVENT       = ADDRESS_CHANGED

O agente:

1. recebe
2. interpreta
3. consulta Db2
4. aplica regras
5. talvez chama ferramentas
6. produz resultado

Perfeito.

Mas aparece a primeira pergunta importante:

Quando podemos considerar essa mensagem realmente processada?

Quando o agente começou?

Não.

Quando terminou o raciocínio?

Talvez não.

Quando atualizou o Db2?

Ainda precisamos pensar.

Quando confirmou o consumo?

Agora estamos chegando perto do problema.

✉️ CAPÍTULO 4 — TODA MENSAGEM PRECISA DE IDENTIDADE

No JES2 dos Agentes aprendemos:

RUN-ID.

Agora precisamos identificar mensagens.

Conceitualmente:

MESSAGE-ID

Pode existir também:

CORRELATION-ID.

Imagine:

MESSAGE-ID..... M000881
CORRELATION-ID. C000042
RUN-ID......... A004821

Esses identificadores respondem perguntas diferentes.

MESSAGE-ID

Qual mensagem é esta?

CORRELATION-ID

A qual conversa, fluxo ou solicitação ela pertence?

RUN-ID

Qual execução do agente está processando?

Isso será ouro para observabilidade.

🔗 CAPÍTULO 5 — CORRELATION ID: ENCONTRE A CONVERSA NO MEIO DO CAOS

Imagine:

REQUEST
MESSAGE-ID M100
CORREL-ID C500

O serviço responde:

RESPONSE
MESSAGE-ID M101
CORREL-ID C500

São mensagens diferentes.

Mas pertencem à mesma conversa.

Em sistemas distribuídos isso é extremamente útil.

Podemos seguir:

USER REQUEST
     ↓
CICS
     ↓
MQ
     ↓
AGENT
     ↓
Db2
     ↓
ANOTHER QUEUE

Tudo associado a:

CORRELATION-ID C500.

Quando alguém pergunta:

O que aconteceu com a solicitação do cliente?

não precisamos procurar agulha no palheiro.

📦 CAPÍTULO 6 — A MENSAGEM PODE SOBREVIVER AO CONSUMIDOR

Aqui está uma das grandes vantagens de mensageria confiável.

O producer envia.

PUT MESSAGE

O consumer está desligado.

A mensagem pode permanecer na fila conforme sua configuração e características.

Depois:

CONSUMER START

Ele processa.

Isso é muito diferente de uma chamada síncrona simples.

No mundo dos agentes isso é poderoso.

O LLM pode estar indisponível.

O worker pode reiniciar.

A aplicação pode sofrer manutenção.

A mensagem continua aguardando.

Mas agora surge uma pergunta:

Quanto tempo?

⏰ CAPÍTULO 7 — MENSAGENS TAMBÉM ENVELHECEM

Olha quem voltou.

Nosso amigo do Db2:

TEMPO.

Imagine:

MESSAGE CREATED:
10:00

O consumidor consegue processar:

14:00.

Tecnicamente a mensagem chegou.

Mas ainda faz sentido?

Talvez seja:

GENERATE MONTHLY REPORT

Sem problema.

Talvez seja:

CUSTOMER IS CURRENTLY LOGGED IN

Quatro horas depois?

Provavelmente inútil.

Logo mensagens também possuem:

AGE
EXPIRY
BUSINESS VALIDITY.

O MQ dos Agentes encontra o Db2 dos Agentes.

Não basta perguntar:

A mensagem chegou?

Pergunte:

Ela ainda significa alguma coisa quando chegou?

💥 CAPÍTULO 8 — A MENSAGEM CHEGOU DUAS VEZES

Finalmente chegamos ao monstro.

Imagine:

GET M001

O agente processa.

INSERT PAYMENT
COMMIT

Tudo certo.

Mas antes de completar adequadamente o ciclo de consumo:

CRASH.

Quando volta, dependendo da arquitetura e semântica empregada, a mensagem pode estar novamente disponível.

GET M001

O agente grita:

— Eu já processei isso!

A infraestrutura responde:

— Prove.

😂

Bem-vindo à possibilidade de:

REDELIVERY.

🧠 CAPÍTULO 9 — POR QUE DUPLICATAS EXISTEM?

Porque sistemas distribuídos possuem pontos de falha.

Considere:

MESSAGE
↓
PROCESS
↓
DATABASE UPDATE
↓
ACKNOWLEDGE

Agora imagine falha exatamente aqui:

DATABASE UPDATE
↓
COMMIT
↓
💀 CRASH
↓
ACKNOWLEDGE

Do ponto de vista do banco:

SUCCESS.

Do ponto de vista da mensageria:

NÃO SEI SE ELE TERMINOU.

O sistema possui duas escolhas ruins.

Escolha A

Assumir que processou.

Pode perder mensagem.

Escolha B

Entregar novamente.

Pode duplicar processamento.

Sistemas confiáveis frequentemente preferem não perder trabalho.

Então seu consumidor precisa estar preparado para duplicatas quando a semântica e arquitetura permitirem redelivery.

🔁 CAPÍTULO 10 — AT-LEAST-ONCE

Uma semântica comum em sistemas de mensageria e processamento distribuído é:

AT-LEAST-ONCE

Ou seja:

A mensagem será processada pelo menos uma vez.

Isso pode significar:

ou:

ou, em situações problemáticas:

mais.

Então:

AT-LEAST-ONCE

não significa:

EXACTLY-ONCE.

Se o efeito da mensagem não puder acontecer duas vezes, precisamos projetar proteção.

🎯 CAPÍTULO 11 — EXACTLY-ONCE É O UNICÓRNIO DA DUNGEON

Todo mundo quer:

EXACTLY ONCE.

A mensagem chega uma vez.

É processada uma vez.

O efeito acontece uma vez.

Perfeito.

Mas sistemas distribuídos possuem:

falhas
timeouts
restarts
partições
retries

E cada fronteira transacional complica o problema.

Se MQ e Db2 participam de uma unidade coordenada adequadamente, podemos obter garantias transacionais fortes em cenários específicos.

Mas quando nosso agente chama:

Db2
REST API
email
LLM
CRM SaaS
payment service

a conversa muda.

Nem todos participam da mesma transação.

Por isso é perigoso jogar:

EXACTLY-ONCE

num slide como se fosse magia.

🛡️ CAPÍTULO 12 — IDEMPOTÊNCIA ENTRA COM UMA ESPADA

A solução prática frequentemente passa por:

IDEMPOTÊNCIA.

Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indesejados depois da primeira aplicação bem-sucedida.

Exemplo perigoso:

ADD R$ 100 TO BALANCE

Execute duas vezes:

+100
+100

Resultado diferente.

Agora imagine:

SET PAYMENT P123 STATUS = PROCESSED

Executar novamente pode ser inofensivo dependendo da regra.

Ou:

PROCESS PAYMENT
WHERE PAYMENT_ID = P123
AND STATUS = PENDING

Depois da primeira execução:

STATUS = PROCESSED.

A segunda encontra:

NOT PENDING.

Nada acontece.

Muito melhor.

🪪 CAPÍTULO 13 — IDEMPOTENCY KEY

Outra técnica:

IDEMPOTENCY-KEY.

Exemplo:

IDEMPOTENCY-KEY = ORDER-9981-PAYMENT

Antes de executar:

SELECT STATUS
FROM PROCESSED_MESSAGES
WHERE IDEMPOTENCY_KEY = :KEY;

Se já existe:

ALREADY PROCESSED

não repetimos o efeito.

Se não existe:

PROCESS
STORE KEY
COMMIT

O detalhe crucial é tornar essa proteção suficientemente atômica para impedir dois consumidores concorrentes de passarem pela verificação simultaneamente.

Porque senão:

AGENT-A: não existe!
AGENT-B: não existe!

AGENT-A: processa!
AGENT-B: processa!

Parabéns.

Construímos uma deduplicação que duplica.

😂

🔐 CAPÍTULO 14 — MQ E Db2 PRECISAM CONVERSAR SOBRE COMMIT

Agora chegamos ao terreno favorito do mainframe.

Imagine:

MQGET
↓
UPDATE Db2
↓
COMMIT

Queremos que o consumo da mensagem e a alteração no banco tenham comportamento consistente.

Idealmente, dentro de um desenho transacional apropriado:

GET MESSAGE
+
UPDATE DATABASE
+
COMMIT

fazem parte de uma unidade lógica coerente.

Se falhar:

ROLLBACK.

A alteração do banco não fica pela metade e a mensagem pode permanecer disponível conforme a unidade de trabalho.

Esse é exatamente o tipo de problema que mainframes resolvem há décadas.

🧱 CAPÍTULO 15 — UNIT OF WORK VOLTOU

Nosso velho amigo:

UOW

Unit of Work.

Conceitualmente:

BEGIN UOW

GET MESSAGE
UPDATE DB2
INSERT AUDIT

COMMIT UOW

Se:

UPDATE DB2

falhar:

ROLLBACK.

O importante é definir claramente:

Quais efeitos pertencem à mesma unidade de consistência?

Para agentes, isso é essencial.

Porque eles tendem a fazer muitas coisas.

☠️ CAPÍTULO 16 — O PROBLEMA DAS AÇÕES EXTERNAS

Nosso agente:

GET MESSAGE
↓
UPDATE Db2
↓
SEND EMAIL
↓
CALL PAYMENT API
↓
POST MESSAGE

Rollback?

Db2:

— Posso ajudar.

MQ:

— Também.

E-mail:

— Já enviei.

API externa:

— Já cobrei.

Internet:

— Boa sorte.

😂

Essa é a fronteira entre transações locais/coordenadas e efeitos distribuídos externos.

Você precisa pensar em:

idempotência
compensação
outbox
inbox
deduplicação
reconciliação

e não simplesmente:

ROLLBACK EVERYTHING.

📤 CAPÍTULO 17 — O OUTBOX PATTERN

Imagine que precisamos:

UPDATE ORDER

e depois publicar:

ORDER_COMPLETED.

Problema clássico:

UPDATE Db2
COMMIT

CRASH

SEND MESSAGE

O pedido mudou.

A mensagem nunca saiu.

Ou:

SEND MESSAGE

CRASH

UPDATE Db2

Mensagem diz que aconteceu.

Banco diz que não.

Uma abordagem conhecida é o:

TRANSACTIONAL OUTBOX.

Dentro da mesma transação do banco:

UPDATE ORDER

INSERT INTO OUTBOX
   ORDER_COMPLETED

COMMIT

Depois outro processo publica registros da outbox.

Assim a intenção de publicar fica persistida junto com a alteração de negócio.

Ainda precisamos tratar duplicatas na publicação.

Mas removemos uma janela perigosa.

📥 CAPÍTULO 18 — INBOX PATTERN

Do outro lado podemos manter registro das mensagens consumidas.

INBOX
────────────────
MESSAGE_ID
PROCESSED_AT
STATUS

Chega:

M001.

Verificamos.

Não existe.

Processamos e registramos.

Chega novamente:

M001.

Existe.

DUPLICATE

Ignoramos ou retornamos o resultado anterior, conforme a aplicação.

Temos então:

OUTBOX

para publicação confiável e:

INBOX

para consumo controlado.

🧪 CAPÍTULO 19 — A MENSAGEM VENENOSA

Imagine:

MESSAGE M666

Chega.

Consumer tenta.

FAIL.

Volta.

Tenta.

FAIL.

Volta.

FAIL.

E continua:

FAIL
FAIL
FAIL
FAIL
FAIL

Talvez a mensagem tenha:

formato inválido
campo impossível
versão incompatível
regra não suportada
dados corrompidos

Ela nunca funcionará sem intervenção.

Chamamos informalmente esse tipo de caso de:

POISON MESSAGE.

Nosso agente não deveria ficar mastigando veneno eternamente.

☠️ CAPÍTULO 20 — BACKOUT QUEUE

Em ambientes IBM MQ, podemos projetar tratamento para mensagens que repetidamente causam rollback/backout.

Depois de determinado limite:

BACKOUT COUNT > THRESHOLD

a aplicação pode encaminhar a mensagem para uma:

BACKOUT QUEUE.

Assim:

NORMAL QUEUE

continua processando mensagens saudáveis.

E a problemática vai para investigação.

Conceitualmente:

QUEUE
  │
  ▼
CONSUMER
  │
  ├── SUCCESS → DONE
  │
  └── FAIL
       │
       ▼
    RETRY
       │
       ▼
 THRESHOLD?
   │       │
  NO      YES
   │       │
 retry     ▼
       BACKOUT QUEUE

Isso impede que uma única mensagem bloqueie eternamente o fluxo.

⚰️ CAPÍTULO 21 — DEAD-LETTER QUEUE NÃO É EXATAMENTE A MESMA COISA

Aqui precisamos separar conceitos.

Uma:

DEAD-LETTER QUEUE

é tradicionalmente associada a mensagens que o sistema não consegue entregar ou encaminhar ao destino esperado por determinados problemas de entrega.

Uma:

BACKOUT QUEUE

pode ser usada pela aplicação para mensagens que foram entregues, mas falham repetidamente durante processamento e sofrem backout.

No discurso moderno muita gente usa “DLQ” genericamente para qualquer fila de mensagens problemáticas.

Mas no universo IBM MQ a distinção operacional é útil.

O mainframeiro olha e diz:

Nome correto evita reunião de duas horas.

🔁 CAPÍTULO 22 — RETRY PRECISA TER CÉREBRO

Falhou.

Tentamos novamente?

Depende.

Erro:

HTTP 503

Talvez.

Erro:

INVALID CUSTOMER ID

Provavelmente não.

Erro:

TIMEOUT

Talvez.

Erro:

SCHEMA VERSION UNSUPPORTED

Repetir cem vezes provavelmente produzirá cem fracassos.

Portanto:

RETRYABLE ERROR

NON-RETRYABLE ERROR

deveriam ser tratados diferentemente.

Retry não é religião.

É política.

⏳ CAPÍTULO 23 — EXPONENTIAL BACKOFF

Imagine 10.000 agentes.

Serviço externo cai.

Todos tentam novamente:

NOW.

O serviço tenta recuperar.

Dez mil chamadas chegam.

Ele cai novamente.

Chamamos isso de:

RETRY STORM.

Uma estratégia:

1s
2s
4s
8s
16s

é exponential backoff.

Adicione:

JITTER

para não fazer todos acordarem exatamente juntos.

4.1s
3.7s
4.8s

Agora reduzimos o efeito manada.

WLM agradece.

🚂 CAPÍTULO 24 — E SE AS MENSAGENS CHEGAREM FORA DE ORDEM?

Imagine:

M1:
CUSTOMER_CREATED

depois:

M2:
CUSTOMER_BLOCKED.

Queremos:

M1 → M2.

Mas o consumidor observa:

M2 → M1.

Agora pode concluir:

Não existe cliente para bloquear.

Depois cria o cliente.

Resultado:

ACTIVE.

Mas deveria estar:

BLOCKED.

O conteúdo estava correto.

As mensagens estavam corretas.

A ordem estava errada.

Mais um monstro.

🔢 CAPÍTULO 25 — SEQUÊNCIA TAMBÉM É DADO

Podemos adicionar:

ENTITY-ID...... CUSTOMER-123
SEQUENCE....... 42

Depois:

ENTITY-ID...... CUSTOMER-123
SEQUENCE....... 43.

O consumidor recebe 43 antes de 42.

Pode:

esperar
reordenar
rejeitar
reconciliar

dependendo da arquitetura.

Mas precisa saber que existe ordem.

Sem informação de sequência, talvez seja impossível perceber o problema.

🧩 CAPÍTULO 26 — ORDEM GLOBAL É CARA E MUITAS VEZES DESNECESSÁRIA

Precisamos de todas as mensagens do sistema inteiro em ordem?

Provavelmente não.

Talvez precisemos apenas manter ordem por:

CUSTOMER-ID

ou:

ORDER-ID

ou:

ACCOUNT-ID.

Isso permite paralelismo entre entidades diferentes.

CUSTOMER A → ordered
CUSTOMER B → ordered
CUSTOMER C → ordered

mas A, B e C podem ser processados simultaneamente.

O segredo é perguntar:

Qual é a menor fronteira dentro da qual a ordem realmente importa?

🕰️ CAPÍTULO 27 — ATRASADA NÃO SIGNIFICA FORA DE ORDEM

Outra distinção.

Uma mensagem pode chegar:

30 minutos atrasada

mas ainda na ordem correta.

Ou:

100 ms depois

mas fora de ordem em relação a outra.

Temos conceitos diferentes:

LATENCY
ORDERING
FRESHNESS.

Não misture.

O Db2 dos Agentes nos ensinou:

dado tem idade.

O MQ acrescenta:

a notícia sobre o dado também tem idade.

📰 CAPÍTULO 28 — EVENT TIME E PROCESSING TIME

Imagine evento:

EVENT_TIME:
10:00:01

Chega ao consumidor:

PROCESSING_TIME:
10:00:09.

São tempos diferentes.

Isso pode ser extremamente relevante.

Se o agente analisa:

O que aconteceu às 10:00?

precisa considerar:

EVENT TIME.

Se pergunta:

Quando processamos?

usa:

PROCESSING TIME.

Misturar os dois pode gerar análises absurdas.

🤖 CAPÍTULO 29 — O AGENTE PRECISA SABER QUE O EVENTO NÃO É O ESTADO ATUAL

Chega mensagem:

10:00
CUSTOMER_STATUS_CHANGED
ACTIVE → BLOCKED

Nosso agente recebe às:

10:10.

Antes de executar ação crítica, talvez precise consultar Db2.

Porque às:

10:05

o cliente pode ter sido:

UNBLOCKED.

Então a mensagem descreve:

ALGO QUE ACONTECEU

e não necessariamente:

COMO O MUNDO ESTÁ AGORA.

Essa distinção é gigantesca.

EVENT ≠ CURRENT STATE.

🗄️ CAPÍTULO 30 — MQ E Db2 CONTAM HISTÓRIAS DIFERENTES

Db2 frequentemente responde:

Qual é o estado armazenado?

MQ frequentemente transporta:

Algo aconteceu.

Exemplo:

Db2:
STATUS = ACTIVE

Evento antigo:

CUSTOMER_BLOCKED.

Se o agente tratar o evento antigo como estado atual:

problema.

Por isso, para ações críticas:

EVENT
↓
INTERPRET
↓
READ CURRENT STATE
↓
REVALIDATE
↓
ACT.

Nosso princípio do Db2 dos Agentes volta novamente.

🔄 CAPÍTULO 31 — EVENTUAL CONSISTENCY

Em sistemas distribuídos, diferentes componentes podem não refletir a mesma mudança exatamente no mesmo instante.

Imagine:

SYSTEM A
STATUS = BLOCKED

Evento viaja.

Enquanto isso:

SYSTEM B
STATUS = ACTIVE.

Alguns milissegundos ou segundos depois:

SYSTEM B
STATUS = BLOCKED.

Durante esse intervalo:

A ≠ B.

Isso não significa necessariamente corrupção.

Pode ser uma consequência do modelo de propagação.

Agentes precisam compreender isso.

Dois sistemas podem temporariamente apresentar visões diferentes.

Lembra dos dois agentes do Db2?

Eles voltaram.

📊 CAPÍTULO 32 — OBSERVABILIDADE DA FILA

Nosso SDSF dos Agentes ganha novos campos.

Imagine:

QUEUE........ CUSTOMER.EVENTS
DEPTH........ 18,442

OLDEST MSG... 00:07:31
PUT RATE..... 920/s
GET RATE..... 710/s

CONSUMERS.... 24
BACKOUTS..... 17
RETRIES...... 2,881

Agora conseguimos enxergar:

QUEUE DEPTH

Mas profundidade sozinha não basta.

18 mil mensagens pode ser terrível.

Ou normal.

Precisamos de contexto.

Talvez mais importante seja:

OLDEST MESSAGE AGE.

Se a fila cresce e a mensagem mais velha envelhece:

temos backlog real.

📈 CAPÍTULO 33 — PRODUCER MAIS RÁPIDO QUE CONSUMER

Imagine:

PRODUCER = 1000 msg/s
CONSUMER = 700 msg/s

Diferença:

+300 msg/s.

Depois de um minuto:

18,000 messages

Depois de uma hora:

1,080,000.

A fila absorve pico.

Mas não derrota matemática.

😂

Se a entrada continuamente supera a saída:

BACKLOG ↑
LATENCY ↑
MESSAGE AGE ↑

Precisamos:

mais consumers
mais capacidade
reduzir trabalho
priorizar
aplicar backpressure

WLM aparece novamente.

🚦 CAPÍTULO 34 — BACKPRESSURE

Se consumidores não conseguem acompanhar produtores, precisamos evitar crescimento ilimitado.

Isso pode envolver:

rate limiting
quotas
producer throttling
queue limits
load shedding
priority

Mensageria desacopla componentes.

Mas desacoplamento não significa capacidade infinita.

Fila é amortecedor.

Não buraco negro.

🧰 CAPÍTULO 35 — CHECKLIST DO MQ DOS AGENTES

Antes de colocar um agente consumindo mensagens, responda:

1. Quem produz?

PRODUCER?

2. Quem consome?

CONSUMER?

3. A mensagem é persistente quando necessário?

Defina de acordo com criticidade.

4. Ela pode ser entregue novamente?

Projete assumindo que sim quando sua semântica permitir.

5. O processamento é idempotente?

Se não, por quê?

6. Existe idempotency key?

Defina.

7. Existe MESSAGE-ID?

Sempre saiba qual mensagem está tratando.

8. Existe CORRELATION-ID?

Rastreie o fluxo.

9. A ordem importa?

Defina a fronteira.

10. Existe sequence number?

Quando necessário.

11. A mensagem expira?

Defina validade.

12. Existe retry?

Classifique erros.

13. Existe backoff?

Evite tempestades.

14. Existe poison message handling?

Tenha backout ou quarentena adequada.

15. Existe DLQ?

Monitore.

16. A mensagem representa evento ou estado?

Não confunda.

17. Precisa revalidar no Db2?

Para ações críticas, provavelmente.

18. O commit inclui quais recursos?

Defina UOW.

19. Existem efeitos externos?

Planeje idempotência ou compensação.

20. Conseguimos provar o que aconteceu?

Logs, traces, IDs e timestamps.

🥚 EASTER EGG — A MENSAGEM IMORTAL

04:12.

O operador percebe:

BACKOUT COUNT = 847.

— Professor...

Turing aproxima-se.

MESSAGE-ID = M666

— Há quanto tempo?

FIRST DELIVERY:
1999-12-31 23:59:58

Silêncio.

O programador COBOL arregala os olhos.

— Isso está tentando processar desde o bug do milênio?

O administrador MQ responde:

— Ninguém teve coragem de apagar.

O pequeno robô pergunta:

— O que ela contém?

Abrem.

CUSTOMER-ID = 000000001
ACTION      = MIGRATE
FORMAT      = VERSION-0

Turing olha.

— Algum consumidor suporta versão zero?

Todos:

— Não.

— Então por que continuam tentando?

Silêncio.

O operador responde:

— Retry policy.

Turing pega o café.

— Qual?

RETRY = FOREVER.

Turing fecha os olhos.

No fundo do CPD alguém sussurra:

Ela não é uma mensagem... agora ela é patrimônio histórico.

😂

🧬 CAPÍTULO 36 — NOSSO MAINFRAME DOS AGENTES GANHOU SISTEMA NERVOSO

Nossa arquitetura agora 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?

Db2
↓
QUAL REALIDADE O AGENTE ESTÁ VENDO?

E agora:

MQ
↓
COMO A NOTÍCIA VIAJA ENTRE OS AGENTES?

Começamos a montar algo muito interessante.

🏰 CAPÍTULO 37 — O SISTEMA OPERACIONAL CONCEITUAL DOS AGENTES

Turing desenha:

                        HUMANO
                           │
                           ▼
                        CICS
                           │
               ┌───────────┴───────────┐
               │                       │
               ▼                       ▼
             AGENT                    MQ
               │                       │
               │                  ┌────┴────┐
               │                  ▼         ▼
               │               AGENT-B   AGENT-C
               │                  │         │
               └──────────┬───────┴─────────┘
                          ▼
                         Db2

Acima:

JES2
SCHEDULING

Ao redor:

WLM
CAPACITY

Na porta:

RACF
AUTHORITY

Na sala de operações:

SDSF
OBSERVABILITY

E sobre as mensagens:

MESSAGE-ID
CORRELATION-ID
SEQUENCE
TIMESTAMP
VERSION

Agora agentes não são apenas pequenos cérebros isolados.

Eles formam:

UM SISTEMA DISTRIBUÍDO.

E sistemas distribuídos possuem regras próprias.

🧠 CAPÍTULO 38 — O PROGRAMADOR COBOL TEM OUTRA VANTAGEM INESPERADA

Para muita gente:

event-driven architecture
message queues
async processing
retries

parecem invenções moderníssimas.

O mainframeiro olha para MQ e diz:

Sente-se, jovem.

😂

Porque aplicações corporativas trabalham com:

mensageria
filas
commit
rollback
correlation
persistence
backout
recovery

há décadas.

Claro que tecnologias modernas acrescentaram:

cloud
Kafka
microservices
containers
serverless
agents
LLMs.

Mas a pergunta fundamental continua:

Como dois componentes independentes trocam trabalho sem transformar cada falha em catástrofe?

Essa pergunta é antiga.

E continua excelente.

☕ CAPÍTULO 39 — O AGENTE PRECISA SER DESCONFIADO

Um consumidor robusto não deveria pensar:

Recebi uma mensagem. Vou obedecer.

Deveria perguntar:

Quem enviou?

Posso confiar?

Qual schema?

Qual versão?

Já processei?

Está na ordem?

Ainda é válida?

Tenho autorização?

Preciso consultar o estado atual?

Posso executar duas vezes?

Como confirmo?

Como desfaço?

Isso parece paranoia.

Em produção chamamos de:

ENGENHARIA.

🎭 CAPÍTULO 40 — EVENTO NÃO É ORDEM

Outra regra importante para agentes.

Mensagem:

CUSTOMER_CHANGED_ADDRESS

significa:

O endereço mudou.

Não significa automaticamente:

Faça alguma coisa perigosa.

O agente precisa interpretar eventos dentro de política.

Uma arquitetura segura separa:

FACT

de:

DECISION

ACTION.

Assim:

EVENT
↓
OBSERVE
↓
VALIDATE
↓
DECIDE
↓
AUTHORIZE
↓
ACT

Essa separação reduz o risco de transformar qualquer mensagem numa ordem administrativa.

RACF agradece novamente.

🔐 CAPÍTULO 41 — MENSAGEM TAMBÉM PRECISA DE ZERO TRUST

Nosso agente não deveria confiar numa mensagem apenas porque ela apareceu numa fila.

Considere:

identity
authorization
queue permissions
message integrity
origin
schema validation
content validation

Uma mensagem malformada ou maliciosa pode tentar fazer o agente:

CALL TOOL
TRANSFER MONEY
DELETE DATA

Logo:

MQ

não elimina segurança.

Ele apenas transporta dados.

Autorização continua sendo outra camada.

🧾 CAPÍTULO 42 — SCHEMA É O COPYBOOK DA MENSAGEM

O programador COBOL conhece isso imediatamente.

Mensagem:

01 PAYMENT-MESSAGE.
   05 MSG-VERSION       PIC 9(04).
   05 PAYMENT-ID        PIC X(20).
   05 CUSTOMER-ID       PIC 9(09).
   05 AMOUNT            PIC S9(11)V99 COMP-3.
   05 EVENT-TIMESTAMP   PIC X(26).

Isso define estrutura.

Mas lembramos do Db2 dos Agentes:

ESTRUTURA NÃO É SEMÂNTICA.

Precisamos saber:

AMOUNT é em BRL?
PAYMENT-ID é único?
EVENT-TIMESTAMP usa qual timezone?
CUSTOMER-ID pode ser zero?
MSG-VERSION 0002 é compatível?

O copybook voltou.

Ele nunca foi embora.

🔄 CAPÍTULO 43 — VERSIONAMENTO DE MENSAGEM

Hoje:

VERSION 1

Amanhã precisamos adicionar:

CURRENCY.

Criamos:

VERSION 2.

Mas ainda existem consumidores antigos.

Agora precisamos pensar:

backward compatibility
forward compatibility
schema evolution

Nosso agente deve saber:

Consigo interpretar esta versão?

Se não:

QUARANTINE

é melhor do que:

VOU CHUTAR.

Especialmente quando “chutar” movimenta dinheiro.

🌊 CAPÍTULO 44 — A FILA É UM AMORTECEDOR, NÃO UM MILAGRE

Turing desenha:

PRODUCER
████████████████████████
          ↓
       QUEUE
~~~~~~~~~~~~~~~~~~~~~~~~
          ↓
CONSUMER
██████████

A fila absorve diferença temporária.

Mas se producer permanece mais rápido:

QUEUE DEPTH ↑

até algum limite operacional.

Portanto monitoramos:

depth
oldest age
put rate
get rate
consumer count
failure rate
backout count

Uma fila crescente é uma mensagem.

Ironicamente:

A própria fila está tentando falar com você.

🏁 CAPÍTULO 45 — A REGRA DE OURO

Alan Turing escreve no quadro:

MESSAGE RECEIVED
≠
BUSINESS ACTION COMPLETED

Depois:

BUSINESS ACTION COMPLETED
≠
MESSAGE ACKNOWLEDGED

Depois:

MESSAGE ACKNOWLEDGED
≠
WORLD STILL UNCHANGED

O pequeno robô fica olhando.

— Então eu não posso confiar em nada?

Turing sorri.

— Pode.

— Em quê?

— Em protocolos, transações, IDs, versões, políticas, observabilidade e verificações.

— Parece trabalhoso.

— É.

— E se eu simplesmente confiar que tudo dará certo?

Do fundo do CPD, cinco administradores começam a rir.

☕ EPÍLOGO — RECEBIDO NÃO SIGNIFICA TERMINADO

07:02.

A equipe da manhã chega.

Nosso agente recebe:

MESSAGE-ID..... M004821
CORREL-ID...... C009912
EVENT.......... PAYMENT_REQUESTED
PAYMENT-ID..... P88271
AMOUNT......... 850.00
SEQUENCE....... 42
EVENT-TIME..... 07:02:01

Ele verifica:

SCHEMA......... OK
VERSION........ SUPPORTED
AUTHORITY...... OK
DUPLICATE...... NO
ORDER.......... OK
FRESHNESS...... OK

Consulta Db2.

CURRENT STATE.. VALID

Inicia unidade de trabalho.

PROCESS PAYMENT
INSERT AUDIT
REGISTER MESSAGE

Confirma.

COMMIT.

Resultado:

SUCCESS.

Alguns milissegundos depois:

💥

O worker cai.

Reinicia.

A mensagem aparece novamente.

O velho agente teria gritado:

Já fiz isso!

O novo apenas consulta:

IDEMPOTENCY-KEY = P88271.

Resposta:

ALREADY PROCESSED.

Nenhum pagamento duplicado.

Nenhuma madrugada destruída.

Nenhum DBA perseguindo robôs pelo corredor.

O agente registra:

DUPLICATE DELIVERY
BUSINESS EFFECT SKIPPED
STATUS = SAFE

Turing toma o primeiro café da manhã.

O programador pergunta:

— Então a duplicata deixou de ser um problema?

— Não.

— Mas não aconteceu nada.

— Exatamente.

O programador pensa.

Turing continua:

— Engenharia confiável não é construir um universo onde falhas nunca acontecem.

Aponta para a tela:

REDELIVERY DETECTED

— É construir um sistema no qual falhas esperadas deixam de virar desastres inesperados.

O pequeno robô levanta a mão.

— Professor?

— Sim?

— Posso apagar a mensagem de 1999?

Do outro lado do CPD o administrador MQ grita:

— NÃO! PRIMEIRO FAZ BACKUP!

😂

Turing fecha o terminal.

Na tela permanece:

MQ
────────────────────────

MESSAGE-ID...... M004821
DELIVERY........ 2
PROCESSING...... IDEMPOTENT
BUSINESS EFFECT. ONCE
STATUS.......... SAFE

COMMIT.......... OK

E embaixo:

A MENSAGEM PODE CHEGAR NOVAMENTE.

O EFEITO NÃO PRECISA ACONTECER NOVAMENTE.

Essa é talvez a grande lição do MQ dos Agentes.

Porque quando centenas de inteligências artificiais começarem a conversar entre si, delegando tarefas, publicando eventos, recebendo respostas, reiniciando workers, atravessando APIs, bancos, filas e nuvens, não bastará perguntar:

A mensagem chegou?

Teremos de perguntar:

Qual mensagem?

De quem?

Quando?

Em qual ordem?

Quantas vezes?

Ainda é válida?

Já foi processada?

O efeito foi confirmado?

Posso executar novamente?

E se eu cair exatamente agora?

O mainframe conhece essa paranoia há décadas.

E talvez por isso tenha tanta coisa para ensinar aos agentes.

MQGET
   ↓
VALIDATE
   ↓
DEDUPLICATE
   ↓
REVALIDATE
   ↓
PROCESS
   ↓
COMMIT
   ↓
ACKNOWLEDGE

Alan Turing olha para o fluxo.

Toma mais um gole.

E acrescenta apenas uma linha:

IF IN DOUBT
   DO NOT CHARGE THE CUSTOMER TWICE.

READY

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 Alan Turing entra no CPD

O mapa dos agentes de IA explicado por um mainframer

Esta série acompanha a evolução de uma ideia: compreender os problemas modernos dos agentes de inteligência artificial usando conceitos conhecidos por quem trabalha com mainframe, IBM Z e sistemas corporativos.

A viagem começa pelas pessoas e pela experiência de uso, passa por observabilidade, priorização e execução, chega às transações, estado e mensageria e termina na organização hierárquica do contexto.

FEV / 2023

🧠 O currículo invisível da inteligência artificial

Antes de construir agentes inteligentes precisamos preparar as pessoas que trabalharão com eles. Técnica, pensamento crítico, conhecimento de negócio, segurança, ética e responsabilidade formam o currículo que nem sempre aparece no certificado.

Ler: Alan Turing e o currículo invisível da IA →

MAR / 2023

🤖 A UX dos agentes

Quando uma IA deixa de apenas responder e começa a executar ações, sua interface precisa mostrar objetivos, progresso, permissões e resultados. PF3, MAXCC e RACF tornam-se excelentes analogias para controle, retorno e privilégio mínimo.

Ler: Alan Turing e a UX dos agentes →

ABR / 2023

🔭 O SDSF dos agentes

Autonomia sem observabilidade cria uma caixa-preta. Inspirado no SDSF do z/OS, este capítulo pergunta como acompanhar agentes, tarefas, estados, filas, falhas, logs e resultados em tempo real.

Ler: O SDSF dos agentes — o que o robô está fazendo? →

MAI / 2023

⚖️ O WLM dos agentes

CPU, GPU, tokens, APIs e bancos de dados são recursos finitos. O Workload Manager inspira uma discussão sobre prioridades, objetivos de serviço, importância do trabalho e distribuição dinâmica de recursos entre agentes.

Ler: Alan Turing e o WLM dos agentes →

JUN / 2023

🏭 O JES2 dos agentes

Quem recebe uma tarefa? Onde ela espera? Quem decide quando poderá executar? A lógica de entrada, filas, despacho, execução e saída do JES2 oferece um paralelo interessante para a orquestração do trabalho dos agentes.

Ler: O JES2 dos agentes — quem recebe e despacha o trabalho? →

JUL / 2023

⚡ O CICS dos agentes

Uma coisa é uma IA produzir texto. Outra é permitir que ela execute operações reais de negócio. CICS introduz a conversa sobre processamento transacional, concorrência, segurança e integridade.

Ler: Alan Turing e o CICS dos agentes →

AGO / 2023

🗄️ O Db2 dos agentes

Agentes precisam manter estado, checkpoints, decisões e resultados. O Db2 fornece o ponto de partida para discutir unidade de trabalho, consistência, COMMIT, ROLLBACK e recuperação.

Ler: Alan Turing e o Db2 dos agentes →

SET / 2023

📨 O MQ dos agentes

Sistemas de agentes não precisam conversar sincronamente o tempo inteiro. IBM MQ conduz a discussão para filas, mensagens, desacoplamento, resiliência, retries, correlação e processamento assíncrono.

Ler: O MQ dos agentes — mensagem não significa conversa síncrona →

OUT / 2023

🌳 O IMS dos agentes

Nem todo conhecimento precisa ser imaginado como uma tabela. IMS leva a série para estruturas hierárquicas, relações parent/child e navegação contextual — conceitos úteis para pensar organização e recuperação de contexto.

Ler: Alan Turing e o IMS dos agentes — quando o mundo virou uma árvore →

SET / 2026

☕ Alan Turing entra no CPD — O mapa completo

O artigo-âncora reúne toda a evolução da ideia: pessoas, UX, observabilidade, prioridade, orquestração, transações, estado, mensageria e contexto transformam artigos independentes em uma arquitetura conceitual para agentes de IA.

☕ ABRIR O MAPA COMPLETO DOS AGENTES DE IA →

🖥️ Leitor da série

Selecione qualquer capítulo acima para abri-lo normalmente. O painel abaixo é apenas um recurso adicional de navegação.

JavaScript está desativado. Todos os capítulos continuam disponíveis pelos links HTML desta página. Abrir o mapa completo dos agentes de IA

sábado, 3 de junho de 2023

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

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

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:

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:

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.

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🤖 Alan Turing entra no CPD

O mapa dos agentes de IA explicado por um mainframer

FEV / 2023

🧠 O currículo invisível da inteligência artificial

Ler: Alan Turing e o currículo invisível da IA →

MAR / 2023

🤖 A UX dos agentes

Ler: Alan Turing e a UX dos agentes →

ABR / 2023

🔭 O SDSF dos agentes

Autonomia sem observabilidade cria uma caixa-preta. Inspirado no SDSF do z/OS, este capítulo pergunta como acompanhar agentes, tarefas, estados, filas, falhas, logs e resultados em tempo real.

Ler: O SDSF dos agentes — o que o robô está fazendo? →

MAI / 2023

⚖️ O WLM dos agentes

Ler: Alan Turing e o WLM dos agentes →

JUN / 2023

🏭 O JES2 dos agentes

Ler: O JES2 dos agentes — quem recebe e despacha o trabalho? →

JUL / 2023

⚡ O CICS dos agentes

Ler: Alan Turing e o CICS dos agentes →

AGO / 2023

🗄️ O Db2 dos agentes

Agentes precisam manter estado, checkpoints, decisões e resultados. O Db2 fornece o ponto de partida para discutir unidade de trabalho, consistência, COMMIT, ROLLBACK e recuperação.

Ler: Alan Turing e o Db2 dos agentes →

SET / 2023

📨 O MQ dos agentes

Ler: O MQ dos agentes — mensagem não significa conversa síncrona →

OUT / 2023

🌳 O IMS dos agentes

Ler: Alan Turing e o IMS dos agentes — quando o mundo virou uma árvore →

SET / 2026

☕ Alan Turing entra no CPD — O mapa completo

☕ ABRIR O MAPA COMPLETO DOS AGENTES DE IA →

🖥️ Leitor da série

Selecione qualquer capítulo acima para abri-lo normalmente. O painel abaixo é apenas um recurso adicional de navegação.

JavaScript está desativado. Todos os capítulos continuam disponíveis pelos links HTML desta página. Abrir o mapa completo dos agentes de IA

Translate

segunda-feira, 11 de setembro de 2023