For product teams
Ship the answer experience. Skip the year of infrastructure.
Your users want to ask your product a question and get an answer — one that knows both what they are entitled to and how the thing works. Those two facts live in different systems, and between them and an answer sits a pile of infrastructure that has nothing to do with what your product is for.
The alternative
A year of work, none of it your product.
You could build every one of these, and some teams should. The question is whether retrieval quality is what your customers are actually buying from you.
A chunker
Boundaries that do not cut a claim in half, and a strategy you can change later without re-embedding everything.
An embedder
A model choice you are stuck with, because changing it means recomputing every vector you have ever stored.
A vector store
Sizing, sharding, and a rebuild path for the day it loses a collection.
An entity and relationship extractor
Prompt design per content type, shard-level retries, and a cost ceiling so one tenant cannot spend your whole model budget.
A graph store
Entity resolution that holds under concurrent writers, so two workers processing two documents do not create two nodes for one thing.
An ontology manager
Versioning, and an apply path that does not destroy rows the new schema rejects — otherwise every vocabulary change is irreversible.
An answer synthesiser
Grounding enforced in the prompt, citation markers validated against the documents actually returned, and a refusal path when the corpus does not answer.
Or two endpoints
Ingest and search. No SDK, no framework, no code-level dependency on us.
Getting there
Four steps, and none of them are a migration.
No crawler, no credentials, nothing moved. You send us content and ask us questions.
Push what you already have
One POST per document, keyed on your own identifier. Most teams wire this into whatever already fires when content changes on their side.idempotent — safe to replay
Tag it with a source
Say which system it came from. That is what makes the extraction domain-aware — a billing row is read differently from a runbook — and later it is what tells you which entities appear in more than one of your applications.lms_content · salesforce · zendesk · notion · generic
Search from your product
One POST with the question and, optionally, the prior turns of the conversation. You get ranked passages, a cited answer, and the timings.nothing about the user is stored
Render the citations
Every marker resolves to a document you gave us, so you can link it straight back into your own UI with your own URL scheme.markers are validated before you see them
curl -X POST https://api.graas.ai/v1/ingest \
-H "x-api-key: $GRAAS_KEY" \
-H "content-type: application/json" \
-d '{
"sourceSlug": "billing",
"externalId": "account-4471",
"title": "Account 4471 — Team Annual",
"textContent": "Plan: Team Annual. Seats: 240.
SSO entitlement: false. Renews: 2027-03-01."
}'
# 202 Accepted
# { "documentId": "...", "externalId": "account-4471",
# "status": "extracting", "chunksCreated": 1,
# "statusUrl": "/v1/ingest/.../status" }curl -X POST https://api.graas.ai/v1/search \
-H "x-api-key: $GRAAS_KEY" \
-H "content-type: application/json" \
-d '{ "query": "does onboarding reduce churn?" }'What you ship
Four things teams put in front of users.
All of them the same two calls underneath.
An in-product answer box
A question field that returns prose with footnotes your user can open, rather than ten blue links into your own documentation.
A support copilot
Grounded in your ticket history and your help centre together, so an agent gets the answer plus every previous case that supports it.
An agent tool
Your agent calls search as a tool and gets back cited passages, or connects over MCP and gets the whole surface with one authorisation.
An internal question surface
The thing your team actually needs: one place to ask across the wiki, the tickets and the courses at once.
Why we answer, rather than only retrieve
Otherwise every caller writes the same prompt, worse.
A retrieval API that hands back passages and stops leaves each caller to write their own synthesis prompt over provenance they understand less well than we do — which in practice means grounding that is hoped for rather than enforced, and citation markers nobody validates.
So the answer comes with the passages. Grounding is in the prompt, invented citation markers are dropped before you see them, and refusal is a real outcome rather than an embarrassing hallucination. If you would rather write your own prompt, the passages are right there and you can ignore ours.
FAQ
Frequently asked
Wire it up on the free tier first.
Ten thousand documents, cited answers, no card. Enough to put a real answer box in front of a real user before you commit.
- no card required
- first workspace is free
- one POST to ingest