{
  "id": 15446617,
  "title": "I gave my agent a graph and it stopped guessing who owned what",
  "url": "https://urgent.news/2026/10/18/i-gave-my-agent-a-graph-and-it-stopped-guessing-who-owned-what",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-18T16:37:53.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/sznimperial/i-gave-my-agent-a-graph-and-it-stopped-guessing-who-owned-what-4gbi"
  },
  "original_language": "en",
  "account": "The story revolves around a moving company that used graph technology to improve how its on-call engineers answered questions. Typically, when a page hit at 2am, the engineers would ask who owned a particular system. However, the existing Retrieval-Augmented Generation (RAG) approach only searched for text chunks similar to the question, which often led to outdated or irrelevant information since the relevant data was scattered across various sources like wikis, Slack threads, and ticket history.\n\nThe solution was to treat company knowledge as a graph to be traversed instead of just a text to be searched. In this graph, entities like Person, Project, System, Ticket, Document, and Decision were linked together based on their relationships. This allowed the system to not only find the right text but also understand the relationships between different entities.\n\nFor instance, the system could determine who owned a system, understand the dependencies of a system, and trace the decisions made about a system. This was achieved by creating a graph database called company_brain that stored all the relevant entities and their relationships. The graph contained around 4,000 nodes with relationships such as 'works on', 'uses', 'depends on', 'reported in', 'wrote', and 'decided'.\n\nThe key queries used in this approach were:\n1. Finding the owner and the path leading to the owner\n2. Tracing the blast radius, i.e., which systems could be affected if a particular system failed\n3. Tracing a decision back to its source to verify the answer.\n\nInstead of maintaining separate databases for memory, the memory was integrated into the same graph. Each user's question and answer was stored as 'ASKED' and 'PROCESSED' nodes respectively, along with timestamps. This allowed the system to remember past interactions without needing a separate database.\n\nIn conclusion, by thinking of company knowledge as a graph instead of text, the moving company was able to provide more accurate and context-aware answers, which significantly improved the efficiency of its on-call engineers.",
  "summary": "How moving company knowledge from vector chunks into FalkorDB changed the way my agent answers the three questions on-call engineers actually ask. The 2am page A payments retry storm hits. The pager goes off, and the first thing someone asks the assistant is: who owns payments-api? It gives a name. The problem is that the person left the team four months ago. Nobody updated the wiki. The org…",
  "key_points": [
    "Moving company used graph technology to improve on-call engineers' knowledge retrieval.",
    "Graph database \"companybrain\" stored entities and relationships, enabling accurate answers.",
    "System could trace ownership, dependencies, and decision sources through graph queries."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}