Giving AI Agents a Memory They Can Reason Over: Building AI Supervisor with FalkorDB

How we used graph memory to connect failures, decisions, dependencies, and verification in an AI coding-agent control plane.

The problem: AI agents can finish a task without finishing the job

AI coding agents are getting better at writing code, fixing bugs, and completing multi-step tasks. But delegating work to an agent still creates a problem: how do you know the job was actually done correctly?

An agent might misunderstand a requirement, repeat a failed approach, lose important context during a handoff, or report success even when its changes fail tests. When several tasks depend on one another, these problems become harder to manage.

Developers end up supervising every run: checking progress, diagnosing failures, deciding what to try next, transferring context, and verifying the output manually.

That led us to build AI Supervisor around a simple principle:

An agent's completion message is a claim. Evidence determines what can be verified.

Instead of managing isolated agent runs, users submit a mission. AI Supervisor plans the work, coordinates compatible agents, monitors execution, handles recovery, and evaluates results against acceptance criteria.

Why graph memory?

Our first challenge was not simply storing execution history. It was representing how one event affects another.

Consider a failed coding task. The failure matters, but so do the questions that follow:

• Which execution produced the failure?
• What decision did the Supervisor make in response?
• Which agent was selected for the next attempt?
• Was the task eventually verified?
• What evidence supports the result?

A collection of disconnected logs makes these relationships harder to follow. We wanted mission history to be connected and queryable.

We chose FalkorDB as the graph memory and relationship layer for AI Supervisor. SQLite continues to handle application state, while FalkorDB represents relationships across missions, tasks, executions, failures, decisions, handoffs, and verification evidence.

Turning execution history into a graph

We model the important parts of a mission as graph entities, including Mission, Task, Execution, ExecutionEvent, Decision, Handoff, Verification, and Evidence.

Relationships express how these entities connect:

• DEPENDS_ON represents task dependencies.
• FAILS_WITH connects an execution to a failure event.
• RESPONDS_TO connects a supervisory decision to the event that triggered it.
• SELECTS records agent selection.
• TRANSFERS_CONTEXT represents context transfer during handoffs.
• EVALUATES and EVALUATES_EXECUTION connect verification to a task and a specific execution.
• SUPPORTED_BY links verification to supporting evidence.

These relationships give us more than a history of what happened. They provide a structure for investigating why it happened and what followed.

The difference between completed and verified

One of our most important design decisions concerns task dependencies.

Suppose an agent reports that a task is complete. That does not automatically mean its output is correct. A change might compile but fail its tests, or an implementation might miss an acceptance criterion.

AI Supervisor distinguishes between completion and accepted verification. A dependent task should remain blocked until the required prerequisite verification is accepted.

FalkorDB represents the dependency and verification relationships so they can be inspected together. This makes it easier to trace why a task is blocked and which execution and evidence relate to its verification.

The broader lesson is that agent coordination needs explicit state and evidence—not just optimistic status messages.

Making failures useful: our parsing-error demonstration

We also built a failure-recovery workflow involving a UTF-8 BOM parsing issue.

The initial execution encounters a parsing error. The workflow records the failure and connects it to the subsequent recovery decision, selected agent, next attempt, and verification evidence.

That sequence matters because a retry should not be treated as an unrelated event. Connecting the attempts creates a traceable history that developers can inspect to understand what failed, how the system responded, and whether the eventual result was verified.

With FalkorDB, these events become related graph data rather than isolated records. The persisted graph can also be inspected after restarting the application.

This is the direction we want AI supervision to take: failures should leave behind useful context for recovery and debugging.

Making graph memory visible

We built a Graph Memory Workspace so the graph would be something developers could explore rather than an invisible database behind the application.

The workspace includes graph health and statistics, an interactive graph explorer, node and relationship inspection, execution and decision lineage, activity history, and a read-only Cypher query interface with query templates.

This gives developers a way to inspect mission relationships directly: follow a failure to the decision it triggered, examine the subsequent attempt, and trace verification back to its supporting evidence.

The graph becomes both an architectural component and a debugging tool.

What we learned

Building AI Supervisor taught us several lessons.

1. Relationships can be as important as records. Storing an execution is useful, but connecting it to its failure, recovery decision, and verification makes the history much more informative.

2. Memory needs a purpose. Persistent storage alone does not make an AI system more reliable. The important question is whether stored context can help explain decisions, coordinate work, or support recovery.

3. Verification should be part of orchestration. Treating verification as an afterthought allows unverified work to flow into dependent tasks. Making accepted verification a prerequisite creates a clearer boundary between attempted work and validated outcomes.

4. Observability should be built into the architecture. Developers need to understand not only what the system did, but why a task is blocked, which event triggered a decision, and what evidence supports the result.

5. Honest system states matter. An unavailable agent, a failed execution, and an unverified result should not be presented as successful outcomes. Reliable supervision requires visible states and traceable evidence.

What we built with

AI Supervisor 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.

The project includes a graph storage layer, graph-backed mission relationships, API endpoints for graph inspection, a Graph Memory Workspace, and tests covering graph integration and mission-control behavior.

What's next?

We want to continue improving how AI Supervisor uses mission history to support recovery decisions, coordinate work across compatible agent runtimes, and verify results independently.

There are still engineering challenges in keeping application state and graph history consistent, handling infrastructure failures, and ensuring that recovery decisions are genuinely informed by previous attempts. Those are areas that require continued testing and refinement.

Our goal is not to add a graph database just to say that a project uses one. It is to make connected memory useful to the actual workflow.

Final thoughts

AI agents can generate code, but dependable software development also requires coordination, recovery, accountability, and verification.

FalkorDB gave us a natural way to model the relationships behind that process. By connecting tasks, failures, decisions, handoffs, and evidence, we can make mission history easier to query, explore, and understand.

AI Supervisor is built around one idea: delegate the work, but never confuse an agent's claim of success with evidence that the job is done.

Project: https://github.com/M0izz/AI-Supervisior

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