Multi-Agent Kanban

A natural-language interface for a team Kanban board. Users type requests in plain English ("create a task to fix the login bug and assign it to Priya"), and a LangGraph state machine classifies the intent, extracts the relevant entities, and drives the corresponding Kanban action while enforcing role-based access control. It is backed by a FastAPI service, a Supabase (Postgres) database, and a React + shadcn/ui frontend.

What it does

• Turns free-form chat messages into structured Kanban operations: create, update, move, assign, and delete tasks and projects, plus read-only information queries.
• Classifies each message into an intent (for example CREATE_TASK, MOVE_TASK, ASSIGN_TASK, QUERY_INFORMATION) and extracts entities such as task titles, assignees, and status.
• Asks follow-up questions when a request is missing required fields before it commits an action.
• Separates conversation flows into talking to your own agent, routing a request to another user's agent, and query-only lookups.
• Supports admin and member logins with company-level (multi-tenant) isolation so users only see data belonging to their own company.

Architecture and approach

The core of the backend is a LangGraph StateGraph that models the conversation as an explicit state machine. Each incoming message flows through the graph:

1. Intent classification node. An LLM-backed classifier (intent_classifier.py, using langchain-openai with gpt-4o-mini) determines the intent and extracts structured entities.
2. Conditional routing. Based on the classified flow type (OWN_AGENT, OTHER_AGENT, QUERY_ONLY) the graph routes to the matching node.
3. Follow-up node. If required fields are missing, the graph pauses and asks the user for the missing information.
4. Kanban integration node. Completed, validated intents are translated into Kanban operations against Supabase (kanban_integration.py, kanban_service.py).
5. Response generation node. A natural-language reply is generated and returned to the client.

Conversation state, classified intents, and Kanban updates are persisted to Supabase, which also enables conversation continuity across turns and vector-similarity lookups over prior messages (see database_migrations/add_vector_search_function.sql).

React + shadcn/ui frontend
        |  REST (axios)
        v
FastAPI  (backend/main.py, ~39 endpoints)
        |
LangGraph state machine (backend/langgraph_service_complete.py)
   intent classification -> routing -> follow-up -> kanban action -> response
        |
Supabase / Postgres  (auth data, tasks, projects, conversation flows, messages)
        ^
OpenAI API (gpt-4o-mini) for classification and responses

A more detailed design write-up lives in backend/LANGGRAPH_ARCHITECTURE.md.

Tech stack

• Backend: Python, FastAPI, Uvicorn, LangGraph, LangChain, langchain-openai, Pydantic, supabase-py.
• LLM: OpenAI gpt-4o-mini for intent classification and response generation.
• Database: Supabase (PostgreSQL), with SQL migrations under database_migrations/ and backend/langgraph_schema.sql.
• Frontend: React 18, TypeScript, Vite, shadcn/ui (Radix UI), Tailwind CSS, TanStack Query, axios.

Repository layout

backend/               FastAPI app, LangGraph service, intent classifier, Kanban integration
backend/*.sql          Database schema for LangGraph tables
database_migrations/   Incremental SQL migrations
frontend/              React + Vite + shadcn/ui client

Setup and run

Prerequisites

• Python 3.11+
• Node.js 18+
• A Supabase project and an OpenAI API key

1. Database

Create a Supabase project, then apply the SQL in backend/langgraph_schema.sql and the files in database_migrations/ using the Supabase SQL editor or psql.

2. Backend

cd backend
python -m venv venv
source venv/bin/activate        # on Windows: venv\Scripts\activate
pip install -r requirements.txt

cp .env.example .env            # then fill in your own keys
python main.py                  # serves on http://localhost:8000

backend/.env must define SUPABASE_URL, SUPABASE_ANON_KEY, and OPENAI_API_KEY. See backend/.env.example.

3. Frontend

cd frontend
npm install
cp .env.example .env            # then fill in your own values
npm run dev                     # Vite dev server

frontend/.env must define VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, and VITE_API_BASE_URL (the backend URL, default http://localhost:8000). See frontend/.env.example.

Scope and limitations

This is a proof-of-concept and personal project, not production-hardened software. Known limitations, kept here honestly rather than hidden:

• Authentication uses SHA-256 password hashing with a salt. This is not a slow password-hashing function; a production system should use bcrypt, scrypt, or Argon2.
• The backend CORS policy is currently allow_origins=["*"], which is convenient for local development but too permissive for production. Restrict it to known origins before deploying.
• The Supabase anon key is a public, client-side key by design. Data protection therefore depends on Supabase Row Level Security policies being configured correctly; do not rely on the frontend alone for authorization.
• Multi-tenant isolation is enforced in application code by passing company_id/user_id through the endpoints. It has not been formally audited.
• No automated test suite is included, and the project has not been load-tested.
• Secrets must be supplied via environment variables. No real credentials are committed; use the provided .env.example files.

License

Released under the MIT License. Copyright (c) 2025 Tanmay Bisen.