After Ditching the Pricing Calculator, We Built a Memory Engine for AI Coding Assistants Using a Graph Database

AI coding assistants (like Claude Code and Cursor) repeatedly stumble over the same pitfalls in real projects: forgetting architectural decisions, violating dependency boundaries, and burning large amounts of context just to understand the codebase. A failed product prototype, a Gemini quota exhaustion incident, and a graph database once mistaken for "Redis in disguise" gave birth to Banana—an open-source project that uses graph structures to provide memory and context orchestration for coding agents.

From Failed Product to Pivot

Banana started as a B2B SaaS pricing calculator. After spending hours tinkering with discount sliders in Streamlit, the author asked himself one question: would I actually use this product? The answer was no. So the UI was scrapped entirely, and the project pivoted toward the context problem of AI coding agents.

This turning point is worth noting: rather than starting from technology and searching for a use case, it started from the gut feeling of "I wouldn't use this" and cut the direction. The new positioning was clear—provide code relationship retrieval, architectural decision memory, and explicit rule checks for coding agents via the MCP protocol.

FalkorDB: The Underrated Graph Engine

The author was initially highly skeptical of FalkorDB, suspecting it might be a rebranded RedisGraph or a simplified Neo4j that needed 4GB of RAM just to start. The turning point came after actually reading the docs: FalkorDB is built on GraphBLAS, representing nodes and relationships as sparse linear algebra matrices implemented in optimized C.

This means when you request a multi-hop dependency traversal, the engine performs sparse matrix multiplication rather than the in-memory pointer-chasing recursion of traditional graph engines. Measured numbers:

• Three-hop multi-edge traversal: 17.4 ms
• Architectural decision recall: 1.37 ms
• AST boundary check: 0.28 ms

The author's own words: queries return faster than Python can serialize the response to JSON. This directly supports the low-latency requirements of the agent loop.

GraphBLAS is an open standard and C language interface specification (led by IEEE) for expressing linear algebra operations on graph structures. Its core idea is to encode a graph's adjacency structure as a sparse matrix, unifying graph operations like traversal, join, and shortest path as linear algebra primitives such as matrix multiplication and masked assignment. Because sparse matrix multiplication can be heavily optimized (computing only over non-zero elements), the underlying implementation achieves excellent memory locality and parallelism. FalkorDB is a graph database built on top of a GraphBLAS implementation, so its multi-hop traversal is essentially a chain of sparse matrix multiplications rather than the pointer-hopping recursion of traditional graph databases. This is the fundamental reason it can return multi-hop results at millisecond latency.

A Quota Outage Ironically Validated the Architecture

During testing, the Gemini API quota ran out, but this incident actually became an opportunity to validate the architecture. The team had already indexed the codebase into the graph database: 39 files, 42 classes, 84 functions, and 275 import and call relationships.

The agent can query the graph directly to fetch dependencies, inspect code structure, and recall stored decisions without spending LLM tokens on these operations. The graph became both the memory layer and the fallback when the model is unavailable. This points to a more general design principle: offload deterministic, structured retrieval tasks from the LLM—it saves money and improves reliability.

Allocating Context Budget with Max-Flow

The solution to context bloat has two steps. First, index structure rather than text: the codebase is modeled as an AST graph (file, class, and function nodes connected by IMPORTS and CALLS edges), and Cypher queries traverse these relationships via sparse matrix multiplication.

Second, it borrows the Edmonds-Karp max-flow algorithm. In this analogy, the "liquid" is code tokens and the "pipes" are dependencies:

1. The source is the file or function being edited
2. The pipe network is every class, helper function, and imported module connected to it, with capacities weighted by PageRank and architectural relevance
3. The sink is the strict LLM context budget (e.g., 950 or 2000 tokens)

Edmonds-Karp uses breadth-first search to find augmenting paths, pushing the maximum volume of critical architectural context through the dependency graph until it hits the budget bottleneck. The result: complete interfaces, no missing direct dependencies, no token overflow, and no truncation mid-function. The goal in one sentence: give the agent what it needs, not everything you have.

The Edmonds-Karp algorithm is one of the classic algorithms for solving the max-flow problem: in a directed network with capacities, push as much flow as possible from source to sink, each time using breadth-first search to find a shortest augmenting path with positive residual capacity, push the additional flow along that path, and repeat until no augmenting path exists. Its time complexity is O(VE²), and it is simple to implement with predictable behavior. When Banana borrows this model, it treats the dependency graph as a flow network: edge capacities are weighted by PageRank and architectural relevance, the source is the current editing unit, the sink is the token budget, and the "flow" pushed by the algorithm is the set of code units selected into context. The resulting subgraph maximizes coverage of critical architectural information within budget. It should be noted that the "architectural decision recall 1.37 ms" mentioned in the original article refers to the speed of retrieving stored decisions via graph queries, which is separate from max-flow computation; the latter involves multiple breadth-first searches and is more on the order of tens of milliseconds. Still, a single query or single traversal remains significantly faster than an LLM call.

Scratch Graphs: The Agent's Sandbox for What-If Reasoning

When an agent needs to reason about hypothetical changes—say, simulating a refactor, testing a breaking dependency, or asking "what happens if I change this interface"—it shouldn't write directly into the persistent code graph.

Because FalkorDB is built on in-memory GraphBLAS linear algebra, graph creation and destruction take milliseconds. Banana leverages this to implement scratch draft graphs: when the agent enters speculative simulation mode, the system spins up an isolated micro-graph (banana_scratch_<session_id>) within 5 ms, in which the agent simulates AST diffs, tests scenario strategies, and checks circular dependencies; when simulation ends, a single command discards it. No disk residue, no persistent memory pollution, and no risk of hallucinated artifacts being written into the real codebase.

FalkorDB can support millisecond-scale creation and destruction of scratch graphs because its sparse matrix structures live in memory; a new graph with only a few nodes and edges just allocates a handful of sparse blocks, with no disk files, directories, or transaction logs to write, and no schema creation overhead like traditional databases. By contrast, in persistent graph databases like Neo4j, creating a separate graph for a single hypothetical scenario typically involves disk writes and heavier initialization costs, making frequent create-delete cycles noticeably expensive. Therefore, Banana's banana_scratch_<session_id> need not be full database-level isolation; it can also be a lightweight partition of a separate namespace or set of sparse blocks, with the "isolation" mainly meaning that data never enters the persistence layer and is entirely discarded when the session ends.

Guardrail Checks Without LLM Calls

If an agent tries to import a low-level database driver directly into a UI component, and that dependency violates an explicit architectural rule, Banana can check the relevant graph relationships directly and flag the violation without LLM involvement. The team also built deterministic checks for hardcoded credentials and unsafe code primitives. In tests, AST safety and boundary checks had a latency of 0.28 ms.

The author also acknowledges the limits: not all security issues can be caught by simple rules, but explicit constraints shouldn't cost an LLM call every time.

MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic for letting AI applications integrate external tools and data sources in a unified way. It uses a client-server model: the host application (e.g., Claude Code, Cursor) acts as the client, and the external capability provider acts as the MCP server, exchanging JSON-RPC messages over stdio or HTTP transport. The MCP server declares to the model the tools it can call, the resources it can read, and the prompt templates it can use, and the model decides when to invoke them. Banana implements itself as an MCP server, so coding agents can call code indexing, context assembly, guardrails, and memory tools in a standardized way, without per-host adaptation.

Overall Architecture

Banana exposes code indexing, context assembly, guardrails, and persistent memory tools to coding agents via an MCP server. The backend is managed by FalkorDB across three layers of graphs:

• banana_knowledge: code structure, dependencies, and architectural decisions
• banana_demand: architectural rules, invariants, and constraints
• banana_scratch_*: temporary micro-graphs for isolated reasoning and strategy simulation

The service is deployed on AWS Lambda, backed by FalkorDB Cloud. The project is open-sourced on GitHub and provides an online endpoint and demo video.

Four Lessons

The author's takeaways deserve to be called out separately: code is a graph, not just text—imports, calls, and class relationships matter when retrieving context; not every problem needs an LLM—deterministic checks are faster and more predictable; memory is only valuable when it's retrieved—storing decisions is useful, but retrieving them at the right moment is what matters; scratch graphs unlock safe agent reasoning—an instant, disposable graph sandbox prevents the real codebase from being polluted.

For teams building AI coding tools, Banana offers a paradigm worth borrowing: use graph structures for structured reasoning, use algorithms (max-flow) to manage context budgets, use deterministic checks to cover explicit rules, and leave the LLM for the parts that truly need semantic understanding.

One-line Summary

Open-source project Banana uses a graph database to give AI coding agents memory, context orchestration, and deterministic guardrails.

Paragraph Summary

Banana is an open-source project that evolved from a failed B2B pricing calculator, aiming to solve the problems of AI coding assistants forgetting architectural decisions, violating dependency boundaries, and consuming huge amounts of context in real projects. It connects to Claude Code and Cursor via the MCP protocol, with a backend powered by FalkorDB—based on GraphBLAS sparse matrix operations—managing knowledge graphs, rule graphs, and scratch draft graphs. The codebase is modeled as an AST graph, context budget is allocated across the dependency graph by the Edmonds-Karp max-flow algorithm, and deterministic guardrail checks require no LLM calls. Measured results: three-hop traversal in 17.4 ms, decision recall in 1.37 ms, boundary checks in 0.28 ms, and scratch graphs created and discarded within 5 ms.