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
DIR

passamos 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 FAZER

começamos a dizer:

O QUE QUEREMOS

Mas 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ÁRIO

Você 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 resultado

Nã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 0000

ou:

CC 0008

ou:

ABEND S0C7

Existe 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.

PF3

Fim.

É 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:

1. que ele ainda está executando;

2. em qual etapa está;

3. o que já realizou;

4. o que pretende realizar;

5. 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ção

E ao lado:

PAUSAR
CANCELAR
VER DETALHES

O 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 banco

Você interrompe na etapa 5.

Ótimo.

Mas as etapas anteriores aconteceram.

Portanto existem dois conceitos diferentes:

STOP

e:

UNDO

Parar 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
   ↓
COMMIT

Se alguma condição impedir a conclusão:

ROLLBACK

Mas 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ÍVEL

de:

IRREVERSÍVEL

E 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 fortemente

A 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:

RACF

O 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:

READ

sobre determinados recursos.

Só isso.

Imagine:

AGENTE-RELATORIO
     │
     ├── RELATORIOS.*   READ
     ├── DOCUMENTACAO.* READ
     ├── EMAIL           NONE
     ├── PAYROLL.*       NONE
     └── PROD.ADMIN      NONE

Se 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
      ↓
REVISE

Nunca:

DÊ TUDO
↓
REZE

Isso 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=0000

Todo programador iniciante rapidamente aprende a gostar dessa visão.

Mas também aprende uma lição mais importante:

MAXCC=0000 significa 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 = DONE

Precisamos 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 EXECUTADA

Agora 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ÇÃO

Nã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 humana

Isso é 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 CLIENTE

Um 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: executado

Meses 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ção

Se 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 limite

Observe que isso começa a parecer uma mistura de:

REQUISITOS
+
SEGURANÇA
+
REGRAS DE NEGÓCIO
+
UX

Exatamente.

---

🧪 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
↓
RESULTADO

Antes de:

AGENTE
↓
PRODUÇÃO

Podemos 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 = ABC123

Se ABC123 já foi processada:

NÃO PROCESSAR NOVAMENTE

Agentes 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
↓
TIMEOUT

O 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

STOP

Agora 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 ABERTO

Pare 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ÇÕES

Depois 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?

INTERRUPTIBILIDADE

O usuário precisa manter autoridade para interromper.

MAXCC — FUNCIONOU?

OBSERVABILIDADE

Precisamos saber o estado e o resultado.

RACF — PODIA FAZER ISSO?

AUTORIZAÇÃO

Precisamos limitar autoridade.

Portanto:

PF3
↓
CONTROLE

MAXCC
↓
EVIDÊNCIA

RACF
↓
AUTORIDADE

Esses 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
LOGS

E 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:

MANUAL

versus:

AUTÔNOMO

Podemos 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ÇÃO

Sã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:

EXECUTAR

Pode ser:

PARAR

A informação mais importante talvez não seja:

CONCLUÍDO

Pode ser:

CONCLUÍDO
COM 2 EXCEÇÕES
E 1 AÇÃO AGUARDANDO APROVAÇÃO

E a configuração mais importante talvez não seja:

SEJA MAIS INTELIGENTE

Mas:

VOCÊ NÃO TEM AUTORIZAÇÃO PARA ISSO

Curiosamente, 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 HUMANO

O 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:

PF3

quando o robô resolver que teve uma ideia brilhante demais.

READY

Sempre existe outro job esperando.