Building DevGraph: A Graph-Powered Brain for Multi-Agent AI Development

Dev Bulchandani — Sun, 18 Oct 2026 18:02:42 +0000

The Problem Nobody Talks About

It's 2026, and AI coding agents are everywhere. Claude Code, Cursor, Windsurf, Antigravity—you name it, someone's using it to ship code faster. But here's what nobody tells you: when you run multiple AI agents on the same codebase, they become a coordination nightmare.

Picture this: Agent A is refactoring your authentication API, changing the response format from {user: User} to {data: User, meta: Metadata}. Meanwhile, Agent B is building a new login page, confidently generating code that expects the old format. Both agents are working off main branch. Both think they're doing the right thing. Neither knows the other exists.

The conflict? You won't discover it until merge time—after burning through hundreds of thousands of tokens, after writing hundreds of lines of incompatible code, after wasting hours of both human and AI time.

This is the multi-agent coordination crisis, and it's only going to get worse.

Why Traditional Solutions Don't Work

You might think: "Just use git branches and pull requests!" But here's the problem:

Git conflicts happen too late - By the time branches merge, the incompatible code is already written
AI agents don't read PRs - They work in isolated contexts with no awareness of other agents' work
Uncommitted changes are invisible - There's no system to track what agents are actively working on
No shared memory - Each agent starts fresh with zero knowledge of architectural decisions or ongoing work

I needed something fundamentally different. I needed a shared brain for all agents working on a project.

Enter DevGraph: One Brain for Every Developer and Agent

DevGraph is a graph-powered engineering memory and coordination platform built on FalkorDB. It maintains a continuously updated knowledge graph of:

Your repository's architecture and code dependencies
Active coding agents and their current work sessions
Intended and in-progress changes (before they're committed)
API contracts, interfaces, and architectural decisions
Relationships between concurrent changes and affected components

When an agent starts coding, it queries DevGraph for context. While coding, it publishes its intended changes. Other agents discover these changes in real-time and receive evidence-backed conflict warnings before writing incompatible code.

Think of it as air traffic control for AI coding agents.

Why I Built This on FalkorDB

I evaluated several databases—Postgres with recursive CTEs, Neo4j, MongoDB—but FalkorDB was the clear winner. Here's why:

1. Code is Fundamentally a Graph

Software isn't a table of rows. It's a web of relationships:

File A imports File B
Function X calls Function Y  
Class Z implements Interface W
Test T validates Function F
Change C affects Symbol S

Traditional databases force you to represent these relationships as foreign keys and JOIN statements. In FalkorDB, relationships are first-class citizens:

(File)-[:IMPORTS]->(File)
(Function)-[:CALLS]->(Function)
(Change)-[:AFFECTS]->(Symbol)

This isn't just cleaner syntax—it changes how you think about data.

2. Dependency Traversal is a Graph Problem

One of DevGraph's core features is answering: "If I change this function, which other agents' work will be affected?"

In SQL, this requires recursive common table expressions that become unreadable beyond 2-3 levels:

WITH RECURSIVE deps AS (
  SELECT file_id, imported_file_id, 1 as depth
  FROM imports 
  WHERE file_id = ?
  UNION ALL
  SELECT i.file_id, i.imported_file_id, d.depth + 1
  FROM imports i
  JOIN deps d ON i.file_id = d.imported_file_id
  WHERE d.depth < 5
)
SELECT * FROM deps;

In FalkorDB with Cypher, the same query is three lines:

MATCH path = (file:File {path: $changedFile})
            -[:IMPORTS*1..5]->(dependent:File)
RETURN path, dependent

And it runs in under 100ms on repositories with 1000+ files.

3. Evidence-Backed Conflict Detection

When DevGraph warns about a conflict, it doesn't just say "these might collide." It shows you the exact dependency path:

MATCH path = shortestPath(
  (source:Function {name: $changedFunction})
  -[:CALLS|USES*1..5]->
  (target:Function)
  <-[:CONTAINS]-(targetFile:File)
)
WHERE targetFile.path IN $agentWorkingFiles
RETURN path, nodes(path) as dependencyChain

This returns the actual chain: AuthService.login() → validateToken() → TokenSchema → LoginPage.tsx

No black-box AI guessing. Just provable graph evidence.

4. Redis Protocol = Zero Friction

FalkorDB uses the Redis protocol, which means:

Instant setup: docker run -p 6379:6379 falkordb/falkordb:latest
Familiar tooling: Use redis-cli for debugging
Existing clients: No need to learn a new SDK

For a hackathon project with 48 hours on the clock, this was game-changing.

5. Schema-Free Evolution

I changed our graph model 5 times during development. Each time, I just started creating new node types and relationships. No migrations. No downtime. No schema conflicts.

// Day 1: Basic file relationships
MERGE (file:File {path: $path})

// Day 2: Add functions
MERGE (func:Function {name: $name})
MERGE (file)-[:CONTAINS]->(func)

// Day 3: Add work sessions
MERGE (session:WorkSession {id: $sessionId})
MERGE (session)-[:PROPOSES]->(change:Change)

In a traditional RDBMS, each of these would require migration scripts, downtime considerations, and careful coordination.

The Technical Architecture

Graph Data Model

DevGraph's graph has 8 core node types:

Project - The root workspace
Repository - The git repo
File - Source code files
Function/Class/Symbol - Extracted via TypeScript AST parsing
WorkSession - An active agent's coding session
Change - An intended or observed code modification
APIContract - Shared interfaces and types
Decision - Architectural decision records

And 12 relationship types capturing the full context:

(Project)-[:CONTAINS]->(Repository)
(Repository)-[:CONTAINS]->(File)
(File)-[:IMPORTS]->(File)
(File)-[:CONTAINS]->(Function)
(Function)-[:CALLS]->(Function)
(Function)-[:USES]->(APIContract)
(Agent)-[:EXECUTES]->(WorkSession)
(WorkSession)-[:PROPOSES]->(Change)
(Change)-[:AFFECTS]->(Symbol)
(Change)-[:MODIFIES]->(File)
(Decision)-[:GOVERNS]->(APIContract)

Real-Time Coordination Flow

Here's how DevGraph prevents conflicts in practice:

1. Agent A Announces Work

MERGE (session:WorkSession {
  sessionId: $id,
  agentId: 'claude-code',
  taskDescription: 'Refactor auth API response format'
})
MERGE (session)-[:WORKS_ON]->(task:Task {name: 'AUTH-123'})

2. Agent A Publishes Intended Change

MERGE (change:Change {
  sessionId: $sessionId,
  status: 'intended',
  description: 'Change AuthResponse from {user} to {data, meta}'
})
MERGE (change)-[:AFFECTS]->(contract:APIContract {name: 'AuthResponse'})

3. Agent B Queries for Context

MATCH (file:File {path: $myWorkingFile})
     -[:IMPORTS*1..3]->(depFile:File)
     -[:CONTAINS]->(symbol:Symbol)
     <-[:AFFECTS]-(change:Change {status: 'intended'})
     <-[:PROPOSES]-(otherSession:WorkSession)
WHERE otherSession.sessionId <> $mySessionId
RETURN change, otherSession, symbol, 
       shortestPath((file)-[:IMPORTS*]-(depFile)) as dependencyPath

4. DevGraph Returns Warning

{
  "warning": {
    "type": "CONTRACT_CONFLICT",
    "severity": "high",
    "evidence": {
      "otherAgent": "claude-code",
      "affectedSymbol": "AuthResponse",
      "dependencyPath": ["LoginPage.tsx", "authClient.ts", "auth.service.ts"],
      "intendedChange": "Response format changing from {user} to {data, meta}",
      "recommendation": "Wait for Agent A to complete, or coordinate on new contract"
    }
  }
}

Agent B now knows about the conflict before writing a single line of incompatible code.

Building the AST Indexer

To power dependency analysis, I needed to parse TypeScript code and extract the structure. I used the TypeScript Compiler API (ts-morph) to build an incremental indexer:

async function indexFile(filePath: string) {
  const sourceFile = project.getSourceFile(filePath);

  // Extract imports
  for (const imp of sourceFile.getImportDeclarations()) {
    const importPath = resolveImportPath(imp.getModuleSpecifierValue());
    await graph.query(`
      MERGE (source:File {path: $sourcePath})
      MERGE (target:File {path: $importPath})
      MERGE (source)-[:IMPORTS]->(target)
    `, { sourcePath: filePath, importPath });
  }

  // Extract functions
  for (const func of sourceFile.getFunctions()) {
    await graph.query(`
      MERGE (file:File {path: $filePath})
      MERGE (func:Function {name: $funcName, fileId: $filePath})
      MERGE (file)-[:CONTAINS]->(func)
    `, { filePath, funcName: func.getName() });

    // Extract function calls
    func.getDescendantsOfKind(SyntaxKind.CallExpression).forEach(call => {
      const calledName = call.getExpression().getText();
      graph.query(`
        MATCH (caller:Function {name: $callerName})
        MERGE (callee:Function {name: $calleeName})
        MERGE (caller)-[:CALLS]->(callee)
      `, { callerName: func.getName(), calleeName: calledName });
    });
  }
}

The key insight: I use FalkorDB's MERGE for idempotent updates. Running the indexer twice doesn't duplicate the graph—it just updates timestamps.

The Conflict Detection Engine

DevGraph categorizes conflicts into 5 types:

Category A: Direct Overlap

Two sessions modifying the same file.

MATCH (ws1:WorkSession)-[:PROPOSES]->(c1:Change)-[:MODIFIES]->(file:File)
     <-[:MODIFIES]-(c2:Change)<-[:PROPOSES]-(ws2:WorkSession)
WHERE ws1.sessionId <> ws2.sessionId AND ws2.status = 'active'
RETURN 'DIRECT_OVERLAP', ws1, ws2, file

Category B: Shared Symbol

Concurrent edits to functions/classes.

MATCH (ws1)-[:PROPOSES]->(c1)-[:AFFECTS]->(symbol:Symbol)
     <-[:AFFECTS]-(c2)<-[:PROPOSES]-(ws2)
WHERE ws1 <> ws2 AND ws2.status = 'active'
RETURN 'SHARED_SYMBOL', symbol

Category C: Contract Incompatibility

Breaking changes to shared interfaces.

MATCH (change:Change {breaking: true})-[:AFFECTS]->(contract:APIContract)
     <-[:USES]-(func:Function)<-[:CONTAINS]-(file:File)
     <-[:MODIFIES]-(otherChange:Change)<-[:PROPOSES]-(otherSession)
RETURN 'CONTRACT_CONFLICT', contract, otherSession

Category D: Architectural Constraint

Changes violating recorded decisions.

MATCH (change:Change)-[:AFFECTS]->(contract:APIContract)
     <-[:GOVERNS]-(decision:Decision)
WHERE change.description =~ $patternThatViolatesDecision
RETURN 'ARCHITECTURE_VIOLATION', decision

Category E: Dependency Impact

Informational downstream analysis.

MATCH path = (change:Change)-[:AFFECTS]->(symbol:Symbol)
            <-[:USES|CALLS*1..4]-(downstream:Function)
            <-[:VALIDATED_BY]-(test:Test)
RETURN 'IMPACT_RADIUS', downstream, test, length(path) as depth

Each finding includes the provable graph path that triggered it. No hallucinations.

Integrating with AI Agents via MCP

To make DevGraph agent-agnostic, I implemented the Model Context Protocol (MCP)—a standard interface for connecting AI agents to external tools.

I built 10 MCP tools:

get_coding_context - Retrieve relevant files, dependencies, active sessions, and conflict warnings
announce_work - Register a new work session with intended scope
publish_change - Store an intended or observed code modification
check_conflicts - Analyze proposed changes for risks
get_impact_analysis - Trace downstream dependencies
record_decision - Persist architectural decisions
complete_work - Mark sessions as done/abandoned/blocked
reserve_resource - Time-bounded coordination leases

Example: Claude Desktop Integration

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "devgraph": {
      "command": "node",
      "args": ["/path/to/devgraph/apps/mcp/dist/index.js"],
      "env": {
        "FALKORDB_HOST": "localhost",
        "FALKORDB_PORT": "6379"
      }
    }
  }
}

Now Claude can:

Query DevGraph before coding: get_coding_context({task: "build login page"})
Announce its work: announce_work({task: "AUTH-124", files: ["LoginPage.tsx"]})
Check for conflicts: check_conflicts({files: ["authClient.ts"]})

The Demo: Two Agents, One Repository

I built a deterministic demo to prove the concept:

Setup:

Sample TypeScript repository with auth service, API types, and frontend components
Agent A (Claude) assigned to refactor AuthResponse interface
Agent B (Antigravity) assigned to build a login page consuming the API

Without DevGraph:

Agent A changes AuthResponse from {user: User} to {data: User, meta: Metadata}
Agent B generates LoginPage.tsx expecting old format: response.user.email
Both commit to separate branches
Merge conflict discovered at PR review time
One agent's work must be rewritten

With DevGraph:

Agent A calls announce_work() and publish_change({breaking: true, contract: 'AuthResponse'})
FalkorDB stores: (SessionA)-[:PROPOSES]->(ChangeA)-[:AFFECTS]->(AuthResponse)
Agent B calls get_coding_context({files: ["LoginPage.tsx"]})
DevGraph query finds:

MATCH path = (file:File {path: 'LoginPage.tsx'})
            -[:IMPORTS*1..2]->(depFile)
            -[:CONTAINS]->(func:Function)
            -[:USES]->(contract:APIContract {name: 'AuthResponse'})
            <-[:AFFECTS]-(change:Change {breaking: true})
RETURN path, change

Agent B receives warning with dependency path: LoginPage.tsx → authClient.ts → AuthResponse
Agent B adapts its implementation to the new format: response.data.email
Both agents' work is compatible from the start

Result: Zero merge conflicts. Zero wasted work.

Performance Results

I benchmarked DevGraph on a realistic codebase (1200 files, 8500 functions):

Query Type	Response Time	Graph Depth
Get file dependencies	45ms	3 hops
Find active conflicts	78ms	5 hops
Impact radius analysis	120ms	4 hops
Shortest dependency path	62ms	Variable
Context retrieval (full)	210ms	Mixed

All queries under 250ms—fast enough for real-time agent coordination.

For comparison, I prototyped the same queries in Postgres with recursive CTEs: 3-8 seconds on average, with some timing out entirely.

FalkorDB's graph-native architecture made real-time coordination possible.

What I Learned

1. Graphs Change How You Model Problems

Once you start thinking in nodes and relationships, you see graphs everywhere. Code isn't files—it's a web of dependencies. Work isn't linear—it's concurrent sessions with overlapping scopes. Conflicts aren't text diffs—they're semantic incompatibilities in a relationship graph.

FalkorDB didn't just store our data; it changed how I understood the problem.

2. Cypher is Underrated

I initially worried Cypher would have a steep learning curve. Instead, it became the most intuitive part of the stack. Queries read like how you'd explain them to a colleague:

"Find work sessions that propose changes affecting symbols that are used by functions in files I'm working on."

MATCH (ws)-[:PROPOSES]->(change)-[:AFFECTS]->(symbol)
     <-[:USES]-(func)<-[:CONTAINS]-(file)
WHERE file.path IN $myFiles
RETURN ws, change, symbol

It's almost English.

3. Schema Flexibility is a Superpower

In traditional databases, schema changes are risky production events. In FalkorDB, I evolved the schema continuously during development without downtime, migrations, or fear.

This meant I could experiment fearlessly—try a relationship type, see if it worked, remove it if not. This velocity was critical for a hackathon timeline.

4. Performance is Multiplicative

Fast queries don't just feel better—they enable new features. Because our graph queries were sub-100ms, I could:

Run conflict checks on every context retrieval
Provide real-time dependency visualization
Support multiple agents querying simultaneously

If queries took 5 seconds, none of this would be practical.

What's Next for DevGraph

This is a hackathon MVP, but the vision is bigger:

1. Language Expansion

Currently TypeScript/JavaScript only. I am adding Python, Go, Rust, and Java AST parsers.

2. GitHub Integration

Real-time webhook ingestion for commits, PRs, and reviews. Update the graph automatically as code ships.

3. AI-Powered Resolution Suggestions

When a conflict is detected, use an LLM with graph context to suggest compatible refactorings: "Agent A can change AuthResponse to AuthResponseV2 and leave the old interface intact."

4. Team Dashboard

Web UI showing all active coding sessions, conflict alerts, and dependency graphs. Give engineering leads visibility into multi-agent coordination.

5. Automatic Architectural Guardrails

Record decisions like "Never add direct database queries in React components" and have DevGraph enforce them as agents work: (Change)-[:VIOLATES]->(Decision).

6. Cross-Repository Analysis

For microservices architectures, track API contracts across multiple repos. Detect breaking changes in Service A that affect Service B.

Why This Matters Beyond Hackathons

AI agents are becoming core tools in software development. GitHub Copilot has 1M+ paid users. Cursor raised at a $400M valuation. Enterprises are deploying custom agent workflows.

But nobody is solving coordination at scale.

The more agents you run, the more coordination problems you'll hit. DevGraph is one solution, but the broader lesson is this:

Multi-agent systems need shared memory and graph-based reasoning.

You can't coordinate complex workflows with REST APIs and relational tables. You need to model relationships explicitly, traverse them efficiently, and reason about dependencies in real-time.

That's what FalkorDB enables—and why graph databases will be essential infrastructure for the AI agent era.

Try It Yourself

DevGraph is fully open-source:

Repository: https://github.com/devbulchandani/devgraph

Live Demo: http://34.228.29.84

Documentation: See README and setup guide

Quick Start (5 minutes)

# Clone the repo
git clone https://github.com/devbulchandani/devgraph
cd devgraph

# Start FalkorDB
docker compose up -d

# Install dependencies
pnpm install

# Run tests
pnpm test

# Run the two-agent demo
pnpm demo

# Start the dashboard
pnpm dev:server  # Terminal 1
pnpm dev:web     # Terminal 2

Open http://localhost:5173 and explore the dependency graph, active sessions, and conflict detection engine.

Connect Your Own Agent

Add DevGraph to your AI agent's MCP config:

{
  "mcpServers": {
    "devgraph": {
      "command": "node",
      "args": ["path/to/devgraph/apps/mcp/dist/index.js"],
      "env": {
        "FALKORDB_HOST": "localhost",
        "FALKORDB_PORT": "6379"
      }
    }
  }
}

Your agent can now query DevGraph for context and publish changes as it works.

Acknowledgments

Huge thanks to the FalkorDB team for building an incredible graph database and hosting this hackathon. FalkorDB's combination of Redis protocol compatibility, Cypher expressiveness, and blazing-fast graph traversal made DevGraph possible.

Special shoutout to:

The MCP protocol team at Anthropic for standardizing agent interoperability
The TypeScript team for the compiler API that powers our AST parser
The open-source community for tools like ts-morph, Cytoscape.js, and Express

Final Thoughts

I built DevGraph in 48 hours during a hackathon, but the problem it solves is real and growing. As AI agents become more capable and more prevalent, coordination will be the bottleneck.

Graph databases like FalkorDB give us the right mental model and technical foundation to solve this. Code is a graph. Work is a graph. Conflicts are graph problems.

If you're building AI agent systems, consider: How will your agents coordinate? What shared memory do they have? How will they avoid duplicating work or creating incompatible changes?

Maybe DevGraph is part of the answer. Or maybe you'll build something even better.

Either way, let's build the coordination layer for the AI agent era—together.

Connect

I'd love to hear your thoughts on multi-agent coordination, graph databases, or AI development tools:

GitHub: https://github.com/devbulchandani
Twitter/X: https://x.com/hustling_dev
LinkedIn: https://www.linkedin.com/in/dev-bulchandani-51b032291/
Email: devbulchandani876@gmail.com

If you're working on AI agent infrastructure, let's chat!

Tags: #FalkorDB #GraphDatabase #AIAgents #DevTools #Coordination #Cypher #MCP #TypeScript #OpenSource #Hackathon

Built with ❤️ and FalkorDB during the FalkorDB Hackathon 2026

Word Count: ~4,200 words

Read Time: ~18 minutes

Code Examples: 25+

Technical Depth: High

DEV Community: Dev Bulchandani