TraceOps AI: Building an AI-Powered Service Investigation Agent with FalkorDB and MCP

kallur harshu — Sun, 18 Oct 2026 13:57:59 +0000

How I combined graph-based operational knowledge, local AI, and Model Context Protocol to investigate microservice failures with connected evidence.

Introduction

Modern applications are rarely built as a single service. They consist of multiple interconnected services, databases, APIs, deployments, and teams. When one service starts failing, the problem may affect several other services through their dependencies.

The difficult part of troubleshooting is not simply identifying that something is broken. It is understanding what is connected to the failure, which services may be impacted, what evidence is available, and where an engineer should investigate next.

That challenge inspired me to build TraceOps AI, an AI-powered service investigation and root-cause analysis prototype developed for FalkorDB Graph Hacks.

My project explores how a graph database can provide structured operational context to an AI agent, enabling it to investigate service dependencies, retrieve related incidents, identify service ownership, and find relevant troubleshooting runbooks.

The project focuses on the hackathon track Agents That Act on Connected Data.

The Problem: Operational Information Is Connected, but Troubleshooting Is Difficult

Consider a system containing Payment API, Checkout, Order Management, and Auth Service.

Order Management depends on Checkout, and Checkout depends on Payment API. If Payment API becomes degraded, the impact may extend beyond the service where the issue originated.

An engineer investigating this situation may need to answer several questions:

Which services depend on the degraded service?
What is the dependency path between an affected service and the failure?
Which team owns the service?
Are there related incidents?
Is there a deployment associated with the incident?
Which runbook contains troubleshooting guidance?

These questions require information from multiple connected entities.

A conventional list of services or a collection of disconnected records does not naturally represent these relationships. An engineer or automated system must reconstruct the connections before it can understand the operational context.

I wanted to explore a different approach: represent the operational environment as a graph and allow an AI agent to investigate that graph through structured tools.

Introducing TraceOps AI

TraceOps AI combines FalkorDB, Model Context Protocol (MCP), a local language model, and a web interface to support graph-based service investigations.

Rather than asking a language model to guess why a service failed, the system can retrieve connected evidence from the graph and use that information to construct an investigation response.

The prototype includes synthetic operational data representing services, teams, incidents, deployments, and runbooks.

Its main capabilities include:

Service dependency exploration
Multi-hop dependency traversal
Service ownership lookup
Related incident retrieval
Runbook discovery
Deployment and incident correlation
AI-assisted investigation reports

The goal is not to claim that every investigation establishes a definitive root cause. Instead, TraceOps AI aims to help connect relevant evidence and distinguish observed relationships from conclusions that still need verification.

Why FalkorDB Is Central to the Project

One of the most important architectural decisions was using FalkorDB as the core graph database.

In TraceOps AI, the information is represented through nodes and relationships rather than treated as unrelated records.

Graph data model

The graph contains the following main entity types:

Node label	Purpose
`Service`	Represents an application or microservice
`Team`	Represents the team responsible for a service
`Incident`	Represents an operational incident
`Deployment`	Represents a software deployment
`Runbook`	Represents troubleshooting documentation

Relationships connect these entities:

Relationship	Meaning
`DEPENDS_ON`	Connects a service to a service it depends on
`OWNED_BY`	Connects a service to its responsible team
`AFFECTED`	Connects an incident to an affected service
`HAS_RUNBOOK`	Connects a service to a relevant runbook
`DEPLOYED_TO`	Connects a deployment to its target service
`FOLLOWED_BY`	Represents the modeled association between a deployment and a subsequent incident

This structure allows the system to retrieve operational context by traversing relationships.

For example, a service investigation can start at Payment API, retrieve its owner, locate incidents affecting it, discover associated runbooks, and inspect modeled deployment relationships.

Exploring multi-hop dependencies

One useful graph operation is traversing dependencies across multiple services.

In the synthetic graph, the dependency path is:

Order Management → Checkout → Payment API

This tells us that Payment API is two dependency hops away from Order Management.

That relationship is useful when investigating potential downstream effects. If Payment API becomes unavailable, Order Management may be impacted through Checkout.

The graph provides a path that can be inspected and explained. It does not, by itself, prove that Order Management is experiencing an actual failure.

Example Cypher query

A simplified Cypher query for exploring services that depend on Payment API is:

MATCH path = (source:Service)-[:DEPENDS_ON*1..5]->(target:Service)
WHERE toLower(target.name) = "payment api"
RETURN source.name AS service,
       length(path) AS dependency_hops
ORDER BY dependency_hops;

This query traverses directed DEPENDS_ON relationships toward Payment API and returns the upstream services and their dependency distances.

The important point is that the result comes from graph traversal. The system does not need to ask the language model to invent a dependency chain.

FalkorDB therefore performs a meaningful part of the investigation rather than serving merely as a place to visualize the architecture.

Connecting the Graph to an AI Agent with MCP

A graph database can store valuable operational knowledge, but an AI agent also needs a structured way to access it.

For this project, I integrated graph investigation capabilities through the Model Context Protocol (MCP).

MCP provides a standard way for an AI application to discover and invoke tools exposed by a server. In TraceOps AI, the tools connect the agent's investigation workflow to graph-backed operations.

The project includes tools for:

get_service_details — retrieve service information
find_dependencies — explore dependency relationships
get_service_owner — identify the owning team
get_related_incidents — retrieve associated incident evidence
get_service_runbooks — locate relevant runbooks
get_incident_deployment_correlations — inspect modeled deployment and incident associations

This separation is important.

The graph database manages the connected operational information. The MCP tools expose specific operations. The AI agent interprets the user's request and uses the available tools to gather relevant evidence.

The language model is not treated as the source of truth for service dependencies or incident records.

Local AI with Ollama and Qwen

For the language-model component, I used Ollama with Qwen 2.5 3B.

Running the model locally allowed me to develop and test the prototype without sending investigation prompts to an external hosted language-model API.

The local model supports the conversational investigation experience, while the backend and graph tools provide access to structured operational information.

This division of responsibilities is a key design principle:

FalkorDB stores and connects operational knowledge.
MCP exposes graph investigation operations.
The local language model interprets requests and helps communicate the findings.
The backend coordinates the application workflow.
The frontend lets users submit investigations and inspect the results.

Local inference has practical trade-offs, including hardware requirements, response latency, and the reasoning limitations of a small model. Those constraints make it especially important to ground responses in retrieved evidence.

Architecture and Investigation Workflow

The application includes a React-based frontend, a Flask backend, MCP-based graph tools, FalkorDB, and the local Ollama model.

The investigation workflow can be summarized as follows:

Receive the question. A user asks the AI Investigator to investigate a service.
Interpret the request. The agent determines which operational information is relevant.
Retrieve graph evidence. MCP tools query FalkorDB for service details, dependencies, ownership, incidents, runbooks, or deployment correlations.
Traverse relationships. Graph queries retrieve connected evidence, including multi-hop dependency paths where applicable.
Construct the investigation response. The agent uses the retrieved information to explain the findings and identify useful next steps.
Present the results. The frontend displays the investigation output to the user.

The application also provides service topology and investigation result views.

This architecture keeps graph retrieval separate from language generation, making the workflow easier to test and reason about.

A Walkthrough: Investigating Payment API

Consider a user asking:

Investigate Payment API and identify related incidents, dependencies, the owning team, and relevant runbooks. Check whether a deployment is associated with the incident.

The synthetic graph contains Payment API as a degraded service, incident INC-1045 with high severity and an investigating status, deployment DEP-208 running version v2.4.1, the Payment Platform team, and the associated payment runbook RB-PAY-01.

TraceOps AI can retrieve this information through its graph investigation capabilities.

It can then present the connected evidence, including:

Incident: INC-1045, a high-severity payment incident
Deployment: DEP-208, version v2.4.1
Owning team: Payment Platform
Runbook: RB-PAY-01
Dependencies: Connected service paths retrieved from the graph

If the graph contains a modeled relationship between the deployment and the incident, the system can report that association.

However, an association is not sufficient proof that the deployment caused the incident. Establishing causality would require additional evidence, such as verified timing, logs, metrics, or a confirmed investigation result.

This distinction is important because an operational AI system should help engineers investigate problems, not confidently invent explanations.

The project also supports exploring a different service, such as Auth Service, where the connected evidence includes its owner, a resolved authentication incident, and an authentication runbook.

These scenarios demonstrate how different graph starting points can produce different investigation contexts.

Technical Challenges and What I Learned

Building TraceOps AI involved more than connecting a language model to a database. Several lessons shaped the implementation.

1. Designing a graph that solves a real problem

A graph database is most useful when relationships are essential to the task.

Simply storing service names in a graph would not justify the architecture. The valuable part is the ability to follow dependencies, connect incidents to affected services, retrieve ownership information, and traverse operational relationships.

I learned to think about the graph in terms of the questions the application needs to answer.

2. Making graph traversal meaningful

A dependency relationship has direction. If Checkout depends on Payment API, traversing from Checkout toward Payment API answers a different question from traversing in the reverse direction.

Understanding this distinction is necessary when identifying dependencies versus potential impact.

Multi-hop traversal also needs sensible bounds and clear interpretation so that the results remain useful.

3. Separating evidence from AI-generated explanations

A language model can generate plausible technical explanations even when the supporting evidence is incomplete.

By exposing structured graph operations through MCP, the system can retrieve specific facts and relationships before presenting an investigation.

I learned that tool access alone does not guarantee correct reasoning. The application must also validate the retrieved evidence and avoid treating correlation as proof of causation.

4. Making the system testable

The project includes tests for investigation behavior, dependency direction, deployment correlations, and causal validation.

Testing these areas is important because an investigation can look convincing while still traversing the wrong relationship or making an unsupported conclusion.

I also learned the importance of checking the application at multiple levels: database connectivity, graph queries, backend logic, MCP integration, frontend behavior, and end-to-end investigation.

5. Working with a local model

Using Ollama and Qwen 2.5 3B provided a local inference setup, but it also highlighted the need to design tool workflows carefully.

A small model may not always select the correct tool or interpret a complex investigation perfectly. Clear tool descriptions, structured results, validation, and well-designed prompts all contribute to reliability.

6. Building incrementally

I developed the project in stages, from database setup and synthetic graph creation to investigation queries, MCP integration, frontend functionality, and testing.

This incremental approach made it easier to isolate problems and verify each component before building on it.

It also reinforced a practical lesson: an AI application is only as dependable as the complete system around the model.

Testing and Validation

During development, the project reached the following milestones:

FalkorDB connectivity was verified locally.
A synthetic operational graph was created and queried.
The investigation logic was covered by a Python test suite.
The frontend lint and production build completed successfully.
The interface was connected to the backend investigation workflow.

These are development validation results, not a claim of production readiness or a measured improvement in incident resolution time.

The next stage would be testing against larger synthetic graphs, adding more realistic incident evidence, measuring retrieval accuracy, and evaluating the quality and latency of investigation responses.

What Comes Next?

TraceOps AI is a prototype, and there is room to extend it.

Potential future improvements include:

Integrating time-series metrics, structured logs, and traces.
Incorporating deployment timestamps and richer change metadata.
Adding confidence and provenance information to investigation findings.
Expanding graph coverage and testing more complex dependency networks.
Measuring graph retrieval accuracy and end-to-end response quality.
Adding safeguards for tool failures, missing data, and unsupported conclusions.
Evaluating multi-tenant graph isolation and access control before handling real operational data.

These improvements would help move the prototype toward a more comprehensive operational investigation assistant.

Conclusion

TraceOps AI was an opportunity to explore a practical use of graph databases and AI agents.

The central insight is that service troubleshooting depends on relationships. A degraded service, its dependencies, its owning team, related incidents, deployments, and runbooks form a connected operational picture.

FalkorDB provides the graph structure and traversal capabilities to retrieve that context. MCP exposes the relevant operations to an AI agent, and a local language model helps turn retrieved evidence into an understandable investigation.

For me, the biggest learning was that building a useful AI agent is not just about choosing a model. It is about designing the right data model, exposing reliable tools, validating evidence, and making the system's conclusions explainable.

TraceOps AI demonstrates how connected data can give an AI agent a more structured foundation for investigating complex technical systems.

The project was developed for FalkorDB Graph Hacks under the track Agents That Act on Connected Data.

Project: TraceOps AI

Technologies: FalkorDB, Cypher, Python, Flask, MCP, Ollama, Qwen 2.5 3B, React, and Vite.

Project repository: https://github.com/Harshukallur/TraceOps_AI.git

Architecture:

Acknowledgements: Thanks to the FalkorDB Graph Hacks organizers for the opportunity to explore graph-powered AI applications.

DEV Community: kallur harshu