A queryable world model, not a list of links

We compute the structure of the web in order to build the index — which host published what, which passages report the same story, which entities appear together, who links to whom. Every other search API throws those edges away. We hand them to your agent.

What it replaces

The expensive part of agentic retrieval is not the search call. It is everything the agent does afterwards to work out which results are duplicates, which sources are independent, which are authoritative, and what to read next — reasoning that happens in the context window and is billed by the token.

Rebuilding it in context

20 calls

Every intermediate result lands in the context window and is paid for in tokens, whether or not it turns out to matter.

+8 more not drawn

Traversing the graph

1 call

The relationships already exist because we own the index. assemble_context returns the corroborated, trust-ranked, budget-packed set directly.

Both paths answer the same question. The difference is how much of the answer the agent has to reason its way to.

The usual loop

~20 callsjavascript

// Without a graph: the agent rebuilds the structure itself.
const hits    = await search("acme corp funding round");
const dedup   = dedupeByTitle(hits);              // guesswork
const sources = await Promise.all(                // N more searches
  dedup.map(h => search(`"${h.title}" -site:${h.host}`))
);
const trusted = rankByVibes(sources);             // no authority signal
// ~20 calls, every intermediate result in the context window

With the graph

1 calljavascript

// With the coverage graph: the index already knows.
const pack = await assembleContext({
  query: "acme corp funding round",
  budget: 4000
});
// 1 call. Story-deduplicated, corroboration-ranked,
// packed to budget, each passage carrying its reason.

What one result is connected to

Every hit a search returns is a node, not a dead end. These are the edges available from any one of them — each traversable in a single call, and each already computed.

Six operations over the same graph. No other web search API exposes traversal over arbitrary open-web documents — you can build one over your own corpus, but not over the web.

Six operations

Each one collapses an agent pattern that would otherwise cost many searches and a lot of in-context reasoning.

related

Returns the connected neighbourhood of a passage from the coverage graph — the edges are what to read next.

Collapses: A search per hop. One call replaces the whole chain.

corroborate

Reports how many distinct hosts independently carry a story — the anti-hallucination check.

Collapses: Manual cross-searching to verify a claim.

authorities

Returns the top passages on a topic ranked by graph centrality — trust-triage a field without reading junk into context.

Collapses: Reading twenty mediocre results to find the three that mattered.

dossier

Builds a one-hop brief on an entity: mentions, the hosts covering it, and the entities co-mentioned with it.

Collapses: ~10 searches plus a manual merge, in one call.

path

Finds the shortest chain of edges linking two passages — reasoning-path retrieval, or connect-the-dots.

Collapses: Open-ended investigation, reduced to a structural query.

assemble_context

GraphRAG as a service: returns a ready-to-read context pack — corroborated, story-deduplicated, trust-ranked and packed to a token budget, each passage carrying the reason it was included.

Collapses: The entire do-it-yourself RAG loop.

Why we can offer this and others cannot

Not because the graph is hard to query, but because you have to own the index to have one. The link structure, story clusters, entities and topic tags are all things we already compute to run our own index. Exposing them costs us very little; building them on top of a reseller's result list is not possible at any price.

Link graph

Host-to-host, from the crawl

Story clusters

Near-duplicate detection at admission

Entities & terms

Salient extraction

Embeddings

Already computed for the vector tier

Coverage graph

Typed nodes and edges

Every edge carries a type, a weight, a confidence and a provenance. Node identifiers come from a stable dictionary rather than a content hash, so they survive a rebuild — which is what makes epoch-to-epoch diffs meaningful.

Node types

Passage: A unit of admitted text — the thing search returns.
Host: The publishing domain, carrying its own authority score.
Story: A cluster of near-duplicate passages reporting the same thing.
Topic: A coarse subject tag assigned at index time.
Entity: A person, organisation, product or place named in the text.

Edge types

HOSTED_ON: A passage to the domain that published it.
IN_STORY: A passage to the near-duplicate cluster it belongs to.
ABOUT: A passage to the topics it covers.
MENTIONS: A passage to the entities it names.
LINKS_TO: A host to the hosts it links out to — the web link graph.

The free part: signals on every hit

You do not have to call a graph endpoint to benefit from the graph. Four of its measurements are folded into the index as stored fields, so every ordinary search hit carries them — and you can filter and sort on them for nothing.

centrality

PageRank-style score over the graph. How load-bearing this passage is.

min_centrality

independent_sources

Distinct hosts asserting this story. Survives deduplication.

min_independent_sources

community_id

Label-propagation cluster. Which discourse this belongs to.

community

in_degree

How many other nodes point at this one.

sort=centrality

Corroboration survives deduplication — which is not obvious, and matters

A naive index that removes near-duplicates destroys exactly the signal you need to judge a claim: twelve copies collapse to one, and the fact that twelve outlets carried it is gone. When a duplicate is rejected at admission we record its host against the surviving passage. The index stays compact and independent_sources still counts every host that asserted it.

Frequently asked questions

What is a coverage graph?

A typed graph over the search index itself. Nodes are passages, hosts, stories, topics and entities; edges record which passage was published where, which passages report the same story, what each is about and who links to whom. It is built from signals the index already computes in order to exist, so querying it costs almost nothing extra.

How is this different from GraphRAG?

GraphRAG and Neo4j build a knowledge graph over your documents — you supply the corpus, run entity extraction, and operate the infrastructure. The coverage graph is already built, over the open web, and queried through the same API as search. There is no ingestion step and nothing to operate.

Does using the graph cost more than a normal search?

No. Graph calls bill as ordinary requests. The baked signals — centrality, community, independent source counts, in-degree — arrive on every search hit at no additional cost, because they are stored fields rather than computed at query time.

What does independent_sources actually count?

The number of distinct hosts asserting a story, not the number of copies kept. When a near-duplicate is rejected at admission its host is still recorded against the surviving passage, so deduplication compacts the index without destroying the corroboration signal. corroborate returns both numbers: independent sources and merged duplicates.

Can I use the graph without the MCP server?

Yes. Every graph tool is also a plain HTTP endpoint — /related, /corroborate, /authorities, /dossier, /path and /assemble_context — usable from any language with the same API key.

Try the graph on your own questions

assemble_context is the fastest way to see the difference — one call returns the corroborated, trust-ranked, budget-packed set an agent would otherwise spend twenty calls assembling.

Get your API key Read the API reference