Context Graph

Context that makes agent actions verifiable.

Rippletide Context Graph structures facts, relationships, and decision traces so your agent retrieves the applicable context, and invalidates what is no longer true, before it acts.

Applicability over retrieval: the right context for this action, now.
Temporal validity built in: facts can expire, be superseded, or invalidated.
Scoped by design: each agent ID maps to an isolated graph (no leakage).

What is a Context Graph?

A Context Graph is a persistent, structured representation of facts, relationships, rules, exceptions, and decision traces that an AI agent can query before it acts. It stores typed entities, explicit connections, temporal validity windows, and provenance metadata in an isolated, per agent namespace.

It is not just a chat log, session memory, or a vector store: it can capture personal working memory, with optional team sharing. It is the reasoning substrate that makes agent actions verifiable and auditable.

The core idea: applicability

Most agent failures are not caused by missing information. They are caused by using the wrong information at the wrong time. A Context Graph is designed to answer one question reliably:

Which context is allowed, valid, and relevant for this action right now?

What the Context Graph provides.

Applicability

Retrieval is filtered by what is relevant to the current action, not by embedding similarity. The graph uses type, scope, permissions, relationship paths, and current validity to produce action aware recall. Your agent gets the right context for this decision, now.

Temporal validity

Time is a first class dimension. Policies change, contracts expire, exceptions are temporary. Each fact carries a validity window and can be superseded or revoked. Expired, superseded, or revoked facts are excluded from recall automatically. No stale context reaches the agent, and reproducibility stays possible.

Scope isolation

Each agent ID maps to an isolated graph namespace. No shared state between agents or tenants unless explicitly configured. Personal memory stays private by default, and only shared with a team when you choose to. Enforced at the infrastructure level. This prevents cross agent leakage that can happen in shared retrieval stores.

Provenance and audit trail

Every fact is traceable to its source, timestamp, and the agent or service that wrote it. You can audit any decision back to the data that informed it, including what was considered applicable at decision time.

How it works

Four MCP primitives. One reasoning loop.

The Context Graph exposes four tool calls via MCP (Model Context Protocol). Any MCP compatible client can connect with a single config file.

`remember`: Store structured facts

Write entities, attributes, and metadata to the graph. Each fact carries provenance (source, timestamp) and an optional validity window.

Provenance and auditability from the first write.

`relate`: Map explicit relationships

Connect facts to each other with typed edges. The graph captures causal chains, dependencies, and hierarchies, not just flat key value pairs.

Applicability: relationships define what context is relevant to what.

`recall`: Retrieve applicable context

Query the graph for the context that is applicable to a specific action, right now. Recall respects validity windows, scope boundaries, and relationship paths.

Temporal validity: expired or superseded facts are excluded automatically.

`invalidate`: Revoke what is no longer true

Mark facts as expired, superseded, or revoked. Downstream relations update accordingly. Agents never act on stale context.

Use cases

Built for enterprise agent workloads.

Each use case maps directly to Rippletide Enterprise Use Cases, where you can explore partner integrations and governance capabilities.

Customer Support Agents

Governed decisions for refunds, exceptions, and commitments.

Retrieve applicable customer context (history, entitlements, policies) before every action.
Invalidate superseded commitments so agents never reference expired offers.
Full audit trail for disputes and compliance.

Coding Agents

Governed code and UI generation constrained by patterns and policy.

Store and recall personal coding memory (style and habits), optional team-shared preferences, and company best-practice code conventions.
Relate new code decisions to existing architectural patterns.
Enforce consistency across projects with scoped, versioned context.

Cybersecurity Incident Response

Governed isolate, block, and revoke with thresholds and audit.

Recall severity baselines, blast radius thresholds, and prior incident context.
Invalidate stale threat intelligence before automated response.
Post incident auditability with full decision provenance.

Background Agents and AI Analysts

Accountable analysis with versioned assumptions and traceability.

Store versioned assumptions and causal reasoning chains.
Recall only currently valid data points when generating insights.
Trace every conclusion back to its source facts and relationships.

Frequently asked questions.

How is a Context Graph different from agent memory (chat or session memory), and what production problems does it actually solve?

A Context Graph is structured, typed, and queryable context designed for reliable decision making, not just conversation continuity. Unlike chat memory (usually untyped text), a Context Graph stores facts as entities plus relationships plus provenance plus validity, so agents can retrieve exactly the relevant context for a decision, avoid mixing unrelated sessions or users, enforce freshness and revocation, and produce auditable explanations for actions.

Why is applicability (action relevant context) more reliable than similarity search (RAG or vectors) when an agent must trigger sensitive actions?

Applicability answers: what is allowed, valid, and relevant to this action right now? For sensitive actions (refunds, approvals, account changes), semantic similarity can surface plausible but wrong context. A Context Graph adds constraints (type, scope, permissions, recency, status) so recall is gated by correctness, not just relevance.

How should I model typed facts (entities, attributes, relationships) so the graph stays clean and recall stays truly action aware?

Start with a small ontology. Entities: Customer, Account, Contract, Ticket, User, Tool, Policy. Relationships: owns, is_authorized_for, relates_to, governed_by, depends_on. Facts: typed statements with provenance plus timestamps. Keep the graph clean by storing atomic facts (one claim per node or edge), using stable identifiers (external IDs where possible), separating policy and constraints from observations, and defining retrieval intents (what an agent needs for each action).

How does temporal validity work in practice (expiry, supersession, revocation), and how do you prevent agents from acting on stale context?

Every fact can carry validity metadata (created_at, valid_from, valid_to, expiry, source). When recalling context for an action, the system can filter by time window (only facts valid now), most recent wins (supersession), status based rules (for example contract_active must be current), and source confidence (CRM system of record over inferred text). This makes stale context a first class failure mode you can prevent systematically.

What happens when you invalidate a fact? Do downstream relationships get recomputed, and how do you ensure revoked context cannot be recalled?

Invalidation marks a fact as no longer eligible for recall (revoked, expired, superseded). From that point, retrieval excludes it by default, dependent reasoning can be recomputed based on your rules, and audit logs preserve history (who or what invalidated it and why). So you get both: no stale recalls in production, and full traceability for investigations.

How is per agent or per tenant isolation enforced at the infrastructure level to prevent any cross agent context leakage?

Isolation is enforced through scoping: each fact is written with a tenant or agent scope, reads are filtered by that scope (and optionally by role and permissions), and the API enforces access boundaries so agents cannot query outside allowed context. In practice, this prevents cross tenant spillover issues common in shared retrieval.

What gets recorded for provenance and audit (source, timestamps, writer agent), and how can I reconstruct why an action was taken?

Each fact can carry: source (system, tool, document, user), timestamps (created, updated, validity), writer (which agent or service wrote it), confidence or evidence links (optional), and relation paths (how this context connects to the decision). When an agent acts, you can reconstruct what it recalled, which constraints applied, and which nodes directly supported the action, giving you a clear why with an audit trail.

What does MCP integration look like? What are the core primitives (remember, relate, recall, invalidate), and how do I adopt it without changing my agent framework?

MCP integration is designed to be drop in: your agent keeps its framework, and MCP provides tools to manage context safely. Core primitives: remember (write a typed fact), relate (connect entities or facts), recall (retrieve applicable context for an intent or action), invalidate (revoke or supersede outdated facts). Adopt it incrementally: start by writing key entities and facts, recall context for one high value action, add invalidation rules as you learn failure modes, then expand to more actions and policies.