IA em operação crítica

IA que pode cair sem derrubar a operação

Separando a automação determinística da inteligência probabilística.

Janis / LabOSLaboratório / P&Dexit 1302025–2026Pesquisa e desenvolvimento próprios

PythonPydantic AINATSOllamaAnsiblePrometheus

o problema

Como colocar IA dentro de uma operação crítica sem que a operação passe a depender da IA para funcionar.

O jeito comum de fazer, e por que não me servia

O assistente doméstico típico manda tudo para a nuvem: sem internet, a casa emburrece — e os dados da sua rotina moram no servidor de outra empresa.
Quando existe IA no meio, ela costuma estar no caminho crítico: se o modelo trava ou alucina, a luz do corredor às 3h da manhã trava junto.
Frameworks de agente prometem facilidade, mas escondem o que importa — o loop de chamadas ao modelo, a validação, o retry — e cobram isso em latência.
“Memória” de assistente costuma ser um balde de vetores: responde bem a “o que é parecido?” e falha em “o que aconteceu terça?”.

As três decisões difíceis

Cada uma tinha um caminho óbvio. Em todas eu segui o outro — e em todas isso custou alguma coisa.

Joguei fora o framework de agentes

o caminho óbvio: CrewAI. É o que quase todo mundo usa para orquestrar agentes.
o que eu fiz: Reescrevi os quatro Egos como workers Python residentes (asyncio) usando Pydantic AI, com a orquestração virando o próprio NATS — filas, subjects e replay via JetStream.
por quê: CrewAI é feito para deliberação em lote, com várias rodadas de modelo por tarefa. Cada rodada extra multiplica chamadas; numa GTX 1080 Ti local isso vira 10 a 30 segundos de latência onde eu precisava de 2 a 5. E eu queria agentes reagindo a eventos 24/7, não um lote que começa e termina.
o que custou: Perdi as conveniências prontas — delegação entre agentes, memória de crew. Se um fluxo multi-agente complexo aparecer, avalio uma ferramenta específica para ele, não como base de tudo.

O modelo é read-only; a memória é que cresce

o caminho óbvio: O assistente “aprende” — fine-tuning, ou joga tudo num banco vetorial e faz RAG.
o que eu fiz: Três camadas de memória, cada uma para um tipo de pergunta: Redis para o agora, SQLite para o factual e temporal (o que aconteceu, quantas vezes, desde quando) e um banco vetorial para o semântico. Fatos têm proveniência e são supersedidos, nunca sobrescritos.
por quê: Busca vetorial é estruturalmente ruim para pergunta temporal. E manter o conhecimento fora dos pesos do modelo deixa tudo auditável, apagável e portátil entre trocas de modelo — a casa cresce nos dados, não nos pesos.
o que custou: Três armazéns para operar e uma política de consolidação para manter. Um job noturno decide o que virou fato durável e o que é ruído — porque lembrar de tudo é o mesmo que não lembrar de nada.

A autoridade sobre dinheiro mora no banco, não no sistema

o caminho óbvio: Se o assistente paga contas, ele guarda a credencial e transfere quando preciso.
o que eu fiz: A recorrência é autorizada uma vez no app do banco, com teto por conta. O sistema apenas orquestra e concilia — nunca detém poder de transferência livre. Valor variável sempre pede aprovação com segundo fator; um débito acima de 1,5× do esperado não executa, vira proposta.
por quê: Pagar é a ação mais irreversível que o sistema pode tomar. Ela merece uma decisão de segurança de primeira classe, separada da arquitetura e visível no índice de decisões.
o que custou: Menos automação “mágica”: algumas ações param e esperam um toque humano. É exatamente o que se quer quando o assunto é dinheiro.

o pulo do gato

A casa nunca depende da IA

A automação crítica é determinística e roda sem modelo nenhum — Home Assistant e a rede Zigbee resolvem sozinhos. A inteligência vive numa camada à parte, alcançada por eventos, e só age quando a confiança é alta. Se a IA cai, o caminho reativo assume; se tudo cai, o interruptor de parede ainda acende a luz.

Telegram ──▶ Janis Reactive (FastAPI · sem LLM · <500ms)
                │
     confiança alta │ confiança baixa
                ▼         ▼
       Home Assistant    NATS ──▶ Egos (Pydantic AI · Ollama local)
                ▲
  interruptor físico (funciona mesmo com tudo o mais fora do ar)

Caminho reativo com fallback por confiança — a IA nunca está no caminho crítico

em português claro

Se a inteligência artificial parar de funcionar, nada essencial para de funcionar junto.

O que eu refiz

A Janis não nasceu em Pydantic AI. A base anterior já rodava, funcionando, sobre CrewAI — um wrapper fino, um agente por chamada. Na unificação dos repositórios eu arranquei o CrewAI inteiro e reescrevi os quatro Egos como workers residentes, preservando a interface pública e os testes existentes. Jogar fora código que já funciona é difícil de justificar para si mesmo. Mas a latência da deliberação em lote era estrutural, não um ajuste — e adiar a troca só aumentaria a base construída sobre a fundação errada.

Onde chegou

decisões de arquitetura registradas, uma por escolha difícil

testes automatizados

agentes residentes, cada um com um papel

camadas de memória com ciclos de vida distintos

Um sistema nervoso para um apartamento-laboratório: automação crítica determinística, quatro agentes de IA rodando localmente numa GPU própria, memória em três camadas, provisionamento do host como código (Ansible), observabilidade com Prometheus e Grafana e backup automatizado com Restic. Tudo reconstruível a partir do repositório.

o que ainda falta

Está na fundação (Fase 0/1): a arquitetura foi aprovada e a Janis unificada implementada, mas as fases de infraestrutura plena e voz ainda virão.
Em desenvolvimento, os Egos rodam via API externa; a inferência 100% local no servidor com GPU é o alvo de produção, ainda não fechado.
É P&D próprio — não é um produto vendido. Está aqui como prova de como eu penso arquitetura, não como oferta.

Tem um problema parecido?

Vamos conversar