Skip to main content

Querying the graph

Most people never write a query. They ask the agent a question in plain language, or they explore the ontology view in the dashboard. Both run on the same query engine. How that engine works decides which questions get fast, exact answers, so it's worth a look.

The agent plans, the engine executes​

Ask "how many centers are out of ratio in Texas?" and SixDegree doesn't turn the model loose to wander the graph one lookup at a time. It splits the work.

The agent plans. It reads your question and picks one query shape: what to start from, what to traverse, what to count or group or rank. That's a single bounded decision.

The engine executes. A deterministic compiler runs that plan against the graph. No model sits in this loop. The same plan returns the same answer every time, in milliseconds.

That split is the point. The slow, expensive part is the reasoning, and it happens once, over the shape of the query. Running the query is plain graph work.

info

Earlier versions answered a counting question by fetching entities and tallying them in the model's head. It was slow, and it drifted on large sets. Now the agent writes one structured query and the engine computes the answer. You get the same number every time, and you get it fast.

Some questions can't be expressed as a structured query. There the agent falls back to exploring with tools, under a budget of time and tokens. A hard question gets a slower answer. It never spins forever.

What a query is made of​

Every query has the same three parts, whether the agent wrote it or you sent it to the structured query API:

  • A starting set of entities: a kind, optionally narrowed by name, attribute, or meaning.
  • An optional traversal that walks relationships to connected entities.
  • A result shape: a list, a count, a breakdown, a matrix, or a grouped aggregate.

You say what you want. The engine decides how to run it, enforces your access scope, and returns typed results. There's no query language to learn or sanitize.

Operations that compose​

The engine isn't a fixed menu of reports. A handful of operations combine, so a hard question becomes one query instead of a sequence of manual steps.

  • Count a set, or split it by an attribute and compute a metric per group (count, sum, average, min, max).
  • Rank groups or entities and keep the top few. "The three states with the most understaffed centers" is one query.
  • Filter groups by their aggregate. "States with more than ten understaffed centers" filters after the grouping runs.
  • Keep or drop entities by whether a relationship exists. This is how you find gaps: repositories with no owner, accounts with a champion but no open opportunity.
  • Label each entity by its first matching relationship, or cross a relationship axis with an attribute axis to get a matrix.

Because they compose, "top three kinds by entity count" is a single query: count across all kinds, group by kind, sort descending, take three. The agent assembles the operations. The engine runs them in one pass.

Resolving concepts by meaning​

You don't always know the exact name of what you mean. "The billing service," "Pre-K classrooms," and "the payments team" are concepts, not literal names.

The engine can resolve a concept to the entities that match it. It runs a vector search over the graph before the rest of the query runs. The agent reaches for this when it can't match a name exactly, and it scopes the match to the right kind, so "Pre-K" lands on classrooms, not on a document that happens to mention Pre-K.

If a step that should have matched something comes back empty, the engine notices and re-plans once, this time preferring a concept resolution over a literal name. That self-correction is why a question phrased in human terms finds the right entities instead of quietly returning nothing.

tip

Semantic resolution finds the doorway. Once the concept resolves to concrete entities, every count, traversal, and aggregate runs over exactly that set. You get the reach of search with the precision of an exact query.

Computing values at query time​

Some questions need a value nobody stored: an SLA breach state, an age bucket, a staffing ratio, a what-if. The engine can derive a new column at query time from an expression over each entity's fields, then filter, group, sort, or rank on the result.

So "which contracts renew within thirty days and are over their seat limit?" is one query. Derive days-to-renewal and seat overage per contract, then filter on both. The agent doesn't add these up by hand, token by token. The engine evaluates the expression per entity, the same way every time.

Time-relative values read a reference clock. By default that's now, but you can pin it, which turns "as of last Friday at 5pm" into a parameter instead of a separate code path. The same capability drives history and time travel.

Reading across systems​

The same real thing often lives in several systems at once. A childcare center might be a Salesforce account, a Workday cost center, and a LineLeader site. You shouldn't have to know that to ask about centers.

Canonical kinds unify those sources into one type you query directly. Query the canonical Center and the engine reads across every backing source, returns one entity per center with a stable set of attributes, and keeps the native fields underneath for drill-down. When two sources disagree, a declared precedence rule picks the authoritative value and records the other as provenance, so you can always see where a value came from.

Canonical relationships work the same way. The engine materializes the edges between canonical entities, so you can traverse straight from an Incident to the CustomerAccount it affects without first knowing which native systems back each side.

Built to stop​

A structured query runs in bounded time. The fallback exploration loop runs under an explicit budget of tool calls, tokens, cost, and wall-clock. A query that nears its budget ends with a synthesis of what it found. You'll sometimes get a partial answer to a genuinely hard question. You won't wait forever for one.

Next steps​