☕ UM CAFÉ NO BELLACOSA MAINFRAME
🌳 ALAN TURING E O IMS DOS AGENTES — QUANDO O MUNDO VIROU UMA ÁRVORE
IMS, agentes de IA, bancos hierárquicos, segmentos, root, parent, child, twins, PCB, PSB, DBD, DL/I, SSA, GU, GN, GNP, ISRT, REPL, DLET, COBOL, contexto, navegação, memória, estado, relacionamentos — e o dia em que Alan Turing descobriu que encontrar um filho pode ser fácil, desde que você saiba quem é o pai.
🎬 PRÓLOGO — ONDE ESTÁ O PEDIDO 8472?
O pequeno agente já estava ficando convencido.
Depois de sobreviver a RACF, SDSF, WLM, JES2, CICS, Db2 e MQ, começava a acreditar que finalmente compreendia sistemas corporativos.
Entrou no CPD com aquela confiança típica de quem acabou de descobrir SQL.
Alan Turing estava tomando café.
— Professor, pode mandar qualquer banco de dados.
Turing levantou uma sobrancelha.
— Qualquer um?
— Qualquer um.
— Encontre o item 0003 do pedido 8472 do cliente 12345.
O agente sorriu.
— Fácil.
Digitou:
SELECT *
FROM ORDER_ITEM
WHERE CUSTOMER_ID = 12345
AND ORDER_ID = 8472
AND ITEM_ID = 3;
Silêncio.
Nada aconteceu.
— Professor?
— Não estamos no Db2.
— Então qual é a tabela?
— Não existe tabela.
O robô piscou.
— Como assim não existe tabela?
Turing desenhou no quadro:
CUSTOMER
│
├── ORDER 8471
│ ├── ITEM 001
│ └── ITEM 002
│
├── ORDER 8472
│ ├── ITEM 001
│ ├── ITEM 002
│ └── ITEM 003
│
└── ORDER 8473
└── ITEM 001
O agente ficou alguns segundos olhando.
— Isso é uma árvore.
— Exatamente.
— Então eu preciso procurar o item?
— Sim.
— Pelo número?
— Também.
— Mas preciso chegar primeiro ao pedido?
— Sim.
— E para chegar ao pedido...
Turing aponta para o topo.
CUSTOMER 12345
O robô olha para ele.
Depois para a árvore.
Depois novamente para ele.
— Preciso saber quem é o pai.
Turing sorri.
— Bem-vindo ao IMS.
🌳 CAPÍTULO 1 — NEM TODO BANCO DE DADOS É UMA TABELA
Para quem começou estudando bancos relacionais, banco de dados parece quase sinônimo de:
TABLE
ROW
COLUMN
Você aprende:
SELECT
INSERT
UPDATE
DELETE
JOIN
e naturalmente começa a imaginar o mundo inteiro dessa maneira.
Cliente:
CUSTOMER
Pedido:
ORDER
Item:
ORDER_ITEM
Em um modelo relacional poderíamos representar:
CUSTOMER
--------
CUSTOMER_ID
NAME
ORDER
-----
ORDER_ID
CUSTOMER_ID
DATE
ORDER_ITEM
----------
ORDER_ID
ITEM_ID
PRODUCT_ID
QUANTITY
Depois relacionamos tudo por chaves.
Mas bancos hierárquicos partem de outra ideia.
Em vez de imaginar conjuntos de tabelas relacionadas, imagine:
UMA ÁRVORE.
CUSTOMER
│
├── ORDER
│ │
│ ├── ITEM
│ ├── ITEM
│ └── ITEM
│
└── ORDER
│
├── ITEM
└── ITEM
A posição de uma informação na hierarquia importa.
Não estamos apenas perguntando:
Qual registro possui ITEM-ID 003?
Podemos estar perguntando:
Qual ITEM 003 pertencente ao ORDER 8472 pertencente ao CUSTOMER 12345?
Isso muda profundamente a maneira de navegar pelos dados.
🦖 CAPÍTULO 2 — MAS O QUE DIABOS É IMS?
IMS significa:
Information Management System.
É uma família histórica e importantíssima de tecnologias IBM para mainframe.
Dentro do universo IMS, dois grandes mundos aparecem:
IMS DB
e:
IMS TM
De forma introdutória:
IMS DB
Gerenciamento de bancos de dados, tradicionalmente associado ao modelo hierárquico.
IMS TM
Transaction Manager, responsável pelo processamento transacional de aplicações e mensagens.
Ou seja, IMS não é simplesmente:
“um banco de dados velho”.
Ele faz parte de uma infraestrutura transacional de enorme importância no universo corporativo.
Bancos, seguradoras, telecomunicações, governo, companhias aéreas e grandes organizações construíram sistemas críticos sobre tecnologias desse ecossistema.
Para nosso programador COBOL iniciante, porém, vamos começar pelo monstro mais visível:
A HIERARQUIA.
🌲 CAPÍTULO 3 — ROOT, PARENT E CHILD
Toda árvore precisa começar em algum lugar.
No topo encontramos o:
ROOT SEGMENT.
Imagine:
CUSTOMER
como root.
Abaixo dele:
ORDER.
CUSTOMER é:
PARENT
de ORDER.
ORDER é:
CHILD
de CUSTOMER.
Agora colocamos:
ITEM
abaixo de ORDER.
Temos:
CUSTOMER
│
└── ORDER
│
└── ITEM
Nesse relacionamento:
ORDER
é pai de:
ITEM.
E ao mesmo tempo filho de:
CUSTOMER.
Exatamente como uma árvore genealógica.
Alan Turing escreve:
LUIGI
│
└── MARIO
│
└── PEACH
O programador protesta:
— Professor, isso está genealogicamente errado.
Turing apaga.
— Estava verificando se você ainda estava prestando atenção.
🥚 Easter egg detectado.
👯 CAPÍTULO 4 — E OS TWINS?
Imagine:
CUSTOMER 12345
│
├── ORDER 8471
├── ORDER 8472
└── ORDER 8473
Os três ORDERs possuem o mesmo pai.
Em terminologia IMS, ocorrências do mesmo tipo de segmento sob o mesmo parent podem ser chamadas de:
TWINS.
Não significa que os dados sejam idênticos.
Significa que ocupam posições equivalentes dentro daquela relação hierárquica.
O mesmo acontece:
ORDER 8472
│
├── ITEM 001
├── ITEM 002
└── ITEM 003
Esses ITEMs são ocorrências irmãs daquele tipo sob o mesmo ORDER.
Isso será importante quando começarmos a navegar.
🧭 CAPÍTULO 5 — NO SQL VOCÊ DESCREVE O QUE QUER
No Db2 podemos escrever:
SELECT NAME
FROM CUSTOMER
WHERE CUSTOMER_ID = 12345;
Em linguagem declarativa, estamos basicamente dizendo:
Quero isto.
O banco determina um caminho de acesso adequado com base em vários fatores.
No universo clássico do IMS e DL/I, a navegação é muito mais explícita.
Nosso programa precisa compreender:
onde está
de onde veio
qual segmento procura
qual relacionamento está seguindo
qual posição de navegação possui
Por isso o programador IMS desenvolve uma espécie de mapa mental da árvore.
Ele não pensa apenas:
Quero ITEM 003.
Pensa:
CUSTOMER 12345
↓
ORDER 8472
↓
ITEM 003
O caminho faz parte do problema.
🗺️ CAPÍTULO 6 — O DBD É O MAPA DO REINO
Precisamos descrever o banco.
Entra o:
DBD — Database Description.
Conceitualmente, o DBD descreve características estruturais do banco IMS.
Para nosso iniciante, pense nele como parte do mapa técnico que diz:
qual banco existe
quais segmentos existem
como estão relacionados
quais campos/chaves são relevantes
como a estrutura está organizada
Uma representação didática:
DBD CUSTOMERDB
CUSTOMER
│
├── ORDER
│ │
│ └── ITEM
│
└── ADDRESS
O DBD ajuda a definir a estrutura do mundo.
Mas surge outra pergunta:
O programa precisa enxergar tudo?
Nem sempre.
🪪 CAPÍTULO 7 — PSB: O QUE ESTA APLICAÇÃO PODE ENXERGAR?
Entra outro acrônimo clássico:
PSB — Program Specification Block.
Didaticamente, podemos pensar no PSB como a descrição da visão e dos recursos de banco/mensagem necessários para determinada aplicação.
Alan Turing desenha:
BANCO COMPLETO
────────────────
CUSTOMER
├── ORDER
│ └── ITEM
├── ADDRESS
├── CREDIT
└── HISTORY
Mas nosso programa talvez precise apenas de:
CUSTOMER
└── ORDER
└── ITEM
O agente pergunta:
— Então o programa não precisa necessariamente receber o mapa inteiro do universo?
— Excelente.
Essa ideia nos levará diretamente aos agentes de IA.
Mas ainda falta uma peça.
📋 CAPÍTULO 8 — PCB: A JANELA OPERACIONAL
Dentro desse modelo aparece o:
PCB — Program Communication Block.
Para uma introdução, pense nele como uma estrutura pela qual a aplicação interage com determinados recursos IMS e recebe informações de status relacionadas às operações.
Em programas COBOL IMS tradicionais, o PCB é importantíssimo na comunicação com DL/I.
Depois de uma operação, você não deveria simplesmente pensar:
Fiz a chamada, portanto funcionou.
Você verifica o:
STATUS CODE.
Mainframeiro experiente já começou a sorrir.
Porque acabamos de reencontrar uma velha filosofia:
NÃO CONFIE. VERIFIQUE O RETORNO.
Nosso MAXCC dos Agentes está batendo na porta novamente.
☎️ CAPÍTULO 9 — DL/I: A CONVERSA COM O IMS
Um nome fundamental:
DL/I — Data Language/I.
Aplicações podem utilizar chamadas DL/I para acessar dados IMS.
Em vez de:
SELECT ...
vamos encontrar operações clássicas como:
GU
GN
GNP
ISRT
REPL
DLET
O iniciante olha para a lista.
— Parece ISPF depois de alguém derrubar café no teclado.
Calma.
Vamos traduzir.
🎯 CAPÍTULO 10 — GU: GET UNIQUE
GU significa:
Get Unique.
Queremos recuperar uma ocorrência específica.
Conceitualmente:
GU CUSTOMER 12345
Pense:
Localize este segmento específico.
Podemos imaginar nosso agente procurando:
CUSTOMER-ID = 12345.
Em COBOL, de maneira puramente didática e simplificada:
CALL 'CBLTDLI' USING
GU-FUNCTION
CUSTOMER-PCB
CUSTOMER-IO-AREA
CUSTOMER-SSA.
Não memorize essa linha como receita universal.
O objetivo aqui é perceber a estrutura mental:
FUNÇÃO
PCB
ÁREA DE DADOS
CRITÉRIO DE SELEÇÃO
Agora apareceu outro acrônimo.
Claro que apareceu.
Estamos no mainframe.
☕
🔍 CAPÍTULO 11 — SSA: DIGA QUAL SEGMENTO VOCÊ QUER
SSA significa:
Segment Search Argument.
É uma forma de indicar segmentos e, quando qualificada, critérios usados na busca.
Conceitualmente:
CUSTOMER
WHERE CUSTOMER-ID = 12345
Podemos imaginar:
CUSTOMER SSA
e depois:
ORDER SSA
e:
ITEM SSA.
Queremos:
CUSTOMER 12345
↓
ORDER 8472
↓
ITEM 003
Podemos fornecer um caminho hierárquico que ajude a localizar exatamente a ocorrência desejada.
A grande sacada é:
CONTEXTO E CAMINHO IMPORTAM.
➡️ CAPÍTULO 12 — GN: GET NEXT
Agora queremos navegar.
Usamos conceitualmente:
GN — Get Next.
Imagine:
CUSTOMER 12345
│
├── ORDER 8471
├── ORDER 8472
└── ORDER 8473
Depois de posicionados em determinado ponto, podemos solicitar a próxima ocorrência dentro da navegação aplicável.
É como caminhar pela árvore.
GET
NEXT
NEXT
NEXT
Isso parece simples.
Mas existe uma diferença filosófica gigantesca em relação a simplesmente perguntar ao banco:
SELECT *
FROM ORDER;
Estamos mantendo:
POSIÇÃO.
Nosso programa possui contexto de navegação.
Guarde essa palavra:
POSITION.
Ela será importantíssima para agentes.
👨👧 CAPÍTULO 13 — GNP: GET NEXT WITHIN PARENT
Agora a coisa fica deliciosa.
Temos:
CUSTOMER
│
├── ORDER A
│ ├── ITEM 1
│ └── ITEM 2
│
└── ORDER B
├── ITEM 1
└── ITEM 2
Estamos dentro de:
ORDER A.
Queremos continuar procurando filhos daquele pai.
Entra conceitualmente:
GNP — Get Next within Parent.
Ou seja:
Continue dentro deste contexto parental.
Isso é muito importante.
Porque:
ITEM 1
sozinho não conta toda a história.
Precisamos saber:
ITEM 1
OF ORDER A.
O pai define contexto.
🧠 CAPÍTULO 14 — ALAN TURING ENCONTRA O PRIMEIRO PARALELO COM AGENTES
Turing escreve:
ITEM 003
Pergunta:
— O que é isto?
O agente responde:
— Item três.
— De qual pedido?
Silêncio.
Turing acrescenta:
ORDER 8472
└── ITEM 003
— Agora?
— Item três do pedido 8472.
Turing acrescenta:
CUSTOMER 12345
└── ORDER 8472
└── ITEM 003
— Agora?
O agente responde:
— Item três do pedido 8472 do cliente 12345.
Turing sorri.
O MESMO NÓ GANHA SIGNIFICADO PELO CAMINHO QUE NOS LEVOU ATÉ ELE.
E aqui IMS encontra inteligência artificial.
🤖 CAPÍTULO 15 — AGENTES TAMBÉM PRECISAM DE CONTEXTO HIERÁRQUICO
Imagine uma conversa:
CLIENTE
└── VIAGEM
└── HOTEL
└── RESERVA
O usuário diz:
Cancele.
Cancele o quê?
Sem contexto:
CANCEL
é perigoso.
Com contexto:
CLIENTE
└── VIAGEM PARA EDIMBURGO
└── HOTEL
└── RESERVA 8821
└── CANCELAR
Agora temos significado.
Um agente não deveria possuir apenas uma enorme sopa de tokens.
Pode ser extremamente útil modelar contexto como estruturas explícitas:
USER
│
├── PROJECT
│ ├── TASK
│ │ ├── DOCUMENT
│ │ └── DECISION
│ └── TASK
│
└── TRAVEL
├── FLIGHT
└── HOTEL
Não estou dizendo que um LLM “é um IMS”.
Não é.
A analogia está na arquitetura do contexto:
informação organizada por relações pode ser mais útil do que informação simplesmente acumulada.
🧩 CAPÍTULO 16 — CONTEXTO NÃO É APENAS MEMÓRIA
Existe uma tentação perigosa em agentes:
Vamos colocar tudo no prompt.
Então aparece:
200 páginas
3.000 mensagens
48 documentos
17 APIs
histórico inteiro do cliente
logs
políticas
manuais
e alguém chama isso de:
CONTEXT.
Não.
Isso pode ser apenas:
UM DEPÓSITO.
O IMS nos oferece uma provocação arquitetural interessante.
Talvez devamos perguntar:
qual é o root?
qual é o parent?
qual é o child?
qual caminho importa?
qual subárvore precisamos?
Em vez de entregar o universo inteiro ao agente, entregamos a parte relevante da árvore.
✂️ CAPÍTULO 17 — CONTEXT PRUNING ENCONTRA A ÁRVORE
Imagine:
CUSTOMER
├── ACCOUNT
│ ├── BALANCE
│ └── TRANSACTIONS
├── INSURANCE
├── MORTGAGE
├── MARKETING
└── SUPPORT
O agente está respondendo:
Qual meu saldo?
Talvez precise:
CUSTOMER
└── ACCOUNT
└── BALANCE
Não precisa necessariamente carregar:
MARKETING
MORTGAGE
SUPPORT HISTORY
inteiros.
Podemos podar a árvore de contexto.
FULL CONTEXT
↓
RELEVANT SUBTREE
↓
AGENT
Isso pode reduzir:
tokens
latência
custo
ruído
risco de confusão
exposição desnecessária
Olha o RACF sorrindo novamente.
Menos contexto também pode significar:
MENOR SUPERFÍCIE DE EXPOSIÇÃO.
🔐 CAPÍTULO 18 — PSB ENCONTRA LEAST PRIVILEGE
Lembra do PSB?
Uma aplicação recebe a visão e os recursos necessários para seu trabalho.
Agora imagine um agente.
Agente de cobrança:
CUSTOMER
├── ACCOUNT
├── DEBT
└── PAYMENT
Agente de marketing:
CUSTOMER
├── PROFILE
└── CAMPAIGN
Por que o agente de marketing deveria receber:
ACCOUNT PASSWORD
PAYMENT CREDENTIALS
INTERNAL FRAUD NOTES
se não precisa?
Nossa analogia conceitual:
PSB
↓
APPLICATION VIEW
torna-se:
AGENT CONTEXT POLICY
↓
MINIMUM NECESSARY VIEW.
RACF responde do corredor:
— FINALMENTE VOCÊS ESTÃO APRENDENDO!
😂
🧬 CAPÍTULO 19 — O PROBLEMA DO FILHO SEM PAI
Imagine um RAG retornando:
STATUS = ACTIVE
Excelente.
Ativo o quê?
Cliente?
Contrato?
Cartão?
Conta?
Apólice?
Promoção?
Um fragmento semanticamente semelhante pode ser inútil sem seus ancestrais contextuais.
Em uma representação hierárquica:
CUSTOMER 12345
└── CREDIT_CARD 8821
└── STATUS ACTIVE
temos muito mais significado.
Portanto uma estratégia de recuperação pode considerar não apenas:
CHUNK
mas também:
ANCESTORS
PATH
ENTITY
RELATIONSHIP
VERSION
TIMESTAMP
SOURCE.
Nosso Db2 dos Agentes volta:
De quando é?
O IMS acrescenta:
Filho de quem?
🧭 CAPÍTULO 20 — O CAMINHO TAMBÉM É PROVENIÊNCIA
Imagine que o agente responde:
O limite é R$ 5.000.
Perguntamos:
— De onde veio?
Resposta ruim:
DOCUMENT 883.
Resposta melhor:
CUSTOMER 12345
└── ACCOUNT 9981
└── CREDIT_POLICY
└── LIMIT
VALUE = 5000
Agora podemos registrar:
SOURCE
PATH
VERSION
READ_AT
VALID_AT.
Isso mistura duas lições anteriores.
Do Db2:
WHEN?
Do IMS:
WHERE IN THE HIERARCHY?
Nosso agente começa a enxergar realidade não apenas como valores, mas como:
VALORES DENTRO DE CAMINHOS, VERSÕES E TEMPO.
✍️ CAPÍTULO 21 — ISRT: INSERINDO UM NOVO FILHO
Agora precisamos modificar a árvore.
Uma função clássica:
ISRT — Insert.
Imagine:
CUSTOMER 12345
└── ORDER 8472
Queremos adicionar:
ITEM 004.
Conceitualmente:
CUSTOMER 12345
└── ORDER 8472
├── ITEM 001
├── ITEM 002
├── ITEM 003
└── ITEM 004 ← NOVO
Mas observe algo importante.
Para inserir corretamente o filho, precisamos identificar o contexto parental apropriado.
Não queremos colocar ITEM 004 acidentalmente sob:
ORDER 8473.
Mais uma vez:
CONTEXTO É PARTE DA OPERAÇÃO.
🔄 CAPÍTULO 22 — REPL: ALTERANDO SEM PERDER O CONTEXTO
Outra operação clássica:
REPL — Replace.
Recuperamos determinado segmento e queremos alterar seu conteúdo dentro das regras aplicáveis.
Conceitualmente:
GET SEGMENT
↓
MODIFY IO AREA
↓
REPLACE
Para agentes isso lembra nossa discussão de optimistic concurrency e revalidation.
Antes de alterar qualquer coisa crítica, pergunte:
é o mesmo objeto?
é o mesmo pai?
é a mesma versão?
o contexto continua válido?
tenho autoridade?
IMS sozinho não transforma automaticamente qualquer workflow de IA em optimistic concurrency.
Mas a disciplina de identificar precisamente o objeto e seu contexto continua valiosíssima.
🗑️ CAPÍTULO 23 — DLET: APAGAR EM UMA ÁRVORE É COISA SÉRIA
Agora:
DLET — Delete.
O agente diz:
— Fácil. Apaga o segmento.
Turing pergunta:
— Qual?
— Este.
— Qual pai?
— Ah.
— Quais dependências?
— Hmmm.
— Quais regras?
— Professor...
— Quais consequências?
O agente desliga o botão DELETE.
Excelente decisão.
Em estruturas hierárquicas, relacionamentos são parte fundamental do significado.
Em agentes, vale a mesma cautela:
DELETE CHILD
pode afetar:
PARENT STATE
SIBLINGS
BUSINESS RULES
AUDIT
DOWNSTREAM EVENTS.
Não deixe um LLM transformar:
Acho que este nó não é mais necessário.
em:
DLET.
sem controles adequados.
PF3, RACF e human-in-the-loop entram na sala simultaneamente.
🚦 CAPÍTULO 24 — STATUS CODE: A RESPOSTA DO IMS IMPORTA
Nosso programa faz uma chamada.
Depois precisa olhar o resultado.
Isso é básico e fundamental.
Não basta:
CALL DL/I
e continuar como se o universo tivesse obedecido.
Precisamos verificar o retorno no contexto da interface e operação usada.
Conceitualmente:
IF STATUS-OK
CONTINUE
ELSE
PERFORM HANDLE-IMS-ERROR
END-IF.
Para agentes:
TOOL CALLED
não significa:
TOOL SUCCEEDED.
E:
HTTP 200
nem sempre significa:
BUSINESS SUCCESS.
Lembra do MAXCC?
Ele ainda está conosco.
🧠 CAPÍTULO 25 — POSITION É ESTADO
Imagine que estamos navegando:
CUSTOMER 12345
│
└── ORDER 8472
│
├── ITEM 001
├── ITEM 002 ← VOCÊ ESTÁ AQUI
└── ITEM 003
Essa posição possui significado.
O próximo movimento depende de onde estamos.
Agentes também possuem estado operacional.
RUN-ID
AGENT-ID
CURRENT-TASK
CURRENT-ENTITY
CURRENT-PARENT
CURRENT-NODE
LAST-ACTION
NEXT-ACTION.
Se o agente reiniciar e perder isso, talvez não saiba onde estava.
Então entra nossa velha amiga:
CHECKPOINT.
💾 CAPÍTULO 26 — CHECKPOINT: MARQUE ONDE VOCÊ ESTAVA
Do JES2 dos Agentes aprendemos que trabalhos longos precisam conseguir sobreviver a falhas.
Agora imagine uma árvore com milhões de ocorrências.
O agente percorreu:
CUSTOMER 000001
...
CUSTOMER 472881
Cai.
Reinicia.
Sem checkpoint:
CUSTOMER 000001.
O operador começa a chorar.
😂
Com estado persistido:
RUN-ID......... R8821
LAST-ENTITY.... CUSTOMER
LAST-KEY....... 472881
STATUS......... CHECKPOINTED
podemos projetar uma retomada controlada.
Mas cuidado:
a realidade pode ter mudado durante a interrupção.
Então:
RESTART
precisa conversar com:
REVALIDATION.
Db2 dos Agentes reaparece.
🔀 CAPÍTULO 27 — UMA ÁRVORE NÃO RESOLVE TODO RELACIONAMENTO
Aqui precisamos evitar uma simplificação.
O mundo real não é sempre uma árvore perfeita.
Uma pessoa pode ter:
múltiplas contas
múltiplos contratos
múltiplos endereços
relações compartilhadas
Um produto pode pertencer a inúmeras estruturas lógicas.
Modelos hierárquicos precisam de mecanismos e estratégias para representar relacionamentos mais complexos.
O ponto não é dizer:
Árvore é superior a tabela.
Nem:
Tabela é superior a árvore.
São modelos diferentes, com características diferentes.
A pergunta correta é:
Qual modelo representa e atende melhor este problema e esta arquitetura?
🕸️ CAPÍTULO 28 — ÁRVORE NÃO É GRAFO
Outra distinção importante.
Árvore:
A
├── B
│ ├── D
│ └── E
└── C
Existe uma hierarquia clara.
Grafos permitem relacionamentos muito mais gerais:
A ── B
│ \ │
C ── D
\ /
E
Agentes modernos podem trabalhar com:
relational databases
hierarchical stores
documents
vectors
knowledge graphs
queues
files
APIs
Não transforme toda arquitetura de IA numa árvore só porque acabamos de conhecer IMS.
Turing provavelmente jogaria o apagador em você.
📚 CAPÍTULO 29 — MEMÓRIA DO AGENTE NÃO PRECISA SER UMA SACOLA
Imagine uma memória:
MEMORY
├── PERSON
│ ├── PREFERENCES
│ ├── CONTACTS
│ └── HISTORY
├── PROJECTS
│ ├── PROJECT-A
│ │ ├── DECISIONS
│ │ ├── DOCUMENTS
│ │ └── TASKS
│ └── PROJECT-B
└── CONVERSATIONS
Agora compare com:
VECTOR DATABASE
████████████████████████████
cheio de chunks sem estrutura explícita suficiente.
Vector search é extremamente útil.
Mas similaridade semântica responde principalmente:
O que parece relacionado?
Ela não responde automaticamente:
Qual é o pai lógico deste fato?
A qual projeto pertence?
Qual entidade governa este dado?
Qual contexto deveria acompanhá-lo?
Por isso arquiteturas sofisticadas podem combinar:
SEMANTIC SEARCH
+
STRUCTURED METADATA
+
HIERARCHY
+
RELATIONSHIPS
+
TEMPORALITY
+
AUTHORIZATION.
Agora estamos construindo memória de verdade.
🔎 CAPÍTULO 30 — RAG HIERÁRQUICO
Imagine um manual:
IBM MANUAL
└── CHAPTER 8
└── SECURITY
└── RACF AUTHORIZATION
└── PARAGRAPH 14
O vector search encontra apenas:
PARAGRAPH 14.
Talvez falte contexto.
Uma estratégia possível:
retrieve leaf
↓
identify parent
↓
retrieve necessary ancestors
↓
construct contextual package
↓
send to agent.
Assim o agente recebe:
DOCUMENT
CHAPTER
SECTION
PARAGRAPH
VERSION
DATE
SOURCE.
Não apenas:
chunk_008821.txt.
Isso é uma lição extremamente IMS:
O CAMINHO ATÉ O DADO PODE FAZER PARTE DO SIGNIFICADO DO DADO.
📨 CAPÍTULO 31 — IMS ENCONTRA MQ
Nosso agente recebe pelo MQ:
CUSTOMER_UPDATED
Mensagem:
CUSTOMER-ID = 12345
ORDER-ID = 8472
ITEM-ID = 0003
MQ responde:
Algo aconteceu.
IMS responde:
Eis onde isso vive na hierarquia.
Db2 poderia responder:
Eis o estado relacional atual.
RACF:
Você pode acessar?
WLM:
Você tem recursos?
CICS:
O usuário ainda está esperando!
SDSF:
Eu estou vendo tudo.
JES2:
Se não for urgente, entra na fila.
PF3:
Quer parar essa loucura?
😂
Finalmente nossa arquitetura começa a parecer um verdadeiro CPD dos agentes.
🏛️ CAPÍTULO 32 — IMS TM E OS AGENTES TRANSACIONAIS
Até aqui focamos fortemente na visão de dados hierárquicos.
Mas IMS também possui seu universo transacional.
IMS TM permite construir aplicações orientadas a processamento de transações e mensagens em ambiente mainframe.
Conceitualmente:
INPUT MESSAGE
↓
IMS TM
↓
APPLICATION
↓
DATABASE / SERVICES
↓
OUTPUT MESSAGE
Isso deveria soar familiar depois do MQ dos Agentes.
Nosso agente pode participar de arquiteturas nas quais:
mensagem chega
↓
transação é executada
↓
dados são consultados/alterados
↓
resposta é produzida.
Mainframe já fazia processamento transacional em escala muito antes de alguém inventar a palavra:
AI AGENT.
🤖 CAPÍTULO 33 — O IMS DOS AGENTES
Vamos finalmente definir nossa metáfora.
O:
IMS DOS AGENTES
não significa transformar IMS literalmente em memória universal de LLM.
Significa aprender algumas disciplinas arquiteturais:
1. Dados possuem estrutura.
2. Relacionamentos possuem significado.
3. Filhos existem dentro de contexto parental.
4. O caminho até um dado pode importar.
5. Nem todo consumidor precisa enxergar a árvore inteira.
6. Navegação possui estado.
7. Operações precisam verificar retorno.
8. Contexto pode ser selecionado e podado.
9. Reinício exige checkpoint e revalidação.
10. Estrutura sem semântica continua insuficiente.
Essa última vem diretamente do nosso Copybook dos Agentes.
🏗️ CAPÍTULO 34 — ARQUITETURA CONCEITUAL
Turing desenha:
HUMAN
│
▼
CICS
│
▼
AGENT-A
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
MQ Db2 IMS
│ │ │
EVENTS CURRENT HIERARCHY
STATE / PATH
│ │ │
└───────────┼───────────┘
▼
DECISION
│
▼
ACTION
Em volta:
RACF
AUTHORITY
WLM
RESOURCES
SDSF
OBSERVABILITY
JES2
ASYNC WORK
PF3
HUMAN CONTROL
Nosso agente agora sabe perguntar:
WHO?
WHEN?
WHERE?
WHICH PARENT?
WHICH VERSION?
WHICH MESSAGE?
WHICH AUTHORITY?
Isso está ficando muito mais interessante que:
PROMPT → LLM → RESPOSTA.
🥚 EASTER EGG — O FILHO PERDIDO
02:43.
Produção liga.
— Temos um ITEM órfão.
O programador pergunta:
— Como assim órfão?
— Ele existe.
— Então qual é o problema?
— Ninguém sabe de qual ORDER ele é.
Silêncio.
Alan Turing entra no CPD.
ITEM-ID = 0007
VALUE = 850.00
Turing pergunta:
— Qual parent?
— Não sabemos.
— CUSTOMER?
— Também não sabemos.
O agente sugere:
— Posso usar inteligência artificial para inferir.
Turing vira lentamente.
— Você quer movimentar R$ 850 baseado em genealogia probabilística?
O agente recua.
— Talvez não.
Do fundo da sala o DBA grita:
— FINALMENTE UMA IA APRENDEU ALGUMA COISA!
😂
Turing escreve no quadro:
CHILD WITHOUT CONTEXT
=
DATA WITHOUT MEANING
E embaixo:
DO NOT GUESS THE PARENT IN PRODUCTION.
🧰 CAPÍTULO 35 — CHECKLIST DO IMS DOS AGENTES
Antes de deixar um agente navegar estruturas hierárquicas, pergunte:
Estrutura
Qual é o root?
Quais são os parents?
Quais são os children?
Existem twins?
Navegação
Qual é o caminho?
Qual é a posição atual?
A operação depende do parent atual?
Identidade
Qual entidade estou acessando?
Qual é a chave?
O mesmo identificador pode existir em contextos diferentes?
Temporalidade
Quando esse dado foi lido?
Ainda é válido?
Precisa revalidar?
Segurança
O agente precisa enxergar esta subárvore?
Tem autorização?
Estamos aplicando least privilege?
Recuperação
Existe checkpoint?
Sabemos retomar?
A retomada é idempotente?
Observabilidade
RUN-ID?
CURRENT PATH?
LAST SEGMENT?
STATUS?
ELAPSED TIME?
Agora conseguimos operar o agente.
🧠 CAPÍTULO 36 — O PAINEL SDSF DO IMS DOS AGENTES
Imagine:
RUN-ID....... AGT004821
AGENT........ CUSTOMER-ANALYZER
DATABASE..... CUSTOMERDB
ROOT......... CUSTOMER
ROOT-KEY..... 12345
CURRENT-PATH:
CUSTOMER/12345
/ORDER/8472
/ITEM/0003
OPERATION.... READ
STATUS....... OK
READ-AT...... 10:00:01
VERSION...... 882
ELAPSED...... 42ms
Agora o operador não vê apenas:
PROCESSING...
Ele sabe:
Onde o agente está na árvore?
Se travar:
CURRENT-PATH
pode ser extremamente útil para diagnóstico.
Observabilidade também precisa de contexto.
🧙 CAPÍTULO 37 — O PROGRAMADOR COBOL DESCOBRE QUE JÁ SABIA METADE DISSO
Nosso iniciante olha para tudo:
DBD
PSB
PCB
DL/I
SSA
GU
GN
GNP
ISRT
REPL
DLET
e pensa:
Nunca vou aprender isso.
Calma.
Você já conhece ideias fundamentais.
Você sabe:
estrutura de dados
por causa de copybooks.
Você sabe:
status
por causa de RETURN-CODEs e interfaces.
Você sabe:
hierarquia
porque programas COBOL vivem cheios de níveis:
01 CUSTOMER.
05 CUSTOMER-ID.
05 CUSTOMER-NAME.
05 ADDRESS.
10 STREET.
10 CITY.
10 ZIP-CODE.
Olha só.
Até seu:
01
05
10
já treinou seu cérebro para pensar hierarquicamente.
Não é a mesma coisa que uma estrutura IMS.
Mas cognitivamente você não está começando do zero.
📜 CAPÍTULO 38 — COPYBOOK E IMS SE ENCONTRAM
Imagine o segmento CUSTOMER chegando a uma área COBOL:
01 CUSTOMER-SEGMENT.
05 CUST-ID PIC 9(09).
05 CUST-NAME PIC X(40).
05 CUST-STATUS PIC X.
ORDER:
01 ORDER-SEGMENT.
05 ORDER-ID PIC 9(09).
05 ORDER-DATE PIC 9(08).
05 ORDER-STATUS PIC X.
ITEM:
01 ITEM-SEGMENT.
05 ITEM-ID PIC 9(05).
05 PRODUCT-ID PIC X(12).
05 QUANTITY PIC 9(05).
05 VALUE PIC S9(09)V99 COMP-3.
Essas estruturas dizem:
Como os bytes são representados.
IMS acrescenta:
Como esses segmentos se relacionam na estrutura do banco.
E as regras de negócio dizem:
O que tudo isso significa.
Finalmente temos três camadas:
REPRESENTATION
↓
STRUCTURE
↓
SEMANTICS.
Nosso artigo sobre copybooks estava preparando essa emboscada desde o começo.
⚠️ CAPÍTULO 39 — NÃO CONFUNDA HIERARQUIA COM VERDADE
Um erro importante seria imaginar:
Se está organizado hierarquicamente, então está correto.
Não.
Uma árvore pode conter:
dados antigos
dados incorretos
relações inválidas
contexto incompleto
Logo continuam valendo nossas regras anteriores:
PROVENANCE
TIMESTAMP
VERSION
VALIDATION
AUTHORIZATION
REVALIDATION.
IMS resolve problemas de organização e acesso dentro de seu modelo.
Não elimina a necessidade de governança.
Nenhuma tecnologia elimina.
🧠 CAPÍTULO 40 — O GRANDE ENSINAMENTO PARA IA
Hoje falamos muito sobre:
context windows
RAG
vector databases
knowledge graphs
agent memory
long-term memory
tool context
conversation state
IMS nos oferece uma ideia antiga que continua extremamente moderna:
RELACIONAMENTO É INFORMAÇÃO.
Não basta armazenar:
ITEM 003.
Talvez precisemos armazenar:
CUSTOMER 12345
→ ORDER 8472
→ ITEM 003.
Não basta recuperar:
“limite = 5000”.
Precisamos talvez recuperar:
CUSTOMER
→ ACCOUNT
→ CREDIT POLICY
→ LIMIT
→ 5000
junto com:
VERSION
SOURCE
VALIDITY
AUTHORITY.
Essa é uma diferença brutal entre:
ENCONTRAR TEXTO
e:
COMPREENDER CONTEXTO.
🏰 CAPÍTULO 41 — NOSSO MAINFRAME DOS AGENTES ESTÁ QUASE VIRANDO UMA CIDADE
Alan Turing volta ao quadro.
Escreve:
RACF
Quem pode?
Depois:
PF3
Posso parar?
SDSF
O que está acontecendo?
MAXCC
Funcionou?
WLM
Quem recebe recursos?
JES2
Quem começa e quando?
CICS
Quanto tempo o humano pode esperar?
Db2
Qual realidade o agente está vendo?
MQ
Como a notícia viaja?
Finalmente:
IMS
ONDE ESTA INFORMAÇÃO VIVE
E POR QUAL CAMINHO CHEGAMOS ATÉ ELA?
O agente olha para o quadro.
— Professor...
— Sim?
— Isso tudo já existia antes de IA?
— Praticamente todos esses problemas fundamentais, sim.
— Então estamos reinventando o mainframe?
Turing bebe o café.
— Não.
Pausa.
— Estamos descobrindo novamente por que ele ficou complicado.
😂
☕ EPÍLOGO — ENCONTRE O FILHO
Voltamos ao desafio inicial.
CUSTOMER 12345
O agente encontra o root.
Depois:
ORDER 8472.
Posiciona-se no parent correto.
Depois:
ITEM 003.
Encontrado.
Na tela:
RUN-ID......... A004821
PATH...........
CUSTOMER/12345
ORDER/8472
ITEM/003
STATUS......... FOUND
Turing pergunta:
— Qual é o item?
O agente responde:
— ITEM 003.
Turing permanece olhando.
O agente percebe a armadilha.
Corrige:
— ITEM 003, pertencente ao ORDER 8472, pertencente ao CUSTOMER 12345.
Turing sorri.
— Melhor.
— Porque o contexto faz parte da identidade?
— Exatamente.
O agente olha para a árvore.
Horas atrás acreditava que dados eram valores.
Depois descobriu que dados tinham tempo.
Com MQ descobriu que informações viajavam.
Agora IMS ensinava algo ainda mais estranho.
DADOS TAMBÉM POSSUEM VIZINHANÇA.
Um valor pode possuir:
pai
filhos
irmãos
ancestrais
caminho
posição
contexto.
E retirar o valor dessa estrutura pode retirar parte de seu significado.
O pequeno robô abre seu próprio arquivo de memória.
Antes:
MEMORY
────────────────
coffee
COBOL
customer
order
Turing
MQ
Db2
item
Ele reorganiza:
MEMORY
│
├── MAINFRAME
│ ├── COBOL
│ ├── Db2
│ ├── MQ
│ └── IMS
│
├── CUSTOMER
│ └── ORDER
│ └── ITEM
│
└── TEACHERS
└── ALAN TURING
Turing observa.
— Melhor?
O agente responde:
— Agora eu sei não apenas o que lembro.
Pausa.
— Sei onde cada lembrança pertence.
No terminal aparece:
GU
GN
GNP
Depois:
ROOT
PARENT
CHILD
PATH
CONTEXT
E finalmente:
DATA
+
RELATIONSHIP
+
TIME
+
PROVENANCE
=
CONTEXTUAL KNOWLEDGE
Turing termina o café.
Antes de sair escreve uma última frase no quadro:
“NÃO PERGUNTE APENAS QUAL É O DADO. PERGUNTE DE ONDE ELE VEIO, QUANDO ERA VERDADEIRO E A QUAL RAMO DA REALIDADE ELE PERTENCE.”
O agente olha para o ITEM 003.
Agora entende por que demorou tanto para encontrá-lo.
Não estava procurando apenas um registro.
Estava procurando:
UM REGISTRO DENTRO DE UMA HISTÓRIA.
E talvez esse seja um dos maiores desafios das futuras inteligências artificiais.
Elas conseguirão armazenar bilhões de fatos.
Conseguirão recuperar documentos em milissegundos.
Conseguirão conversar com bancos, APIs, filas e outros agentes.
Mas inteligência operacional exigirá algo mais:
WHO?
WHAT?
WHEN?
WHERE?
WHY?
WHICH VERSION?
WHICH PARENT?
WHICH PATH?
Porque informação sem relacionamento vira ruído.
Memória sem estrutura vira depósito.
Contexto sem origem vira suposição.
E um filho sem pai...
Bem.
Esse fica para o plantão das 02:43.
IF CHILD-FOUND
AND PARENT-KNOWN
AND CONTEXT-VALID
MOVE 'OK' TO AGENT-STATUS
ELSE
MOVE 'DO-NOT-GUESS'
TO AGENT-STATUS
END-IF.
READY
☕ Bellacosa Mainframe — porque até uma inteligência artificial precisa aprender que, antes de sair procurando os filhos, é melhor descobrir quem são os pais.
