A maioria das ferramentas de IA hoje pressupõe um endpoint na nuvem. Lavc Systems parte de uma premissa diferente: toda a stack de execução — LLM, agentes, memória, RAG, agendador e observabilidade — é executada na própria máquina do desenvolvedor. Esta postagem analisa as decisões de engenharia que tornam isso possível e as compensações que cada escolha tecnológica acarreta.
A execução de um sistema de agente de IA na nuvem funciona bem quando você precisa atender usuários externos em grande escala. Funciona mal quando os dados que você precisa analisar são internos, confidenciais ou valiosos apenas em conjunto em sua própria infraestrutura. O histórico de tarefas, documentos internos, credenciais de API e registros operacionais de uma empresa não devem sair do prédio apenas para executar uma consulta de IA sobre eles.
Lavc Systems foi projetado em torno dessa restrição. O sistema deve ser capaz de raciocinar sobre dados proprietários, executar tarefas e manter a memória entre sessões – sem que nenhum material entre em contato com um servidor de terceiros. Cada escolha tecnológica na stack flui a partir deste princípio.
A consequência é uma arquitetura mais rígida do que a exigida por uma plataforma em nuvem. Você não pode assumir uma escala horizontal infinita. Você deve ser cuidadoso sobre o que permanece na memória, o que vai para o disco e o que é indexado em um banco de dados vetorial. A infraestrutura de IA local não é uma versão simplificada da IA em nuvem – é uma disciplina de engenharia diferente.
O backend é executado FastAPI com Python 3.14 e Uvicorn. A escolha de Python em vez de Node.js aqui não é principalmente uma questão de desempenho – é uma questão de proximidade do ecossistema. As bibliotecas mais importantes para sistemas de agentes — LangGraph, ChromaDB, HuggingFace, APScheduler, SQLAlchemy — são todas nativas de Python. Construir um backend Node.js e chamar serviços Python adiciona um limite de processo que complica o gerenciamento de estado e a depuração sem agregar valor significativo.
O suporte assíncrono de FastAPI é mapeado naturalmente no modelo de execução de um sistema de agente onde muitas operações são vinculadas a E/S: aguardando uma resposta do modelo, lendo de ChromaDB, consultando SQLite. A estrutura modular do roteador permite que cada domínio – tarefas, agentes, documentos, agendador, objetivos, observabilidade – possua seus próprios endpoints sem acoplar em um arquivo manipulador monolítico.
Ollama lida com o atendimento do modelo localmente, expondo um API compatível que o backend chama exatamente como chamaria um provedor de nuvem. O modelo padrão é qwen2.5-coder:7b, escolhido por seu forte raciocínio de código e razoável consumo de recursos no hardware do desenvolvedor. A arquitetura não se vincula a este modelo - mudar para um modelo diferente com suporte Ollama é uma mudança de configuração, não uma mudança de código.
A importante decisão de engenharia aqui é o que Ollama resolve no nível do sistema: remove a dependência da rede do caminho de inferência. Quando um agente está no meio da tarefa e precisa ligar para o modelo, a viagem de ida e volta é local. Isso torna a latência previsível, elimina o risco de limitação de taxa durante a execução intensiva e elimina a área de superfície onde os dados internos poderiam ser expostos a um provedor externo.
O custo é hardware. Um modelo de parâmetros 7B executado na CPU é mais lento que uma chamada de nuvem API. Em uma máquina com uma GPU capaz, a diferença diminui significativamente. O design do sistema leva em conta isso agrupando chamadas LLM em lote na camada de orquestração, em vez de fazer chamadas redundantes em cada etapa do agente.
LangGraph é a camada de orquestração. Em vez de escrever loops de agente imperativos em Python, LangGraph modela o fluxo de trabalho multiagente como um gráfico direcionado onde os nós são etapas do agente e as arestas são transições condicionais. Isto tem várias consequências práticas para um sistema como Lavc Systems.
Primeiro, as decisões do agente coordenador tornam-se transições gráficas explícitas, em vez de controlar o fluxo em um corpo de função. Quando o coordenador decide delegar ao agente programador, essa delegação é uma aresta nomeada no grafo, e não uma chamada enterrada dentro de um bloco condicional. Isso torna o rastreamento de execução legível e depurável – a tela Agent Graph na UI torna isso ativo, mostrando quais nós estão ativos, quais foram concluídos e quais eventos foram emitidos.
Em segundo lugar, o gerenciamento de estado do LangGraph é combinável. Cada etapa do agente recebe o estado atual do gráfico, modifica sua fatia relevante e passa o estado atualizado para o próximo nó. Isso significa que o contexto disponível para cada agente é explícito e verificado por tipo, e não um objeto de ambiente encadeado em uma stack de chamadas. Para uma trilha de auditoria que aparece para os usuários como um rastreamento operacional, as transições de estado explícitas são significativamente mais fáceis de resumir do que o estado compartilhado implícito.
ChromaDB é o banco de dados vetorial que suporta a camada RAG. A escolha de design para usar ChromaDB em vez de alternativas como Qdrant ou Weaviate se resume à simplicidade operacional: ChromaDB é executado em processo e armazena seus dados no disco local sem nenhum serviço separado para gerenciar. Para um sistema local onde a sobrecarga operacional é uma restrição primária, isso é importante.
RAG em Lavc Systems serve a dois propósitos que valem a pena distinguir. A primeira é a recuperação de documentos: quando um agente precisa raciocinar sobre documentos internos – PDFs carregados, arquivos de políticas, referências técnicas – ele consulta ChromaDB com uma incorporação do contexto da tarefa atual e recupera os k principais pedaços semanticamente relevantes. O segundo propósito é o feedback do artefato: os resultados gerados pelos agentes durante a execução da tarefa podem ser carregados de volta no ChromaDB, disponibilizando a saída de uma tarefa como contexto para tarefas futuras.
Os embeddings são gerados usando a biblioteca Sentence Transformers do HuggingFace, novamente executando localmente. O modelo de incorporação é executado uma vez na inicialização e permanece residente na memória durante a sessão. Isso elimina a necessidade de chamar uma API de embeddings para cada consulta de bloco de documento, o que reintroduziria as preocupações de latência e privacidade que justificavam a infraestrutura local em primeiro lugar.
A memória do agente em Lavc Systems usa um HybridMemory abstração que unifica dois backends de armazenamento diferentes: SQLite para registros estruturados e ChromaDB para recuperação semântica.
A divisão é deliberada. Registros estruturados – histórico de tarefas, interações do usuário, fatos específicos sobre o estado do sistema – pertencem ao SQLite porque precisam ser consultados de forma determinística. "Quais tarefas o agente programador concluiu esta semana" é uma consulta SQL, não uma pesquisa semântica. Mas "qual contexto é mais relevante para esta tarefa" é uma questão semântica, e isso pertence a ChromaDB.
HybridMemory permite que a camada de agente use uma única interface e roteia a consulta para o armazenamento apropriado com base no tipo de consulta. Isso evita o modo de falha comum em que as equipes escolhem um paradigma de armazenamento e, em seguida, distorcem todas as consultas para ajustá-lo: forçando pesquisas semânticas em pesquisas SQL LIKE ou colocando filtros estruturados em pontuações de similaridade vetorial.
Agendador APS lida com trabalhos recorrentes – tarefas que precisam ser executadas de acordo com uma programação e não sob demanda do usuário. Isso tem mais consequências do que parece para um sistema de agente. Uma fração significativa do valor operacional não vem de conversas interativas de IA, mas de tarefas que são executadas de forma confiável em segundo plano: geração diária de relatórios, agregação de dados, reindexação de documentos, verificações de integridade do sistema.
Acima do APScheduler está o GoalEngine, que gerencia objetivos de ordem superior. As metas não são tarefas programadas – são missões multitarefas com urgência, importância e fatores de prazo associados que geram um priority_score. Uma meta como "preparar o relatório executivo semanal" pode ser decomposta em diversas tarefas: extrair documentos recentes, resumir riscos e oportunidades, gerar um relatório Markdown e criar tarefas de acompanhamento no Kanban.
O relacionamento entre o escalonador, o mecanismo de meta e o Kanban é a espinha dorsal operacional do sistema. O Kanban rastreia o estado de execução. O agendador dispara a recorrência. O mecanismo de metas fornece a intenção de nível superior que define quais tarefas serão criadas e em que sequência.
O front-end é um React 18 aplicativo construído com Vite e estilizado com CSS do vento favorável. Usos de gerenciamento de estado Zustand. Essas são escolhas convencionais para um aplicativo TypeScript primeiro React, e o interesse é menos em por que cada um foi escolhido e mais em como eles se adaptam aos requisitos em tempo real de uma interface de monitoramento de agente.
A tela Agent Graph é a parte tecnicamente mais exigente do frontend. Ele renderiza o fluxo de trabalho multiagente ao vivo – nós, bordas, estados ativos, contagens de eventos e linha do tempo – e atualiza em tempo real à medida que o backend envia eventos WebSocket. Isso requer um armazenamento Zustand que possa receber atualizações parciais do manipulador WebSocket e acionar novas renderizações seletivas sem renderizar novamente o gráfico inteiro em cada evento.
A placa Kanban tem um requisito diferente: atualizações otimistas. Quando um usuário arrasta um cartão de tarefa para uma nova coluna, a UI deve refletir essa alteração imediatamente, antes da solicitação PATCH para /api/tasks/{id}/move foi concluído. Se a solicitação falhar, o cartão deverá ser revertido. Esse padrão — mutação otimista com reversão de falha — é gerenciado no armazenamento de tarefas Zustand, e não dentro do componente, mantendo a camada do componente livre de lógica de coordenação.
O /ws O endpoint transporta todos os eventos em tempo real do backend para o front-end: alterações de status de tarefas, conclusões de etapas do agente, entradas de log, atualizações de integridade do sistema e resultados de trabalhos do agendador. Usar uma única conexão WebSocket em vez de pesquisar vários endpoints reduz a carga do servidor e fornece à UI um modelo de evento consistente, independentemente de qual módulo gerou o evento.
O backend gerencia a conexão WebSocket em ws.py, que mantém a lógica de gerenciamento de conexão separada dos módulos do roteador. Cada roteador emite eventos chamando um emissor de eventos compartilhado; o manipulador WebSocket assina esse emissor e encaminha eventos para clientes conectados. Isso significa que adicionar um novo tipo de evento — digamos, uma nova ação de agente em um módulo futuro — requer apenas a emissão do evento do novo roteador, sem alterações na camada de transporte WebSocket.
Uma plataforma que armazena credenciais de API, executa tarefas de forma autônoma e se conecta a ferramentas externas precisa de um modelo de segurança coerente, mesmo quando executada localmente. Lavc Systems inclui gerenciamento de usuários e empresas com acesso com escopo definido, um log de auditoria que registra quem fez o quê e quando, e um cofre de credenciais locais para armazenar chaves e segredos API usados por ferramentas e plug-ins.
O cofre não é intencionalmente um gerenciador de segredos da nuvem. Armazenar credenciais localmente em um cofre que a camada do agente possa ler em tempo de execução mantém os segredos fora de qualquer serviço externo, ao mesmo tempo que permite a automação que os exige. A desvantagem é que a segurança do cofre local é tão forte quanto a máquina em que ele é executado – o que é um limite aceitável para um sistema projetado explicitamente para operação local.
Skyler aparece em dois lugares no portfólio Lavc. A versão pública - Skyler Assistant — roda em Cloudflare Workers com RAG manual, fallback de provedor e um modelo de orquestração leve projetado para visitantes de portfólio público. Ele responde a perguntas sobre o trabalho, a stack e a experiência de Patrick. Não tem acesso a dados privados. Não executa tarefas. É uma interface conversacional somente leitura em uma base de conhecimento fixa.
Skyler dentro de Lavc Systems é uma implementação diferente na mesma função conceitual. Ela é executada dentro do backend FastAPI, tem acesso ao banco de dados SQLite, pode consultar ChromaDB, pode criar tarefas, ler arquivos carregados, gravar credenciais no cofre local e gerar um rastreamento operacional de suas próprias respostas. O rastreamento não é uma prosa gerada pelo modelo sobre o que o modelo pensou — é um registro estruturado das transições de estado reais executadas durante a resposta: intenção detectada, fonte de contexto consultada, ação tomada, próxima etapa recomendada.
A lição arquitetônica de ambas as versões é que a qualidade de um assistente de IA não é determinada principalmente pelo modelo. É determinado pelos dados que o assistente pode obter, pelas ações que lhe é permitido tomar e pela transparência do seu raciocínio para as pessoas que nele dependem. O público Skyler é útil porque possui a base de conhecimento correta e regras de resposta claras. O sistema Skyler é mais capaz porque tem acesso a todo o contexto operacional da plataforma em que vive.
Os sistemas de agentes falham de maneiras difíceis de depurar sem observabilidade estruturada. Uma tarefa que produz um resultado errado pode ter falhado na etapa de planejamento do coordenador, na etapa de recuperação de documentos do analista, na etapa de geração do programador ou na etapa de validação do revisor – e sem dados de rastreamento, o único sinal é que a saída estava errada.
Lavc Systems trata a observabilidade como uma preocupação de primeira classe desde o início. O módulo de observabilidade registra rastreamentos, métricas e eventos de execução para cada ação do agente. A tela Controle os expõe como um painel. A página de detalhes da tarefa mostra o log completo de execução de uma tarefa específica, incluindo quais agentes foram executados, quais ferramentas eles chamaram, qual contexto eles consultaram e quanto tempo levou cada etapa.
Isto não é principalmente para depuração – é para confiança. É difícil confiar em um sistema de agente que executa de forma autônoma e produz resultados sem qualquer janela de como ele chegou lá para um trabalho consequente. Observabilidade é o mecanismo pelo qual o sistema ganha confiança para funcionar sem supervisão em tarefas cada vez mais importantes.