Vedana

Vedana does not answer in one pass. It runs a small agent that explores the data, one step at a time, and you can inspect every step.

A question arrives. An optional small model first narrows the domain to the entities and links that matter, so the main agent sees less noise. Then the agent loops, up to five steps: at each step it picks one of two tools, reads the result, and decides what to do next. One tool is vector search over embeddings, for meaning in text. The other is a Cypher query against the graph, for structure, links and exact sets. The graph query runs read-only and returns at most 30 rows, so a bad query cannot run wild.

When the agent has enough, it assembles the answer from the tool results. The same question triggers the same operations, and every retrieved node, query and text chunk is recorded, so you can answer why the assistant said what it said.

The domain lives in Grist, a spreadsheet-style store, as three things: anchors (the entities), attributes (their fields), and links (how they relate). That is the whole model. A domain expert and an engineer fill it in, and no code ships to change it.

An incremental ETL keeps the stores in sync. It recomputes only what changed, then loads nodes and edges into the graph and embeddings into the vector store. Add an anchor, add a link, or fix a value, then re-run the sync. The assistant reads the latest snapshot, so it keeps answering while you edit.

The model provider sits behind a thin wrapper, so you can move between providers without touching the code. Where the answer must be exact, the graph carries it; where it must follow meaning, the vector store does.

Most of the value shows up on four question shapes that vector search alone gets wrong, and a graph handles cleanly.

Count: "how many contracts expire this quarter" needs a real total over the whole set. A count from the top results only looks right.

Show all: "every document that regulates category X" needs the complete list, with nothing dropped.

Relationships: "is product A compatible with product B" needs the assistant to follow edges in the graph. Matching text misses it.

Domain logic: "can we sell A and B together to this client" needs rules run against real values.

Each of these is a walk over explicit edges. "Which documents regulate this category" traverses product to category to regulation to document, and returns the path with the document cited at the end. Because the walk visits every match, the set is complete.

Vedana is never better than its data model. Vague anchors confuse the assistant, and links that were never described mean multi-hop questions do not work. That is by design: it does not guess structure. If you want emergent behavior over a pile of text, classic RAG fits with less setup.

There is real setup. For a non-trivial domain, budget a domain expert plus an engineer for a few days to describe the model, a golden set of about 50-200 test questions, and several tune-and-check passes. It pays back on big, important domains, and it is overkill for a weekend prototype.

A single question typically takes around 2-10 seconds and costs well under a cent on a small model, both depending on the model and how many steps the question needs. That suits an interactive chat and can be tight for a real-time API. Vedana reduces hallucinations, it does not erase them, so a strict prompt and evaluation on hard questions still earn their keep. And it ships with no built-in access control inside a request, so you gate data at the API layer, or split the graph per tenant. We claim no latency or accuracy numbers here: measure both against your own domain and traffic.