Relay

Enterprise currently is not suited for entire teams to use AI for programming. That's where Relay steps in, allowing teams to collaborate
Relay orchestrates and coordinates agents through a graph database of files' dependencies and relationships to prevent conflicts.
There are three statuses a node representing a file may have. Open, locked, and neighbor locked. this is inspired by multithreading.
Our project's system architecture.

Inspiration

AI coding agents are no longer experimental. Teams in companies run Claude Code, Cursor, Cline, and Copilot side by side, with every developer delegating real work to their own agent. This is great for individual velocity. It's a disaster for team coordination.

The issue: agents can't talk to each other. Developer A's agent has no idea that Developer B's agent is rewriting the same authentication module. Nobody finds out until PR time, when hours of parallel work collide into merge conflicts, broken builds, and wasted effort.

We saw this happening in our own workflows and realized: Git doesn't solve it. Branch strategies don't solve it. The agents themselves have no protocol for signaling intent nor preventing merge conflicts.

This is inspired by the process of multithreading, where resources are locked to ensure only one thread accesses a shared resource at a time.

What it does

Relay is a coordination layer for AI coding agents. It provides:

Lock-Based Coordination:Agents claim READING or WRITING locks before touching files. Atomic multi-file locking prevents race conditions.The three types of states a node representing a file can be in are:

Open (Default) A file that is available for editing. No one is currently working on this file.
Locked A file that someone (or a system) has explicitly locked for editing. Shown with a thicker border and different coloring. Indicates "I am actively working on this file, hands off!"
Neighbor Locked A file that is adjacent to (depends on or is depended upon by) a locked file. This is used to warn: "Be careful editing this file, someone is working on a related file." Helps prevent merge conflicts and coordination issues.

Dependency-Aware Conflict Detection: Builds live dependency graphs from repository imports. Detects both direct conflicts (same file) and neighbor conflicts (editing a file that another agent's target depends on). Orchestration Commands: Returns clear directives: PROCEED, SWITCH_TASK, PULL, PUSH. Native MCP Integration: Works with any MCP-compatible agent through a /mcp endpoint (HTTP + SSE, JSON-RPC 2.0).

How we built it

Backend: Next.js 14 with TypeScript. Vercel KV (Redis) for atomic lock transactions using Lua scripts. GitHub API integration for dependency graph generation with intelligent caching.

Frontend: React 18 with ReactFlow for interactive dependency graph visualization. Dagre for hierarchical layout. Framer Motion for lock transition animations.

MCP Protocol: Native JSON-RPC 2.0 implementation with SSE streaming directly in Next.js API routes, no separate server needed.

Challenges we ran into

Architecture Pivot: We built Relay specifically for the Dedalus Labs track, with the initial goal of leveraging their infrastructure for MCP server hosting. During our integration planning, we consulted with the Dedalus Labs team about our architecture requirements for real-time multi-agent coordination. After productive discussions, the Dedalus Labs team identified that certain expectations around our use case (specifically, open MCP server hosting with third-party non Dedalus Labs agents through their MCP SDK) weren't currently feasible with their infrastructure model. Dedalus Labs' OpenAI-compatible SDK specializes in creating new agentic workflows through one clean API, while our use case was very different. The Dedalus Labs team was incredibly supportive and encouraged us to proceed with a Vercel-hosted MCP implementation while maintaining the core principles of their track challenge.

GitHub API Rate Limits: Dependency graphs require dozens of API calls per repo. We kept on running out of API calls, making our project very difficult to test. We found a leak in our API calls that, once fixed, allowed smooth operation. Added aggressive caching and graceful degradation.

Scope: We originally wanted function-level dependency tracking. We realized this wasn't feasible and pivoted to file-level locking, which solved the core problem more reliably.

Accomplishments that we're proud of

Production-ready MCP implementation with full JSON-RPC 2.0 compliance and SSE streaming
Neighbor conflict detection that catches subtle breakages file-level locking alone would miss
<5ms p99 latency for lock operations using Vercel KV
Clean dependency graph visualization with Dagre hierarchical layout
Zero-friction integration: if your agent speaks MCP, it speaks Relay -Useful Features: Light/dark mode, admin panel (A+Shift+1), miniview, GitHub login, and brightly colored identifiable edges.

What we learned

Hackathon Lessons:

Scope ruthlessly: we cut chat features and multi-repo support to nail core lock orchestration
Be flexible: pivoting from function-level to file-level was the right call to increase efficiency
Test the happy path first: getting check_status → post_status → PROCEED working end-to-end built confidence fast Technical Insights:
Building MCP endpoints directly in Next.js was easier than expected
Redis Lua scripts gave us true atomicity without complex distributed locking patterns
Regex-based import parsing was 10x faster than full AST parsing