 |
| Bellacosa Mainframe e a ux do agente |
☕ UM CAFÉ NO BELLACOSA MAINFRAME
🤖 ALAN TURING E A UX DOS AGENTES — QUANDO PF3, MAXCC E RACF VOLTARAM PARA SALVAR A INTELIGÊNCIA ARTIFICIAL
Agentes de IA, human-in-the-loop, least privilege, permissões, observabilidade, auditabilidade, rollback, checkpoints, guardrails, RACF, JCL, JES2, SDSF, CICS — e o dia em que o programador COBOL descobriu que dar autonomia a uma IA sem botão de emergência era quase como entregar SPECIAL no RACF para o estagiário.
🎬 PRÓLOGO — TURING VOLTOU AO CPD
Alan Turing estava novamente sentado diante do terminal.
Da última vez, nossa conversa havia começado com algo muito simples:
C:\>O computador esperava.
Nos tempos do CP/M e DOS, ele não tentava adivinhar o que queríamos. Precisávamos conhecer o comando, sua sintaxe e muitas vezes até o caminho completo do arquivo.
Depois vieram as interfaces gráficas.
Em vez de lembrar:
COPY
DEL
REN
DIRpassamos a reconhecer ícones, menus, janelas e botões.
Depois chegaram os sistemas de inteligência artificial generativa.
E a relação mudou novamente.
Em vez de explicar:
COMO FAZERcomeçamos a dizer:
O QUE QUEREMOSMas agora havia uma pequena criatura sobre a mesa.
Parecia um robô simpático.
Turing apontou para ela.
— Este não é apenas um chatbot.
— O que ele faz?
— Você dá um objetivo. Ele pode planejar etapas, consultar ferramentas, buscar informações e executar ações.
O jovem programador COBOL ficou alguns segundos olhando para a criatura.
Então perguntou:
— E se ele fizer besteira?
Turing sorriu.
— Finalmente chegamos à pergunta importante.
🧠 CAPÍTULO 1 — CHATBOT NÃO É A MESMA COISA QUE AGENTE
Precisamos começar pela base.
Quando conversamos com um chatbot tradicional, existe normalmente um ciclo relativamente simples:
USUÁRIO
↓
PROMPT
↓
MODELO
↓
RESPOSTA
↓
USUÁRIOVocê pergunta:
Explique este trecho COBOL.
A máquina responde.
Você continua no controle do fluxo.
Agora imagine algo diferente:
Analise todos os programas deste projeto, descubra quais utilizam o copybook
CLIENTE, identifique possíveis impactos de uma alteração de layout, crie um relatório e abra tarefas para os responsáveis.
Observe o tamanho da mudança.
A IA talvez precise:
entender o objetivo
↓
descobrir onde estão os programas
↓
pesquisar arquivos
↓
identificar dependências
↓
analisar código
↓
correlacionar resultados
↓
gerar relatório
↓
consultar responsáveis
↓
criar tarefas
↓
informar o resultadoNão estamos mais diante de uma simples geração de texto.
Temos um workflow.
E quando o sistema consegue controlar partes desse workflow e utilizar ferramentas para atingir o objetivo, entramos no território dos agentes.
É aqui que a UX muda radicalmente.
🪄 CAPÍTULO 2 — O BOTÃO “ENVIAR” NÃO É MAIS SUFICIENTE
Quando uma IA apenas escreve um texto, o principal objeto da interface é a resposta.
Você lê.
Gostou?
Usa.
Não gostou?
Descarta.
Mas imagine que o agente possa:
enviar e-mail;
alterar arquivo;
consultar banco de dados;
executar programa;
abrir ticket;
cancelar pedido;
modificar configuração;
criar usuário;
iniciar processo;
chamar uma API.
Agora a interface precisa responder perguntas completamente diferentes.
Por exemplo:
O que o agente está fazendo?
Por que está fazendo?
Qual ferramenta está usando?
Quais dados recebeu?
Qual informação enviará para fora?
Quanto já gastou?
Posso interrompê-lo?
Posso desfazer aquilo que ele acabou de fazer?
Quem autorizou esta ação?
Existe log?
Ele ultrapassou o objetivo original?
Essas perguntas parecem modernas.
Mas Turing olha para o jovem COBOL e pergunta:
— Tem certeza?
🏛️ CAPÍTULO 3 — O MAINFRAME JÁ CONHECE PARTE DESSE PROBLEMA
Imagine submeter um job:
//PAYROLL JOB ...
//STEP01 EXEC PGM=PAYCALC
//INFILE DD DSN=EMPRESA.FOLHA.INPUT,DISP=SHR
//OUTFILE DD DSN=EMPRESA.FOLHA.OUTPUT,
// DISP=(NEW,CATLG,DELETE)Você não entrega simplesmente um objetivo abstrato para o sistema.
Existe uma estrutura.
Sabemos:
qual programa será executado;
quais datasets entram;
quais datasets saem;
qual identidade submeteu;
quais recursos podem ser acessados;
qual foi o resultado;
qual etapa falhou.
O job entra no JES.
Você pode observá-lo no SDSF.
Depois aparecem informações como:
JOB12345
PAYROLL
CC 0000ou:
CC 0008ou:
ABEND S0C7Existe estado.
Existe identidade.
Existe execução.
Existe resultado.
Existe evidência.
Não estamos dizendo que JCL seja um sistema de agentes de IA.
Não é.
Mas muitos dos problemas de governança que estamos redescobrindo na IA possuem parentes conceituais muito antigos no processamento corporativo.
🚪 CAPÍTULO 4 — PF3: TODO AGENTE PRECISA SABER PARAR
Quem passou algum tempo em ISPF conhece a sensação.
Você entrou numa tela.
Terminou.
Quer voltar.
PF3Fim.
É claro que PF3 não é literalmente um mecanismo universal de emergência.
Mas ele oferece uma analogia excelente para uma propriedade fundamental da UX dos agentes:
INTERRUPTIBILIDADE
Se um agente está executando uma sequência de vinte ações, o usuário precisa saber:
que ele ainda está executando;
em qual etapa está;
o que já realizou;
o que pretende realizar;
como interrompê-lo.
Imagine uma interface mostrando apenas:
Working...Cinco minutos.
Dez minutos.
Quinze minutos.
O usuário começa a pensar:
Trabalhando em quê?
Essa é péssima UX para sistemas autônomos.
Uma interface melhor poderia apresentar:
OBJETIVO:
Preparar relatório mensal
[✓] Localizar arquivos
[✓] Validar período
[✓] Consolidar planilhas
[>] Consultar sistema financeiro
[ ] Gerar relatório
[ ] Enviar para aprovaçãoE ao lado:
PAUSAR
CANCELAR
VER DETALHESO velho PF3 acaba de renascer.
Só que agora possui barba de IA.
🚦 CAPÍTULO 5 — CANCELAR NÃO É A MESMA COISA QUE DESFAZER
Aqui encontramos um detalhe importantíssimo.
Suponha que o agente tenha realizado:
1. leu relatório
2. criou arquivo
3. alterou cadastro
4. enviou e-mail
5. atualizou bancoVocê interrompe na etapa 5.
Ótimo.
Mas as etapas anteriores aconteceram.
Portanto existem dois conceitos diferentes:
STOPe:
UNDOParar significa:
Não continue.
Rollback significa:
Tente retornar a um estado anterior seguro.
Em sistemas transacionais, isso é assunto antigo.
No universo de bancos de dados, pensamos em operações, transações, COMMIT e ROLLBACK.
Num fluxo simplificado:
BEGIN
↓
ALTERAÇÕES
↓
VALIDAÇÃO
↓
COMMITSe alguma condição impedir a conclusão:
ROLLBACKMas existe um problema.
Nem toda ação do mundo real é reversível.
Se o agente enviou um e-mail, não existe ROLLBACK mágico que retire a mensagem da memória do destinatário.
Se publicou informação externamente, a informação pode ter sido copiada.
Se efetuou um pagamento, o estorno pode constituir outra transação.
Por isso a UX precisa distinguir:
REVERSÍVELde:
IRREVERSÍVELE ações irreversíveis merecem controles adicionais.
✋ CAPÍTULO 6 — HUMAN-IN-THE-LOOP: O HUMANO NÃO PRECISA APROVAR TUDO
Surge então uma solução aparentemente maravilhosa:
Coloque aprovação humana em tudo!
Problema resolvido?
Não.
Imagine um agente que execute 300 ações e pergunte:
Posso ler este arquivo?
Sim.
Posso abrir este diretório?
Sim.
Posso consultar esta tabela?
Sim.
Posso ordenar os resultados?
SIM!
Posso gerar...
SIM, RAIO!
😂
Depois da centésima confirmação, o usuário começa a clicar em Sim automaticamente.
A aprovação continua existindo tecnicamente.
Mas perdeu seu valor cognitivo.
Isso é semelhante ao problema clássico de alert fatigue.
Se tudo é emergência, nada parece emergência.
Human-in-the-loop precisa ser colocado nos pontos em que o julgamento humano realmente acrescenta valor.
Por exemplo:
LER ARQUIVO AUTORIZADO
→ automático
GERAR RESUMO LOCAL
→ automático
ALTERAR DOCUMENTO
→ talvez confirmar
ENVIAR DOCUMENTO EXTERNAMENTE
→ confirmar
EXCLUIR DADOS
→ confirmar
TRANSFERIR DINHEIRO
→ confirmar fortementeA boa UX não pergunta tudo.
Ela pergunta quando importa.
🛡️ CAPÍTULO 7 — RACF ENTRA NA SALA
Turing coloca outro livro sobre a mesa.
Na capa:
RACFO jovem programador sorri.
Agora estamos em casa.
O princípio fundamental é simples:
Uma identidade não deveria possuir mais autoridade do que necessita para executar sua função.
É a ideia de least privilege.
Suponha que um agente tenha como objetivo:
Leia os relatórios de produção e prepare um resumo.
Por que ele precisaria de autorização para:
DELETE?
Não precisa.
Então não dê.
Talvez ele necessite:
READsobre determinados recursos.
Só isso.
Imagine:
AGENTE-RELATORIO
│
├── RELATORIOS.* READ
├── DOCUMENTACAO.* READ
├── EMAIL NONE
├── PAYROLL.* NONE
└── PROD.ADMIN NONESe o agente sofrer uma interpretação errada, receber uma instrução maliciosa ou simplesmente tomar uma decisão ruim, o estrago potencial fica limitado.
É exatamente por isso que permissões são tão importantes.
💀 CAPÍTULO 8 — NÃO DÊ SPECIAL AO ROBÔ
No RACF, atributos administrativos poderosos devem ser tratados com extremo cuidado.
Imagine então alguém criando um agente corporativo e dizendo:
Para evitar problemas de permissão, vou dar acesso a tudo.
Turing derruba o café.
O administrador RACF sente uma perturbação na Força a quilômetros de distância.
😂
Essa é uma das piores maneiras de resolver problemas de integração.
Funciona?
Provavelmente.
Até deixar de funcionar espetacularmente.
O princípio correto deveria ser:
COMECE COM ZERO
↓
DESCUBRA O NECESSÁRIO
↓
CONCEDA O MÍNIMO
↓
MONITORE
↓
REVISENunca:
DÊ TUDO
↓
REZEIsso vale para humanos.
Vale para aplicações.
Vale para service accounts.
E vale ainda mais para agentes capazes de escolher dinamicamente quais ferramentas utilizar.
📊 CAPÍTULO 9 — MAXCC: “FUNCIONOU” PRECISA TER SIGNIFICADO
Agora chegamos ao nosso segundo ancestral mainframe.
MAXCC=0000Todo programador iniciante rapidamente aprende a gostar dessa visão.
Mas também aprende uma lição mais importante:
MAXCC=0000significa que aquilo que o sistema mediu terminou de determinada maneira. Não significa automaticamente que o negócio alcançou o resultado correto.
Um programa pode executar sem erro técnico e produzir informação logicamente errada.
O mesmo vale para agentes.
Imagine:
TASK COMPLETEDÓtimo.
Mas...
O que significa completed?
O arquivo foi criado?
O conteúdo foi validado?
O destinatário correto recebeu?
Todos os registros foram processados?
Alguma exceção foi ignorada?
O resultado corresponde ao objetivo?
Portanto agentes precisam de critérios de sucesso observáveis.
Não basta:
STATUS = DONEPrecisamos de algo semelhante a:
OBJETIVO: Consolidar 12 relatórios mensais
Arquivos esperados: 12
Arquivos encontrados: 12
Arquivos processados: 12
Erros: 0
Divergências: 2
Aprovação humana: pendente
Entrega externa: NÃO EXECUTADAAgora temos informação útil.
🔭 CAPÍTULO 10 — OBSERVABILIDADE: O SDSF DOS AGENTES
Imagine um agente trabalhando durante vinte minutos.
Depois alguém pergunta:
O que ele fez?
Resposta:
Não sei. Mas terminou.
Isso seria inaceitável num ambiente corporativo sério.
Queremos algo conceitualmente parecido com a experiência de observar processamento através de ferramentas como JES e SDSF.
Para agentes, gostaríamos de enxergar:
AGENTE
↓
OBJETIVO
↓
PLANO
↓
FERRAMENTA UTILIZADA
↓
ENTRADA
↓
RESULTADO
↓
DECISÃO
↓
PRÓXIMA AÇÃONão necessariamente precisamos mostrar todo detalhe interno de raciocínio do modelo.
O que precisamos é telemetria operacional.
Por exemplo:
10:01:03 Tarefa iniciada
10:01:04 Consultando catálogo
10:01:08 42 documentos encontrados
10:01:09 Aplicado filtro: setembro/2026
10:01:12 7 documentos selecionados
10:01:14 Análise iniciada
10:02:31 2 divergências encontradas
10:02:33 Aguardando aprovação humanaIsso é observabilidade.
🕵️ CAPÍTULO 11 — OBSERVABILIDADE E AUDITORIA NÃO SÃO A MESMA COISA
Essa distinção é importantíssima.
Observabilidade responde principalmente:
O que está acontecendo?
Auditoria responde:
O que aconteceu, quem autorizou e quais evidências ficaram?
Imagine uma operação:
ALTERAR LIMITE DO CLIENTEUm registro auditável poderia conter:
Agente: CREDIT-AGENT-07
Usuário solicitante: OPERADOR123
Data/hora: 14:32:11
Objetivo: revisão cadastral
Registro: CLIENTE 938271
Valor anterior: 10000
Valor proposto: 15000
Aprovação humana: GERENTE42
Resultado: executadoMeses depois, alguém consegue reconstruir o evento.
Isso é fundamental em ambientes regulados.
O agente não pode ser uma criatura mágica que responde:
Confia em mim.
Mainframe corporativo não sobreviveu décadas com:
SOURCE: VOZES DA MINHA CABEÇA😂
Governança exige evidência.
📸 CAPÍTULO 12 — CHECKPOINTS: SALVE ANTES DE ENTRAR NO BOSS
Quem jogou RPG entende imediatamente.
Você atravessou uma dungeon enorme.
Encontrou uma porta gigantesca.
Música sinistra.
O que faz?
SAVE.
O conceito de checkpoint é igualmente interessante para workflows de agentes.
Imagine:
ESTADO 0
↓
coleta de documentos
↓
CHECKPOINT 1
↓
análise
↓
CHECKPOINT 2
↓
alterações propostas
↓
APROVAÇÃO
↓
execuçãoSe algo falhar depois da análise, talvez não seja necessário repetir toda a coleta.
Checkpoints podem ajudar em:
recuperação;
continuidade;
auditoria;
revisão humana;
controle de custos;
debugging.
Para um mainframer isso lembra diversas estratégias históricas de restart e recuperação de processamento batch.
Nada particularmente glamouroso.
Mas extremamente importante às três da manhã.
🧱 CAPÍTULO 13 — GUARDRAILS: O AGENTE PRECISA CONHECER AS PAREDES
Imagine dar esta instrução:
Resolva o problema do cliente.
Parece razoável.
Mas quais ações são permitidas?
Pode oferecer desconto?
Quanto?
Pode cancelar contrato?
Pode devolver dinheiro?
Pode acessar histórico financeiro?
Pode enviar dados para terceiros?
Pode apagar registros?
Um objetivo sem limites pode ser perigoso.
Portanto precisamos de guardrails.
Exemplo:
OBJETIVO
Resolver reclamação do cliente
PERMITIDO
✓ consultar pedido
✓ consultar entrega
✓ gerar resposta
✓ oferecer crédito até R$ 50
EXIGE APROVAÇÃO
! crédito entre R$ 50 e R$ 500
! cancelamento
PROIBIDO
✗ alterar dados financeiros
✗ revelar dados de outro cliente
✗ excluir histórico
✗ executar pagamentos acima do limiteObserve que isso começa a parecer uma mistura de:
REQUISITOS
+
SEGURANÇA
+
REGRAS DE NEGÓCIO
+
UXExatamente.
🧪 CAPÍTULO 14 — SANDBOX: DEIXE O ROBÔ BRINCAR LONGE DA PRODUÇÃO
Programadores COBOL conhecem perfeitamente esta conversa:
Vamos testar direto em produção?
Silêncio no CPD.
Alguém começa a procurar a saída de emergência.
😂
Agentes também deveriam possuir ambientes seguros para experimentação.
Em desenvolvimento:
AGENTE
↓
SANDBOX
↓
DADOS DE TESTE
↓
APIs SIMULADAS
↓
RESULTADOAntes de:
AGENTE
↓
PRODUÇÃOPodemos simular:
APIs;
arquivos;
usuários;
transações;
erros;
timeouts;
indisponibilidade;
dados inesperados.
Inclusive devemos testar comportamento adverso.
O que acontece quando a API responde algo incompleto?
E quando uma ferramenta fica indisponível?
E quando o documento contém uma instrução tentando desviar o agente?
E quando duas fontes discordam?
A inteligência do modelo não elimina testes.
Ela cria novas categorias de teste.
🔁 CAPÍTULO 15 — IDEMPOTÊNCIA: POSSO EXECUTAR DE NOVO?
Aqui aparece um conceito técnico extremamente útil.
Imagine que o agente tente:
Efetuar pagamento de R$ 1.000.
A chamada é enviada.
A conexão cai.
O agente não sabe se o pagamento aconteceu.
Então pensa:
Vou tentar novamente.
Parabéns.
Talvez tenhamos acabado de pagar R$ 2.000.
Por isso operações precisam considerar idempotência.
Uma operação idempotente pode ser repetida sem produzir efeitos adicionais indesejados.
Por exemplo, conceitualmente:
PROCESSAR PAGAMENTO
ID_TRANSACAO = ABC123Se ABC123 já foi processada:
NÃO PROCESSAR NOVAMENTEAgentes tornam esse tipo de engenharia ainda mais importante porque podem decidir repetir ações diante de falhas.
Retries cegos são perigosos.
⏱️ CAPÍTULO 16 — TIMEOUT, RETRY E CIRCUIT BREAKER
Imagine:
AGENTE
↓
API
↓
TIMEOUTO que fazer?
Tentar novamente?
Quantas vezes?
Imediatamente?
Depois de cinco segundos?
Depois de um minuto?
Precisamos de políticas.
Por exemplo:
Tentativa 1
↓ falhou
espera 2 s
Tentativa 2
↓ falhou
espera 4 s
Tentativa 3
↓ falhou
STOPAgora imagine que a API inteira esteja indisponível.
Mil agentes continuam tentando.
Você acaba transformando uma falha em uma avalanche.
É aqui que conceitos como circuit breaker entram.
Depois de determinado número de falhas:
CIRCUITO ABERTOPare temporariamente de chamar o serviço.
Isso não nasceu com IA.
São princípios conhecidos de sistemas distribuídos.
Mas agentes precisam respeitá-los.
A IA não aboliu engenharia de software.
Ela entrou na fila para aprender engenharia de software.
🧙 CAPÍTULO 17 — TURING DESENHA O AGENTE CORPORATIVO
Turing pega o giz.
Desenha:
HUMANO
│
▼
OBJETIVO
│
▼
┌─────────────┐
│ AGENTE │
└─────────────┘
│
┌───────┼────────┐
▼ ▼ ▼
DADOS APIs FERRAMENTAS
│ │ │
└───────┼────────┘
▼
AÇÕESDepois coloca uma muralha ao redor:
┌─────────────────────────────────┐
│ GOVERNANÇA │
│ │
│ IDENTIDADE │
│ PERMISSÕES │
│ LEAST PRIVILEGE │
│ GUARDRAILS │
│ CHECKPOINTS │
│ LOGS │
│ AUDITORIA │
│ HUMAN-IN-THE-LOOP │
│ ROLLBACK │
│ OBSERVABILIDADE │
└─────────────────────────────────┘— Agora — diz Turing — você possui algo mais próximo de um sistema corporativo.
🏰 CAPÍTULO 18 — PF3, MAXCC E RACF FORMAM UMA TRÍADE
Finalmente percebemos a brincadeira.
Três velhos conhecidos representam três perguntas fundamentais.
PF3 — POSSO PARAR?
INTERRUPTIBILIDADEO usuário precisa manter autoridade para interromper.
MAXCC — FUNCIONOU?
OBSERVABILIDADEPrecisamos saber o estado e o resultado.
RACF — PODIA FAZER ISSO?
AUTORIZAÇÃOPrecisamos limitar autoridade.
Portanto:
PF3
↓
CONTROLE
MAXCC
↓
EVIDÊNCIA
RACF
↓
AUTORIDADEEsses três princípios são extraordinariamente modernos.
Embora suas implementações sejam diferentes, as perguntas permanecem.
🧠 CAPÍTULO 19 — A UX DO AGENTE NÃO É “UMA CAIXA DE CHAT MAIS BONITA”
Aqui está talvez a grande conclusão técnica.
Durante os primeiros anos da IA generativa, muita interface foi construída como:
┌─────────────────────────────┐
│ │
│ CONVERSA │
│ │
├─────────────────────────────┤
│ Digite uma mensagem... │
└─────────────────────────────┘Perfeito para conversa.
Mas um agente exige muito mais.
Talvez precisemos mostrar:
OBJETIVO
ESTADO
PLANO
PROGRESSO
FERRAMENTAS
PERMISSÕES
CUSTO
RISCO
AÇÕES
RESULTADOS
APROVAÇÕES
LOGSE ainda assim não podemos transformar a tela num cockpit de Boeing para alguém que só queria organizar a agenda.
Esse é o grande desafio de UX:
mostrar controle suficiente sem devolver toda a complexidade ao usuário.
🎚️ CAPÍTULO 20 — AUTONOMIA DEVERIA SER UM CONTINUUM
Não existe apenas:
MANUALversus:
AUTÔNOMOPodemos imaginar níveis.
Nível 0 — Assistência
IA sugere.
Humano executa.Nível 1 — Preparação
IA prepara.
Humano confirma.Nível 2 — Execução limitada
IA executa ações de baixo risco.
Confirma ações críticas.Nível 3 — Autonomia supervisionada
IA executa workflow.
Humano acompanha exceções.Nível 4 — Autonomia ampla dentro de limites
IA executa.
Humano audita e intervém quando necessário.A UX deveria deixar claro em qual regime estamos.
Um usuário nunca deveria descobrir depois que aquilo que parecia uma sugestão era uma ação real.
👨💻 CAPÍTULO 21 — O PROGRAMADOR COBOL PODE TER UMA VANTAGEM SURPREENDENTE
Alguém poderia imaginar que toda essa revolução torna experiência em sistemas antigos irrelevante.
Pode acontecer exatamente o contrário em algumas áreas.
Quem trabalha com sistemas corporativos já pensa naturalmente em:
IDENTIDADE
TRANSAÇÃO
AUTORIZAÇÃO
LOG
RECOVERY
COMMIT
ROLLBACK
RESTART
AUDITORIA
SLA
PRODUÇÃOSão exatamente os problemas que reaparecem quando transformamos modelos inteligentes em sistemas capazes de agir.
Um chatbot divertido pode sobreviver a:
“Ops, respondi errado.”
Um agente financeiro não.
Um chatbot pode inventar o nome de um livro e gerar uma situação engraçada.
Um agente alterando uma base de produção precisa de outro nível de engenharia.
Portanto o futuro da IA empresarial não pertence apenas a quem entende modelos.
Também pertence a quem entende:
sistemas.
🥚 EASTER EGG — O AGENTE PEDE SPECIAL
Às 03:17 da manhã, o agente envia uma mensagem:
AGENT01:
Preciso de acesso administrativo total
para concluir minha tarefa.O jovem programador olha para Turing.
Turing olha para o administrador RACF.
O administrador RACF olha para o agente.
Silêncio.
Finalmente:
ICH408I USER(AGENT01)
ACCESS INTENT(UPDATE)
ACCESS ALLOWED(NONE)O agente pergunta:
Posso tentar novamente?
O administrador responde:
NO.Turing sorri.
— Excelente sistema de alinhamento.
☕ EPÍLOGO — TALVEZ A INTERFACE MAIS IMPORTANTE SEJA O FREIO
Durante décadas pensamos em UX perguntando:
Como tornar computadores mais fáceis?
Depois:
Como reduzir cliques?
Depois:
Como tornar aplicativos intuitivos?
Com IA generativa perguntamos:
Como tornar natural conversar com a máquina?
Mas agentes introduzem uma pergunta nova:
Como tornar compreensível, controlável e reversível aquilo que a máquina está fazendo em nosso nome?
Isso muda tudo.
O botão mais importante talvez não seja:
EXECUTARPode ser:
PARARA informação mais importante talvez não seja:
CONCLUÍDOPode ser:
CONCLUÍDO
COM 2 EXCEÇÕES
E 1 AÇÃO AGUARDANDO APROVAÇÃOE a configuração mais importante talvez não seja:
SEJA MAIS INTELIGENTEMas:
VOCÊ NÃO TEM AUTORIZAÇÃO PARA ISSOCuriosamente, quanto mais inteligente a máquina se torna, mais importantes ficam algumas das disciplinas aparentemente antigas da computação corporativa.
Permissões.
Logs.
Auditoria.
Transações.
Checkpoints.
Rollback.
Recovery.
Observabilidade.
Segregação de funções.
Least privilege.
Human-in-the-loop.
Porque autonomia sem controle não é sofisticação.
É apenas uma maneira extremamente moderna de produzir um incidente extremamente antigo.
Alan Turing fecha o terminal.
Antes de sair, escreve três linhas no quadro:
PF3 → POSSO PARAR?
MAXCC → FUNCIONOU?
RACF → PODIA FAZER?E abaixo acrescenta:
AGENTE DE IA
=
OBJETIVO
+ AUTONOMIA
+ LIMITES
+ EVIDÊNCIA
+ CONTROLE HUMANOO jovem programador COBOL olha para aquilo.
Finalmente entende.
A grande revolução dos agentes não será simplesmente construir máquinas capazes de trabalhar por nós.
Será construir sistemas nos quais saibamos:
o que delegamos,
o que elas fizeram,
o que ainda pretendem fazer,
até onde podem ir,
quando precisam perguntar,
como podemos interrompê-las,
e o que fazer quando alguma coisa der errado.
No velho CPD aprendemos a perguntar:
QUAL JOB ESTÁ RODANDO?Na era dos agentes perguntaremos:
QUAL OBJETIVO ESTÁ RODANDO?Mudou a abstração.
Não mudou nossa responsabilidade.
E talvez esta seja uma das maiores ironias da inteligência artificial:
quanto mais autonomia entregamos às máquinas, mais precisamos reaprender algumas das lições que os grandes sistemas corporativos levaram décadas para descobrir.
Não basta fazer funcionar.
Temos que saber quem executou.
Por que executou.
Com qual autoridade.
Contra quais dados.
Qual foi o resultado.
E, principalmente...
como apertar o equivalente moderno de:
PF3quando o robô resolver que teve uma ideia brilhante demais.
READY
Sempre existe outro job esperando.
🤖 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.
