Knowledge graph
The governed workspace context graph: source facts, relationships, provider metadata, and agent evidence, read within scope.
Every workspace has a governed context graph: a tenant-isolated Neo4j graph that holds approved entities and relationships from connected sources, plus stable provider metadata. Oxagen checks every read in workspace scope, so an agent can ground answers in shared context without Oxagen becoming a remote copy of a developer's checkout.
Search it with oxagen graph search, or with search_graph and the other graph tools over the API or MCP.
What lives in the graph
| Node kind | Examples | Origin |
|---|---|---|
| Entities | Issue, PullRequest, SourceRepository, and the types you map a Postgres table to | Connected sources: GitHub, Linear, and Postgres |
| Provider metadata | Repository, configured refs, commits, pull requests, workflow runs, changed-file paths | GitHub connections and verified provider events |
| Run metadata | Agent runs, steps, approvals, tool calls, and metering facts | The durable run record and audit events |
| Documents & assets | Ingested documents and uploaded files | Uploads and connector ingestion |
Oxagen flags product-owned nodes (runs and generated assets) is_system, and the graph reads leave them out, so results show your own entities.
Agent memories live in Postgres and stay out of the graph. See Agent memory.
Code graph boundary
The code graph is a separate graph. Oxagen builds a cloud copy of each commit on a connected repository's default branch, with its symbols, chunks, and embeddings, and keeps it apart from the workspace graph. A local code graph of your working tree, uncommitted changes included, stays on your machine. See Code graph from the CLI and the code graph tools in MCP tools.
The workspace graph holds no source text, symbols, chunks, or code embeddings. It keeps stable Git-provider metadata for governance and replay: provider and repository identity, refs and commits, pull requests, workflow runs, and changed-file paths. Oxagen does not work out which run changed which file.
Sources
list_connections lists the source connections that feed the graph. Each connection maps its source record types to your entity types (a mapping step you confirm at setup), then syncs on a cadence: webhook, polling, or manual. You can pause a connection, re-sync it incrementally or in full, or delete it in one of three modes: connection only (keep data), data only (keep config), or full.
Sources write an operational record to Postgres and an approved graph projection to Neo4j. Agents retrieve within scope.
Searching the graph
Two searches work together:
- Semantic search embeds a natural-language query and ranks eligible shared knowledge (entities, documents, messages, and provider metadata) by vector similarity. It excludes repository source text, symbols, chunks, and code embeddings.
- Lexical search matches substrings in node names and descriptions. Use it when you know what something is called.
From any node you can walk its neighbors one hop at a time, or traverse several hops along named relationship types. Reads support bitemporal queries: "as of" a valid time (what was true in the world) and "as known at" a transaction time (what Oxagen had recorded).
Inferred relationships
Oxagen writes no relationship a model inferred into the workspace graph.
Governing the graph's shape
The workspace schema registry sets the graph's vocabulary: which entity types, properties, and relationship types it allows.
Import agent configuration
Link a repository and Oxagen finds its CLAUDE.md, AGENTS.md, rules, skills, commands, subagent files and MCP configs, turns them into steering records, and opens one steering PR.
Schema registry
Define and enforce the workspace ontology: node labels, properties, and relationship types, with drafts, versions, and AI-assisted setup.