Pular para conteúdo

Muninn

O Agente Muninn atua como o Executor Técnico e Operacional dentro do ecossistema Jack-In Station. Ele é o braço de execução de mais baixo nível, projetado para ser rápido, preciso e totalmente determinístico.

Abaixo detalho a origem de seu nome, o seu papel arquitetural e como ele se comporta no sistema.

A Origem do Nome

Na mitologia nórdica, Muninn é um dos dois corvos que acompanham o deus Odin, representando a "memória" (ou mente/recordação). No universo do Jack-In Station, esse arquétipo mitológico é traduzido diretamente para a sua função: Muninn atua como a memória técnica do sistema. Ele é o agente que "sabe onde a informação técnica está" e a recupera.

Ele forma uma dupla com o agente Huginn (o "pensamento"). Enquanto Huginn raciocina sobre os artefatos para explicar como as tabelas e lógicas se relacionam, Muninn simplesmente busca "o que é e o que sempre foi registrado", trazendo à tona os fatos armazenados.

O Papel de Muninn

Arquiteturalmente, Muninn é o braço executor técnico do sistema. Ele opera sob uma fronteira epistemológica extremamente rígida, resumida na regra: "Rogue decide. Muninn executa. Muninn não corrige. Muninn não interpreta. Muninn não chama LLM.".

Suas principais características e responsabilidades incluem: * Ausência de IA Generativa: Diferente de Eirene ou Pythia, Muninn não utiliza Inteligência Artificial (LLM). Ele atua de forma 100% determinística. * Zero Interpretação Semântica: Ele não tenta adivinhar o que o usuário quer dizer e não normaliza intenções. Se a entrada estiver errada ou o alvo não existir, ele simplesmente falha a execução com um erro de NOT_FOUND. * Acesso Direto ao "Ferro": É o agente responsável por executar comandos técnicos práticos e consultas físicas no banco de dados. * Catálogo de Comandos: Muninn é especializado em responder a comandos estruturados curtos, como /ddl (retorna o código de criação armazenado), /registros (executa contagens nas tabelas), /sql, /pk, /fk, /schema e /colunas.

Seu Comportamento e Arquitetura

O comportamento de Muninn é de um worker (trabalhador) assíncrono altamente obediente que responde à agente orquestradora Rogue.

1. O Fluxo de Trabalho e o Job Board Muninn não interage diretamente com o usuário. A orquestradora Rogue coloca "contratos de trabalho" em um mural (Job Board) implementado em DuckDB, especificamente no mural destinado a ele (board="muninn"). O ciclo de vida de seu trabalho é preciso: * Ele monitora constantemente o mural em busca de trabalhos com o status POSTED. * Ao encontrar uma tarefa, ele assume a posse atômica mudando o status para IN_PROGRESS. * Ele executa a consulta de banco de dados solicitada (por exemplo, efetuando um SELECT COUNT(*) na base física para o comando /registros). * Ele empacota o resultado final (um payload contendo o JSON da resposta) e devolve ao mural com o status COMPLETED ou FAILED.

2. Runtime Residente Em sua arquitetura mais recente, Muninn deixou de ser um script isolado e passou a operar como um serviço residente (MuninnWorker ou Muninn Runtime) embutido na interface principal do sistema (chat_screen). Isso significa que ele gira em um ciclo contínuo (através de uma função tick() ou work_once()), permitindo que a interface indique visualmente o seu status (● MUNINN ONLINE) e processe comandos instantaneamente sem bloquear a interface de usuário.

Graças a essa arquitetura independente e puramente técnica, Muninn pode processar múltiplos comandos de exploração de forma ultrarrápida enquanto outros agentes mais pesados (como a Myst) ficam aguardando requisições lentas do LLM em segundo plano.

muninn_flow_diagram.svg