How I built an AI Kanban platform with FastAPI, RAG and agents

The product boundary

The platform is not a chatbot attached to a board. The Kanban is the operational surface and the agent system is the execution layer behind it. Tasks, logs, context, and status updates must stay connected so the user can understand what the system is doing.

FastAPI as the control plane

FastAPI owns the API boundary, task creation, agent calls, document access, and WebSocket events. This keeps model calls, memory access, and UI state behind explicit backend routes instead of spreading orchestration logic into the frontend.

RAG and memory

RAG is useful only when retrieval is scoped and auditable. Lavc Systems separates structured records in SQLite from semantic retrieval in ChromaDB, then uses local embeddings and Ollama so internal context can remain on the machine.

What this demonstrates

The project demonstrates applied AI engineering, backend design, local LLM orchestration, task observability, and a practical boundary between generated suggestions and system actions.

Why Kanban is a useful AI interface

A Kanban board gives the agent workflow a concrete shape. Instead of asking a user to trust a hidden chain of prompts, each task can expose intent, current status, blockers, generated notes, and final output. That matters because AI work often fails in the middle, not only at the answer. A task can be waiting for retrieval, waiting for a tool result, blocked by missing context, or ready for human review. Modeling those states in the product turns agent behavior into something inspectable.

Designing agents as backend workers

The safer pattern is to treat agents as backend workers with narrow responsibilities. A planning agent can break work down, a retrieval step can load context, and a synthesis step can prepare the response, but the API still owns persistence, permissions, logging, and state transitions. This keeps the model from becoming the application. It also makes testing easier, because the workflow can be exercised around inputs, outputs, events, and failure states instead of relying only on prompt snapshots.

Observability changes the user experience

WebSocket updates are not only a technical convenience. They let the UI show what changed without forcing the user to refresh or guess whether the system is stuck. When logs, task state, and agent events move together, the product becomes calmer to operate. A user can see that retrieval finished, a model call is running, a validation step failed, or a final answer is waiting. That transparency is what makes an AI system feel like software rather than a black box.