"If the Database goes down, what breaks?" The answer lives in a wiki page that was accurate eighteen months ago, a ticket queue nobody trusts, and one person's head.

You could point a RAG chatbot at your docs. We'll do exactly that and watch our vector search return a fluent, well-formatted, incorrect number. We'll try the obvious fix, watch it appear to work, and unpack why that's the most dangerous result of the day.

Then we'll fix it properly. Working against a free graph database holding both your service topology and your unstructured ticket text, you'll build four retrieval strategies and learn exactly what each one gives up: semantic (vector) search, parameterized graph db queries, the two combined, and natural-language-to-query.

You'll build it twice on the same data: once in Python, once in a no-code agent builder. You leave with both, and a working agent you can adapt to your own infrastructure.

Takeaways

• Model infrastructure, ownership, and work-in-flight as one queryable graph
• Choose a retrieval strategy deliberately instead of defaulting to one search approach
• Build an assistant/agent from the ground up!
• Recognize some specific shapes of question an LLM will answer confidently and wrongly