Context

Most agent systems pull context from scattered sources -- a vector database for embeddings, a relational database for structured data, an API for live state. Omnigraph collapses these into a single store where typed structure, search, and traversal live together.

The graph as world model

An Omnigraph repository is a world model. The schema defines what kinds of things exist. The data represents the current state of those things. Queries let agents ask precise questions about that state.

This is different from a vector database, where context is a bag of similar text chunks. In a graph, context has structure: entities have types, relationships have meaning, and traversal follows the connections between things.

Patterns

Schema as agent instructions

The .pg schema tells agents what the world looks like. An agent can read the schema to discover available entity types, their properties, and their relationships -- without hardcoding any of this in its prompt.

node Customer {
    email: String @key
    name: String @index
    plan: enum(free, pro, enterprise)
    embedding: Vector(1536) @index
    @description("A customer account. Use email as the primary identifier.")
}

The @description annotation gives agents natural-language guidance that travels with the schema.

Hybrid context retrieval

Combine structured traversal with semantic search in a single query. Start with a known entity, traverse to its neighborhood, and search within that neighborhood.

query relevant_tickets($customer_email: String, $question: String, $vec: Vector) {
    match {
        $c: Customer { email: $customer_email }
        $c filed $t: Ticket
        $t hasMessage $m: Message
        search($m.body, $question)
    }
    order rrf(nearest($m.embedding, $vec), bm25($m.body, $question))
    return { $t.slug, $t.title, $m.body }
}

This retrieves messages that are both structurally connected to the right customer and semantically relevant to the question.

Scoped reads

Agents don't need to see the whole graph. A query scopes what they read to exactly the subgraph they need.

query agent_context($account: String) {
    match {
        $a: Account { name: $account }
        $a hasContact $c
        $a hasDeal $d
        $a hasActivity $act
    }
    return { $c.name, $d.name, $d.stage, $act.summary }
}

The agent gets a focused context window: contacts, deals, and activities for a single account. Nothing else leaks in.

Evolving knowledge

Agents write back to the graph as they learn. New entities, new relationships, and new properties accumulate over time. Because the graph is typed, these writes are validated against the schema.

omnigraph branch create --from main enrichment-run-042
# Agent writes new data on the branch
omnigraph branch merge enrichment-run-042 --into main

The next agent that reads the graph sees the enriched data. Knowledge compounds.

Gap detection as context

Negation queries tell agents what is missing. This is context too -- knowing what you don't know is often more useful than knowing what you do.

query accounts_without_recent_activity() {
    match {
        $a: Account
        not {
            $a hasActivity $act
            $act.date > "2025-01-01"
        }
    }
    return { $a.name }
}

An agent can use this to prioritize outreach to accounts that have gone silent.

Comparison: vector DB vs Omnigraph

A vector database answers "what is similar to X?" Omnigraph answers that and also "what is connected to X?", "what is missing from X?", and "what changed about X?"