Context Graph (Dynamic CMDB)
A context graph is a live, integration-fed graph database that models people, devices, applications, services, and the relationships between them — used by an agent-first ITSM system to ground its reasoning. Every Tier-A AI-ITSM player ships one, under different brand names: Atomicwork calls theirs the “Enterprise Knowledge Graph,” STLabs calls theirs Axiom®, Console simply calls it the “context graph,” and Serval ships an equivalent through its integration proxy + asset/identity surface.
This is the modern replacement for the traditional CMDB (Configuration Management Database) as the substrate for IT operations.
What It Is
Traditional CMDB Context Graph
───────────────── ──────────────
Static, table-shaped Live, graph-shaped
Manual data entry Self-maintaining via integrations
Periodic refresh / drift Continuous ingestion
Joins to query relationships Traversals follow natural relationships
Single-source-of-truth fiction Provenance per assertion (source + timestamp)
Audit-only role Reasoning substrate for AI
A context graph stores entities (people, devices, applications, services, infrastructure) and the typed edges between them. It pulls data from identity providers, MDM/UEM, HRIS, ticketing, cloud APIs, observability, security tools, network configuration — and merges it without losing provenance (each fact carries its source and timestamp).
How It Works
Common pattern across the four implementations researched:
- Continuous ingestion. Integrations (Okta, Entra, Workday, Lansweeper, Intune, Jamf, AWS, Splunk, ServiceNow, Slack, …) sync to the graph automatically. The graph “emerges as a side effect of tools already doing their jobs” (STLabs framing).
- Provenance per assertion. Each fact in the graph carries its origin (which integration), timestamp, and confidence. Conflicting data can be traced back to its source rather than overwritten silently.
- Permission-aware queries. Identity context (groups, roles, ACLs) is part of the graph itself — so RAG and action-execution respect document/system permissions natively.
- Reasoning surfaces.
- Blast radius / impact analysis — “if I patch service X, which downstream services and users are affected?”
- Root cause clustering — “these 200 tickets share the same upstream cause; one fix resolves them all.”
- Compliance posture — “who has access to what, and is that consistent with policy?”
- Maintenance windows — “the lowest-traffic window for this service is …”
- Onboarding/offboarding — “the right access bundle for this role at this company is …”
Why It Matters
The shift from CMDB to context graph is foundational for AI-ITSM, not cosmetic:
- AI grounding. LLMs need a structured representation of “what exists in this company and how it connects” before they can reason about action. A flat ticket history isn’t enough.
- Determinism without rigidity. Workflows and policies can be expressed against the graph rather than against a fragile rule sheet. When the graph updates, the logic adapts.
- No drift. Manual CMDB updates are notoriously broken in practice. A graph ingested from live sources can’t drift in the same way (it can be incomplete, but not stale).
- Audit + accountability. Provenance per assertion means actions taken by AI can be retraced to specific facts and specific sources — the compliance story for autonomous execution requires this.
Naming and Distinctions
| Vendor | Brand name | Distinguishing emphasis |
|---|---|---|
| Atomicwork | Enterprise Knowledge Graph | Heavy focus on knowledge (SharePoint/Confluence/Drive content) + identity/asset graph; PII redacted at ingestion; per-tenant self-hosted vector DB ^[extracted]. |
| STLabs | Axiom | Strict provenance per assertion; explicit “graph over tables” framing; positioned against the CMDB as the differentiating primitive; combines vectors for semantic lookup with graph traversal for structural reasoning ^[extracted]. |
| Console | Context graph | Integrated into the agent runtime; emphasized for “ticket as audit record” pattern ^[extracted from Console research]. |
| Serval | (no public brand name) | Equivalent function delivered via the integration proxy (server-side credentials + fixed scope) and Assets surface; the context substrate is implicit, not marketed as a distinct primitive ^[inferred]. |
When It Helps (and When It Doesn’t)
Helps when:
- The buyer organization has several disconnected systems of record (IdP + HRIS + MDM + ITSM + cloud) — the graph creates the connective tissue.
- Workflows depend on cross-system context — onboarding spans HR + IdP + MDM + email + access management; offboarding spans IdP + MDM + HRIS + license reclamation.
- AI is asked to take action, not just answer — grounded actions need grounded context.
Less useful when:
- A single system already covers the full stack (rare).
- Buyer is comfortable with manual CMDB and doesn’t need autonomous action.
- Integration coverage in the vendor’s catalog doesn’t include the buyer’s actual stack.
Trade-offs
- Integration coverage is the moat. A context graph is only as useful as its inputs. STLabs and Atomicwork both market 50–100+ integrations; Serval is at 65–70; Console publishes its connector list. Connector breadth is the actual product surface.
- Provenance discipline is hard. Merging conflicting facts from multiple sources without losing source-of-truth is non-trivial. STLabs makes provenance their headline: each graph edge/property is a timestamped assertion with source and confidence metadata ^[extracted].
- Permission propagation has corner cases. Document ACLs, group memberships, time-bound access — getting RAG to honor all three at query time is genuinely hard.
- Vendor lock-in risk. The graph is a customer-specific asset built inside the vendor’s product. Export paths and vendor-portability are an open buying-team concern; not yet a standard feature in any researched player.
Why It Matters for initlabs
The context graph is table stakes, not a differentiator, for any serious entrant in this category. initlabs cannot ship without one — and the bar for a credible offering is now continuous ingestion, provenance per assertion, permission-aware queries, and ≥50 connectors.
Possible differentiation axes within the context-graph space:
- Provenance-first UX — surface “why did the AI think this?” with a graph trace as the answer. STLabs leans this direction in its blog post; the actual product UX is unverified.
- Open / portable graph — customer-owned graph export, or a self-hostable graph layer. None of the Tier-A players ship this today ^[inferred].
- Connector velocity — a community-built or marketplace approach to integrations vs first-party-only.
- Graph reasoning over policy — represent compliance + access policies as graph queries, audit-able against the graph itself.
- Engineering self-service — STLabs hints at this (database credential self-service); deeper integration with infra-as-code, secrets, and dev environments could become a real flank.