Context graph
How Systemiq uses a graph-shaped model to structure operational context across the stack.
In Systemiq, a context graph is the working structure used to organize modeled entities, their relationships, and their directional impacts across the stack.
The graph is not a separate feature sitting next to the platform. It is how Systemiq keeps operational structure explicit enough to model, maintain, and query context over time.
Enterprise signals
Systemiq selects operational evidence from across the stack instead of treating every raw source as agent input.
- APIs
- Business systems
- Documents
- Events
- Transactions
- And more selected evidence...
Selected evidence enters the model. Agents do not need to reconstruct it from scratch.
Systemiq model
The model translates raw enterprise signals into a queryable operational structure with persistent memory.
Elements
Atomic nodes, local state, and indicator evidence.
Tools
Subsystem context and modeled local behavior.
Systems
Operational boundaries, rollups, and propagated interpretation.
Client
Cross-system interpretation, summaries, and shared context.
Persists as
Context graph examples
See how the modeled context is structured.
Agent access
Agents query modeled context directly through stable access surfaces instead of rebuilding reality from raw systems.
Which systems matter now?
What changed since the last run?
Where is impact rising or propagating?
Access surfaces
What the graph represents
- Elements act as the atomic modeled entities where local state and evidence are attached.
- Tools group connected elements into subsystem context such as connection circles, causal loops, or other modeled structures.
- Systems define major operational boundaries where tool-level context is interpreted together.
- Client-level interpretation can aggregate all or selected systems into higher-level insights and summaries.
- Mappings and impact relations make dependencies and directional influence explicit across layers.
- Records, metrics, summaries, and impacts persist graph-derived context as operational memory.
How Systemiq uses the graph
- Selected enterprise signals are attached to modeled entities instead of left as isolated raw inputs.
- Subsystem context is built by connecting elements into tools and other higher-order structures.
- System-level interpretation is derived by aggregating connected tool context within an operational boundary.
- Impact propagation is made explicit so the platform can carry forward influence, dependency, and change across the stack.
- The resulting graph-derived outputs are persisted and served back through MCP, APIs, maps, records, and metrics.
What this enables for agents
- Agents can retrieve narrowed operational context instead of reconstructing business reality from raw source systems.
- Agents can reason about relationships, dependencies, and rising impact rather than isolated signals.
- Multiple agents can work from the same current model instead of maintaining separate local interpretations.
- The context remains queryable over time rather than disappearing after a single execution.
Where it appears in the platform
- In stack structure: client scope, systems, tools, elements, mappings, and impacts.
- In query surfaces: MCP tools, records, metrics, and model navigation workflows.
- In visualization: maps and model views that make connected context inspectable.
- In operational memory: persisted outputs that retain graph-derived context over time.
Continue with Stack model for the concrete shape of client scope, systems, tools, elements, records, and metrics, or move to MCP to see how agents query the model.