☕ UM CAFÉ NO BELLACOSA MAINFRAME

☕ ALAN TURING ENTRA NO CPD — O MAPA DOS AGENTES DE IA EXPLICADO POR UM MAINFRAMER

De currículo invisível, PF3 e SDSF até WLM, JES2, CICS, Db2, MQ e IMS — nove conversas sobre agentes de inteligência artificial que acabaram revelando que alguns dos problemas mais modernos da computação possuem parentes muito antigos.

---

🎬 PRÓLOGO — EU NÃO ESTAVA ESCREVENDO UMA SÉRIE

Existe uma coisa curiosa em escrever durante muitos anos.

Às vezes você pensa que está escrevendo artigos independentes.

Um assunto aparece.

Você investiga.

Escreve.

Publica.

Toma outro café.

Algumas semanas depois aparece outra pergunta.

Outro artigo.

Outro café.

Até que um dia você olha para trás e percebe:

Espere um pouco...

Esses textos estão conversando entre si.

Foi exatamente o que aconteceu com uma sequência de artigos que comecei a construir usando Alan Turing como nosso visitante imaginário dentro de um CPD.

No começo, a pergunta parecia relativamente simples:

Como devemos preparar pessoas para trabalhar com inteligência artificial?

Depois apareceu outra:

Como será a interface de um agente que não apenas responde, mas executa ações?

E outra:

Como descobriremos o que esse agente está fazendo?

Depois:

Quem decide qual agente é mais importante?

Quem coloca o trabalho para executar?

Como controlamos uma transação?

Onde guardamos o estado?

Como agentes conversam sem depender uns dos outros?

Como organizamos memória e contexto?

Quando percebi, Alan Turing já estava andando pelo corredor do CPD acompanhado de alguns velhos conhecidos:

ISPF
SDSF
WLM
JES2
CICS
Db2
MQ
IMS

E foi aí que apareceu a hipótese que une esta série inteira:

Talvez alguns dos problemas que estamos descobrindo agora nos agentes de IA sejam novos em implementação, escala e comportamento — mas não necessariamente novos como problemas de engenharia.

O mainframe passou décadas resolvendo problemas como:

IDENTIDADE
AUTORIZAÇÃO
EXECUÇÃO
PRIORIDADE
OBSERVABILIDADE
TRANSAÇÃO
ESTADO
MENSAGERIA
RECUPERAÇÃO
AUDITORIA
CONCORRÊNCIA
DEPENDÊNCIAS

Naturalmente:

JES2 não é um framework de agentes.

SDSF não é observabilidade de LLM.

WLM não é um scheduler de prompts.

CICS não é LangGraph.

Db2 não é memória de IA.

MQ não é protocolo mágico entre agentes.

IMS não foi inventado para armazenar a infância digital de um robô.

😂

A comparação é conceitual.

E justamente por isso ela é tão interessante.

Este artigo é o mapa dessa viagem.

---

🧠 CAPÍTULO 1 — O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL

Antes de construir o agente, precisamos construir quem vai trabalhar com ele

👉 ALAN TURING E O CURRÍCULO INVISÍVEL DA INTELIGÊNCIA ARTIFICIAL

Nossa viagem começa antes da arquitetura.

Começa nas pessoas.

Existe uma tentação enorme diante de qualquer revolução tecnológica:

NOVA TECNOLOGIA
      ↓
NOVO CURSO
      ↓
NOVA FERRAMENTA
      ↓
CERTIFICADO
      ↓
PRONTO

Mas nunca foi tão simples.

Quem viveu várias gerações da informática sabe disso.

Aprender COBOL não significava apenas conhecer:

MOVE
PERFORM
IF
EVALUATE

O programador acabava aprendendo silenciosamente muitas outras coisas:

• decomposição de problemas;

• leitura de documentação;

• disciplina operacional;

• análise de impacto;

• debugging;

• responsabilidade sobre dados;

• relacionamento com usuários;

• conhecimento do negócio;

• avaliação de riscos.

Existe, portanto, um currículo formal e outro quase invisível.

Com IA acontece algo semelhante.

Prompt engineering pode ser útil.

Conhecer modelos também.

Mas trabalhar seriamente com IA começa a exigir algo muito maior:

IA
│
├── pensamento crítico
├── validação
├── segurança
├── privacidade
├── conhecimento de domínio
├── avaliação de resultados
├── automação
├── ética
├── governança
└── capacidade de perguntar

Este primeiro artigo estabelece o fundamento humano da série.

Antes de perguntar:

O que o agente pode fazer?

precisamos perguntar:

Quem saberá dizer se aquilo que ele fez está correto?

Esse detalhe acompanhará todos os capítulos seguintes.

---

🤖 CAPÍTULO 2 — A UX DOS AGENTES

Quando PF3 voltou para salvar a inteligência artificial

👉 ALAN TURING E A UX DOS AGENTES — QUANDO PF3, MAXCC E RACF VOLTARAM PARA SALVAR A INTELIGÊNCIA ARTIFICIAL

Então demos autonomia à máquina.

E imediatamente apareceu outro problema.

Um chatbot responde.

Um agente age.

Essa diferença parece pequena até colocarmos ferramentas nas mãos dele.

Imagine:

USUÁRIO
   ↓
OBJETIVO
   ↓
AGENTE
   ├── consulta arquivos
   ├── chama API
   ├── pesquisa banco
   ├── altera documento
   ├── envia mensagem
   └── executa processo

De repente a interface precisa responder perguntas que o velho chatbot não precisava responder:

O QUE ESTÁ FAZENDO?

POR QUE ESTÁ FAZENDO?

QUAL ETAPA ESTÁ EXECUTANDO?

POSSO PARAR?

POSSO DESFAZER?

QUEM AUTORIZOU?

O QUE JÁ FOI ALTERADO?

E eis que aparece nosso velho amigo:

PF3

O PF3 torna-se uma metáfora perfeita para interruptibilidade.

O artigo também traz RACF para a conversa por meio do princípio de menor privilégio.

Se um agente precisa ler relatórios:

READ

por que entregar:

ALTER
DELETE
CONTROL

?

Não entregue uma bazuca para matar um mosquito.

E jamais resolva problemas de autorização usando a filosofia:

DÊ ACESSO A TUDO
       ↓
DEPOIS A GENTE VÊ

Quatro décadas de segurança corporativa já ensinaram como essa história termina.

O capítulo estabelece uma nova regra:

Autonomia sem controle não é sofisticação. É risco operacional.

---

🔭 CAPÍTULO 3 — O SDSF DOS AGENTES

Não basta o robô trabalhar. Precisamos enxergar o que está acontecendo.

👉 ALAN TURING E O SDSF DOS AGENTES — O QUE DIABOS O ROBÔ ESTÁ FAZENDO?

Agora o agente está trabalhando.

Maravilha.

Só existe uma pequena pergunta:

O que ele está fazendo?

Quem trabalhou com batch conhece uma rotina quase instintiva:

SUBMIT
  ↓
SDSF
  ↓
ST
  ↓
JOB
  ↓
OUTPUT

Não ficamos olhando para o terminal durante quinze minutos vendo:

Working...

Queremos estado.

Queremos evidência.

Queremos saber onde o processamento está.

A documentação da IBM confirma exatamente essa função histórica do SDSF: monitorar e controlar processamento, visualizar jobs e seus outputs e permitir ações como hold, release e cancel.

Transportando o princípio para agentes:

AGENTE FINANCEIRO

OBJETIVO:
Consolidar relatório mensal

STATUS:
Executando

ETAPA 1 — localizar arquivos       OK
ETAPA 2 — validar período          OK
ETAPA 3 — consultar Db2            OK
ETAPA 4 — reconciliar valores      RUNNING
ETAPA 5 — gerar relatório          WAITING
ETAPA 6 — enviar relatório         APPROVAL

Esse talvez seja um dos conceitos mais importantes da série.

Autonomia aumenta a necessidade de observabilidade.

Quanto menos diretamente o humano controla cada passo, mais importante se torna enxergar o estado da execução.

---

⚖️ CAPÍTULO 4 — O WLM DOS AGENTES

Quando descobrimos que nem todo trabalho possui a mesma importância

👉 ALAN TURING E O WLM DOS AGENTES

Agora temos outro problema.

Imagine mil agentes querendo trabalhar simultaneamente.

Um está:

resumindo newsletter

Outro:

processando fraude bancária

Outro:

gerando imagem

Outro:

atendendo cliente VIP

Outro:

fechando folha de pagamento

Todos deveriam receber os mesmos recursos?

Evidentemente não.

Bem-vindo ao velho problema de workload management.

No z/OS, WLM trabalha justamente com classes de serviço, metas de desempenho e importância relativa do trabalho. Quando todos os objetivos não podem ser satisfeitos simultaneamente, essa importância participa das decisões de gerenciamento dos recursos.

Nos agentes podemos imaginar:

AGENT WORKLOAD
│
├── CRITICAL
│   └── fraude
│
├── HIGH
│   └── atendimento
│
├── NORMAL
│   └── relatórios
│
└── DISCRETIONARY
    └── indexação histórica

E aparece outra ideia fundamental:

Agentes competirão por recursos.

Tokens custam.

GPU custa.

CPU custa.

APIs possuem limites.

Bancos possuem capacidade.

Pessoas disponíveis para aprovação humana também são um recurso limitado.

O problema deixa de ser:

O agente consegue executar?

e passa a ser:

Qual trabalho merece recursos primeiro?

Alan Turing acaba de conhecer o WLM.

---

🏭 CAPÍTULO 5 — O JES2 DOS AGENTES

Alguém precisa receber, organizar e despachar o trabalho

👉 ALAN TURING E O JES2 DOS AGENTES

Temos prioridades.

Temos recursos.

Temos agentes.

Agora alguém precisa organizar a bagunça.

No mundo batch, JES recebe jobs, mantém trabalhos em filas, encaminha jobs para execução e administra seus outputs. É exatamente assim que a própria documentação introdutória do z/OS descreve suas funções fundamentais.

Conceitualmente:

SUBMISSÃO
    ↓
  FILA
    ↓
CLASSIFICAÇÃO
    ↓
DESPACHO
    ↓
EXECUÇÃO
    ↓
 RESULTADO

Agora substitua JOB por TASK:

TASK-8472
OBJETIVO = analisar contratos
PRIORIDADE = HIGH
AGENTE = LEGAL-07
STATUS = WAITING

Começamos a perceber que um ecossistema corporativo de agentes precisará responder:

Quem recebeu a tarefa?

Onde ela está?

Quem executará?

Está esperando?

Está rodando?

Falhou?

Pode reiniciar?

Existe dependência?

Qual resultado produziu?

Não significa transformar JES2 em orquestrador de LLM.

Significa reconhecer que gerenciamento do ciclo de vida do trabalho é um problema antigo.

---

⚡ CAPÍTULO 6 — O CICS DOS AGENTES

Quando inteligência encontra transação

👉 ALAN TURING E O CICS DOS AGENTES

Até aqui nossos agentes estavam realizando trabalho.

Mas empresas não vivem apenas de trabalho.

Vivem de transações.

Comprar.

Vender.

Reservar.

Cancelar.

Transferir.

Atualizar.

Consultar.

Registrar.

CICS existe justamente no universo de processamento transacional. Uma transação dispara programas associados, pode envolver diversos programas e recursos, e muitas instâncias podem executar concorrentemente.

Agora imagine um agente recebendo:

Resolva o problema deste cliente.

Ele talvez precise:

CONSULTAR PEDIDO
      ↓
CONSULTAR PAGAMENTO
      ↓
VALIDAR ENTREGA
      ↓
CALCULAR CRÉDITO
      ↓
ATUALIZAR CADASTRO

Não estamos mais falando apenas de linguagem.

Estamos mexendo no estado real do negócio.

Aqui surge uma fronteira essencial:

PENSAR
≠
AGIR

e:

GERAR UMA RESPOSTA
≠
EXECUTAR UMA TRANSAÇÃO

Quando um agente atravessa essa fronteira, entram em cena concorrência, integridade, autorização, recuperação e consistência.

O simpático chatbot acabou de entrar em produção.

Agora a brincadeira ficou séria.

---

🗄️ CAPÍTULO 7 — O DB2 DOS AGENTES

Quando o agente descobriu que memória também precisa de COMMIT

👉 ALAN TURING E O DB2 DOS AGENTES

Um agente sem estado vive eternamente no presente.

Para realizar trabalhos complexos ele precisa guardar coisas.

Por exemplo:

objetivos
tarefas
resultados
aprovações
clientes
documentos
eventos
checkpoints
estado do workflow

Mas guardar informação introduz um problema:

Quando uma mudança se torna definitiva?

O velho Db2 imediatamente levanta a mão.

No Db2, uma unidade de trabalho representa uma sequência recuperável de operações; COMMIT confirma as mudanças e ROLLBACK pode desfazer alterações ainda não confirmadas.

Isso produz uma analogia poderosa para agentes.

Imagine:

LER
 ↓
ANALISAR
 ↓
PROPOR ALTERAÇÃO
 ↓
VALIDAR
 ↓
APROVAÇÃO
 ↓
COMMIT

Se algo falhar:

ROLLBACK

Mas existe uma pegadinha deliciosa.

Nem tudo no mundo possui rollback.

Se o agente:

ENVIAR EMAIL

não existe:

ROLLBACK EMAIL

que retire a mensagem da cabeça de quem leu.

😂

Portanto sistemas de agentes precisam distinguir ações reversíveis de ações irreversíveis.

O Db2 nos ensina algo maior que SQL:

Estado precisa possuir fronteiras de consistência.

---

📨 CAPÍTULO 8 — O MQ DOS AGENTES

Mensagem enviada não significa destinatário disponível

👉 ALAN TURING E O MQ DOS AGENTES — MENSAGEM ENVIADA NÃO SIGNIFICA CONVERSA SÍNCRONA

Então nossos agentes começaram a conversar.

E imediatamente alguém inventou:

AGENTE A
   ↓
AGENTE B
   ↓
AGENTE C

Parece maravilhoso.

Até o agente B ficar indisponível.

Ou lento.

Ou ocupado.

Ou reiniciar.

Ou o agente C morar em outro ambiente.

É exatamente aqui que décadas de mensageria corporativa começam a parecer extremamente atuais.

IBM MQ permite que aplicações se comuniquem através de mensagens e filas, inclusive executando em momentos, velocidades e locais diferentes. Produtor e consumidor podem ficar desacoplados.

Portanto:

AGENTE A
   ↓
 MENSAGEM
   ↓
  FILA
   ↓
AGENTE B

A existência da fila muda completamente a arquitetura.

O produtor não precisa necessariamente ficar parado olhando para o consumidor.

Podemos construir sistemas:

ASSÍNCRONOS
RESILIENTES
DESACOPLADOS
DISTRIBUÍDOS

Mas surgem novos problemas:

ordenação
duplicidade
correlação
persistência
retry
dead letter
idempotência
timeout

A IBM também documenta que filas mantêm mensagens até que aplicações possam recuperá-las e que consumidores e produtores podem operar desacoplados.

De repente, multiagentes deixam de parecer uma reunião de robôs conversando.

Começam a parecer...

sistemas distribuídos.

Bem-vindo ao inferno.

Tem café na entrada.

---

🌳 CAPÍTULO 9 — O IMS DOS AGENTES

Quando Alan Turing descobriu que encontrar um filho é fácil se você souber quem é o pai

👉 ALAN TURING E O IMS DOS AGENTES — QUANDO O MUNDO VIROU UMA ÁRVORE

Finalmente chegamos ao IMS.

E aparece uma pergunta fascinante:

Toda memória precisa ser representada como tabela?

Não.

IMS trabalha historicamente com modelo hierárquico.

Temos relações:

ROOT
 │
 ├── CHILD
 │     ├── CHILD
 │     └── CHILD
 │
 └── CHILD

Na terminologia oficial do IMS, segmentos possuem relações parent/child; um segmento pode inclusive ser filho de um segmento e pai de outro.

Isso oferece uma metáfora extraordinariamente útil para determinados tipos de contexto de agentes.

Imagine:

CLIENTE
│
├── PEDIDOS
│   ├── PEDIDO 8472
│   │   ├── ITENS
│   │   ├── PAGAMENTO
│   │   └── ENTREGA
│   └── PEDIDO 9011
│
├── CONTRATOS
│
└── ATENDIMENTOS

Contexto frequentemente possui relações naturais.

A própria IBM explica uma diferença fundamental: numa base hierárquica IMS, segmentos ao longo de um caminho hierárquico já possuem relações implícitas com pais e filhos, enquanto no modelo relacional relacionamentos normalmente são construídos explicitamente por joins.

Isso não significa:

Vamos substituir vector databases por IMS!

Calma.

😂

A lição é mais interessante:

A forma como representamos conhecimento influencia profundamente a maneira como conseguimos navegar por ele.

E assim chegamos da execução à memória.

---

🗺️ CAPÍTULO 10 — AGORA OLHE PARA O MAPA INTEIRO

Depois dos nove artigos, podemos finalmente enxergar a arquitetura escondida.

┌───────────────────────────────────────┐
│       CURRÍCULO INVISÍVEL             │
│ Quem está preparado para trabalhar?   │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│          UX / PF3 / RACF              │
│ Como controlar autonomia?             │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               SDSF                    │
│ O que está acontecendo?               │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│                WLM                    │
│ Qual trabalho é mais importante?      │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               JES2                    │
│ Quem recebe e despacha o trabalho?    │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               CICS                    │
│ Como executar ações de negócio?       │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               Db2                     │
│ Como manter estado consistente?       │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│                MQ                     │
│ Como componentes conversam?           │
└──────────────────┬────────────────────┘
                   ↓
┌───────────────────────────────────────┐
│               IMS                     │
│ Como organizar e navegar contexto?    │
└───────────────────────────────────────┘

Agora a série revela algo que talvez não estivesse completamente evidente quando escrevemos o primeiro artigo.

Não estamos mais discutindo simplesmente:

INTELIGÊNCIA ARTIFICIAL

Estamos discutindo:

SISTEMAS DE INTELIGÊNCIA ARTIFICIAL

Essa diferença é gigantesca.

---

🧩 CAPÍTULO 11 — O AGENTE DEIXOU DE SER O CENTRO

Durante algum tempo olhamos para IA assim:

PROMPT
  ↓
LLM
  ↓
RESPOSTA

Só que um sistema corporativo real começa a parecer muito mais com:

                    USUÁRIO
                       │
                       ↓
                   OBJETIVO
                       │
                       ↓
                 ORQUESTRADOR
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
     AGENTE A       AGENTE B       AGENTE C
        │              │              │
        └──────────────┼──────────────┘
                       ↓
                    TOOLS
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
       DB             MQ             API
        │
        ↓
      ESTADO

E ao redor disso precisamos:

IDENTIDADE
AUTORIZAÇÃO
OBSERVABILIDADE
AUDITORIA
PRIORIZAÇÃO
RECUPERAÇÃO
LIMITES
CHECKPOINTS
APROVAÇÕES
MENSAGERIA
TRANSAÇÕES

O LLM continua importante.

Mas ele passa a ser um componente da arquitetura.

Essa talvez seja a evolução mais importante de toda a série.

---

🧙 CAPÍTULO 12 — TURING FAZ A PERGUNTA ERRADA

Alan Turing olha para nosso jovem programador COBOL.

E pergunta:

— Então finalmente construímos uma máquina que pensa?

O programador olha para o CPD.

Olha para:

SDSF
WLM
JES2
CICS
DB2
MQ
IMS

Depois olha para o pequeno agente trabalhando no terminal.

E responde:

— Não sei.

Turing fica surpreso.

— Depois de tudo isso?

— Talvez a pergunta tenha mudado.

— Como assim?

O programador pega uma caneta.

E escreve no quadro:

CAN MACHINES THINK?

Risca.

Embaixo escreve:

CAN MACHINES WORK
SAFELY,
RELIABLY,
OBSERVABLY
AND
RESPONSIBLY?

Turing olha.

Sorri.

---

🦖 CAPÍTULO 13 — O MAINFRAME NÃO PREVIU A IA

E precisamos deixar uma coisa muito clara.

O mainframe não previu os LLMs.

JES2 não é ancestral tecnológico direto de agentes.

WLM não administra pensamentos.

CICS não executa raciocínio.

Db2 não possui consciência.

MQ não faz robôs fofinhos conversarem.

IMS não é cérebro artificial.

O valor da comparação está em outro lugar.

Durante décadas sistemas corporativos precisaram responder:

Quem pode executar?

O que pode executar?

Quando executará?

Com qual prioridade?

Sobre quais recursos?

Como sabemos que terminou?

O que acontece quando falha?

Como desfazemos mudanças?

Como componentes se comunicam?

Como reconstruímos o que aconteceu?

Essas perguntas reaparecem quando agentes deixam o laboratório e começam a operar sistemas reais.

Não copiamos a solução.

Reaproveitamos o conhecimento de engenharia.

---

🥚 EASTER EGG — O PROGRAMA QUE JÁ ESTAVA RODANDO

Turing caminha até o último terminal do CPD.

Na tela existe apenas:

READY

Ele digita:

WHO

A máquina responde:

TURING

Ele pergunta:

STATUS

Resposta:

ACTIVE

Turing sorri.

— Interessante.

O programador COBOL pergunta:

— O quê?

— Passamos nove capítulos tentando descobrir como controlar agentes inteligentes.

— Sim.

Turing aponta para o CPD.

— E vocês passaram cinquenta anos construindo sistemas para controlar humanos, programas, jobs, transações e mensagens.

Silêncio.

O operador do outro lado da sala grita:

— JOB ABENDOU!

Turing pergunta:

— S0C7?

— S0C7!

Turing pega seu café.

— Algumas coisas realmente nunca mudam.

😂

---

☕ EPÍLOGO — TALVEZ O FUTURO TENHA CHEIRO DE CPD

Existe uma tendência natural na tecnologia de acreditar que tudo começou ontem.

Cada nova geração cria novas palavras.

Novos frameworks.

Novos diagramas.

Novas abstrações.

E muitas delas realmente representam avanços extraordinários.

Mas engenharia também possui memória.

Quando vejo agentes de IA discutindo:

orchestration
observability
workload
state
messaging
transactions
authorization
checkpoints
recovery

é impossível para quem viveu mainframe não sentir um estranho déjà-vu.

Não porque sejam as mesmas tecnologias.

Não são.

Mas porque computadores continuam enfrentando alguns problemas fundamentais:

TRABALHO PRECISA SER ORGANIZADO.

RECURSOS SÃO FINITOS.

ESTADO PRECISA SER PROTEGIDO.

FALHAS ACONTECEM.

MENSAGENS SE PERDEM.

SISTEMAS FICAM INDISPONÍVEIS.

USUÁRIOS COMETEM ERROS.

PROGRAMAS COMETEM ERROS.

AUTOMAÇÃO AMPLIFICA ERROS.

E agora acrescentamos uma criatura nova:

AGENTES PODEM ESCOLHER A PRÓXIMA AÇÃO.

Isso muda muita coisa.

Mas não apaga setenta anos de engenharia de sistemas.

Talvez faça justamente o contrário.

Torne esse conhecimento ainda mais valioso.

Por isso esta série não é apenas sobre Alan Turing.

Não é apenas sobre mainframe.

E nem sequer é apenas sobre inteligência artificial.

É sobre algo muito mais antigo:

COMO CONSTRUÍMOS SISTEMAS NOS QUAIS PODEMOS CONFIAR?

Começamos ensinando pessoas.

Depois demos autonomia à máquina.

Criamos formas de observá-la.

Priorizamos seu trabalho.

Organizamos suas filas.

Controlamos suas transações.

Protegemos seu estado.

Permitimos que conversasse com outros sistemas.

Finalmente começamos a organizar sua memória.

E talvez este seja apenas o começo.

Porque no fundo do CPD existe uma porta.

Turing acabou de encontrá-la.

Na porta existe uma pequena placa:

AGENTS
AUTHORIZED PERSONNEL ONLY

Ele olha para nós.

— Vamos?

O programador COBOL suspira.

Salva tudo.

Confere o spool.

E responde:

— Só depois do café.

☕

Bellacosa Mainframe