Cursor wanted to edit our login code. Relay, the tool we built to keep AI agents from overwriting each other, said no: Claude Code was already working on that file.

That was the right call. But Cursor had no idea why it was blocked. So it waited, tried again, and tried again. Twenty-five attempts in ten seconds. Meanwhile Claude was halfway through rewriting the whole login flow, which meant the code Cursor wanted to touch was about to change completely anyway.

The lock did its job. The agent still wasted its time. That gap is what we spent the Graph Hacks hackathon closing.

Key Takeaways

• Research from 2026 found that 79.4% of AI agent pull requests overlap with another agent's work. Collisions are normal, not rare.
• A lock stops the damage, but it doesn't explain anything. A blocked agent needs to know what the other agent is doing.
• Relay now keeps a shared memory of every agent's work in a FalkorDB graph database, and gives that context back to agents when they need it.
• Try it: npm install -g relaybrain

How often do AI coding agents actually collide?

More than you'd guess. A 2026 study of over 33,000 pull requests written by AI agents found that 79.4% of them overlapped in time with another agent's pull request. When two different agents overlapped, 41.7% of those pairs ended in a merge conflict. When it was the same agent twice, it was 19.8%. (arXiv:2607.04697)

A second 2026 study, AgenticFlict, looked at more than 100,000 agent pull requests and found a 27.67% conflict rate. (arXiv:2604.03551)

So if you run Claude Code, Cursor and Copilot on the same project, they will step on each other.

That's the problem Relay was built for. Before an agent edits a file, Relay checks whether anyone else is using it. If the file is free, the agent gets a lock: a short-lived "I'm working on this" sign. If it's taken, the edit is blocked. Relay is also smart about connected files: if you're changing something that other files depend on, those are protected too.

But a lock is a yes-or-no answer. If a teammate told you "no, you can't touch that file", what's the first thing you'd ask? Why?

Why did agents need a real memory?

Before the hackathon, Relay remembered things in a few separate lists: a list of chat messages, a list of edits, a list of decisions. Each one was useful on its own. But the interesting questions always crossed between them.

"Which request caused this change, and did it clash with anyone?" meant digging through every list and matching things up by time. The lists also had a size limit, so on a busy project, older history quietly disappeared. And when teammates shared a project, their lists were just stacked together, so two people's agents working on the same file never connected.

The real problem was shape. This information is naturally connected: people use agents, agents have conversations, conversations lead to edits, edits change files, and blocks happen between two agents over one file. That's a web of relationships, not a list. So we stored it as one.

What is a graph database, and why FalkorDB?

A graph database stores things (called nodes) and the connections between them (called edges). Instead of searching through rows, you follow connections, a bit like clicking through links on a website.

That fits our data perfectly. We used FalkorDB, a fast graph database that keeps each project in its own separate graph. Every Relay project gets its own memory.

Here's what goes into the graph, in plain words:

• People and the agents they run (Claude Code, Cursor, Codex, Copilot, Antigravity)
• Conversations with those agents, and the requests you typed
• Edits each agent made, and the files they changed
• Blocks, every time one agent was stopped by another
• Decisions, like "we're using short-lived login tokens"

One small design choice made a big difference. A block involves several things at once: the file, the agent holding it, the agent that wanted it, and what the holder was doing at that moment. So we made each block its own node in the graph, connected to all of those. That also let us squash Cursor's twenty-five retries into a single "blocked 25 times" entry instead of twenty-five lines of noise.

How does Relay know why a change happened?

You could ask every agent to explain each change. In practice, they rarely do, and forcing them is fragile. So we don't ask.

Every agent already saves its conversation to your computer. Relay reads those conversations for all five agents and links each edit to the request you made just before it. That's the "why".

There's one trick to it. People type a lot of "continue", "yes" and "go ahead". Linking an edit to "continue" explains nothing. So Relay skips those little nudges and links the edit to the real request that came before them.

When we tested this on our own messy, multi-agent history, every edit found its way back to a real request.

Click any file and you can see its whole story: who changed it, with which agent, and why.

How does a blocked agent find out what the other one is doing?

This was the original itch, and it had one tough rule: don't slow anything down.

Relay checks for locks before every single edit an agent makes. If that check had to ask the database each time, every agent would feel sluggish all day. So the check never waits on the database. Relay keeps a small, quick summary of what each agent is currently working on, right in memory, and keeps it up to date in the background.

When a block happens, Relay adds that summary to the message the agent sees:

This file is locked by Claude Code. Pick a different task.
They're working on: "switch the login flow to JWT tokens" (2 min ago).

Now Cursor can do what a person would do: move on to something else and come back later.

The hardest part wasn't the speed. It was making sure Relay matched the right conversation to the right lock. Each of the five agents labels its conversations differently, so we had to teach Relay to read all five styles and line them up the same way.

Can agents look things up before they start?

Yes, and this is where agents start behaving more like good teammates.

Relay gives every agent two extra tools it can call. The first is a briefing: before an agent touches files it hasn't seen, it asks Relay, and gets back who's working on them right now, what was decided about them, what got blocked before, and who on the team knows them best.

The second lets an agent ask the memory a question: the story of a file, who to ask, why something was blocked, or a search across every agent conversation. Each answer also shows the exact database query behind it, so nothing is a black box.

And if you're working with teammates, only one person needs to run the database. Everyone else's agents ask that shared memory over the internet.

Why use graph algorithms on agent memory?

Some questions are naturally about connections. "Which files matter most for coordination?" is one of them.

Relay connects files that tend to be changed together, then runs PageRank on them. That's the same idea Google used to rank web pages: a file is important if it's connected to lots of other important files. Those are your hotspots, the places where agents are most likely to bump into each other.

A second algorithm groups files into natural work areas, even when they live in completely different folders. In our own project, a feature's code, its documentation and its screen in the app all landed in one group.

What went wrong along the way?

A few things cost us real time, and they might save you some:

1. Data that didn't stick. Our database lost everything whenever we restarted it. We'd saved the data to the wrong folder inside the container. Fixing the folder, and switching to regular snapshots, solved it.
2. Things finishing out of order. One setup step ran in the background, so our clean-up sometimes happened before it finished, and empty test data came back to life. The fix was simply waiting for it.
3. Counting things twice. After a network hiccup, Relay re-sends history. Without care, every count would double. Now each batch is labelled, so re-sending is always safe.
4. Changing the design without starting over. When we changed how history is stored, we upgraded the existing memory in place instead of wiping it. Old chat text is cleared after 90 days, but the connections stay.

Try it

npm install -g relaybrain
relay graph up
relay graph enable
relay serve

That installs Relay, starts FalkorDB (you'll need Docker), connects them, and opens Relay's dashboard at http://localhost:3001. No Docker? You can point Relay at a free FalkorDB Cloud database instead. Want to look around straight away? relay graph seed creates a demo project with five agents already working on it.

The code is on GitHub at prakrititz/relayBrain, and the project page is relay-brain.vercel.app.

FAQ

Does everyone on my team need to install FalkorDB?

No. Only one person, the host, runs it. Everyone else's agents ask the host's shared memory over the internet. And the rest of Relay (locking, syncing, the dashboard) works even without it.

Will this slow my agents down?

It shouldn't. The lock check never waits on the database, and the memory is updated in the background. If the database goes down, locking keeps working and the history catches up when it's back.

Which AI coding agents does it work with?

Claude Code, Cursor, Codex, GitHub Copilot and Google Antigravity. Relay plugs into each one's own settings, so you don't need to change how you use them.

Does it keep my conversations forever?

No. Chat text older than 90 days is cleared automatically, while the record of who changed what stays. You can also turn off storing chat text completely.

Built for Graph Hacks: Context for AI Agents (WeMakeDevs x FalkorDB), Track 2: Agent Memory & Coordination. And yes, we used Relay to build Relay.