O laboratório onde eu testo o meu método

Um apartamento-laboratório em 19 decisões de arquitetura registradas — IA local que ajuda sem nunca virar dependência.

Laborató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 projeto

O Janis é o meu laboratório — o projeto mais ambicioso e mais documentado que tenho. Começou como o sistema nervoso de um apartamento, com uma regra inegociável: a IA ajuda, mas nada essencial depende dela. Se o modelo parar, a luz, a fechadura e a presença continuam funcionando, porque a automação crítica é determinística e roda sem modelo nenhum. Mas o Janis virou algo maior: é onde eu refino a minha própria forma de construir — completamente modular e customizável, com cada decisão de arquitetura registrada por escrito (são dezenove). É o campo de provas, no meu risco, do que depois entra num sistema de cliente.

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 decisões difíceis

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 residentes usando Pydantic AI, com a orquestração virando o próprio barramento de eventos — filas e replay, em vez de um framework de agentes.
por quê: CrewAI é feito para deliberação em lote, com várias rodadas de modelo por tarefa. Cada rodada extra multiplica chamadas; numa GPU 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.
o que custou: Perdi as conveniências prontas — delegação, 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.
o que eu fiz: Três camadas de memória, cada uma para um tipo de pergunta: o agora, o factual e temporal, e o semântico. Fatos têm origem registrada e são supersedidos, nunca sobrescritos, com uma consolidação curada toda noite.
por quê: Busca vetorial é 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: Camadas para operar e uma política de consolidação para manter. Lembrar de tudo é o mesmo que não lembrar de nada — alguém tem que decidir o que esquecer.

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 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.
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 — a rede de dispositivos resolve sozinha. 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 ──▶ Reativo (sem IA · <500ms)
                │
     confiança alta │ confiança baixa
                ▼         ▼
       Automação nativa   Eventos ──▶ Egos (IA local)
                ▲
  interruptor físico (funciona com tudo o mais fora do ar)

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

O que eu refiz

O Janis não nasceu em Pydantic AI. A base anterior já rodava, funcionando, sobre CrewAI. Na unificação dos repositórios eu arranquei o CrewAI inteiro e reescrevi os quatro agentes como workers residentes, preservando a interface e os testes. 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

108

testes automatizados

agentes residentes, cada um com um papel

camadas, do host à interface

É o meu laboratório de método: além da casa, é onde eu refino como construo. A stack se levanta inteira por código (infra como código), o deploy é soberano e observado, e a disciplina de registrar cada decisão por escrito virou a própria ferramenta de trabalho. Modular por desenho — perfis e redes separadas —, com um núcleo de conversa que serve várias interfaces sem virar cérebros diferentes.

o que ainda falta

Está na fundação: a arquitetura foi aprovada e a base implementada, mas as fases de infraestrutura plena e voz ainda virão.
Em desenvolvimento, os agentes 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.

Tem um problema parecido?

Vamos conversar