Bellacosa Mainframe e as prioridades dos agenstes de ia

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🚦 ALAN TURING E O WLM DOS AGENTES — QUANDO 500 INTELIGÊNCIAS ARTIFICIAIS QUEREM TRABALHAR AO MESMO TEMPO

Workload Management, filas, prioridades, SLA, SLO, backpressure, rate limits, throttling, quotas, tokens, custos, latência, concorrência, CICS, Db2, MQ, JES2, WLM — e o dia em que Alan Turing descobriu que inteligência artificial também precisa aprender a esperar na fila.

---

🎬 PRÓLOGO — QUINHENTOS ROBÔS CHEGARAM PARA TRABALHAR

Alan Turing entrou no CPD às 08:59.

Tudo parecia tranquilo.

O café estava quente.

O operador examinava o SDSF.

O jovem programador COBOL tentava entender por que um PIC 9(05) não aceitava aquilo que ele jurava ser um número.

Então o relógio marcou:

09:00:00

E alguma coisa aconteceu.

Um agente iniciou o relatório diário.

Outro começou a analisar contratos.

Cinquenta agentes de atendimento acordaram.

Cem agentes começaram a consultar clientes.

O departamento financeiro disparou processamento.

Marketing resolveu analisar documentos.

Desenvolvimento iniciou uma varredura de código.

Segurança disparou verificações.

Em poucos segundos:

AGENTS ACTIVE: 500

O pequeno robô olhou orgulhoso para Turing.

— Veja! Todos estão trabalhando!

Turing olhou para o painel.

LLM REQUESTS........ 497
DB2 CONNECTIONS..... 100%
CICS REQUESTS....... +380%
API RATE LIMIT...... EXCEEDED
QUEUE DEPTH......... 4,281
LATENCY P95......... 47.2s
COST RATE........... $$$$$$$

Silêncio.

O robô corrigiu:

— Bem... todos estão tentando trabalhar.

Turing puxou uma cadeira.

— Excelente. Agora vocês descobriram por que sistemas corporativos possuem gerenciamento de workload.

---

🧠 CAPÍTULO 1 — RECURSOS NÃO SÃO INFINITOS

Quando começamos a estudar programação, frequentemente pensamos assim:

PROGRAMA
   ↓
CPU
   ↓
RESULTADO

Parece simples.

Mas sistemas corporativos executam muitas coisas simultaneamente.

No mainframe temos:

batch
CICS
Db2
IMS
TSO
APIs
serviços
jobs
subsistemas

Todos competindo por recursos.

CPU.

Memória.

I/O.

Storage.

Threads.

Conexões.

Tempo.

Agora acrescente agentes de IA.

Eles podem disputar:

LLM capacity
tokens
API calls
Db2 connections
CICS transactions
MQ resources
network bandwidth
tool concurrency
memory
CPU
budget

E surge uma verdade fundamental:

Não podemos deixar todo mundo consumir tudo ao mesmo tempo.

Se existem 500 agentes e apenas 50 operações simultâneas são sustentáveis, alguma coisa precisa decidir:

QUEM EXECUTA?
QUEM ESPERA?
QUEM TEM PRIORIDADE?
QUANTO CADA UM PODE CONSUMIR?
QUANDO DEVEMOS RECUSAR TRABALHO?

Bem-vindo ao problema de gerenciamento de workload.

---

🏛️ CAPÍTULO 2 — O MAINFRAME CONHECE ESSA BRIGA HÁ DÉCADAS

No z/OS, Workload Management — WLM — existe justamente porque recursos precisam ser administrados conforme objetivos de serviço.

A ideia mais importante não é simplesmente:

JOB A = prioridade 10
JOB B = prioridade 5

Isso seria uma visão pobre demais.

A pergunta mais interessante é:

Qual trabalho precisa de determinado nível de serviço e qual é sua importância para o negócio?

Imagine:

Pagamento online
Relatório mensal
Backup
Consulta interativa
Processamento estatístico

Todos são importantes.

Mas não necessariamente possuem a mesma urgência.

Se um cliente está esperando uma autorização de pagamento na tela, talvez:

200 ms

importe muito.

Um relatório que precisa terminar até às 06:00 talvez possa esperar alguns minutos.

O WLM trabalha com a ideia de objetivos de serviço, classes de serviço, importância e gerenciamento dinâmico dos recursos disponíveis.

É uma mudança conceitual enorme.

Em vez de perguntar apenas:

Quem tem maior prioridade?

Perguntamos:

Quem está deixando de atingir seu objetivo de serviço?

Guarde essa frase.

Ela será fundamental para nossos agentes.

---

🤖 CAPÍTULO 3 — O AGENTE TAMBÉM É UM WORKLOAD

Suponha que tenhamos:

AGENT-CUSTOMER
AGENT-FRAUD
AGENT-REPORT
AGENT-COBOL
AGENT-MARKETING
AGENT-BACKUP

Cada um possui objetivos diferentes.

O agente de fraude talvez precise responder rapidamente.

AGENT-FRAUD
Target latency: < 2 s
Importance: HIGH

O agente que gera relatório:

AGENT-REPORT
Deadline: 06:00
Importance: MEDIUM

O agente que cataloga documentação antiga:

AGENT-ARCHIVE
Deadline: none
Importance: LOW

Agora chegam 500 solicitações.

Seria absurdo tratar todas igualmente.

Precisamos de classes.

Por exemplo:

PLATINUM
GOLD
SILVER
BACKGROUND

ou:

CRITICAL
INTERACTIVE
STANDARD
BATCH
BACKGROUND

O nome não importa tanto quanto a política.

O princípio é:

Workloads diferentes possuem necessidades diferentes.

---

🚦 CAPÍTULO 4 — PRIORIDADE NÃO SIGNIFICA “O CHEFE PASSA NA FRENTE”

Essa distinção é importante.

Prioridade técnica deveria refletir requisitos de serviço e negócio.

Não:

CEO_AGENT = 999999

😂

Imagine dois agentes.

AGENTE A

Atende um cliente que está esperando numa aplicação.

AGENTE B

Está analisando 200 mil documentos históricos.

Se ambos pedirem recursos ao mesmo tempo, talvez seja razoável favorecer A.

Não porque A seja “mais inteligente”.

Mas porque seu requisito de latência é diferente.

Podemos pensar:

INTERACTIVE
Objetivo: resposta < 2 s

BACKGROUND
Objetivo: concluir em 8 h

O background pode usar muitos recursos quando o sistema estiver ocioso.

Mas reduzir consumo quando workloads críticos precisarem deles.

Isso é muito mais sofisticado que:

PRIORIDADE = 1

---

📜 CAPÍTULO 5 — SLA E SLO: PROMESSA E OBJETIVO

Essas siglas aparecem frequentemente juntas.

Mas não são exatamente a mesma coisa.

SLA — Service Level Agreement

É um acordo de nível de serviço.

Pode envolver compromissos formais.

Por exemplo:

Disponibilidade mensal: 99,9%

ou:

95% das solicitações respondidas
em até 5 segundos.

SLO — Service Level Objective

É um objetivo mensurável usado para operar o serviço.

Exemplo:

p95 latency < 3 s

success rate > 99%

approval queue < 2 min

Para um agente:

AGENT-SUPPORT

SLO:
p95 response < 5 s
task success > 98%
tool error < 1%

Agora conseguimos comparar comportamento real com objetivo.

Sem objetivo, dizer:

LATENCY = 4.2 s

não significa muita coisa.

É bom?

Ruim?

Depende.

Se o objetivo era 30 segundos:

excelente.

Se era 500 milissegundos:

péssimo.

---

🎯 CAPÍTULO 6 — O SLO TRANSFORMA MÉTRICA EM DECISÃO

Lembra do nosso artigo anterior?

Criamos o SDSF dos agentes.

Agora sabemos:

latência
tokens
erros
tool calls
estado
custo

Mas métrica sem contexto é apenas número.

WLM acrescenta uma pergunta:

Esse número está atendendo ao objetivo?

Por exemplo:

AGENT-CUSTOMER

SLO p95:
2 s

CURRENT p95:
1.4 s

STATUS:
HEALTHY

Outro:

AGENT-FRAUD

SLO p95:
1 s

CURRENT p95:
4.8 s

STATUS:
VIOLATING OBJECTIVE

Agora temos uma razão para agir.

Talvez o segundo workload precise receber recursos adicionais.

Essa é a ponte entre:

OBSERVABILIDADE

e:

GERENCIAMENTO

O SDSF nos ajuda a enxergar.

O WLM nos ajuda a decidir como tratar a carga.

---

🚗 CAPÍTULO 7 — FILA NÃO É FALHA

Programadores iniciantes às vezes enxergam:

QUEUED

como algo ruim.

Não necessariamente.

Fila é uma ferramenta extraordinariamente importante.

Imagine uma ponte que suporta:

50 veículos

Chegam:

500 veículos

Temos duas opções.

Opção 1

Liberar os 500.

Resultado:

💥

Opção 2

Controlar entrada.

50 passam
450 aguardam

A fila protege o recurso.

Em agentes:

500 requests
     ↓
   QUEUE
     ↓
50 concurrent workers
     ↓
LLM / API / Db2

Fila não significa necessariamente:

Sistema ruim.

Pode significar:

Sistema protegendo a própria capacidade.

---

🌊 CAPÍTULO 8 — BACKPRESSURE: QUANDO O SISTEMA DIZ “DEVAGAR”

Imagine uma cadeia:

AGENTE
  ↓
API
  ↓
MQ
  ↓
CICS
  ↓
Db2

O agente consegue produzir:

1.000 requests/s

Mas o componente seguinte consegue consumir:

100 requests/s

Se continuarmos produzindo 1.000 indefinidamente, acumularemos:

900
1.800
2.700
3.600
...

A fila cresce.

Memória cresce.

Latência cresce.

Timeouts aparecem.

Retries aparecem.

E os retries produzem ainda mais carga.

Bem-vindo à festa.

Backpressure significa permitir que componentes posteriores sinalizem:

Estou saturado. Diminua o ritmo.

Conceitualmente:

PRODUTOR RÁPIDO
      ↓
CONSUMIDOR SATURADO
      ↓
BACKPRESSURE
      ↓
PRODUTOR REDUZ RITMO

Isso é fundamental para agentes.

Porque uma IA capaz de gerar chamadas rapidamente não deveria concluir:

A API está lenta. Vou chamar mais dez vezes.

😂

---

🚧 CAPÍTULO 9 — RATE LIMIT: VOCÊ SÓ PODE PASSAR N VEZES

Outra ferramenta importante:

RATE LIMITING.

Exemplo:

100 requests/minute

Se o agente ultrapassar:

HTTP 429
Too Many Requests

Rate limits protegem serviços contra excesso de chamadas.

Podemos estabelecer:

AGENT-REPORT
100 calls/min

AGENT-CUSTOMER
500 calls/min

AGENT-BACKGROUND
20 calls/min

Ou limites por:

usuário
agente
tenant
API
modelo
ferramenta

Isso impede que um único agente consuma toda a capacidade.

---

🚿 CAPÍTULO 10 — THROTTLING: FECHE UM POUCO A TORNEIRA

Rate limit e throttling são conceitos relacionados, mas podemos pensar pedagogicamente assim:

Rate limit:

existe um limite de consumo permitido.

Throttling:

o sistema reduz deliberadamente o ritmo.

Imagine uma torneira.

Capacidade máxima:

100 litros/min

Em situação normal:

80

Durante congestionamento:

30

Para agentes, podemos reduzir:

concorrência
requisições
tokens
tool calls

em momentos de pressão.

Um agente de baixa prioridade pode passar de:

20 workers

para:

5 workers

enquanto um serviço crítico recebe capacidade.

---

🎟️ CAPÍTULO 11 — QUOTAS: VOCÊ TEM UM ORÇAMENTO

Agora entra outro conceito.

Quota.

Imagine:

AGENT-MARKETING
Daily token quota:
5,000,000

AGENT-DEVELOPMENT
Daily token quota:
10,000,000

AGENT-EXPERIMENTAL
Daily token quota:
500,000

Quota pode existir para:

tokens
API calls
CPU
storage
requests
tool executions
money

Isso é particularmente interessante em IA porque recursos frequentemente possuem custo diretamente mensurável.

Sem quota, alguém pode escrever:

Analise tudo.

O agente interpreta:

Claro.

Quatro horas depois:

82 milhões de tokens

Financeiro entra no CPD carregando uma espada.

---

💰 CAPÍTULO 12 — CUSTO É UM RECURSO

No mainframe, sempre aprendemos que computação custa.

Não existe almoço grátis.

Nem café grátis.

Muito menos CPU grátis.

Na IA moderna, custo pode aparecer de maneira explícita por:

token
request
model
tool
storage
compute

Portanto o scheduler de agentes pode considerar não apenas:

LATENCY

mas:

COST

Imagine:

AGENT-A

Expected cost:
$0.02

AGENT-B

Expected cost:
$8.40

Se B é um processamento de baixa prioridade, talvez possa aguardar.

Podemos inclusive imaginar políticas:

IF DAILY_BUDGET > 80%
   THROTTLE BACKGROUND AGENTS
END-IF

Olha o COBOL aparecendo.

---

👨‍💻 CAPÍTULO 13 — UM WLM DE AGENTES EM PSEUDO-COBOL

Vamos brincar.

       EVALUATE AGENT-CLASS

           WHEN 'CRITICAL'
               MOVE 50 TO MAX-CONCURRENCY
               MOVE 1000 TO RATE-LIMIT

           WHEN 'INTERACTIVE'
               MOVE 25 TO MAX-CONCURRENCY
               MOVE 500 TO RATE-LIMIT

           WHEN 'STANDARD'
               MOVE 10 TO MAX-CONCURRENCY
               MOVE 200 TO RATE-LIMIT

           WHEN 'BACKGROUND'
               MOVE 2 TO MAX-CONCURRENCY
               MOVE 50 TO RATE-LIMIT

       END-EVALUATE.

Naturalmente um sistema real seria muito mais sofisticado.

Mas o exemplo ensina a ideia:

Nem todo workload recebe a mesma capacidade.

Agora acrescentamos pressão:

       IF SYSTEM-LOAD > 80
           COMPUTE BACKGROUND-LIMIT =
                   BACKGROUND-LIMIT / 2
       END-IF.

E custo:

       IF DAILY-AI-COST > DAILY-BUDGET
           MOVE 'PAUSED' TO BACKGROUND-AGENTS
       END-IF.

Pronto.

Criamos o WLMZINHO.CBL.

Não coloque em produção.

😂

---

🧵 CAPÍTULO 14 — CONCORRÊNCIA: QUANTOS PODEM TRABALHAR JUNTOS?

Imagine:

MAX CONCURRENCY = 20

Isso significa que no máximo vinte execuções trabalham simultaneamente.

As outras aguardam.

100 requests
    ↓
20 EXECUTING
80 QUEUED

Quando uma termina:

19 EXECUTING
81?

Não.

A fila libera outra:

20 EXECUTING
79 QUEUED

Esse controle evita saturação.

Mas o número correto depende do recurso.

Talvez:

LLM concurrency = 100
Db2 concurrency = 30
CICS tool calls = 50
External API = 10

Portanto um agente pode possuir múltiplos limites simultaneamente.

---

🪆 CAPÍTULO 15 — UMA FILA DENTRO DE OUTRA FILA

Aqui começa a diversão de verdade.

O agente está na fila.

Quando começa, chama uma ferramenta.

A ferramenta entra em outra fila.

Ela consulta Db2.

Outra fila.

Depois chama API externa.

Rate limit.

Temos:

AGENT QUEUE
     ↓
LLM QUEUE
     ↓
TOOL QUEUE
     ↓
API QUEUE
     ↓
DB QUEUE

Por isso observar apenas:

AGENT WAITING

não basta.

Precisamos saber:

Esperando o quê?

Lembra do SDSF dos agentes?

Agora ele precisa mostrar:

STATE:
WAITING_RESOURCE

RESOURCE:
DB2-CONNECTION

WAIT:
00:00:08

Isso conecta diretamente observabilidade e workload management.

---

🔥 CAPÍTULO 16 — O RETRY STORM: O MONSTRO QUE SE ALIMENTA DO PRÓPRIO ERRO

Imagine que uma API começa a falhar.

Agente:

Tentativa 1 → falhou

Ele tenta novamente.

Tentativa 2 → falhou

Agora 500 agentes fazem isso.

500 failures
↓
500 retries
↓
500 failures
↓
1.000 retries

O sistema já estava com problemas.

Agora recebe ainda mais carga.

Isso é o equivalente computacional de ver uma porta congestionada e resolver:

TODO MUNDO EMPURRA!

Precisamos de:

retry limit
exponential backoff
jitter
circuit breaker

Exemplo:

Retry 1 → wait 1s
Retry 2 → wait 2s
Retry 3 → wait 4s
Retry 4 → stop

Com jitter, os agentes não voltam todos exatamente no mesmo instante.

Isso evita o famoso:

THUNDERING HERD

a manada trovejante.

Nome maravilhoso.

Problema terrível.

---

🛑 CAPÍTULO 17 — LOAD SHEDDING: ÀS VEZES PRECISAMOS DIZER NÃO

Essa ideia pode parecer estranha.

Um sistema bem projetado às vezes precisa recusar trabalho.

Imagine capacidade:

100 requests/s

Chegam:

10.000 requests/s

Se tentarmos aceitar tudo:

latência ↑
memória ↑
timeouts ↑
falhas ↑

Talvez seja melhor responder rapidamente:

BUSY
TRY LATER

para parte das requisições.

Isso é load shedding.

Sacrificamos parte da carga para proteger o sistema inteiro.

É melhor:

90% funcionando
10% recusado claramente

do que:

100% aceito
100% travado

Essa é uma lição brutal, mas importante.

---

🏥 CAPÍTULO 18 — TRIAGEM DE PRONTO-SOCORRO

Uma boa analogia é um pronto-socorro.

Chegam cem pessoas.

A ordem não deveria ser simplesmente:

quem chegou primeiro

A gravidade importa.

Nos agentes:

CRITICAL INCIDENT

talvez passe à frente de:

GENERATE WEEKLY SUMMARY

Isso não significa ignorar o segundo.

Significa administrar recursos segundo objetivos.

Uma fila inteligente pode considerar:

priority
deadline
age
cost
resource requirements
business importance

Mas cuidado.

Se sempre atendermos os críticos, workloads de baixa prioridade podem nunca executar.

Isso é starvation.

Precisamos impedir que o pobre agente background fique:

QUEUED
QUEUED
QUEUED
QUEUED
QUEUED

até 2047.

---

👴 CAPÍTULO 19 — AGING: RESPEITE OS VELHINHOS DA FILA

Uma técnica clássica é aumentar gradualmente a prioridade de trabalhos que esperam demais.

Exemplo:

BACKGROUND
priority = 1

Depois de uma hora:

priority = 2

Depois:

priority = 3

Assim ele eventualmente recebe recursos.

Isso é chamado de aging em contextos de scheduling.

O princípio é simples:

Quanto mais tempo você espera, mais difícil fica ignorá-lo.

É praticamente a fila do INSS implementada corretamente.

---

⚖️ CAPÍTULO 20 — FAIRNESS: NÃO DEIXE UM AGENTE COMER O BUFFET INTEIRO

Imagine dez departamentos.

Um deles dispara:

90% das requisições

Sem isolamento, ele pode consumir quase toda a capacidade.

Precisamos pensar em fairness.

Por exemplo:

FINANCE....... 25%
CUSTOMER...... 30%
SECURITY...... 20%
DEVELOPMENT... 15%
BACKGROUND.... 10%

Não necessariamente percentuais rígidos.

Capacidade ociosa pode ser emprestada.

Se Security não usa seus 20%, Background pode aproveitar.

Mas quando Security precisar:

DEVOLVE!

Esse conceito de capacidade compartilhada com políticas é muito poderoso.

---

📈 CAPÍTULO 21 — ESCALONAMENTO: CHEGOU MAIS TRABALHO, CHAME REFORÇOS

Outra possibilidade:

queue_depth > 100

Então:

increase workers

Isso é escalonamento.

Pode ser:

horizontal

mais instâncias.

Ou:

vertical

mais recursos por instância.

Mas existe uma armadilha.

Você pode escalar seus workers infinitamente.

O Db2 talvez não possa.

Imagine:

AGENTS: 10 → 100 → 1000

mas:

DB CONNECTIONS: 100

Parabéns.

Você acabou de criar 900 processos esperando conexão.

Escalar o produtor sem considerar o consumidor apenas desloca o gargalo.

---

🔭 CAPÍTULO 22 — O SDSF E O WLM DOS AGENTES PRECISAM CONVERSAR

Nosso painel anterior mostrava:

AGENT       STATE       LATENCY
REPORT      RUNNING     3.2s
FRAUD       RUNNING     4.8s
ARCHIVE     RUNNING     8.1s

Agora acrescentamos:

CLASS        SLO       GOAL STATUS
STANDARD     5s        OK
CRITICAL     1s        VIOLATED
BACKGROUND   60s       OK

Resultado:

AGENT   CLASS       P95    SLO   STATUS
FRAUD   CRITICAL    4.8s   1s    🔴
REPORT  STANDARD    3.2s   5s    🟢
ARCHIVE BACKGROUND  8.1s   60s   🟢

Quem precisa de atenção?

Não necessariamente quem possui maior latência absoluta.

ARCHIVE demora 8,1 segundos.

Mas seu objetivo permite 60.

FRAUD demora 4,8.

Seu objetivo é 1.

Portanto:

FRAUD

está sofrendo mais em relação ao objetivo.

Esse é um raciocínio muito mais poderoso.

---

🎛️ CAPÍTULO 23 — O PAINEL DO WLM DOS AGENTES

Imagine:

AI WORKLOAD MANAGER
────────────────────────────────────────────────────────

CLASS        ACTIVE  QUEUED  P95   SLO   GOAL
CRITICAL       42       3    0.8s  1s    OK
INTERACTIVE    88      21    2.4s  2s    MISS
STANDARD       54     140    5.1s  10s   OK
BACKGROUND     12     812    18s   60s   OK

TOKENS/MIN......... 1.8M
COST/HOUR.......... $41.27
DB2 POOL........... 91%
CICS LATENCY....... 180ms
API RATE LIMIT..... 82%

Agora o operador vê a situação.

E o sistema pode agir:

INTERACTIVE SLO violated
↓
reduce BACKGROUND concurrency
↓
allocate capacity to INTERACTIVE
↓
monitor result

Isso começa a parecer familiar para quem conhece WLM.

---

🧙 CAPÍTULO 24 — TURING DESENHA A ESCADA

Turing pega o giz.

Escreve:

AGENTE
↓
WORKLOAD
↓
CLASSIFICAÇÃO
↓
OBJETIVO DE SERVIÇO
↓
OBSERVABILIDADE
↓
CONTROLE DE RECURSOS
↓
FEEDBACK

Depois desenha um loop:

     OBJETIVO
        ↓
     EXECUÇÃO
        ↓
     MÉTRICAS
        ↓
   ESTÁ CUMPRINDO?
      ↙      ↘
    SIM      NÃO
     ↓        ↓
 MANTÉM    AJUSTA
     ↑        │
     └────────┘

O jovem COBOL observa.

— Então não definimos uma prioridade e esquecemos?

— Exatamente.

Gerenciamento moderno de workload é um problema de feedback.

Observe.

Meça.

Compare com objetivo.

Ajuste.

Observe novamente.

---

🧩 CAPÍTULO 25 — O AGENTE PODE TER MAIS DE UM RECURSO CRÍTICO

Outro detalhe importante.

Um agente pode estar ótimo em CPU e péssimo em:

tokens

Ou ótimo em tokens e bloqueado em:

Db2

Ou ótimo no Db2 e limitado pela:

API externa

Portanto precisamos enxergar múltiplas dimensões:

CPU
MEMORY
TOKEN RATE
LLM CONCURRENCY
DB CONNECTIONS
API RATE
NETWORK
COST

A pergunta deixa de ser:

Temos capacidade?

e vira:

Temos capacidade onde?

Essa pequena palavra muda muita coisa.

---

💡 CAPÍTULO 26 — DICAS PRÁTICAS PARA QUEM ESTÁ COMEÇANDO

Quando começar a trabalhar com agentes, pense desde cedo em workload.

Não espere chegar aos 500 agentes.

Comece perguntando:

1. Qual é o objetivo?

Gerar relatório?
Responder cliente?
Detectar fraude?

2. Qual é o prazo?

500 ms?
5 s?
1 min?
6 h?

3. Qual é a importância?

critical
interactive
standard
background

4. Quais recursos usa?

LLM
Db2
CICS
API
MQ
filesystem

5. Quais limites existem?

rate limit
concurrency
quota
budget

6. O que acontece na saturação?

queue?
throttle?
reject?
degrade?

7. Como saberemos que está ruim?

SLO
metrics
alerts

Essas perguntas evitam muito sofrimento futuro.

---

🥚 EASTER EGG — O AGENTE VIP

São 09:13.

O operador percebe:

AGENT-VIP
PRIORITY = MAXIMUM

Turing pergunta:

— Quem é esse?

— Agente da diretoria.

— Qual o SLO?

— Não tem.

— Qual workload?

— Faz resumo de notícias internas.

Turing olha para outro painel:

AGENT-FRAUD
QUEUED

— E esse?

— Detecta transações suspeitas.

Silêncio.

Turing aponta para AGENT-VIP.

— Por que ele possui prioridade máxima?

O programador responde:

— Porque pediram.

O pequeno robô começa lentamente a se afastar.

Do outro lado do CPD, o administrador WLM fecha os olhos.

Turing pega o café.

— Acabamos de descobrir por que governança existe.

---

👑 CAPÍTULO 27 — PRIORIDADE TAMBÉM PRECISA DE GOVERNANÇA

Esse ponto é fundamental.

Se qualquer equipe puder declarar:

MY_AGENT = CRITICAL

em poucas semanas teremos:

500 CRITICAL AGENTS

E então:

CRITICAL

não significa absolutamente nada.

Precisamos de critérios.

Por exemplo:

CRITICAL
Impacto financeiro imediato
ou risco operacional grave.

INTERACTIVE
Humano aguardando resposta.

STANDARD
Processamento normal.

BACKGROUND
Sem interação humana imediata.

Classificação precisa ser governada.

Caso contrário ocorre a inflação de prioridade.

É como colocar:

URGENTE!!!

em todos os e-mails.

Depois de algum tempo ninguém acredita mais.

---

🛡️ CAPÍTULO 28 — DEGRADAÇÃO GRACIOSA

Imagine que o modelo mais poderoso esteja saturado.

Temos duas escolhas.

A

Falhar.

B

Talvez usar um modelo menor para tarefas compatíveis.

PREMIUM MODEL
      ↓ saturado
SMALL MODEL

Ou reduzir funcionalidades.

FULL ANALYSIS
      ↓ pressão
BASIC ANALYSIS

Isso é uma forma de graceful degradation.

O sistema continua oferecendo valor, embora em nível reduzido.

Mas cuidado.

Nunca faça downgrade silencioso quando isso alterar requisitos críticos de qualidade ou segurança.

A UX precisa informar quando o comportamento muda de maneira relevante.

---

📉 CAPÍTULO 29 — ERROR BUDGET: QUANTO PODEMOS ERRAR?

Em práticas de SRE aparece um conceito interessante:

error budget.

Se nosso SLO é:

99.9%

não estamos declarando perfeição absoluta.

Existe uma margem de falha tolerada.

O orçamento de erro ajuda a equilibrar:

confiabilidade

e:

velocidade de mudança

Para agentes, o conceito pode inspirar discussões úteis.

Mas precisamos tomar cuidado.

Não significa:

O agente tem autorização para errar 0,1% das transferências bancárias.

😂

Contexto importa.

Algumas operações exigem controles muito mais rigorosos.

O princípio é operacional:

Defina objetivos mensuráveis e saiba quanto desvio é tolerável antes de tomar ação.

---

🧠 CAPÍTULO 30 — A INTELIGÊNCIA NÃO ELIMINA A FILA

Talvez esta seja a conclusão mais divertida.

Passamos décadas tornando máquinas mais inteligentes.

Criamos:

machine learning
deep learning
LLMs
agents

E finalmente construímos software capaz de:

interpretar
planejar
decidir
usar ferramentas

Então colocamos 500 deles juntos.

E descobrimos que eles precisam...

pegar senha.

😂

Porque inteligência não cria CPU infinita.

Não cria banda infinita.

Não cria conexões Db2 infinitas.

Não cria tokens infinitos.

E definitivamente não cria orçamento infinito.

Portanto até uma sociedade de agentes precisa de:

fila
prioridade
quota
limite
scheduler

Alguns problemas sobrevivem a todas as revoluções tecnológicas.

---

🏰 CAPÍTULO 31 — A GRANDE ARQUITETURA DOS AGENTES

Agora podemos juntar os artigos anteriores.

Imagine:

                    HUMANO
                       │
                       ▼
                    OBJETIVO
                       │
                       ▼
                ┌────────────┐
                │   AGENTE   │
                └────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
       LLM            APIs           TOOLS
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                    SISTEMAS

Ao redor:

RACF
→ quem pode fazer?

PF3
→ posso parar?

SDSF
→ o que está fazendo?

MAXCC
→ funcionou?

WLM
→ quem recebe recursos primeiro?

Agora nossa arquitetura começa a parecer adulta.

---

☕ EPÍLOGO — ATÉ ROBÔ PRECISA ESPERAR SUA VEZ

No final do dia, Turing voltou ao painel.

Às 09:00 havia:

500 agentes

todos tentando executar simultaneamente.

Agora o sistema mostrava:

AI WORKLOAD MANAGER

CRITICAL
ACTIVE: 42
QUEUED: 3
SLO: OK

INTERACTIVE
ACTIVE: 80
QUEUED: 17
SLO: OK

STANDARD
ACTIVE: 40
QUEUED: 121
SLO: OK

BACKGROUND
ACTIVE: 10
QUEUED: 287
SLO: OK

O pequeno robô protestou:

— Mas existem 287 agentes esperando!

Turing respondeu:

— Sim.

— Isso não é ruim?

— Não necessariamente.

— Mas eles poderiam estar trabalhando.

— Não.

Turing apontou para o painel:

DB2 POOL......... 72%
CICS............. HEALTHY
API ERRORS....... 0.2%
P95.............. WITHIN SLO
COST/HOUR........ CONTROLLED

— Eles poderiam estar competindo.

Essa é uma diferença importante.

Um sistema saudável não é aquele no qual tudo executa imediatamente.

É aquele no qual o trabalho certo recebe os recursos certos no momento certo, enquanto o restante espera de maneira controlada.

Essa lição existe no mainframe há décadas.

E continuará existindo quando nossos sistemas forem povoados por milhares de agentes.

Porque o problema fundamental nunca foi apenas executar trabalho.

Foi administrar:

DEMANDA

contra:

CAPACIDADE

respeitando:

OBJETIVOS

e:

PRIORIDADES

sem destruir:

CONFIABILIDADE

ou:

ORÇAMENTO.

Turing escreve cinco perguntas no quadro:

RACF
QUEM PODE?

PF3
POSSO PARAR?

SDSF
O QUE ESTÁ FAZENDO?

MAXCC
FUNCIONOU?

WLM
QUEM PASSA PRIMEIRO?

O jovem programador COBOL observa aquilo por alguns segundos.

— Professor...

— Sim?

— Estamos realmente inventando o futuro ou apenas reencontrando problemas antigos em abstrações novas?

Turing sorri.

Talvez essa seja uma das perguntas mais importantes de toda esta série.

A computação muda de linguagem.

Muda de interface.

Muda de hardware.

Muda de arquitetura.

Muda de escala.

Mas determinados problemas permanecem:

identidade,

autoridade,

observabilidade,

prioridade,

recuperação,

capacidade,

controle.

Chamávamos uma unidade de trabalho de:

JOB

Agora podemos chamá-la de:

AGENT RUN

Chamávamos o gerenciamento de recursos de:

WORKLOAD MANAGEMENT

E talvez continuemos chamando exatamente assim.

Porque quando 500 inteligências artificiais levantarem a mão ao mesmo tempo e disserem:

Eu quero trabalhar!

alguém — humano ou software — ainda terá que responder:

Pegue uma senha.

No canto da tela aparece:

AGENT-ARCHIVE
STATE: QUEUED
POSITION: 287

O robô pergunta:

— Quanto tempo?

Turing olha para o WLM.

— Depende da importância do seu trabalho.

O robô cruza os braços.

— Isso é discriminação contra inteligências artificiais.

O operador responde do fundo do CPD:

— Não. É capacity planning.

READY

E havia outros 286 agentes na frente dele.