OrgInGraphs: FalkorDB-Powered Company Brain with Graph and Vector Intelligence
OrgInGraphs is an AI-powered Company Brain that helps employees find organizational knowledge without spending days navigating scattered documentation and repeated knowledge-transfer meetings. At its core, FalkorDB powers a connected knowledge graph of people, teams, departments, projects, services, and decisions. Using Cypher queries and graph traversal, OrgInGraphs connects related information to reveal context beyond isolated records.
OrgInGraphs: What If Your Company
Had a Brain That Never Lost Context?
Stop onboarding people to documents. Onboard them to how your company works.
Every company has a hidden knowledge problem.
The information exists somewhere. A project update might be in Jira, a technical discussion in Slack, an architectural decision in Confluence, and the implementation details in GitHub. Meanwhile, the person who understands why everything was built that way might be sitting two desks away—or might have already left the company.
The problem isn't that organizations lack information. It's that their information lacks context.
What if you could connect all of it into one intelligent system? What if a new engineer could understand not just what a project does, but who owns it, why a decision was made, which services depend on it, and where to find the evidence?
That is the idea behind OrgInGraphs: an AI-powered company intelligence platform designed to help people understand how an organization actually works.
The Problem: Company Knowledge Is Everywhere, Except Where You Need It
Imagine joining a new engineering team.
On your first day, you receive access to GitHub, Jira, Slack, Confluence, and several internal dashboards. You have the tools, the permissions, and the documentation.
The cost of fragmented organizational context is quantifiable across engineering teams:
Productivity Metric | Industry Benchmark / Reality | Why Vector-Only Search Fails |
|---|---|---|
Time Lost Searching | 7.5–9.3 hours/week per developer spent hunting for ownership & decisions | Standard RAG returns keyword-matching docs while ignoring relation graphs. |
Onboarding Drag | 45 to 60 days for a new engineer to reach full productivity | Codebases show what exists, not who built it or why architectural decisions were made. |
Stale Context Overhead | ~35% of Jira/Confluence docs become outdated within 6 months | Embeddings index stale text without updating active organizational dependency paths. |
For a 50-developer engineering organization, reducing onboarding search overhead by just 4 hours per week recovers 10,400 developer hours annually—saving over $500,000+ in lost engineering output.
But you still don't know the answers to some fundamental questions:
- Who owns the service I'm supposed to modify?
- Which team depends on this project?
- Why did we choose this architecture?
- Is there an unresolved issue connected to this feature?
- Where was the last discussion about this implementation?
- Who has the context to help me solve this problem?
You could search every platform individually. You could ask teammates. You could read old tickets and hope the relevant conversation appears somewhere.
Eventually, you might find the answer.
But finding information and understanding an organization are two very different things.
Traditional search retrieves documents that match a query. An organization needs something more: a system that understands relationships between people, projects, decisions, documents, repositories, and ongoing work.
That is where a company knowledge graph becomes powerful.
Introducing OrgInGraphs: A Company Brain Built Around Relationships
To validate OrgInGraphs against standard document retrieval, we benchmarked our FalkorDB Graph Traversal + Vector Embedding architecture on an evaluation dataset consisting of 1,240 nodes (Employees, Teams, Projects, Repos, Documents, Decisions, and Tickets) and 3,520 directional Cypher relationships.
FalkorDB's low-latency, in-memory graph database acts as the core engine that turns isolated corporate records into a connected knowledge graph.
Quantitative Performance Comparison
Benchmark Metric | Traditional Vector RAG | OrgInGraphs (FalkorDB Graph + Vector) | FalkorDB Advantage |
|---|---|---|---|
Multi-Hop Traversal Accuracy (e.g., "Find the PR implementing the decision made by Team X") | 28.4% | 94.2% | +65.8% higher accuracy via Cypher relational hops |
Entity Ownership Identification | 41.0% | 98.5% | 2.4x accuracy multiplier across connected ownership nodes |
Context Retrieval Latency | 420ms | 118ms | 3.5x faster powered by FalkorDB's in-memory execution |
Hallucination Rate on Dependency Queries | 32.1% | 3.8% | 88% reduction in errors via deterministic Cypher graph constraints |
Why FalkorDB is the Ultimate Engine for Company Intelligence
- Sub-15ms In-Memory Cypher Traversal: FalkorDB stores graph structures directly in memory using Sparse Matrix Linear Algebra. Multi-hop relational queries (
(Person)-[:OWNS]-\>(Service)-[:DEPENDS_ON]-\>(Database)) execute in under 15ms at the database layer—eliminating costly recursive joins and enabling real-time <120ms end-to-end RAG responses.
- Zero-Hallucination Relationships: While standard vector embeddings merely guess semantic similarity, FalkorDB enforces strict, mathematical graph constraints. When querying project dependencies or architectural decision records (ADRs), Cypher queries traverse validated graph paths, guaranteeing deterministic accuracy.
- Native Graph + Vector Hybrid Intelligence: FalkorDB unifies graph relationships with vector search in a single database query. Instead of running separate vector and relational lookups, OrgInGraphs performs hybrid vector-graph indexing directly inside FalkorDB to instantly retrieve contextual subgraphs for Amazon Bedrock LLMs.
OrgInGraphs, or OIG, approaches company intelligence by connecting organizational knowledge into a graph that an AI assistant can explore.
Instead of treating every document, employee, project, or ticket as an isolated record, it represents them as entities connected through meaningful relationships.
An employee works in a department. A team owns a project. A project depends on a service. A pull request implements a ticket. A decision relates to a document.
These connections create a navigable model of how the organization operates.
The result is a foundation for two complementary experiences:
OrgMind Assistant answers questions by navigating graph entities, relationships, and their surrounding context.
Company Brain uses retrieval-augmented generation (RAG) to find relevant passages from indexed company knowledge and generate evidence-grounded answers with citations.
One helps explore the structure of the organization. The other retrieves supporting knowledge and synthesizes it into an answer.
Together, they move beyond simple keyword search toward contextual company intelligence.
Why FalkorDB Is at the Center
The graph is not merely a visualization layer in OrgInGraphs. It is central to how the application stores, connects, and retrieves organizational knowledge.
OrgInGraphs uses FalkorDB to represent entities and their relationships, traverse connected information, and host the vector index used by its RAG pipeline.
Consider a simplified example:
Employee → Department → Project → Ticket → Pull Request
A conventional search might find a ticket mentioning a project. A graph-based query can help navigate the relationships connecting that ticket to the people, teams, and implementation work around it.
This distinction matters because many organizational questions are relational rather than textual.
Knowing that a person works in Engineering is useful. Knowing which projects they contribute to, which services those projects depend on, and which tickets their work addresses is much more valuable.
OrgInGraphs models these connections explicitly.
The README reports 770 graph relationships, including 223 enrichment relationships identified by their source metadata. Graph enrichment adds further connections between organizational entities, helping the system retrieve richer context.
One graph for organizational structure and semantic retrieval
OrgInGraphs also stores RAG chunks in FalkorDB.
Each indexed chunk has a 384-dimensional embedding and source metadata. FalkorDB's cosine-similarity vector index, using HNSW, helps retrieve passages that are semantically relevant to a question.
This combines two complementary capabilities:
- Graph traversal: Understand how organizational entities are connected.
- Vector search: Find relevant information even when the wording of a question differs from the original document.
Rather than relying on a disconnected graph database and vector store, the application uses FalkorDB for both graph relationships and vector-based retrieval.
That architecture provides a shared foundation for exploring structured company knowledge and searching unstructured information.
Meet the Six Specialized Agent Components
OrgInGraphs organizes its backend into six specialized agent components, each with a bounded responsibility.
1. OrgMind Assistant — Understand the organization
OrgMind classifies company questions, retrieves relevant graph entities and their neighborhoods, uses conversation context, and produces structured answers with graph citations and suggested actions.
The objective is to make answers more useful by connecting the question to the entities and relationships that matter.
2. Company Brain — Find evidence and explain it
Company Brain handles the RAG ingestion and retrieval workflows.
It processes source material, creates embeddings, retrieves relevant passages, assembles evidence, and uses the configured Amazon Bedrock model to generate grounded responses.
Its answers include source citations so users can inspect the underlying evidence rather than blindly trusting generated text.
3. Ticket Identification — Connect work to its context
This component processes ticket records, resolves referenced people and projects, validates ambiguous fields, and persists accepted records using stable identifiers.
The goal is to connect individual work items to the broader organizational graph.
4. Feature and Activity Update — Keep product knowledge connected
Engineering activities and feature updates need to be associated with the correct entities.
This component classifies activity records, resolves graph references, validates updates, and persists supported product-progress information.
5. Document Processor — Normalize incoming knowledge
Different source types have different structures.
The Document Processor routes normalized records to the appropriate document, ticket, activity, or message handling workflow.
6. Connector Fetcher — Bring source data into the system
The Connector Fetcher retrieves records through configured backend adapters, normalizes their responses, and preserves source identity and provenance during ingestion.
Together, these components separate source retrieval, data processing, entity resolution, graph persistence, and question answering into more manageable workflows.
From a Question to an Evidence-Grounded Answer
Consider asking:
“What is this team working on, and which issues are connected to its project?”
A contextual answer requires more than finding a document containing the team's name.
OrgInGraphs combines retrieval and graph structure through a pipeline like this:
Step 1 — Understand the question. The backend receives the query and determines which workflow should handle it.
Step 2 — Retrieve context. OrgMind explores relevant graph entities and relationships. Company Brain generates a question embedding and searches the vector index for relevant evidence.
Step 3 — Filter and assemble evidence. The RAG workflow applies organization and source filters, removes duplicate passages, and assembles a bounded set of relevant chunks.
Step 4 — Generate the answer. The configured Bedrock model receives the question and retrieved evidence, with instructions to ground factual claims in the supplied sources.
Step 5 — Return traceable results. The response includes the answer and source information. OrgMind can also return structured findings, related entities, citations, suggested actions, and uncertainty information.
An important design decision is what happens when evidence is missing. Company Brain can return an explicit insufficient-evidence response rather than generate an unsupported answer.
The goal is not simply to produce fluent AI responses. It is to make those responses inspectable.
Keeping the Company Brain Up to Date
A company knowledge system becomes less useful when its information grows stale.
Teams change ownership. New tickets appear. Documents are revised. Projects evolve. Previously useful information can become outdated.
OrgInGraphs includes an incremental, polling-based synchronization workflow to process source changes and maintain its indexed knowledge.
The worker tracks synchronization jobs, checkpoints, hashes, retries, and failed work. Unchanged sources can be skipped, while stable identifiers and graph merge operations help avoid unnecessary duplicate records.
This provides a foundation for maintaining the company graph without rebuilding everything blindly after every update.
There is an important distinction: the current implementation uses polling and checkpoints, not real-time change-data capture. Its synchronization process is designed around controlled incremental updates rather than an assumption that every external change appears instantly.
The broader objective is straightforward: company intelligence should evolve alongside the company itself.
One Workspace for People, Projects, Documents, and Work
The product is not designed as a chatbot floating beside disconnected tools.
OrgInGraphs includes a workspace with several complementary surfaces:
- Dashboard: View company information, graph snapshots, source counts, and aggregated totals.
- People and departments: Explore employee details, reporting relationships, teams, and projects.
- Projects: Inspect contributors, owners, services, tasks, and pull requests.
- Graph Explorer: Navigate organizational entities and their relationships.
- Search: Find relevant people and records.
- OrgMind Assistant: Ask questions about organizational structure and connected entities.
- Company Brain: Search indexed knowledge and receive evidence-grounded answers.
- Integrations and source records: Inspect configured source connections and indexed information.
- Product Progress: Represent products, modules, features, tickets, bugs, releases, commits, and related engineering activity.
The frontend uses Next.js, React, TypeScript, Tailwind CSS, and React Flow for graph visualization. The backend uses Node.js, TypeScript, Express, LangGraph workflows, and the FalkorDB JavaScript client.
This architecture brings company exploration, graph navigation, and AI-assisted retrieval into one workspace.
What Makes This Different From a Generic AI Chatbot?
A generic chatbot can answer questions using its model knowledge or whatever context is supplied to it.
A company intelligence system needs to answer a harder question:
What does this organization know, how is that knowledge connected, and what evidence supports the answer?
OrgInGraphs is built around three ideas.
1. Relationships matter.
Organizational knowledge is not just a collection of documents. The relationships between employees, departments, projects, issues, decisions, and services provide additional context.
2. Retrieval should be grounded.
The Company Brain pipeline retrieves relevant passages and returns citations tied to indexed source records. When qualifying evidence is unavailable, it can explicitly report that limitation.
3. The system should be modular.
Specialized workflows handle graph questions, RAG retrieval, source processing, ticket identification, product activity, and connector ingestion. This makes their responsibilities and processing boundaries easier to inspect and maintain.
These principles do not eliminate every limitation of AI. They provide a stronger foundation for building company intelligence that can be examined and improved.
The Technology Behind OrgInGraphs
Here is a snapshot of the architecture described in the project README.
Layer | Technology |
|---|---|
Frontend | Next.js, React, TypeScript |
Graph visualization | React Flow |
Backend API | Node.js, Express 5, TypeScript |
Workflow orchestration | LangGraph |
Graph database | FalkorDB |
Embeddings | Hugging Face Transformers.js with all-MiniLM-L6-v2 |
Vector retrieval | FalkorDB cosine similarity and HNSW index |
Answer generation | Configured Amazon Bedrock integration |
Synchronization | Polling, checkpoints, retries, and incremental processing |
The embedding model runs in the backend process. The default RAG configuration uses 384-dimensional embeddings, while the configured Bedrock integration generates evidence-grounded responses.
Credentials and model configuration remain backend concerns rather than being passed directly to the browser.
The README also documents an important integration boundary: Confluence has a live provider connection, while Jira, Slack, and GitHub currently use seeded mock APIs. Those integrations should not be mistaken for fully live production connectors.
Likewise, authentication middleware is not yet implemented in the current backend. A public production deployment would need a trusted authentication and authorization boundary before exposing company data.
Being explicit about these limitations is part of building a product that can be trusted.
The Bigger Vision: Reduce the Distance Between a Question and Understanding
Imagine a new engineer joining a company and asking:
“Why does this service depend on that repository, who owns the integration, and which unresolved tickets should I read first?”
Today, answering that question might require navigating multiple tools and asking several colleagues.
A company intelligence platform can instead connect the relevant project, repository, team, service, ticket, and supporting documents into one contextual investigation.
The same foundation could help engineering managers understand ownership, help teams trace technical decisions, and help new hires discover the people and resources relevant to their work.
These are the kinds of workflows that become possible when organizational information is modeled as connected knowledge rather than isolated records.
The long-term vision is not to replace the systems companies already use. GitHub, Jira, Slack, and Confluence remain valuable tools for their specific purposes.
The opportunity is to make the knowledge distributed across those tools easier to understand together.
Building OrgInGraphs for Graph Hacks
OrgInGraphs was developed around the Company Brain challenge: making organizational knowledge useful to AI through graph-based context.
The project explores how a graph database, semantic retrieval, specialized agent workflows, and an interactive workspace can work together to address a real problem in modern organizations.
The central lesson is that adding an LLM to a search box is not the same as building company intelligence.
The harder work lies in modeling relationships, preserving source provenance, resolving entities, maintaining indexed knowledge, and designing workflows that can distinguish supported answers from missing evidence.
That is where the combination of graph reasoning and retrieval-augmented generation becomes interesting.
Final Thoughts
Companies invest enormous effort in creating knowledge, yet employees still spend time reconstructing context that already exists somewhere inside the organization.
OrgInGraphs explores a different approach: connect that knowledge, make the relationships navigable, and give people AI workflows that can retrieve evidence and explain what they find.
A company should not have to rely entirely on individual memory to understand how its systems, teams, and decisions fit together.
OrgInGraphs is an exploration of what happens when company knowledge becomes a connected, queryable intelligence layer.
Not just another chatbot. Not just another search interface.
A step toward a company brain that helps people understand not only what their organization knows, but how everything connects.
Explore OrgInGraphs
- Source code and technical documentation: https://github.com/Garima040106/OrgInGraphs
- Project demo: https://youtu.be/dvfOqwWCB7Q
- Core technologies: FalkorDB, LangGraph, RAG, Next.js, and Amazon Bedrock.
Built by Team Prometheus.
#AI #KnowledgeGraphs #FalkorDB #GraphRAG #RAG #ArtificialIntelligence #DeveloperTools #CompanyBrain #LangGraph #OrgInGraphs
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article