GraphRAG
Your data already has the answer. It's just spread across six systems.
A knowledge graph connects them — so a question walks from vendor to material to job to margin and comes back with the path it took. Aethyr ships that graph pre-wired to the systems you already run, inside your own boundary.
? Which jobs are exposed to a vendor that just slipped two weeks?
Two jobs, $227K committed, both closing inside the slip window.
Illustrative trace · construction stack
The question isn't whether a graph is better. It's what each one actually returns.
Ask both systems the same thing. A vector index searches for text that resembles your question. A graph walks the relationships between records.
Vector search returns
4 documents mentioning "Cascade Supply" and "delay"
- · A purchase order PDF
- · An email thread from March
- · A meeting note
- · A second, near-identical PO
Now you read them and do the join in your head.
The graph returns
Two jobs, $227K committed, both closing inside the slip window.
vendor → material → job → schedule
And the path it walked, so you can check it.
This gap is measured, not asserted. On multi-hop questions, published benchmarks put graph retrieval around 86% against roughly 32% for vector-only; on schema-bound aggregations — anything counting or summing across records — vector retrieval approaches zero because the answer exists in no single passage.
The real objection
Nobody doubts graphs work. They doubt they can ship one.
That doubt is well earned. The failure mode is consistent enough to be predictable:
of enterprise RAG projects never reach production
Graph construction overhead is a recurring contributor.
to build the graph for a single domain
Two to three months to cover an enterprise.
is where builds actually stall
Extraction is cheap now. Deciding that three records are one customer is not.
more engineering on freshness than on the initial build
A graph that drifts out of date quietly stops being trusted.
Sources: GraphRAG in Production · A Practical Buyer's Guide to GraphRAG · Knowledge Graph Construction for AI
What Aethyr changes
The graph is the product. Building it isn't your project.
Most of that 6-to-12-week build is teaching a pipeline what your systems mean. Our connectors already know.
The connectors already know the schema
14 enterprise integrations running in production — ServiceTitan, HubSpot, Autodesk, QuickBooks, Google and more. A ServiceTitan Job is a job. A QuickBooks Customer is an organization. Nobody writes that mapping from scratch.
Entity resolution ships with it
The step where most builds stall is the one we already solved. The same customer sitting in your CRM, your project system, and your ledger resolves to one node — so a question about them stops depending on which system you asked.
It builds inside your boundary
No corpus shipped to a vendor for indexing. Extraction, resolution, and the graph itself run on your infrastructure — on-prem, private cloud, or fully air-gapped. Neo4j in production, alongside Postgres and Redis, every query org-scoped by construction.
Freshness is a pipeline, not a project
The connectors that build the graph keep it current. That 2–3× maintenance tax is engineering you never take on.
The entities change. The shape doesn't.
Every one of these is a question that spans systems — which is why no single system can answer it.
? Which jobs are exposed to a vendor that just slipped two weeks?
Two jobs, $227K committed, both with close dates inside the slip window.
vendor → material → job → schedule
? What did we actually make on kitchen remodels last quarter?
Estimated against actual, line by line, with the change orders that moved it.
project type → job → cost item → labor → actual
? Who else can supply this, and are they already approved?
Three qualified alternates, with lead time and last-paid price on each.
material → spec → compatible item → vendor → terms
Why regulated teams buy this
An answer you can put in front of an auditor.
"These passages were semantically similar to your query" does not survive a regulatory review. A traversal does: every answer carries the records it walked, the relationships it followed, and the system each one came from.
That path is the difference between an AI answer you can act on and one your counsel will not let you use. It runs on the same tamper-evident audit trail and post-quantum identity as the rest of the stack.
? Which stores received product from the contaminated lot?
41 stores, 3 SKUs, 18 days of sales — with the receiving record for each.
When you don't need this
A graph is the right tool for a narrow class of problem. We would rather say so now than three months into a build.
Your questions live inside one system.
Then you need a better report, not a graph. The value of a graph is the join between systems.
You're looking for a passage in prose.
"What does our warranty policy say about water damage?" is a vector search question. It is cheaper, faster, and better at it.
Your data has no recurring nouns.
Graphs form around entities that appear again and again — customers, jobs, parts, matters. Freeform text with no stable subjects gives a graph nothing to hold onto.
Graph readiness check
What would your graph connect?
Name the systems you run. We'll show you which entities appear in more than one of them — those are the records that become a single node, and the questions that become answerable the moment they do.
Step 1 · Your systems
Which of these do you run?
Pick everything that holds a record about a customer, a job, or a dollar.
Step 2 · Your graph
Nothing selected yet.
Pick the systems you run. The graph assembles as you go.
Illustrative — based on the systems you select, not a scan of your data.
Vector search tells you what you have.
A graph tells you what it means.
Bring us the systems you already run. We'll show you the graph they make — and it stays inside your boundary.