I Got Tired of Explaining the Same Project to AI. So I Built a Shared Brain for AI Agents.
How a frustrating limitation of AI-assisted development inspired BARSA, a graph-powered memory and coordination platform built with FalkorDB.
The Moment That Started Everything
Imagine this.
You've been working with Claude for hours.
You've designed your application's architecture, created the database schema, fixed difficult bugs, implemented several features, and made dozens of small decisions.
Claude understands your project.
It knows what you've completed, why you chose a particular approach, which problems remain unresolved, and what needs to happen next.
Then you hit a usage limit.
You open ChatGPT.
And suddenly, you're back at the beginning.
You have the code, but the new assistant doesn't automatically know the reasoning behind it.
You can copy conversations, write summaries, upload files, and explain everything again.
But something about that process bothered me.
Why should switching AI assistants mean losing the continuity of my work?
I'm a computer engineering student who enjoys experimenting with AI-assisted development. The more I worked with different assistants, the more I noticed that the real problem wasn't necessarily the intelligence of the models.
It was the context surrounding them.
Every assistant could be capable, but the knowledge of what we had already accomplished was scattered.
And that led me to a question:
What if AI agents could share a common memory, just as developers share code through Git?
That question became my Graph Hacks project.
Introducing BARSA — The Collective AI Brain
Switch AI, Not Your Progress.
BARSA is an open-source-oriented AI memory and multi-agent collaboration infrastructure project designed to make working knowledge portable between compatible AI environments.
The idea is simple.
Instead of treating every AI conversation as an isolated workspace, BARSA provides a separate place to preserve meaningful project information.
Not just messages.
Actual working knowledge:
- What we're building and why.
- Requirements and constraints.
- Architectural decisions.
- Completed and unfinished tasks.
- Dependencies and blockers.
- Agent capabilities and contributions.
- Checkpoints and project history.
- Relevant files and artifacts.
Different authorized agents can retrieve that information through supported integrations and continue from the recorded state.
BARSA is not trying to replace ChatGPT, Claude, Gemini, or other assistants.
It's trying to solve the continuity problem between them.
Why Ordinary AI Memory Wasn't Enough
My first thought was straightforward.
Save everything in a database.
When another agent starts, load it back.
Problem solved, right?
Not really.
Imagine a software project with 60 tasks.
A database might tell us:
TASK-023 is incomplete.
That's useful information, but it doesn't answer the questions that matter.
Can an agent start TASK-023 right now?
Does it depend on another unfinished task?
Is there an active blocker?
Which architectural decision applies?
Does the current agent have the right technical capabilities?
What happens to other tasks if this one is completed?
A flat list of saved facts doesn't naturally express the relationships between all these questions.
And a giant conversation summary can still leave the next agent to reconstruct those relationships itself.
This is where my thinking changed.
A useful shared brain shouldn't only remember what happened. It should help an agent understand what that means for what happens next.
That's why I chose FalkorDB.
Why FalkorDB Became the Heart of BARSA
FalkorDB allowed me to represent connected project knowledge as a property graph.
Instead of treating a requirement, task, decision, or agent as an isolated record, BARSA can connect them through explicit relationships.
For example:
PROJECT ATLAS
|
+── HAS_TASK ────────> TASK-023
| |
| +── DEPENDS_ON ──> TASK-017
| |
| +── BLOCKED_BY ──> ISSUE-002
| |
| +── REQUIRES ────> CAPABILITY
|
+── HAS_DECISION ────> ARCHITECTURE DECISION
|
+── HAS_AGENT ───────> BACKEND AGENT
This changes what we can ask.
Instead of:
"Show me all incomplete tasks."
We can ask:
"Which incomplete tasks are unblocked, have satisfied dependencies, and match this agent's capabilities?"
And importantly:
"Why did you recommend this task?"
FalkorDB lets BARSA traverse connected information using Cypher queries to answer those questions.
Memory becomes a decision-making resource
In BARSA, FalkorDB powers graph-based operations such as:
Dependency analysis: Determine which tasks are ready and which depend on unfinished work.
Blocker detection: Exclude tasks affected by active blocking issues.
Capability matching: Connect agents with tasks suited to their skills.
Impact analysis: Trace how changing a requirement or decision affects related work.
Explainable recommendations: Return the relationships that influenced a suggested next action.
This was the most important architectural lesson of the project:
Storing context and reasoning over context are two different problems.
BARSA uses SQLite for transactional records and version history, while FalkorDB provides the connected graph reasoning layer.
Each serves a different purpose.
Building BARSA: Three Ideas That Shaped the Architecture
I didn't want BARSA to become just another application with a database and a chatbot interface.
I wanted its underlying concepts to remain useful across tools and workflows.
Three ideas strongly influenced the design.
1. Java-Inspired Portability
One of the things I appreciate about Java is the idea of portability through a common standard.
I applied that inspiration to AI memory.
BARSA includes the Barsa Memory Standard (BMS), intended to organize meaningful project knowledge into predictable record types.
That gives compatible clients a common structure for interpreting requirements, tasks, decisions, and checkpoints.
The purpose isn't to make every AI provider identical.
It's to make the information they collaborate around more consistent.
2. Git-Inspired Memory Versioning
Imagine two agents working on the same project.
Agent A updates an architectural decision.
Agent B is still working from an older version.
What happens next?
Simply overwriting memory would make it difficult to understand which information changed or why.
So BARSA uses Git-inspired ideas such as commits, branches, revision history, and conflict resolution.
This makes it possible to preserve how project knowledge evolves rather than treating the latest text as the only truth.
3. User-Controlled Storage
I believe the user should have meaningful control over where long-term project memory lives.
That motivated BARSA's local-first approach and its support for user-controlled storage configurations.
The long-term goal is portability without forcing users to depend on one AI provider as the permanent owner of their project history.
The Real Test: Project ATLAS
A memory platform can sound impressive in a feature list.
But I wanted a harder test.
So I created Project ATLAS, a synthetic emergency logistics and supply chain software project.
Imagine a company developing software for warehouses, inventory, suppliers, shipping, and emergency resource coordination.
The project contains interconnected work across many functional modules.
My reported ATLAS test environment included:
| Component | Scale |
|---|---|
| Functional modules | 12 |
| Development tasks | 60 |
| Requirements | 20 |
| Architectural decisions | 12 |
| Agent profiles | 8 |
| Graph nodes | 124 |
| Graph relationships | 369 |
These numbers describe a specific test state, not the maximum scale of BARSA.
The interesting part wasn't how many nodes existed.
It was whether FalkorDB could actually influence which task an agent should tackle.
Experiment 1: Find the Next Task
I queried BARSA's graph-powered continuation workflow for a backend agent.
FalkorDB recommended:
TASK-017 — Atomic Stock Reservation
The recommendation was based on connected project information, including task readiness and agent compatibility.
Experiment 2: Complete a Prerequisite
Next, I marked TASK-017 as completed.
I asked BARSA to evaluate the project again.
This time, the recommendation changed to:
TASK-023 — Supplier Purchase Order Intake
Completing work changed the graph state, which changed the next action.
Experiment 3: Add a Blocker
Then I connected TASK-023 to an active blocking issue.
On the next evaluation, FalkorDB excluded the blocked task and selected:
TASK-027
That was my favorite part of the experiment.
I wasn't manually changing a recommended task in the interface.
I was changing relationships in the project graph.
The recommendation changed because the knowledge changed.
This is the difference between a decorative graph and a graph that participates in decision-making.
Experiment 4: Match the Right Agent
I also tested capability-aware recommendations.
When evaluating work for a DevOps-focused agent, BARSA identified:
TASK-060 — Helm Chart
The graph could connect the agent's capabilities with the technical requirements of the task.
The larger goal is to help multiple agents coordinate work without blindly selecting the same tasks or starting work whose prerequisites aren't ready.
The Test That Matters Most: Disconnect FalkorDB
Graph Hacks challenged participants to make the graph essential to the application.
That made me ask a difficult question:
If I remove FalkorDB, does BARSA still make the same graph-based decisions?
To test that, I deliberately disconnected the graph engine.
The graph-powered continuation endpoint returned an HTTP 503 error with:
FALKORDB_UNAVAILABLE
Regular project storage remained accessible.
After restoring the FalkorDB connection, graph reasoning resumed.
That behavior matters because BARSA isn't supposed to pretend it has performed connected reasoning when the graph database is unavailable.
It demonstrated a clear architectural boundary:
- Transactional memory can remain available independently.
- Graph-dependent task reasoning requires the graph service.
For me, this was a stronger demonstration than simply showing a beautiful network of connected nodes.
A graph becomes essential when removing it changes what the application can actually do.
The Other Challenge: Can One AI Continue Another AI's Work?
The long-term vision behind BARSA is cross-AI continuity.
Imagine a workflow like this:
Claude
|
| Works on a project
| Saves decisions and progress
v
BARSA SHARED MEMORY
|
| Structured memory
| Project checkpoints
| Version history
| FalkorDB relationships
v
ChatGPT
|
| Retrieves authorized context
| Understands unfinished work
| Continues the project
v
NEW CHECKPOINT
BARSA exposes functionality through APIs, MCP tooling, and an installable Agent Skill so compatible clients can participate in this workflow.
The receiving agent should ideally recover:
- The project's current objective.
- Architectural decisions.
- Completed work.
- Remaining tasks.
- Active blockers.
- Relevant project artifacts.
- The next recommended action.
This is fundamentally different from pasting hundreds of old chat messages into a new conversation.
During development, I tested independent client-session continuation through the Barsa integration harness.
However, there's an important distinction I learned:
A successful scripted cross-session test does not automatically prove seamless compatibility with every real AI provider.
Real Claude-to-ChatGPT handovers also depend on client integrations, authentication, available tools, and access to source files.
That's an important area for continued development and real-world testing.
What About Token Savings?
One of my early motivations was efficiency.
A full AI development conversation can contain thousands of tokens of historical discussion that are not relevant to the next action.
BARSA attempts to recover targeted, structured context instead of always reloading the complete conversation.
In one synthetic comparison, the recorded payload sizes were approximately:
| Context approach | Tokens |
|---|---|
| Full-history baseline | 22,385 |
| Selected BARSA context | 118 |
This comparison suggests that targeted retrieval can dramatically reduce the initial context payload for that specific scenario.
But the experiment also taught me something important.
Fewer tokens do not automatically mean better answers.
If the smaller context omits an architectural constraint or critical decision, the agent may make a mistake that costs far more than the tokens saved.
A meaningful evaluation needs to consider task completion accuracy, retrieval costs, additional tool calls, and whether the recovered context is sufficient.
The goal isn't simply to minimize context.
It's to provide the right context at the right moment.
What Building BARSA Taught Me
This project pushed me beyond simply combining existing APIs.
I had to think about memory consistency, graph modeling, failure behavior, versioning, agent coordination, and trustworthy testing.
These were my biggest lessons.
Lesson 1: A Summary Is Not a Shared Brain
Summaries are useful, but complex projects need structured relationships between requirements, decisions, tasks, agents, and changes.
Lesson 2: The Best Graph Demo Is a Changed Decision
A graph with hundreds of nodes looks interesting.
A graph that changes the next recommended task after a dependency update proves something much more meaningful.
Lesson 3: Memory Needs Provenance
Knowing a decision exists isn't always enough.
Agents should be able to understand where it came from, what it affects, and how it changed over time.
Lesson 4: Multiple Agents Introduce Coordination Problems
Different agents can duplicate work, act on stale information, or produce incompatible decisions.
Persistent memory needs versioning, permissions, and conflict handling.
Lesson 5: Failure Tests Reveal the Truth
Disconnecting FalkorDB helped verify which functionality genuinely relied on graph reasoning.
Testing failure cases was as important as demonstrating successful ones.
Lesson 6: AI-Assisted Development Requires Verification
I used AI coding tools while building BARSA.
They helped accelerate implementation, testing, and documentation, but they also reinforced the need to inspect generated code, verify assumptions, and understand the actual architecture.
A polished test report isn't enough.
I needed to know which system was running, which database was being queried, and whether changing the graph genuinely changed the result.
Lesson 7: Great Infrastructure Still Needs Simple UX
Early BARSA dashboard versions exposed nearly everything: graph nodes, commits, checkpoints, memory records, handoff streams, and technical statistics.
It looked powerful, but it was complicated.
That taught me that the interface should answer a few basic questions first:
What am I working on? Who is connected? What happened last? What should happen next?
The complexity can remain available underneath.
Users shouldn't need to understand the entire architecture to benefit from it.
What I Would Improve in FalkorDB
Working with FalkorDB also helped me identify improvements that would make graph-powered AI development easier.
I'd particularly appreciate:
More complete agent-memory examples: End-to-end reference projects showing persistent agent state, dependency reasoning, and handovers.
Better graph debugging workflows: Easier inspection of traversal paths, relationship changes, and why a query produced a particular recommendation.
Clearer data synchronization guidance: Reference architectures for keeping transactional storage and graph projections consistent.
More agent integration examples: Practical guides for connecting FalkorDB-powered reasoning to MCP-based and multi-agent applications.
These aren't blockers to using FalkorDB. They're areas where additional developer tooling could make the learning process smoother.
What Comes Next?
BARSA is still an evolving project.
There are several areas I want to improve:
Real cross-provider continuity: More thorough live testing across independently authenticated AI environments.
Automatic checkpointing: Making it easier for supported agents to preserve progress without repeated manual instructions.
Better context retrieval: Finding the right balance between small payloads and complete task understanding.
Security and permissions: Improving controls for shared project memory and agent access.
Simpler user experience: Making a sophisticated memory system feel like an ordinary, easy-to-use project workspace.
And eventually, I'd like to explore more ambitious forms of knowledge sharing between compatible agents while maintaining user control and data privacy.
But I'm trying to keep the core principle simple.
Final Thoughts: AI Shouldn't Forget Our Progress Just Because We Switch Tools
We are entering a world where people increasingly work with several AI systems.
One agent researches.
Another designs.
Another writes code.
Another reviews it.
Another takes over when the previous session ends.
But for that future to work well, those agents need more than intelligence.
They need continuity.
They need a way to preserve decisions, understand dependencies, explain actions, and coordinate their contributions.
That's why I built BARSA.
FalkorDB helped me approach AI memory not just as stored information, but as connected knowledge that can guide what happens next.
And building Project ATLAS helped me understand the difference.
The future of AI collaboration shouldn't depend on copying conversations from one chatbot to another.
It should depend on preserving meaningful progress in a form that authorized agents can understand and build upon.
That's the future I want BARSA to help create.
BARSA — The Collective AI Brain
Switch AI, Not Your Progress.
Built for Graph Hacks 2026, powered by FalkorDB.
Primary Track: Agent Memory and Coordination
Tech Stack: FalkorDB, Python, FastAPI, React, TypeScript, SQLite, MCP
GitHub Repository: [Insert your public GitHub repository link]
Demo Video: [Insert your real demo video link]
Top comments (0)