OM2 Builder · Custom context graphs for AI agentsWrite the ontology. Skip the ingestion, extraction, rebuilds and on-call.

We built the hardest parts of a context graph, from entity resolution and access on every record to incremental updates, extraction at scale and a benchmark harness. OM2 Builder lets developers build on them easily: you design the model, and we run everything underneath it.

Book a demo See how it works

CLI, API, MCP or your coding agent·Hosted or self-hosted

Agent tools

ConnectExtractBuild

Use cases

Where teams are putting context graphs to work.

Any part of the business with systems behind it can have its own context graph. These five are the ones teams ask for most often today.

Codebase graphs

“If I change this contract, which services break, and who is mid-migration?”

ValueAgents make changes in the right places, so fewer PRs get rejected and teams ship faster without shipping more bugs.

Client AI deployments

“Which of this client’s workflows should we automate first, and who owns each one?”

ValuePartners deliver engagements faster with fewer people, and every project on the account builds on the same context instead of adding tech debt.

Operations graphs

“Which fare rules apply on SFO to JFK next week, and which one takes over on Monday?”

ValueAgents answer with the business’s own rules every time, and the partner delivers them without hand-modeling the ontology first.

Finance operations

“Which payments cover these Northwind invoices, and which invoices are still open?”

ValueManual matching hours go away, with an agent the finance team can rely on.

Customer and shipment graphs

“Where is this order, and is a top-tier customer about to get it late?”

ValueAgents answer “where is my shipment” without a person digging through four systems, and flag a late order for a top-tier customer before they have to ask.

Have a different use case in mind?

Clinical trials, insurance claims, manufacturing lines, legal matters. If your agents need to know it, OM2 can graph it.

Tell us your use case

How it works

Six stages from raw data to an agent that knows your business.

Each stage is labelled with what runs it: deterministic code, a language model, or you. Select a stage to see what happens and what you type.

Deterministic codeLanguage modelYou

Stages 1–2 · Connect and register

Bring it all, with its permissions attached.

Native connectors stream in your systems of record. Anything bespoke, such as a records export, a folder of PDFs or a legacy database dump, comes in through a short source.yaml that maps it onto one of four archetypes. Every record keeps who can see it from the moment it lands.

ArchetypesDocuments, records, conversations, people. Map a source once, then reuse the mapping.

Safety checksEvery push is scanned for personal data and secrets, and a dry run shows what would land before anything does.

Right to deletePurge a source or single records, and everything derived from them, with an audit trail of who and why.

GitHubrepos · PRs · issues

Slackchannels · DMs

Google Drivedocs · sheets

Gmailthreads

Jira / Lineartickets · projects

Notionpages · databases

Salesforce / HubSpotaccounts · deals

HRISroster · leavers

{}

Your filessource.yaml → any format

Extractionopen model · GPU pool

Reads every document and writes out the entities, relations, statements and passages your ontology asks for.

Enrichmentopen model · GPU pool

Builds a profile per entity and links facts about it across documents and sources.

Themesopen model

Clusters recurring topics across sources, with each person’s access respected.

Ontology draftsfrontier model

Proposes types from a sample of your corpus, with a verbatim quote of evidence for each one.

Budgetsyou set them

Monthly caps, alerts, a hard stop, and a cost estimate before every run.

Stage 3 · Extract

The right model for each job, inside your budget.

Extraction runs over every document, so it runs on efficient open models on GPUs that scale with your backlog. Drafting your ontology and reasoning over evidence uses a frontier model. On a self-hosted install, all of it can run on inference inside your own cloud account.

Every extracted fact keeps a pointer to the passage it came from. Agents cite sources, and reviewers can check them.

Stage 4 · Shape

Iterate on your model like you iterate on code.

Your ontology is a YAML file: the types, relations, merge keys and extraction hints that define your domain. Draft or edit it, preview it on real documents, review the diff, then apply.

The graph re-derives itself from the new definition. A second build runs beside the live graph, and a benchmark tells you whether the change helped before you promote it.

Stages 5–6 · Serve and measure

Give your agents tools that speak your domain.

Generic retrieval comes built in: search, lookup, neighbourhood and read-only graph queries. The leverage is in domain tools: named, typed queries over your ontology, each with test cases. They’re compiled, checked against access, replayed as tests and published over MCP to every agent you use.

Persona viewsRun the tools as a given employee and see exactly what their agent would see.

Quality loopProbes generated from your corpus, with each failure traced to the stage that caused it.

Any clientClaude Code, Codex, ChatGPT and in-house agents, over MCP or REST.

What happens when an agent calls a tool

1Agent callsdeferrals_expiring(days: 14) over MCP, as a specific person.

2Access filterThe query runs only over nodes that person is allowed to see.

3Typed answerRows from your ontology, each with the passages that back it.

Example tools.yaml

# tools.yaml: your agents’ vocabulary, in version control
tools:
  - name: deferrals_expiring
    description: Deferred defects that expire before
      the aircraft’s next scheduled base visit.
    input_schema:
      properties: {days: {type: integer}}
    kind: cypher
    query: |
      MATCH (a:Asset)-[:HAS]->(d:Deferral)
      WHERE d.expires < a.next_base_visit
        AND d.expires < date() + duration({days: $days})
      RETURN a.tail, d.ref, d.expires
    test_cases:
      - {args: {days: 14}, expect: {min_rows: 1}}

Build vs. buy

The demo takes a weekend. Everything under it doesn’t.

Teams that set out to build this find the vector store was the easy part. Here is what sits below the waterline once real data and real users arrive.

What your team can prototype in a weekendChunk the docs, embed them, put a prompt in front. It demos beautifully on fifty clean documents.

embeddings + vector DB + prompt

What they would have to build next to run it in productionEach of these is a quarter of engineering on its own, and the last three are what your security team will ask about first.

Entity resolution“J. Alvarez”, “jalvarez@” and “Jorge (Payments)” are one person across nine systems, and two people named Jorge are not.

Permission propagationEvery fact inherits the access of every record it came from, enforced on every query, for every person and every agent.

Incremental re-derivationChange one type in your model and rebuild only what depends on it, without reprocessing a million documents or taking the graph down.

Extraction at scaleGPU pools, retries, backpressure, partial failures, and output parsing that doesn’t silently drop a fifth of your edges.

Evaluation harnessFrozen question sets, baselines against raw search, and failures traced to the stage that caused them.

Lifecycle and deletionLeavers, right-to-delete, purges that leave the graph clean, snapshots and rollback.

Review and auditHuman sign-off on model changes, an agent that can’t approve its own work, and an audit trail a security team will accept.

Cost controlEstimates before runs, caps, alerts and hard stops, so a bad loop doesn’t burn a quarter’s budget overnight.

Isolation and deploymentPer-tenant credentials, sign-in with your identity provider, and an install that runs inside your cloud.

You stay the builder

A power tool for developers. You hold the controls.

Your team owns the design decisions, which live in your repo as files you can read, diff and revert. We own the machinery that makes them work at scale.

You decideThe model, the sources, the tools, the bar

What your domain is made of: every type, relation and merge rule in your ontology
Which sources come in, and how each maps onto the model
The tools your agents get, their queries and their tests
When a change ships, based on your own benchmark and a human review
Where it runs, which models it uses and what it may spend
How you drive it: CLI, API, MCP or your own coding agent

We handleEverything that has to hold up at scale

Ingestion, connectors, deduplication and identity matching
LLM extraction on scalable GPU pools, with budgets and retries
Access checks on every query, for every person and agent
Rebuilds, snapshots, side-by-side builds and safe promotion
The benchmark harness, quality probes and failure attribution
Upgrades, security fixes and the long tail of edge cases

Deployment

Runs where your data lives.

Reach it through MCP or the API, with any model. Coworker can host it, or you can run it in your own cloud. The files are the same either way, so the choice isn’t a one-way door.

Start with one use case and one question set.

Bring a use case and a sample of real data. In two weeks your team will have a graph, a reviewed ontology, domain tools and a benchmark against your current retrieval.

Book a demo See OM2 Custom Graph