 |
| Bellacosa Mainframe monitorando a ia |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🔭 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS A INTELIGÊNCIA ARTIFICIAL ESTÁ FAZENDO AGORA?
Observabilidade, logs, métricas, traces, spans, OpenTelemetry, tokens, custos, latência, estados, workflows, auditoria, SDSF, JES2, SMF, RMF, CICS — e o dia em que Alan Turing descobriu que “AGENT RUNNING...” era quase tão informativo quanto um operador responder “sei lá, está processando”.
🎬 PRÓLOGO — O ROBÔ ESTAVA “TRABALHANDO”
Alan Turing entrou novamente no CPD.
O pequeno agente de IA estava diante de um terminal.
Na tela:
AGENT STATUS
============
RUNNING...Turing esperou.
Um minuto.
Dois minutos.
Cinco minutos.
Continuava:
RUNNING...O jovem programador COBOL apareceu carregando café.
— Bom dia, professor.
Turing apontou para a tela.
— O que ele está fazendo?
— Trabalhando.
— Em quê?
— Não sei.
— Em qual etapa?
— Também não sei.
— Encontrou algum erro?
— Acho que não.
— Quanto já gastou?
— Não faço ideia.
— Está esperando alguma coisa?
— Talvez.
Turing olhou novamente para:
RUNNING...e sentenciou:
— Então vocês construíram uma máquina capaz de tomar decisões, utilizar ferramentas e executar ações... mas colocaram nela a mesma lâmpada de “ocupado” de uma impressora de 1987?
Silêncio.
No fundo do CPD alguém apertou Enter tentando não rir.
Turing puxou uma cadeira.
— Abra o SDSF.
E assim começou nossa terceira aventura.
🏛️ CAPÍTULO 1 — NO MAINFRAME, “ESTÁ RODANDO” NUNCA FOI RESPOSTA SUFICIENTE
Imagine que você submeta:
//PAYROLL JOB ...
//STEP01 EXEC PGM=PAYCALC
//STEP02 EXEC PGM=REPORT
//STEP03 EXEC PGM=ARCHIVEVocê pergunta ao operador:
Como está o PAYROLL?
E ele responde:
Está fazendo coisas.
Provavelmente essa resposta não sobreviveria muitos minutos no CPD.
Queremos saber:
JOBNAME
JOBID
OWNER
STATUS
QUEUE
STEP
RETURN CODE
OUTPUTO SDSF existe justamente nesse universo de monitorar e controlar processamento z/OS. A documentação da IBM descreve painéis capazes de acompanhar jobs desde a fila de entrada do JES, passando pelo processamento, até as filas de saída; o painel ST, por exemplo, é central para gerenciamento de jobs e output.
Podemos encontrar algo como:
JOBNAME JOBID OWNER ST CC
PAYROLL JOB12345 BELLACOSA OUTPUT 0000
FATURAM JOB12346 FINANCE OUTPUT 0008
BACKUP JOB12347 OPERADOR EXEC
REPORT JOB12348 BELLACOSA ABEND S0C7Isso muda tudo.
Não sabemos apenas:
“O computador está ocupado.”
Sabemos quem, o quê, onde e em qual estado.
É exatamente esse salto que precisamos fazer com agentes.
🤖 CAPÍTULO 2 — O AGENTE PRECISA DE UM JOBNAME
Imagine vários agentes corporativos:
AGENT-PAYROLL
AGENT-REPORT
AGENT-SUPPORT
AGENT-COBOL
AGENT-AUDITAgora imagine dezenas de execuções simultâneas.
Dizer:
AGENT RUNNINGé quase inútil.
Precisamos de identidade para a execução.
Por exemplo:
AGENT RUN-ID OWNER STATUS
REPORT A000471 VAGNER RUNNING
COBOLSCAN A000472 DEVTEAM WAITING
SUPPORT A000473 SERVICE APPROVAL
PAYROLL A000474 FINANCE FAILEDPerceba a analogia:
JOBNAME → AGENT/WORKFLOW
JOBID → RUN-ID
OWNER → USUÁRIO/SERVIÇO
STATUS → ESTADO DO WORKFLOWNão são equivalências técnicas perfeitas.
São equivalências conceituais.
E são extremamente úteis para pensar UX.
Porque quando alguém disser:
O agente fez besteira!
a primeira pergunta deveria ser:
Qual execução?
🚦 CAPÍTULO 3 — “RUNNING” NÃO É UM ESTADO SUFICIENTE
Um agente pode estar em situações completamente diferentes enquanto a interface simplesmente mostra:
RUNNINGEle pode estar:
PLANNING
READING
WAITING_TOOL
EXECUTING_TOOL
RETRYING
WAITING_APPROVAL
PAUSED
ROLLING_BACK
COMPLETED
FAILED
CANCELLEDIsso importa muito.
Compare:
AGENT: REPORT
STATUS: RUNNINGcom:
AGENT: REPORT
RUN-ID: A000471
OBJECTIVE:
Consolidar relatórios de setembro
CURRENT STATE:
WAITING_APPROVAL
CURRENT STEP:
5/7 - Enviar relatório financeiro
WAITING FOR:
Aprovação humana
WAIT TIME:
00:03:42Agora sabemos o que está acontecendo.
Talvez o agente nem esteja consumindo processamento significativo.
Está simplesmente esperando alguém.
Uma boa interface precisa diferenciar:
TRABALHANDOde:
ESPERANDOe de:
TRAVADOParece óbvio.
Até você encontrar sistemas que tratam os três como:
PROCESSING...
🪵 CAPÍTULO 4 — LOG: O DIÁRIO DE BORDO
Primeiro instrumento da nossa caixa de observabilidade:
LOG.
Log é basicamente o registro de eventos ocorridos.
O OpenTelemetry define logs como registros de eventos e suporta informações estruturadas como timestamp, severidade, corpo, atributos e também identificadores de trace e span, permitindo correlação com outros sinais.
Um log simples:
10:01:03 Agent started
10:01:04 Reading report
10:01:12 Report loaded
10:01:13 Calling model
10:01:18 Analysis completedJá ajuda.
Mas podemos fazer melhor.
timestamp=10:01:03
agent=REPORT
run_id=A000471
event=workflow.started
owner=VAGNERDepois:
timestamp=10:01:12
agent=REPORT
run_id=A000471
event=file.read
file=REPORT-09
status=success
duration_ms=284Agora temos structured logging.
Em vez de texto para seres humanos lerem manualmente, possuímos campos que sistemas podem consultar.
Podemos perguntar:
event = tool.errorou:
run_id = A000471ou:
duration_ms > 5000Isso é tremendamente mais poderoso.
📜 CAPÍTULO 5 — O SYSOUT DO ROBÔ
Aqui o programador COBOL começa a sorrir.
Porque o conceito não é estranho.
Quando um job termina, frequentemente vamos investigar sua saída.
SDSF permite navegar pelos outputs de jobs e pelas informações de processamento; historicamente, muito output destinado ao JES sequer precisava ser fisicamente impresso — podia ser inspecionado no SDSF.
Nosso agente também deveria deixar evidências.
Algo como:
RUN A000471
AGENT........ REPORT
START........ 10:01:03
END.......... 10:02:44
DURATION..... 00:01:41
MODEL CALLS.. 4
TOOL CALLS... 7
FILES READ... 12
FILES WRITE.. 1
WARNINGS..... 2
ERRORS....... 0
RESULT........ COMPLETED_WITH_WARNINGSNão precisamos literalmente transformar agentes em JES.
Mas precisamos abandonar a filosofia:
“Ele respondeu, então provavelmente deu tudo certo.”
📊 CAPÍTULO 6 — MÉTRICA NÃO É LOG
Turing escreve:
LOG
≠
METRICLog responde muito bem a:
O que aconteceu?
Métrica responde melhor a:
Quanto está acontecendo?
Por exemplo:
agent_runs_total = 15420agent_failures_total = 327average_duration = 18.4 stool_calls_total = 92481approval_wait_time = 47.2 sinput_tokens = ...
output_tokens = ...OpenTelemetry é hoje um framework vendor-neutral para instrumentar, gerar, coletar e exportar telemetria, incluindo traces, metrics e logs.
Para aplicações GenAI, suas convenções incluem atributos relacionados ao uso de tokens e identificação de workflows/agentes; essas convenções específicas continuam evoluindo, portanto não devemos tratá-las como uma pedra gravada para toda a eternidade.
💰 CAPÍTULO 7 — AGORA A TELEMETRIA TEM CONTA PARA PAGAR
No mainframe sempre aprendemos que recurso computacional custa.
CPU.
I/O.
Storage.
Elapsed time.
Consumo não é abstração filosófica.
Com IA, aparece outro recurso:
TOKENSUma execução pode fazer:
CALL 1 → modelo
CALL 2 → modelo
CALL 3 → ferramenta
CALL 4 → modelo
CALL 5 → ferramenta
CALL 6 → modeloTalvez obtenha a resposta correta.
Mas quanto custou?
Um dashboard poderia mostrar:
RUN-ID............ A000471
MODEL CALLS....... 8
INPUT TOKENS...... 34,812
OUTPUT TOKENS..... 8,401
TOOL CALLS........ 14
DURATION.......... 01:47
ESTIMATED COST.... ...As convenções de GenAI do OpenTelemetry contemplam métricas e atributos de uso de tokens; a observabilidade pode então ajudar a detectar prompts excessivamente grandes, regressões de latência e padrões de consumo.
E aqui aparece um velho fantasma mainframe:
EFICIÊNCIA.
Um agente que consegue resolver uma tarefa em:
3 chamadaspode ser operacionalmente preferível a outro que precisa:
37 chamadasmesmo que ambos terminem corretamente.
⏱️ CAPÍTULO 8 — LATÊNCIA: O AGENTE DEMOROU, MAS ONDE?
Imagine:
TOTAL = 18 segundosIsso não nos diz muita coisa.
Talvez:
LLM............. 2 s
DATABASE........ 1 s
API............. 1 s
FILE............ 1 sEntão onde foram parar os outros 13 segundos?
Precisamos decompor.
É aí que entramos no mundo do distributed tracing.
🧵 CAPÍTULO 9 — TRACE: SIGA O FIO DE ARIADNE
Imagine uma execução completa:
Usuário
↓
Agente
↓
LLM
↓
Busca
↓
Db2
↓
LLM
↓
API
↓
ResultadoUm trace acompanha a operação através dessas etapas.
Dentro dele encontramos spans.
Podemos imaginar:
TRACE A000471
│
├─ SPAN 1 invoke_agent ........ 18.2s
│
├─ SPAN 2 plan ................ 1.1s
│
├─ SPAN 3 model_call .......... 2.4s
│
├─ SPAN 4 search_documents .... 4.8s
│
│ ├─ SPAN 5 api_call ........ 3.9s
│ └─ SPAN 6 parse ........... 0.7s
│
├─ SPAN 7 analyze ............. 5.2s
│
└─ SPAN 8 write_report ........ 1.4sAgora descobrimos:
Ahá!
A busca documental está custando quase cinco segundos.
Um span representa uma execução individual de uma operação significativa dentro de um trace; as convenções do OpenTelemetry padronizam atributos para facilitar correlação entre tecnologias diferentes.
🔬 CAPÍTULO 10 — TRACE É O “QUAL STEP ESTÁ DEMORANDO?” DO MUNDO DISTRIBUÍDO
Um programador batch entende isso rapidamente.
Imagine:
STEP01 00:00:01
STEP02 00:00:02
STEP03 00:14:37
STEP04 00:00:01Onde investigar?
Não precisa chamar Sherlock Holmes.
STEP03Tracing faz algo conceitualmente semelhante em sistemas distribuídos.
Mas existe uma complicação.
Um agente pode decidir dinamicamente qual ferramenta chamar.
Portanto duas execuções do mesmo objetivo podem seguir caminhos diferentes.
RUN A
Agent
├─ LLM
├─ Search
├─ Db2
└─ Reportenquanto:
RUN B
Agent
├─ LLM
├─ Search
├─ API
├─ Search novamente
├─ LLM
└─ ReportAgora tracing deixa de ser luxo.
Torna-se instrumento para entender o caminho realmente escolhido.
🧠 CAPÍTULO 11 — O AGENTE POSSUI UM “STEP” QUE NÃO EXISTIA NO JCL
No JCL tradicional, normalmente declaramos etapas.
//STEP01 EXEC PGM=A
//STEP02 EXEC PGM=B
//STEP03 EXEC PGM=CO agente pode raciocinar:
Talvez A.
Não.
Preciso consultar B.
Resultado incompleto.
Vou tentar C.
Agora preciso voltar para A.Isso é poderoso.
Mas torna a execução menos previsível.
Portanto precisamos registrar:
OBJETIVO
↓
DECISÃO
↓
FERRAMENTA ESCOLHIDA
↓
RESULTADO
↓
PRÓXIMA DECISÃONão precisamos — nem devemos — exigir exposição irrestrita de raciocínio interno privado do modelo.
Precisamos registrar decisões e eventos operacionalmente relevantes.
Por exemplo:
STEP 4
ACTION: customer_lookup
REASON: Dados insuficientes para validar pedido
RESULT: 1 customer found
NEXT: order_lookupIsso é auditável e útil sem transformar telemetria em uma descarga indiscriminada de conteúdo interno.
🔗 CAPÍTULO 12 — TRACE ID: O CPF DA EXECUÇÃO
Imagine receber:
ERROR 500Fantástico.
Onde?
Quando?
Para quem?
Em qual execução?
Precisamos de correlação.
Um identificador como:
trace_id = 7A91...pode acompanhar uma operação através de vários componentes.
E então um log pode carregar:
TraceId
SpanIdO modelo de logs do OpenTelemetry prevê justamente essa correlação, permitindo conectar registros a traces e spans.
Assim podemos sair de:
ERROR: timeoutpara:
RUN A000471
TRACE 7A91
SPAN DB2_QUERY
ERROR timeoutAgora temos pista.
🚨 CAPÍTULO 13 — MÉDIA É O MIMIC DA OBSERVABILIDADE
Você olha o dashboard:
Average latency = 2 secondsMaravilhoso.
Só que alguns usuários esperam 40 segundos.
A média esconde caudas.
Por isso sistemas modernos frequentemente observam percentis:
p50
p95
p99Exemplo:
p50 = 1.4 s
p95 = 5.8 s
p99 = 21.7 sAgora percebemos que uma pequena parcela das execuções sofre muito.
Isso vale especialmente para agentes porque workflows podem variar enormemente.
Uma execução consulta duas ferramentas.
Outra consulta vinte.
A média olha para ambas e diz:
Está tudo razoável.
O p99 começa a gritar no corredor.
❤️ CAPÍTULO 14 — MÉTRICAS DO AGENTE NÃO DEVEM SER APENAS TÉCNICAS
Imagine este dashboard:
CPU........ OK
MEMORY..... OK
LATENCY.... OK
ERRORS..... 0Excelente.
Mas o agente resolveu o problema?
Precisamos também de métricas funcionais.
Por exemplo:
TASK SUCCESS RATEHUMAN ESCALATION RATEROLLBACK RATEAPPROVAL REJECTION RATERETRY RATETOOL FAILURE RATEAVERAGE STEPS PER TASKCOST PER SUCCESSFUL TASKE aqui aparece uma métrica especialmente interessante:
TASK COMPLETEDnão deveria significar apenas:
O workflow chegou ao último nó.
Deveria significar:
O critério de sucesso foi realmente atingido.
É a diferença entre:
MAXCC=0000e:
O relatório contém os números corretos.
Velho problema.
Roupa nova.
🧾 CAPÍTULO 15 — OBSERVABILIDADE NÃO É AUDITORIA
Turing escreve no quadro:
OBSERVABILIDADE
≠
AUDITORIAObservabilidade pergunta:
O que está acontecendo com o sistema?
Auditoria pergunta:
Quem fez o quê, quando, com qual autoridade e qual foi o resultado?
Exemplo operacional:
tool_call duration=840msIsso é ótimo para observabilidade.
Mas uma trilha de auditoria pode precisar:
AGENT........ AGENT-CREDIT
RUN-ID....... A001991
REQUESTER.... USER471
ACTION....... CREDIT_LIMIT_CHANGE
CUSTOMER..... 98127
OLD_VALUE.... 10000
NEW_VALUE.... 15000
APPROVER..... MANAGER08
TIMESTAMP.... 14:32:11
RESULT....... SUCCESSAgora podemos reconstruir o evento.
Auditoria é particularmente importante quando o agente age em vez de apenas responder.
🔐 CAPÍTULO 16 — CUIDADO: OBSERVABILIDADE TAMBÉM PODE VAZAR SEGREDOS
Aqui aparece uma armadilha enorme.
Você decide:
Quero registrar tudo!
Prompt.
Resposta.
Documentos.
Argumentos das ferramentas.
Resultados.
Fantástico para debugging.
Talvez terrível para segurança.
Logs podem acabar contendo:
dados pessoais
segredos comerciais
credenciais
tokens
informação financeira
código proprietário
documentos confidenciaisA própria documentação de observabilidade GenAI chama atenção para o fato de que conteúdo de mensagens e tool calls pode ser capturado quando habilitado, enquanto implementações podem permitir desativar a exportação desse conteúdo.
Portanto:
Observabilidade não significa registrar tudo indiscriminadamente.
Precisamos pensar em:
REDACTION
MASKING
SAMPLING
RETENTION
ACCESS CONTROL
ENCRYPTIONO log também é dado.
E dado precisa de governança.
🧹 CAPÍTULO 17 — NÃO TRANSFORME O LOG NUM DEPÓSITO DE LIXO
Outro clássico.
DEBUG 1
DEBUG 2
ENTROU AQUI
PASSOU AQUI
TESTE
XYZ
AAAA😂
Todo programador já encontrou algum parente dessa criatura.
Logs úteis precisam responder perguntas.
Uma boa estrutura pode incluir:
timestamp
severity
service
agent
run_id
trace_id
span_id
event
tool
duration
status
error_typeE usar níveis coerentes:
DEBUG
INFO
WARN
ERRORNão transforme tudo em:
ERRORsenão o erro perde significado.
É o equivalente moderno de um painel inteiro piscando vermelho.
Depois de quinze minutos ninguém mais olha.
🌉 CAPÍTULO 18 — OPENTELEMETRY: UMA LÍNGUA COMUM
Em sistemas distribuídos temos:
Java
Python
Node
API Gateway
Kubernetes
Db2
MQ
CICS
Cloud
Mainframe
LLM
AgentCada componente poderia produzir telemetria de maneira completamente diferente.
Correlação viraria pesadelo.
OpenTelemetry tenta fornecer uma linguagem e arquitetura vendor-neutral para sinais de observabilidade, especialmente traces, metrics e logs.
Podemos imaginar:
APLICAÇÕES
↓
INSTRUMENTAÇÃO
↓
OpenTelemetry
↓
COLLECTOR
↓
BACKEND DE OBSERVABILIDADEO Collector pode receber, processar e exportar telemetria.
O objetivo não é:
“Comprar um dashboard bonito.”
É:
Padronizar a forma de produzir e transportar evidência operacional.
🏷️ CAPÍTULO 19 — CONVENÇÕES SEMÂNTICAS: CHAME A MESMA COISA PELO MESMO NOME
Imagine:
Sistema A:
durationSistema B:
elapsedSistema C:
execution_timeSistema D:
how_long_this_thing_took😂
Agora tente construir um dashboard corporativo.
Convenções semânticas procuram padronizar nomes e significados para operações e dados observáveis. O OpenTelemetry mantém convenções para traces, métricas, logs, profiles e resources.
No universo GenAI isso é especialmente importante.
Queremos poder falar de conceitos como:
agent
model
operation
tool
token usage
workflowde maneira consistente.
As convenções GenAI ainda estão evoluindo, o que é natural numa área que também está mudando rapidamente.
🧬 CAPÍTULO 20 — SDSF + SMF + RMF + OTEL: NÃO SÃO A MESMA COISA
Aqui precisamos evitar uma simplificação perigosa.
Não podemos dizer:
SDSF = OpenTelemetryNão é.
Nem:
SMF = logs
RMF = metricscomo equivalências técnicas exatas.
São tecnologias com histórias, escopos e arquiteturas diferentes.
Mas podemos construir uma ponte didática.
SDSF
Ajuda o operador a ver e controlar execução.
SMF
Produz enorme quantidade de registros operacionais e de accounting sobre atividades do sistema.
RMF
Historicamente fornece medição e análise de performance e recursos.
OpenTelemetry
Padroniza instrumentação e transporte de sinais modernos de observabilidade.
Então, pedagogicamente:
MAINFRAME
MUNDO DISTRIBUÍDO
SDSF ←→ Operational UI
SMF ←→ Telemetry records
RMF ←→ Performance metrics
Job/Step ←→ Trace/Span
JobID ←→ Run/Trace correlation
SYSOUT ←→ Logs / execution evidenceA seta significa:
“pense na função conceitual”
e não:
“são a mesma tecnologia”.
Essa diferença é importantíssima.
🖥️ CAPÍTULO 21 — COMO SERIA O “SDSF DOS AGENTES”?
Agora podemos desenhar.
Imagine:
AGENT OPERATIONS FACILITY
────────────────────────────────────────────────────
AGENT RUN-ID OWNER STATE TIME
REPORT A00471 VAGNER EXECUTING 00:01:47
COBOLSCAN A00472 DEV COMPLETE 00:00:38
PAYROLL A00473 FINANCE APPROVAL 00:03:12
SUPPORT A00474 CRM FAILED 00:00:09
BACKUP A00475 OPS RETRYING 00:00:41Coloque:
Sao lado de REPORT.
Abre:
OBJECTIVE
Consolidar relatórios mensais
CURRENT STEP
4/7 Analyze financial data
MODEL CALLS
5
TOOL CALLS
8
TOKENS
18,471 / 4,901
ELAPSED
00:01:47
WARNINGS
2
STATUS
EXECUTINGAgora:
Lpara logs.
Tpara trace.
Mpara metrics.
Ppara pause.
Cpara cancel.
Apara approvals.
Meu Deus.
Acabamos de reinventar uma workstation operacional para agentes.
O barbudo do mainframe começa a sorrir.
🧰 CAPÍTULO 22 — PASSO A PASSO: INSTRUMENTANDO MENTALMENTE UM AGENTE
Mesmo que você seja um COBOL iniciante e não vá implementar OpenTelemetry amanhã, aprenda o raciocínio.
PASSO 1 — IDENTIFIQUE A EXECUÇÃO
Nunca dependa apenas de:
agent_nameTenha algo equivalente a:
run_id
trace_idPASSO 2 — DEFINA OS ESTADOS
Por exemplo:
QUEUED
PLANNING
RUNNING
WAITING_TOOL
WAITING_HUMAN
PAUSED
COMPLETED
FAILED
CANCELLEDPASSO 3 — REGISTRE EVENTOS IMPORTANTES
Não cada suspiro eletrônico.
Mas:
workflow.started
tool.called
tool.failed
approval.requested
approval.received
checkpoint.created
rollback.started
workflow.completedPASSO 4 — MEÇA
latência
tokens
tool calls
retries
erros
tempo aguardando humano
custoPASSO 5 — TRACE AS DEPENDÊNCIAS
Quando a execução atravessar:
agent → API → Db2 → MQ → CICSpreserve correlação.
PASSO 6 — PROTEJA A TELEMETRIA
Não registre segredos simplesmente porque são úteis para debugging.
PASSO 7 — DEFINA SUCESSO
Não use apenas:
DONEUse critérios de negócio.
PASSO 8 — CONSTRUA ALERTAS ÚTEIS
Não alerte para tudo.
Alerte quando algo realmente exigir atenção.
🚨 CAPÍTULO 23 — O ALERTA QUE TOCA ÀS 3 DA MANHÃ
Todo sistema de observabilidade eventualmente encontra seu verdadeiro teste:
03:17.
Telefone toca.
ALERT:
AGENT FAILURE RATE > 25%Você abre o painel.
Descobre:
Tool: CUSTOMER-API
p99 latency: 31s
Timeout rate: 38%
Retries: 4.2 per runAgora existe hipótese.
Sem observabilidade:
A IA ficou burra.
Com observabilidade:
A API de clientes está degradada; o agente está repetindo chamadas e acumulando timeout.
Essa diferença é gigantesca.
Modelos inteligentes introduzem novas fontes de incerteza.
Não devemos atribuir todo problema ao modelo.
Pode ser:
modelo
prompt
tool
API
rede
Db2
MQ
permissão
rate limit
dados
timeout
bugObservabilidade separa fantasmas de evidências.
🧙 CAPÍTULO 24 — TURING DESENHA AS QUATRO PERGUNTAS
Turing pega o giz.
Escreve:
1. O QUE ESTÁ ACONTECENDO?Estado + logs.
2. QUANTO ESTÁ ACONTECENDO?Métricas.
3. POR ONDE PASSOU?Trace.
4. QUEM AUTORIZOU?Auditoria.
O jovem COBOL acrescenta uma quinta:
5. QUANTO CUSTOU?Turing olha.
— Muito bem.
O administrador do CPD acrescenta:
6. POSSO PARAR?E o administrador RACF:
7. ELE PODIA FAZER ISSO?Agora temos praticamente toda a série:
PF3
↓
POSSO PARAR?
MAXCC
↓
FUNCIONOU?
RACF
↓
PODIA FAZER?
SDSF
↓
O QUE ESTÁ FAZENDO?🥚 EASTER EGG — S A00471
São 02:58.
O jovem operador vê:
AGENT RUN-ID STATE
REPORT A00471 RUNNINGDigite:
S A00471A tela abre.
CURRENT ACTION:
Searching documentation
ELAPSED:
02:47:31
FILES FOUND:
4,281,771
CURRENT DIRECTORY:
/Silêncio.
Turing olha para o programador.
O programador olha para Turing.
O administrador de segurança derruba o café.
Alguém pergunta:
— Quem deu acesso ao filesystem inteiro?
Do fundo da sala vem uma voz:
— Foi para facilitar o protótipo.
O administrador RACF levanta lentamente da cadeira.
ICH408IFim do easter egg.
☕ EPÍLOGO — NÃO QUERO UMA IA TRANSPARENTE; QUERO UMA IA OPERÁVEL
Existe uma diferença importante.
Quando falamos em observabilidade, não estamos necessariamente exigindo enxergar todos os mecanismos internos de um modelo.
Queremos algo muito mais prático.
Queremos saber:
qual tarefa
qual execução
qual estado
qual etapa
qual ferramenta
quanto tempo
quanto recurso
qual erro
qual resultado
qual aprovaçãoEm outras palavras:
OPERABILIDADE.
Um agente corporativo precisa ser operável.
Precisa ser possível colocar alguém diante dele e perguntar:
O que está acontecendo?
E obter resposta melhor que:
RUNNING...Isso parece uma discussão sobre inteligência artificial.
Mas também é uma discussão profundamente antiga sobre sistemas.
O mainframe aprendeu há décadas que executar trabalho empresarial significa deixar evidência.
Jobs possuem identidade.
Execuções possuem estados.
Etapas possuem resultados.
Output pode ser examinado.
Falhas precisam ser investigadas.
Recursos precisam ser medidos.
A IBM descreve SDSF justamente como um meio seguro de monitorar e gerenciar sistemas z/OS, jobs, output, recursos e mensagens operacionais.
O mundo distribuído acrescentou novos desafios.
Microsserviços.
APIs.
Cloud.
Containers.
Mensageria.
Agora adicionamos:
LLMs.
Tools.
RAG.
Copilotos.
Agentes.
Mas a pergunta do operador continua assustadoramente parecida.
O que diabos está acontecendo agora?
OpenTelemetry nos oferece uma linguagem moderna para parte dessa investigação, reunindo logs, métricas e traces e permitindo correlação entre componentes.
E os agentes tornam essa disciplina ainda mais importante.
Porque não estamos observando apenas software executando um caminho predeterminado.
Podemos estar observando software escolhendo dinamicamente qual caminho executar.
Quanto maior a autonomia...
maior a necessidade de evidência.
Quanto mais ferramentas disponíveis...
mais importante a correlação.
Quanto mais passos dinâmicos...
mais necessário o tracing.
Quanto maior o custo variável...
mais importantes as métricas.
Quanto maior o poder de ação...
mais importante a auditoria.
Alan Turing volta ao terminal.
A tela agora mostra:
AGENT: REPORT
RUN-ID: A00471
STATUS........ WAITING_APPROVAL
STEP.......... 6/7
ELAPSED....... 00:01:48
MODEL CALLS... 5
TOOL CALLS.... 8
WARNINGS...... 2
ERRORS........ 0
ACTION........ SEND REPORT
RISK.......... EXTERNAL ACTION
APPROVAL...... REQUIRED
[P] PAUSE
[C] CANCEL
[L] LOG
[T] TRACE
[M] METRICS
[A] APPROVETuring toma um gole de café.
— Melhor.
O programador pergunta:
— Agora sabemos tudo?
Turing sorri.
— Claro que não.
— Então o que sabemos?
Ele aponta para a tela.
— Sabemos onde procurar.
Para um operador, um SRE, um programador COBOL ou qualquer pessoa que já tenha passado algumas horas tentando descobrir por que um sistema parou às três da manhã...
isso já é uma diferença gigantesca.
Porque o futuro talvez esteja cheio de agentes inteligentes.
Mas quando alguma coisa der errado, alguém ainda precisará abrir uma tela e perguntar:
STQual é o status?
Algumas perguntas sobrevivem a todas as revoluções tecnológicas.
READY
E, naturalmente...
há outro agente na fila.
🤖 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.
🧠 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 →🤖 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 →🔭 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? →⚖️ 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 →🏭 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? →⚡ 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 →🗄️ 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 →📨 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 →🌳 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 →☕ 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.
