The hackathon brief had one line that stuck with me: the graph has to shape what the agent does, not sit on the side. That ruled out my first few ideas. They were basically dashboards with a graph bolted on, and I could have built every one of them with Postgres and nobody would have noticed.

So I went looking for a problem where the answer is a path through connected data. That's how I ended up reading about drug shortages at midnight.

Live demo: https://shortagebridge-falkordb.vercel.app

Code: https://github.com/raghul017/shortagebridge-falkordb

Demo video: https://youtu.be/357BPOkj9cY

The problem

The US FDA keeps a public list of drug shortages, and you can pull it from the openFDA API. Each record tells you the drug, the exact package (the NDC code), the status, and when it was last updated.

I picked one record to work with: Lidocaine Hydrochloride Injection, package NDC 0409-4776-01. Lidocaine is a local anaesthetic, so it shows up in a lot of everyday hospital work.

What surprised me was how little the alert tells a hospital. It says the drug is short nationally. It doesn't tell a pharmacy lead whether they stock that package, how many days their stock will last, which wards or procedure rooms depend on it, or who is supposed to look at it. And that's the question they actually ask on the day: what does this affect, here?

To answer it you have to go step by step: the alert points to a package, the package matches something on the hospital's formulary, that item has stock and a usage rate, it's used by certain services, those services follow a shortage protocol, and the protocol sends it to a specific role.

When I wrote it down like that, it was just a chain of relationships, and that's the kind of question a graph database is built for.

What I built

ShortageBridge takes that one public shortage record and walks it through a hospital's data in FalkorDB until it reaches a person who should review it. Then it records that the person did.

On the page it goes like this:

1. You see the public FDA alert, with a link to the source and the time it was pulled.

2. You click Ask the graph. That runs one Cypher query in FalkorDB.

3. The evidence path comes back, and you click Next connection to reveal it one hop at a time, six hops in total.

4. You see the impact: two affected services, their protocol, the review role, and a stock runway of about 4 days.

5. You click Generate review brief. Gemini writes a short brief, but only from what the graph returned.

6. You click Mark review complete, and a new node is written back into the graph, linked to the evidence.

I'd call it a small agent with a strict leash. It reads the graph, explains what it found, and the one action it takes is recording a human decision.

I had no hospital data, and that was fine

This was the first real decision I had to make. I obviously don't have a hospital's inventory, and even if someone had given it to me, I shouldn't put it in a public demo.

So the project uses two kinds of data and never mixes them up:

• Public: the FDA shortage record and the drug package. Shown in blue.

• Synthetic: a made-up hospital called Riverglen Demonstration Hospital, with 24 units in stock, about 6 used per day, two services, a protocol and a review role. Shown in violet with dashed borders.

Every node in the graph has a data_origin property set to either openfda or synthetic_demo, plus an evidence_id pointing to an EvidenceSource node that says where it came from. At first this felt like a lot of bookkeeping for a hackathon. By the end, half the features depended on it: the colours in the UI, the citations in the brief, and the links on the review record all come from those two properties.

There's one edge I spent extra time on: MATCHED_TO, the link between the FDA package and the hospital's own item. That's where public data meets private data, and matching the two is a judgement call that someone has to own. So the edge itself carries a status and a rationale. I liked that the graph could store why two things are connected, not only that they are.

The graph

EvidenceSource -SUPPORTS-> ShortageRecord -REPORTS_ON-> DrugPresentation
                                                            |
                                                       MATCHED_TO (reviewed)
                                                            v
Facility -HAS_ITEM-> FacilityProduct -HAS_SNAPSHOT-> InventorySnapshot
                          |
                       USED_BY
                          v
                     ServiceLine -FOLLOWS-> Protocol -ESCALATE_TO-> ResponseRole

ReviewAction -BASED_ON-> ShortageRecord, FacilityProduct
ReviewAction -CITES----> EvidenceSource

The one query

The whole "what does this affect" answer is one read-only Cypher query with two path patterns. Here's the core of it (the full version is in lib/impact-query.ts):

MATCH shortageToInventoryPath =
  (shortage:ShortageRecord {id: $caseId})-[:REPORTS_ON]->(presentation:DrugPresentation)
    -[match:MATCHED_TO]->(facilityProduct:FacilityProduct)-[:HAS_SNAPSHOT]->(snapshot:InventorySnapshot)
MATCH facilityToReviewPath =
  (facilityProduct)-[:USED_BY]->(service:ServiceLine)-[:FOLLOWS]->(protocol:Protocol)
    -[:ESCALATE_TO]->(role:ResponseRole)
RETURN
  shortageToInventoryPath, facilityToReviewPath,
  match.rationale, service.name, protocol.name, role.name,
  round(snapshot.on_hand_quantity / snapshot.average_daily_use * 10) / 10 AS estimated_runway_days
ORDER BY service.name

Reading it back, it's almost the same sentence I wrote down when I first understood the problem. That was the moment the graph database clicked for me.

A few choices here ended up mattering more than I expected.

I draw the graph from the paths FalkorDB returns. My first version drew the evidence graph with hardcoded positions. It looked fine, but it was lying, because if the data changed the picture wouldn't. Now the frontend takes the path objects from the query result and builds the picture from those nodes and edges. With the seed data that's 8 nodes, 8 relationships and 6 hops.

The runway is calculated in Cypher, not in JavaScript. This gave me my favourite test. Open the FalkorDB Browser and run:

MATCH (i:InventorySnapshot) SET i.on_hand_quantity = 12 RETURN i.on_hand_quantity

Then go back to the app and run the traversal again. The runway drops from 4 days to 2. Nothing was redeployed and no code was touched. That's when I was convinced the graph was doing the work and not just storing data for my app.

The query is fixed and read-only. The server runs it with FalkorDB's roQuery, so this path can't modify anything. The only input is $caseId, and that's validated with Zod before the query runs. Nothing typed in the browser ever becomes part of a Cypher string.

A friend asked me if I could have done this in SQL. Yes, I could have, with a join for every hop and then code to stitch the rows back into connections so I could draw them. But in Cypher the query is the question, and it comes back already shaped as connected evidence. For this problem that made the code a lot simpler.

Keeping Gemini on a short leash

I wanted the reviewer to get a readable summary, not raw JSON. But I really didn't want an LLM inventing details about a hospital's drug supply. So I gave Gemini a very small job:

• It never connects to FalkorDB and never writes Cypher.

• The server runs the graph query itself and passes Gemini only what came back.

• Gemini has to answer in a fixed JSON schema.

• After it answers, the server checks that every service and evidence ID it mentions actually came from the graph. If anything doesn't match, the answer is thrown away.

When that happens, or when there's no API key or the free quota is used up, the app builds the brief directly from the graph facts with no AI at all. The output has the same structure, and the UI tells you which mode ran.

I ran out of Gemini quota more than once while testing, so this fallback got tested properly, just not on purpose. It's probably the part I'm proudest of, because the app keeps working without the model.

The action: recording a human decision

Track 01 is about agents that act on connected data, so reading the graph wasn't going to be enough. But in healthcare, I didn't want my app placing orders or suggesting substitute drugs. That needs a clinician and patient-level context I'll never have.

So the action is narrow on purpose. When a reviewer clicks Mark review complete, the server writes a ReviewAction node into the same graph:

MATCH (shortage:ShortageRecord {id: $caseId})
MATCH (facilityProduct:FacilityProduct {id: $facilityProductId})
MERGE (action:ReviewAction {id: $actionId})
SET action += { data_origin: 'synthetic_demo', status: $status,
                reviewed_at: $reviewedAt, evidence_ids: $evidenceIds }
MERGE (action)-[:BASED_ON]->(shortage)
MERGE (action)-[:BASED_ON]->(facilityProduct)
WITH action
MATCH (evidence:EvidenceSource) WHERE evidence.id IN $evidenceIds
MERGE (action)-[:CITES]->(evidence)

The browser only sends {"confirmed": true}. The server re-reads the graph and writes only IDs it got from FalkorDB. Afterwards the decision sits in the database right next to the evidence it was based on. An audit trail is a graph too, so it made sense to keep it in the same place.

Getting it online

Locally I ran FalkorDB in Docker, which was one command. For the live demo I moved to a hosted FalkorDB instance and deployed the Next.js app on Vercel. The code is the same either way, and only the connection environment variables change.

Seeding uses MERGE, so I could run the seed script again and again without creating duplicates. I did that many times.

One thing I didn't expect: after the app sat idle for a while, the first request was slow while the serverless function started up. Before recording my demo I now do a warm-up click-through, then clear the test review nodes with MATCH (a:ReviewAction) DETACH DELETE a so the graph is clean on camera.

What I learned

Look for problems where the answer is a path. Once I stopped asking "where can I put a graph?" and started asking "which questions are really a chain of relationships?", the project almost designed itself.

Put the logic in the query. Every time I moved logic from JavaScript into Cypher, the frontend got simpler and the demo got more honest.

Record where every piece of data came from, from the start. I'd skip it next time if I were lazy, and I'd regret it.

Don't trust the model's output. Grounding isn't just putting facts in the prompt. You also have to check what comes back and have a plan for when it's wrong.

Keep the action small and the human in charge. It's tempting to make the agent do more. Here, doing less was the right call.

What it doesn't do (yet)

It handles one seeded shortage case. The FDA record is a snapshot, not a live feed. The hospital is fictional and the 4-day runway is an illustration, not a forecast. It isn't a clinical tool, and you can't plug a real hospital database into it.

If I keep working on it, I want to pull the full openFDA shortage feed automatically and flag new matches for a human to confirm. I'd also like to run graph algorithms across many shortages at once, to find the services exposed to the most of them, or protocols that turn into bottlenecks. A real version would have to run inside a hospital's own environment, with their data staying with them.

Thanks

Thanks to WeMakeDevs and FalkorDB for running this. I came in having never written a real Cypher query, and I'm leaving with a project where the database is producing the answer, not just storing data for the app.

If you work in a hospital pharmacy or supply chain and I've modelled something wrong, please tell me. I'd genuinely like to know.