Your Django App Has Years of Data. Here's How to Make AI Agents Actually Use It.

A developer built `django-graph-search`, a library that enables AI agents to query live Django ORM data without custom ETL pipelines or separate vector stores. The tool traverses relational database graphs to create semantically rich vector documents from existing models, configured through a single `settings.py` file with automatic index updates via `post_save` signals.

You have a Django app with years of data — products, articles, orders, users. Your users type natural language queries into a search box and get either nothing or keyword-matched garbage. Worse: you want to connect an AI agent that can answer questions about this data. But everything is locked inside relational tables. To feed it to an LLM, you either dump the database, write custom ETL pipelines, or stand up a separate vector store and manually keep it in sync with your ORM. I ran into exactly this problem. So I built a library that solves it with one config file. Classic Django search solutions solve one problem — search. But they all come with a price: | Solution | What You Need | Why It Hurts | |---|---|---| | Haystack + Elasticsearch | Separate server, manual field mapping | Mountains of boilerplate, no semantics | django.contrib.postgres.search | PostgreSQL only | Exact match, no meaning | | Custom RAG pipeline | Export scripts, pandas, numpy | Data goes stale, no ORM connection | None of them answer the real question: How do I make an AI agent work with live data from my Django app without rewriting the architecture? django-graph-search doesn't just vectorize individual model fields. It traverses your ORM relation graph and builds a rich document that captures the full context of an object. Take a simple Product model: Product pk=42 ├── name: "Pixel 8" ├── description: "Camera-first Android phone with Tensor G3" ├── category → Category.name: "Smartphones" ← FK ├── tags → Tag.name: "android", "5G", "camera" ← M2M └── brand → Brand.description: "Google hardware..." ← FK depth=2 └── country → Country.name: "USA" ← depth=2 All of this gets merged into one text document , which is passed to the embedding model. The resulting vector is semantically rich — it carries information not just about the object itself, but about its entire relational context. This is done by GraphResolver , which recursively walks meta.get fields , handles FK, M2M, and reverse relations, and tracks cycles via a visited set. The most important part: all of this is added on top of your existing Django application. You don't change models, don't create new tables, don't touch your views. Everything lives in settings.py : INSTALLED APPS = ..., "django graph search", GRAPH SEARCH = { "MODELS": { "model": "shop.Product", "fields": "name", "description", "category name", "tags name" , "follow relations": True, "relation depth": 2, }, , "VECTOR STORE": { "BACKEND": "django graph search.backends.ChromaDBBackend", "OPTIONS": {"persist directory": "vector db"}, }, "EMBEDDINGS": { "default": { "BACKEND": "django graph search.embeddings.SentenceTransformerBackend", Multilingual — works with Russian, English, German, etc. "MODEL NAME": "sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2", } }, "DELTA INDEXING": True, } One command and your vector index is built: python manage.py build search index Your Django app runs exactly as before. Data stays in PostgreSQL. Vectors live in ChromaDB alongside. post save signals keep the index updated automatically whenever objects change. Not everything in your database should end up in a vector. Technical fields like slug , created at , internal admin notes — these are noise that degrades search quality. weight fields gives you precise control: "weight fields": { "title": 2.0, repeated twice — embedding "remembers" it more "description": 1.0, standard weight "internal note": 0.0, weight 0.0 = completely excluded from the vector "slug": 0.0, } This isn't just filtering. Under the hood, the GraphResolver. apply weight method repeats text fragments in the document proportionally to their weight. A field with weight 2.0 appears twice in the concatenated string, shifting the embedding centroid toward that concept in vector space. Now for the main point. Here's how this connects to AI agents. The standard RAG pattern Retrieval-Augmented Generation requires: get user query → retrieve relevant context → pass to LLM. Normally "retrieve context" means separate infrastructure. With django-graph-search , it's three lines: python from django graph search import search def build llm context user question: str - str: results = search user question, models= "shop.Product", "blog.Article" , limit=5 Each result contains "text" — the full indexed document and "score" — cosine similarity from 0.0 to 1.0 context = "\n\n".join r "text" for r in results if r "score" 0.7 return context Pass context to the system prompt of any LLM Key detail: results "text" is not just str instance . It's the full text document used to build the vector — with all related fields, all weights applied. The LLM receives rich, relational context , not just an object name. For more demanding use cases, the library ships an optional LangGraph pipeline. It adds: GRAPH SEARCH = { "LANGGRAPH": { "ENABLED": True, "QUERY EXPANSION": True, "RERANKING": True, "MAX EXPANDED QUERIES": 3, "FALLBACK ON ERROR": True, if LLM fails, falls back to pure vector search "LLM": { "BACKEND": "myapp.llm.OllamaBackend", plug in your own Ollama/vLLM/OpenAI }, }, } Important: langgraph is an optional dependency . If the package is not installed, the pipeline automatically falls back to a built-in FallbackGraph with identical behavior. Your application code doesn't change. The conversational endpoint adds stateful memory between requests: User: "show me smartphones under $500" Agent: returns list User: "only Samsung" Agent: understands previous context, interpreted query = "Samsung smartphones under $500" Migrating between vector backends is just changing one line: Dev: ChromaDB → local, no server, files on disk Staging: FAISS → fast, CPU-only, everything in memory Production: pgvector → if you already have PostgreSQL — no new server at all Qdrant → if you need filtering and horizontal scaling Embedding models are swappable the same way: local sentence-transformers , OpenAI, Cohere — all through EMBEDDINGS.BACKEND . Zero code changes. django-graph-search is not just another search library. It's a vector layer on top of your existing Django ORM that: pip install django-graph-search chromadb Your data is already there. It just needs a vector layer. GitHub: svalench/django graph search · PyPI: django-graph-search