A service fails. Its owner is unavailable. Who should the team ask for help?
A list of employee names cannot answer that question. We need to know which services are connected, who owns them, who has resolved related incidents, and who is available now.
That is the problem I explored with TeamRescue, my project for Graph Hacks by WeMakeDevs and FalkorDB.
Try TeamRescue · View the source code
The problem: finding someone with the right context
During an incident, knowing the service owner is useful—but what happens when that person is unavailable?
Someone else may have fixed a related issue before. Their experience matters, even if they are not the official owner.
TeamRescue connects this information so a user can ask:
Checkout is failing. Who can help and why?
The goal is a recommendation that people can inspect: a person, a reason, and the relationships supporting that reason.
A small graph with a meaningful decision
I started with a deliberately small, fictional dataset:
- Checkout depends on Payment Service.
- Priya owns Payment Service.
- Rahul resolved INC-001, a previous payment timeout.
- That incident affected Payment Service.
- Each person has an availability value.
The core graph model is:
| Starting node | Relationship | Connected node |
|---|---|---|
| Person | OWNS | Service |
| Service | DEPENDS_ON | Service |
| Person | RESOLVED | Incident |
| Incident | AFFECTED | Service |
These relationships let the application connect a failing service to someone with relevant experience.
When Priya is unavailable and Rahul is available, TeamRescue recommends Rahul based on his previous incident experience. When Priya becomes available, the recommendation changes to the service owner.
Changing one fact in the graph changes the decision.
Why I used FalkorDB
The question depends on several connected facts, rather than one matching record.
FalkorDB stores those relationships directly. Cypher lets the backend follow a service dependency, find a related incident, and identify the person who resolved it.
This query illustrates the backup-expert lookup for Checkout:
MATCH (:Service {name: 'Checkout'})
-[:DEPENDS_ON]->(s:Service)
<-[:AFFECTED]-(i:Incident)
<-[:RESOLVED]-(p:Person)
WHERE p.available = true
AND i.status = 'resolved'
RETURN
p.name AS recommended_person,
s.name AS service,
i.id AS incident_id,
i.title AS past_incident
ORDER BY p.name, i.id
LIMIT 1
The application first checks for an available owner. A person with relevant resolved-incident experience is the fallback.
This is a simple selection policy, not a sophisticated expertise-ranking system. That made it easier to test and explain during the hackathon.
How the AI uses the graph
TeamRescue uses a React frontend, a Node.js and Express backend, FalkorDB, and Gemini.
The backend exposes tools such as:
-
list_services: identifies services recorded in the graph. -
get_service_context: retrieves ownership, availability, dependencies, and relevant incident experience.
The AI can request this context and turn the returned information into a readable explanation. The backend determines the recommendation from the graph using the owner-first policy.
The interface also displays the supporting evidence separately:
- Which service depends on which.
- Who owns the relevant service.
- Whether that owner is available.
- Who resolved a related incident.
- Why the person was recommended.
This gives the user something concrete to check alongside the generated answer.
A dependency is not proof of the root cause
One important design decision was to limit what the assistant claims.
Checkout depending on Payment Service does not prove that Payment Service caused the current failure.
It gives us a reason to investigate that service and contact someone familiar with it.
TeamRescue makes this distinction visible in its interface. It also states that availability reflects the time of the lookup. After changing availability, the user should ask again to get a fresh recommendation.
These details help keep an explanation from sounding more certain than its evidence allows.
Saving context for the next person
Finding an expert is only part of a handoff. The next person also needs to understand why that recommendation was made.
TeamRescue lets users save a draft handoff containing the recommended person, service, a note, and supporting context in FalkorDB.
Before saving, the backend rechecks current availability. Previously saved records are shown as historical recommendations because availability may have changed since they were created.
For example, a saved record may recommend Rahul from an earlier lookup, while a newer record recommends Priya after she becomes available.
The prototype saves draft records only. It does not send notifications or assign work.
What I tested
I tested the deployed interface with two availability scenarios:
| Scenario | Result |
|---|---|
| Priya unavailable, Rahul available | Rahul recommended based on previous incident experience |
| Priya available, Rahul unavailable | Priya recommended as the available service owner |
I also created handoff drafts and checked that the saved list displayed the recommended people, explanations, and timestamps.
The useful result was seeing the recommendation respond to changed graph data while retaining the context of earlier saved decisions.
What I learned while building
Start with a question, then model the relationships
The most useful starting point was “Who can help when the owner is unavailable?”
That question guided the choice of people, services, incidents, and relationships. A small model was enough to demonstrate a meaningful traversal.
Make the explanation visible
Showing only a recommended name would hide most of the value of the graph.
Displaying ownership, dependencies, and incident history made the decision easier to understand and test.
Local setup and deployment are separate challenges
My first Docker issue was that the command-line tool was installed, but the Docker engine was not running. Starting Docker Desktop resolved that setup problem.
Moving to the cloud involved additional configuration: database connection variables, the frontend’s backend URL, CORS, and the server’s listening address and port.
These steps taught me that a working local application still needs careful deployment verification.
Keep current state separate from historical decisions
Availability can change. A saved recommendation records what was known at one point in time.
Keeping that distinction visible is important when someone reviews a handoff later.
Current limitations
TeamRescue is a hackathon prototype using fictional data.
Its current scope includes:
- The requested service and its direct dependencies.
- A simple owner-first recommendation policy.
- Manually updated availability.
- Saved draft handoffs without notifications or assignment.
- A small demonstration dataset.
The public demo is not intended for confidential company information. Production use would require authentication, access controls, tenant isolation, and stronger operational safeguards.
The free backend hosting can also cause a slower first request after inactivity.
What I would build next
I would extend the project with deeper dependency traversal, incident recency, workload-aware recommendations, and access-controlled integrations with issue trackers.
I would also explore how saved handoffs could help future agent sessions retrieve relevant previous decisions. The current prototype displays historical records; it does not yet use them as an advanced agent-memory system.
For this version, the central lesson was practical: an assistant becomes easier to trust when its recommendation is tied to relationships a person can inspect.
Try it: https://teamrescue.onrender.com
Source code: https://github.com/aditya052003/teamrescue
Top comments (0)