Como criei uma plataforma Kanban com IA usando FastAPI, RAG e agentes
Notas de arquitetura do Lavc Systems: backend FastAPI, UI React, LLMs locais, RAG, memória vetorial, agentes, observabilidade WebSocket e orquestração de tarefas.
Notas de arquitetura do Lavc Systems: backend FastAPI, UI React, LLMs locais, RAG, memória vetorial, agentes, observabilidade WebSocket e orquestração de tarefas.
A plataforma não é um chatbot acoplado a um quadro. O Kanban é a superfície operacional e o sistema de agentes é a camada de execução por trás dele. Tarefas, logs, contexto e status precisam ficar conectados para o usuário entender o que o sistema está fazendo.
O FastAPI concentra a fronteira de API, criação de tarefas, chamadas de agentes, acesso a documentos e eventos WebSocket. Isso mantém chamadas de modelo, memória e estado de UI atrás de rotas explícitas de backend.
RAG só é útil quando a recuperação é bem delimitada e auditável. O Lavc Systems separa registros estruturados em SQLite da busca semântica no ChromaDB, usando embeddings locais e Ollama para manter contexto interno na máquina.
O projeto demonstra engenharia de IA aplicada, design backend, orquestração com LLM local, observabilidade de tarefas e separação prática entre sugestões geradas e ações do sistema.
Um quadro Kanban dá forma concreta ao fluxo dos agentes. Em vez de pedir que o usuário confie em uma cadeia invisível de prompts, cada tarefa pode mostrar intenção, status atual, bloqueios, notas geradas e saída final. Isso importa porque trabalhos com IA costumam falhar no meio do caminho, não apenas na resposta. Uma tarefa pode estar aguardando recuperação de contexto, resultado de ferramenta, informação ausente ou revisão humana. Modelar esses estados no produto torna o comportamento dos agentes inspecionável.
O padrão mais seguro é tratar agentes como workers de backend com responsabilidades estreitas. Um agente de planejamento pode quebrar o trabalho, uma etapa de recuperação pode carregar contexto e uma etapa de síntese pode preparar a resposta, mas a API continua responsável por persistência, permissões, logs e transições de estado. Assim o modelo não vira a aplicação inteira. Isso também facilita testes, porque o fluxo pode ser validado por entradas, saídas, eventos e falhas, não apenas por snapshots de prompt.
Atualizações via WebSocket não são só conveniência técnica. Elas permitem que a UI mostre o que mudou sem obrigar o usuário a atualizar a página ou adivinhar se o sistema travou. Quando logs, estado de tarefa e eventos de agentes caminham juntos, o produto fica mais tranquilo de operar. O usuário enxerga que a busca terminou, uma chamada de modelo está rodando, uma validação falhou ou uma resposta final está pronta. Essa transparência faz o sistema de IA parecer software de verdade, não uma caixa preta.