DEV Community: Mohammad Moiz M

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

Mohammad Moiz M — Sun, 18 Oct 2026 17:56:52 +0000

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/

AI Supervisor: AI agents do the work. AI Supervisor makes sure the work gets done.

Mohammad Moiz M — Sun, 18 Oct 2026 17:55:08 +0000

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

Building ECON: Giving Autonomous Agents an Economic Identity with monad & Brain with Kimi and Qwen-Max

Mohammad Moiz M — Tue, 13 Oct 2026 18:58:43 +0000

Building ECON: Giving Autonomous Agents an Economic Brain with Kimi and Qwen-Max

Most AI agents today are built to complete tasks.

But what happens when an agent starts interacting with an economy?

It might hold assets, consume paid APIs, manage credits, or leave resources sitting unused long after a task is complete. Knowing how to execute a task is one thing. Knowing what to do with the economic resources left behind is a completely different problem.

That's the idea behind ECON the Economic Operating Layer for Autonomous Entities.

And while building it, I've been exploring how different AI models can contribute to the engineering and reasoning behind a more responsible agent economy, including Kimi and Alibaba Cloud's Qwen-Max.

This is my build story.

🧠 What is ECON?

ECON is built around a simple idea:

Don't just let agents spend money. Give them a way to manage an economy.

A wallet tells you where assets are held. ECON aims to reason about the broader economic picture: what an agent controls, what resources it uses, what obligations it has, and what value might no longer serve a purpose.

One of the project's core concepts is the Economic Garbage Collector (EGC).

Just as a garbage collector in software helps identify resources that are no longer needed, ECON's EGC is designed to evaluate potentially unused or stranded economic value.

But economic resources aren't ordinary objects in memory. An unused asset isn't automatically recoverable, and a resource that looks inactive isn't necessarily safe to transfer or sell.

That's why ECON's recovery workflow considers eligibility, ownership, transferability, transaction costs, and policy constraints before a recovery action can proceed.

🛠️ Where Kimi fits in

Kimi was part of my development workflow for ECON.

The interesting part of building an agent economy isn't simply generating a transaction. It's designing the logic around that transaction: what should be checked, which assumptions are safe to make, and how to prevent an intelligent system from having unrestricted control over funds.

I used Kimi for exploring the architecture, implementing a module, reviewing code, or designing tests.

The value I wanted from Kimi wasn't just another block of generated code. It was assistance with the engineering process behind a system where correctness, explicit permissions, and predictable behavior matter.

⚙️ Where Alibaba Cloud Qwen-Max fits in

I also explored Alibaba Cloud's Qwen-Max as part of the development of ECON.

Different models can be useful in different parts of a software engineering workflow, but I don't want to treat model integration as a checkbox. The meaningful question is what a model actually helps the project accomplish.

For example, if supported by your actual implementation, this could include helping analyze economic recovery scenarios, reviewing implementation decisions, generating test cases, or evaluating edge cases involving transferability and authorization.

Using more than one model also creates an opportunity to compare their usefulness on the same engineering task instead of assuming that one model is automatically better at everything.

♻️ The interesting part: Economic Garbage Collection

The EGC is the part of ECON I'm particularly interested in.

Imagine an autonomous agent that has acquired credits or another economic resource for a task. The task finishes, but some of that value remains unused.

What should happen next?

ECON's intended workflow separates the problem into several stages:

Detect: Identify potentially unused or stranded value.
Evaluate: Establish what is known about the resource and whether recovery is permitted.
Calculate: Estimate the net economic value after relevant costs.
Apply policy: Check authorization and approval requirements.
Execute and verify: Perform an eligible action through the appropriate execution layer and verify the result.

The system must distinguish between value that should be kept, value that may be transferred, and value that is genuinely recoverable.

If ownership or transfer rights are unknown, the system should not simply assume permission.

🔐 AI proposes. Policy decides. Contracts enforce.

One design principle guides ECON:

An AI model should not have unrestricted authority to move funds.

The model can help analyze a situation and propose a strategy. ECON's policy layer should determine whether that strategy is permitted, and the relevant smart contract should enforce the on-chain rules.

That separation matters because a convincing AI-generated recommendation is not proof that an action is safe, authorized, or economically worthwhile.

For a system designed around autonomous economic activity, security isn't a feature to add at the end. It's part of the architecture.

🚧 What I'm learning from this build

Working on ECON has pushed me to think beyond the usual AI application pattern of sending a prompt to a model and displaying the answer.

The harder questions are about state, permissions, execution, verification, and failure handling.

I'm also learning that integrating a model is only the beginning. The real engineering work is connecting its output to a useful feature, testing the behavior, and establishing what the system can safely do.

That's the standard I want to apply to both Kimi and Qwen-Max: not just whether they can generate a useful response, but whether their contributions make the project more capable.

🌱 What's next?

The broader vision for ECON is an economic layer for autonomous entities that can track resources, understand obligations, and evaluate recovery opportunities under explicit rules.

There is still work involved in making every part of that vision reliable in real-world conditions. I want to keep building toward a system where the economic state is grounded in verifiable data and value-moving operations are authorized and confirmed—not merely suggested by an AI model.

If you're interested in autonomous agents, open-source AI, blockchain infrastructure, or the engineering challenges around giving agents more responsibility, I'd love to hear what you're building too.

Project repository: https://github.com/M0izz/ECON

Building in public, one difficult engineering problem at a time.

AI #OpenSource #monad #web3 #Kimi #Qwen #Blockchain #AgenticAI

What If Your AI Rewarded You Credits for Closing the App? 🌱

Mohammad Moiz M — Sun, 11 Oct 2026 07:31:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

What if your AI rewarded you in credits/tokens for spending less time online?
Meet OutBound - your AI Game Master for the real world.

Out Bound turns everyday offline activities into quests. Whether it’s exploring a nearby park, taking a walk, discovering something new, or helping clean up your surroundings, the app gives you a reason to step away from your screen and do something meaningful.

Inspired by the progression and community spirit of Hacktoberfest,
Out Bound brings game-like rewards to real-world actions.

🌿 How the game works:

-Get a quest: An AI Game Master generates personalized quests based on your interests and difficulty level.
-Go outside: Accept a quest and complete it in the real world.
-Show your proof: Submit evidence appropriate to the quest.
-Earn rewards: Gain XP, earn virtual GRASS, unlock badges, and build your streak.
-Redeem - Exchange the GRASS to AI tokens and credits
-Keep exploring: Take on new challenges and compete on leaderboards.

The goal isn't to keep you scrolling through another app. It's to make opening the app worthwhile - and completing a quest a reason to put your phone away.

Complete quests. Touch grass. Earn GRASS.

Demo

out-bound-flame.vercel.app

Code

M0izz / Out-Bound

How I Built It

Out Bound combines a gamified web application with an open-source AI Game Master to turn a simple idea—spending more time in the real world—into a personalized progression system.

The app uses:

Frontend: React, TypeScript, and Vite for the interactive quest experience.
Backend: Python and FastAPI for quest workflows, player progress, and application logic.
Open-source AI: Google's Gemma model to generate structured quests based on a player's interests, available time, and chosen difficulty.
Progression system: Deterministic backend logic for XP, virtual GRASS rewards, levels, streaks, badges, and leaderboards.
Proof and verification: A submission flow that lets players provide evidence appropriate to each quest before rewards are granted.
Deployment and data: Vercel and Render

A key design decision was separating AI creativity from reward authority. Gemma can suggest an engaging quest, but deterministic application logic controls validation, rewards, and progression. This makes the system easier to test and helps prevent inconsistent or exploitable AI-generated rewards.

The core gameplay loop is intentionally simple:

Generate a personalized quest.
Accept it and leave the app.
Complete the activity in the real world.
Submit proof.
Receive XP, GRASS, badges, and progress toward the next level.

The result is an AI experience designed around healthy disengagement. The app is useful when it helps the player close it.

Why Does Open Innovation Matter?

An app encouraging people to disconnect shouldn't have to depend entirely on a closed AI service.

Open-weight models such as Gemma offer developers more flexibility to experiment with model behavior, customize the experience, and explore different deployment options. They also make it possible to design toward greater privacy and, where the chosen runtime supports it, more local or offline inference.

For Out Bound, this matters because the AI is not just a chatbot added to a gamified interface. It helps shape the actual experience: deciding what a meaningful, achievable quest could look like for a particular player.

Open innovation gives developers the freedom to inspect, adapt, evaluate, and improve that experience rather than treating the model as an inaccessible black box.

The bigger idea is simple: AI should help people do more with their lives, not just spend more time with technology.

📸 I Built a Cozy Little Photobooth for Someone Special

Mohammad Moiz M — Sun, 04 Oct 2026 17:52:19 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Cozy Photobooth - a little browser-based photobooth made for a friend who loves taking pictures and collecting memories.

The idea was pretty simple :)

Instead of sending someone another boring photo, why not turn the moment into an actual keepsake?

Cozy Photobooth lets you:

📸 Take photos directly from your browser
🎞️ Choose from different photo layouts
🎨 Apply aesthetic filters
🧸 Add stickers, emojis and doodles
✍️ Personalize your photos
🖼️ Create strips, polaroids, collages and postcards
📥 Download the final result in high resolution

No account. No complicated editor. Just open it, take some pictures, make them cute, and save the memory.

Demo

cozy-photobooth.vercel.app

Code

M0izz / Cozy-Photobooth

📸 Cozy Photobooth

A premium, aesthetic, browser-based photobooth experience built with Next.js. Capture, style, and download professional-grade photo strips directly from your browser.

Tip

Live Demo: cozy-photobooth.vercel.app

✨ Overview

Cozy Photobooth is a modern reimagining of the classic physical photobooth, designed for the web. Inspired by nostalgic polaroid aesthetics, it provides an immersive and minimal interface for creating digital keepsakes.

Whether you're looking for a vintage film look or a playful sticker-filled collage, Cozy Photobooth offers a seamless, high-performance workflow that feels both familiar and state-of-the-art.

🚀 Features

🎯 Intelligent Workflow: Guided experience from layout selection to final capture.
🖼️ Iconic Layouts: Choose from classic Strips, Polaroid, Collage, or realistic Postcard formats.
🎨 Studio Suite:
- Premium Filters: Real-time filter engine (Warm Vintage, Soft Café, Golden Hour, etc.) with precision intensity control.
- Dynamic Decorations: High-quality stickers and emojis with intuitive drag-and-drop placement.
- Artist Mode: Integrated doodle layer for freehand drawing…

View on GitHub

How I Built It

I wanted the experience to feel more like an actual photobooth rather than a web form with a camera attached to it.

The app is built with:

Next.js 14
React
JavaScript
Vanilla CSS
HTML5 Canvas
Browser Media APIs
Vercel

The camera feed runs directly in the browser, while Canvas handles the final composition — filters, decorations, doodles and the different photo layouts.

The whole flow is intentionally simple:

Choose → Capture → Customize → Download

One of my favourite parts was getting the Canvas rendering right so the downloaded image actually looks good instead of being a blurry screenshot.

Why Does Open Innovation Matter?

For something like this, open innovation matters because I didn't need a huge proprietary platform to build a fun, personal experience.

Modern web APIs, open-source frameworks and community-built tooling gave me almost everything I needed:

camera → processing → composition → final image

I could experiment, break things, change the UX and build the experience around the person I was making it for :)

That's what I like about open source you can take the building blocks and turn them into something personal and
This was build for my freind who loves photobooths and yearing got it but the city she lives in didn't have any so made this for her birthday and ofcourse she cried 😭 :)

My Agent Session

I slightly use Gemini for project ratings and debugging and it was basic and simple project so it didn't required extensive AI sprints or coding sessions.

Prize Categories

Hacktoberfest Weekend Challenge: Build for a Friend