Context that makes agent actions verifiable.

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.

Similarity search answers: what looks semantically close? 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.

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).

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.

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.

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.

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.

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.