Bellacosa Mainframe e os grafos do conhecimento

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