AI Supervisor 協調 AI 編碼智能體並核驗任務結果

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

AI coding agents can write code and complete tasks, but a completion message doesn't guarantee a working result. They can repeat failed approaches, lose context during handoffs, or report success when their changes still fail verification. Developers end up supervising every run manually.

AI Supervisor is a control plane for AI coding agents. You give it a mission, and it structures the work into tasks, requires human approval before execution, coordinates compatible agent runtimes, monitors progress, responds to failures, and verifies results against acceptance criteria.

One of its central principles is that completed and verified are different states. Dependent work should not proceed simply because an agent says it has finished.

We also integrated FalkorDB as the graph memory layer. Rather than treating execution history as disconnected logs, we connect missions, tasks, failures, supervisory decisions, handoffs, and verification evidence. This creates a traceable history that developers can explore to understand why a task failed, what decision followed, and what evidence supports the outcome.

The project is designed for developers, AI engineers, and small teams running AI agents on real, multi-step software development tasks.

Demo

Live application: https://ai-supervisior.vercel.app/

The application includes a Control Room for mission execution and a FalkorDB Graph Memory Workspace for exploring graph health, task relationships, execution lineage, supervisory decisions, and verification evidence.

Code

GitHub repository: https://github.com/M0izz/AI-Supervisior

The project uses React, TypeScript, and Vite for the frontend; Python and FastAPI for the backend; WebSockets for real-time updates; SQLite for application state; FalkorDB for connected mission memory; and Git Worktrees for task isolation where configured.

How I Built It

I approached AI Supervisor as an orchestration and reliability problem rather than another chat interface around an LLM.

The workflow is built around a mission lifecycle:

Understand → Plan → Approve → Execute → Monitor → Recover → Verify

A user first submits a goal. The Supervisor structures it into tasks, dependencies, and acceptance criteria. The user reviews the plan before execution begins. During execution, the system tracks task states and events, while watchdog monitoring helps surface stalls and recurring failures. Results are then evaluated against the required criteria.

FalkorDB provides the graph model behind the mission relationships. Nodes represent entities such as missions, tasks, executions, failures, decisions, handoffs, verifications, and evidence. Relationships such as DEPENDS_ON, FAILS_WITH, RESPONDS_TO, SELECTS, EVALUATES_EXECUTION, and SUPPORTED_BY connect these entities.

This structure makes execution history easier to investigate. For example, a failure can be traced to the decision that followed it, the agent selected for the next attempt, and the evidence associated with verification.

SQLite and FalkorDB serve different purposes: SQLite handles application state, while FalkorDB represents connected mission history and relationships. A dedicated graph storage layer and the Graph Memory Workspace make that information accessible to the application and developers.

A demonstration workflow involving a UTF-8 BOM parsing error helped illustrate how a failed attempt, recovery path, and verification evidence can be connected and inspected.

Why Does Open Innovation Matter?

AI supervision needs to work across different tools, runtimes, and infrastructure choices. Locking the entire system to one proprietary agent or model would make it harder for developers to adapt the workflow to their own projects.

Open innovation makes it possible to inspect the architecture, adapt integrations, experiment with different compatible runtimes, and improve the system collaboratively. Open-source components also let us choose specialized tools for different responsibilities instead of forcing everything into a single platform.

FalkorDB was especially relevant because its graph model gave us a way to represent relationships between failures, decisions, dependencies, and evidence explicitly. Those connections are central to making mission history useful for debugging and supervision.

The broader lesson is that reliable AI-agent systems need more than capable models. They need transparent state, connected context, inspectable decisions, and ways to verify outcomes.

Prize Categories

• Best Open-Source AI Project