Reply speeds up Porsche troubleshooting with a context graph

Reply reports a 30 to 40 percent reduction in initial incident investigation time. The graph requires ongoing maintenance of its sources.

By Alec Chizhik October 7, 2026 4 min read

Reply speeds up Porsche troubleshooting with a context graph

After a service provider change, Porsche’s new operations engineers had just a few weeks to understand manufacturing IT dating back around 25 years, according to Reply. A context graph now links code, configuration and relationships between systems.

Key takeaways

Reply describes a service provider change in Porsche’s manufacturing IT with just a few weeks for knowledge transfer.
A context graph links code and configurations with relationships between systems and processes.
The project presentation reports 30 to 40 percent less triage time and around 40 percent less time to resolution.

Related:Vector databases for RAG pipelines compared / AWS AgentCore brings Memory to GovCloud

A few weeks to learn legacy manufacturing systems

Maurits De Roover of Reply presented the project at Neo4j GraphTalk Munich on 2 July 2026, under the title “Scaling Context Graphs: From architecture to real-world impact”. His publicly available talk describes Porsche’s manufacturing IT from the contracted service provider’s perspective.

According to De Roover, the new operations engineers had just a few weeks to get up to speed after a service provider change. Some systems were around 25 years old. Operational knowledge was scattered across individuals, code and documentation. Some documents were outdated or incorrect.

The task therefore went beyond finding a relevant passage. During an incident, engineers needed to understand which configuration calls which code and which other systems depend on it. The talk mentions production, logistics and quality systems, among others. Understanding how these parts interact was crucial to troubleshooting.

Similar passages did not yet add up to a process

According to De Roover, the first approach used embeddings. These numerical representations enable searches for information with similar meanings. In this project, however, they returned isolated matches or similarities that could belong to the wrong context. Engineers still had to piece together the actual process chain themselves.

Reply therefore added a graph to the search. It stores information as nodes and relationships as connections. A context graph can, for example, link a configuration to the code it calls and that code’s dependencies. Semantic search remains the starting point.

For specific questions, the system uses prepared queries in Cypher, Neo4j’s query language. These are intended to let the agent retrieve information along the relevant relationships. In the case described, the aim is to identify the next useful investigation step and help engineers find the systems involved.

Data ingestion remains an operational task

The architecture separates source ingestion, the graph and the agents accessing it. Reply describes dedicated processing paths for different programming languages and frameworks. Quality checks are intended to keep incorrect structures from entering the knowledge base unchecked. The talk mentions formal rules using SHACL, among other measures.

During operations, an engineer can submit an error message through the interface. The system finds the context and supports further investigation. If this reveals outdated documentation, the engineer can correct it. Feedback from day-to-day work thus feeds back into the knowledge base.

Code changes must also be reflected. De Roover describes rebuilding an affected subgraph, comparing it with the previous version and replacing it. The rest of the graph remains intact. Without current, validated sources, the assistance remains imprecise.

Reply reports faster investigation and resolution

Reply’s results slides report a 30 to 40 percent reduction in triage time: the time spent initially investigating and classifying an incident. During the Q&A, De Roover puts the reduction in time to resolution at around 40 percent. These two metrics describe different stages of the work.

The presentation also reports around 3,000 tokens per request against a planned budget of 5,000 tokens. Tokens are the units in which a language model processes text. The figure describes consumption per request. It specifies neither total costs nor the graph’s contribution to them.

De Roover also reports that the questions in a prepared test set were answered correctly. Successful answers to known test questions do not guarantee error-free performance during future incidents.

What other businesses can apply

The transferable element is less the software than the work on relationships. Maintaining configurations, code and systems as connected nodes gives engineers context during an incident rather than isolated matches. Applying this approach elsewhere requires mapping each business’s own relationships too.

The cost is maintaining the knowledge base. For changes to code sources, Reply describes a process that rebuilds, checks and then replaces the affected subgraph. Engineers correct outdated documentation directly during troubleshooting. In this project, engineers primarily lacked an overview of interconnected systems. The graph made those relationships accessible for troubleshooting.

Whether building such a system pays off elsewhere depends on the investigation time saved and the cost of building and maintaining it.

Frequently asked questions

Does the graph replace semantic search?

In this project, it complements semantic search. Embeddings provide a starting point, while graph queries reveal relationships between the information found.

What does a context graph need to stay useful?

The knowledge base needs current sources and validated relationships. When code sources change, Reply rebuilds the affected subgraph and checks it before replacement. If the system identifies outdated documentation, engineers can correct it.

Do 3,000 tokens prove that overall costs are lower?

No. Establishing that would require model prices, request volumes and the cost of building and maintaining the knowledge base, among other factors.