Context Graphs for AI Agents: Make Decision History, Exceptions, and Authority Queryable

Documents explain the rule; decision history explains how the organization applied it

Retrieval can find a pricing policy, service playbook, or approval guide. Difficult work often depends on the conditions around prior exceptions: which customer commitment existed, who had authority, what risk was accepted, when the decision occurred, and whether the exception became precedent or remained a one-time judgment. That context is usually scattered across case notes, approvals, messages, and the memory of experienced staff.

Bizz uses data management to turn selected decision events into governed, queryable records. A context graph links the subject, situation, policy version, evidence, decision, reason, authority, time, and outcome. It does not copy every private conversation into permanent memory; it captures the minimum structured lineage needed for a legitimate operational or analytical purpose.

• Choose decision domains where precedent and exceptions materially affect quality or consistency.
• Define the event schema with business, data, risk, and privacy owners.
• Capture verified rationale and authority rather than inferring intent from informal text alone.

Context graphs, knowledge graphs, and retrieval answer different questions

A knowledge graph represents entities and relationships: a customer owns an account, a product belongs to a category, or a facility serves a region. Retrieval-augmented generation finds relevant passages from documents and data. A context graph emphasizes decision lineage through time: under these conditions, this policy and authority produced this decision, which led to this outcome. The three approaches can complement one another.

Bizz combines graph and retrieval patterns with generative AI according to the question. Retrieval can surface the current policy, a knowledge graph can resolve the correct entities, and a context graph can show comparable approved exceptions. The agent still needs a policy boundary and may need human judgment; historical precedent should inform a decision, not silently authorize it.

• Use retrieval for relevant source material and citations.
• Use entity relationships for identity, structure, and connection across systems.
• Use decision lineage when conditions, time, authority, exception, and outcome matter.

Model decisions as events connected to evidence, authority, and consequence

A useful graph begins with a small set of business concepts, not a database technology. A decision event might connect a subject, request, situation, applicable policy, evidence observations, proposed options, selected outcome, decision maker, delegated authority, exception, execution, and later result. Each node or relationship carries an owner and source reference where appropriate. The graph should distinguish a fact copied from an authoritative system from a rationale entered by a reviewer or an inference generated by a model.

Avoid a generic related-to edge that shifts all meaning into prose. Relationships such as evaluated-under, approved-by, delegated-from, exception-to, supported-by, supersedes, executed-as, and resulted-in make queries and controls intelligible. Define cardinality and required properties: can a decision have several approvers, can an exception apply to more than one policy clause, and what does it mean when the outcome is unknown?

Preserve granularity. A customer case may contain several decisions, and one approval may authorize a bounded set of actions. Turning the whole case into one node makes comparison easy but lineage weak. Conversely, representing every chat message as a permanent decision node creates noise and privacy burden. Model the smallest event that changes business state or records accountable judgment, then link supporting artifacts by protected reference.

• Separate authoritative facts, human rationale, model inference, proposals, decisions, execution, and observed outcomes.
• Use meaningful relationship types with defined direction, validity, ownership, and required properties.
• Choose event granularity around accountable state change rather than cases or conversation messages by default.

A decision event needs temporal truth and an accountable source

Policies change, customer status changes, people change roles, and yesterday's exception may be invalid today. Each event should record what was true at the time, which source versions applied, who approved the outcome, and whether later review confirmed or reversed it. Temporal modeling prevents an agent from treating a historic decision as if its conditions still exist.

Bizz connects graph construction to ETL development and authoritative systems. Pipelines can assemble candidate events, but accountable owners should define which fields and decisions are trustworthy. Quality checks look for missing authority, conflicting identities, impossible timelines, and outcomes that were never verified.

• Represent effective dates and source versions rather than storing only current state.
• Link decisions to verified actors, policies, evidence, and later outcomes.
• Distinguish proposed, approved, executed, reversed, and expired decisions.

Use valid time and record time to reconstruct what was known when

A single timestamp cannot answer every audit or operational question. Valid time describes when a fact, policy, authority, or decision applied in the business. Record time describes when the graph learned or stored it. A contract amendment may become effective on Monday but enter the source system on Wednesday. A corrected customer classification may apply retrospectively. Keeping both allows the organization to explain what a decision maker could see at the time and how later corrections changed the record.

Version policies and authority, not just data. A manager's approval limit may change, a regional rule may be replaced, and a temporary delegation may expire. Link the decision to the exact versions and validity intervals used. Do not resolve every query against today's role and policy, or legitimate historical decisions can appear unauthorized after the organization changes.

Model reversal and supersession as new events rather than overwriting history. The graph can show that an approval was issued, an action executed, a dispute raised, and the outcome later reversed. Current-state applications may expose only the latest status, while the lineage supports investigation and learning. Access and retention still apply: historical completeness does not justify indefinite availability to every user.

• Store when a fact was valid and when it entered the governed record.
• Link decisions to time-bounded policy, role, delegation, and source versions.
• Represent correction, reversal, and supersession as lineage-preserving events.

Entity resolution determines whether the graph connects the right history

Decision events arrive from CRM, ERP, case management, approval tools, ticketing, documents, and messaging systems. The same customer, product, employee, facility, or contract may have different identifiers and imperfect names. A false merge can expose unrelated decisions or produce a misleading precedent; a missed match fragments history. Entity resolution is therefore a controlled data product, not a one-time string-matching exercise.

Prefer durable source identifiers and explicit crosswalks where they exist. Use probabilistic matching only with recorded confidence, evidence, and review rules appropriate to the consequence. Preserve the source identity even after linking to a canonical entity so errors can be traced and corrected. Sensitive domains may require purpose-specific identity views rather than one universal enterprise person node.

Corrections must propagate. If two accounts are unmerged or a supplier hierarchy changes, dependent graph edges, indexes, cached context, and evaluation cases may need refresh. Track which decisions used the previous resolution and whether any active workflow should be reconsidered. Bizz applies data warehouse engineering patterns to reconcile sources while keeping lineage and ownership visible.

• Use authoritative identifiers and governed crosswalks before probabilistic matching.
• Retain source identities, match evidence, confidence, and review history for every canonical link.
• Propagate corrections to indexes, context views, and affected active workflows.

Build the graph from durable events, not retrospective transcript mining alone

The highest-quality lineage is captured when the decision occurs. An approval service can emit the proposal, policy version, approver, authority, decision, and execution reference as structured events. A case system can record the exception category and outcome. Change-data capture and event streams can bring those records into the graph while preserving source identifiers and ordering.

Historical backfill is still valuable, but it needs confidence boundaries. Extraction can identify candidate decisions in notes, documents, or email, yet the resulting rationale and authority may be incomplete. Mark inferred events, retain source references, and route high-value cases for domain review. Do not present a model-extracted interpretation as equivalent to an explicitly approved record.

Design ingestion for replay and correction. Use idempotent event keys, schema versions, quarantine for invalid records, quality checks, and reconciliation counts against source systems. Monitor missing owners, impossible timelines, dangling evidence, expired authority, and outcomes that never arrived. Graph usefulness depends less on visual complexity than on a reliable process for keeping decision lineage current.

• Emit structured decision and approval events from operational systems at the time of work.
• Label historically inferred events and require review where consequence or uncertainty warrants it.
• Use replayable, idempotent, versioned pipelines with quality and source reconciliation.

Authorization must filter paths, properties, and purposes before retrieval

Graph connectivity can make sensitive relationships easier to discover. A user permitted to see a customer record may not be permitted to see an employee investigation, legal rationale, or another region's exception that connects through it. Authorization cannot be an afterthought applied only to the final generated answer. It must constrain which nodes, edges, properties, and paths the query can traverse.

Combine user and agent identity, role, relationship to the case, data classification, jurisdiction, declared purpose, and current workflow state. Precompute safe views for common use cases where possible and apply policy at query time for dynamic conditions. Avoid returning hidden-node counts or explanatory metadata that indirectly reveals a protected relationship. The agent should receive only the allowed subgraph required for the task.

Delegated use deserves special care. An agent working for a user should not gain platform-wide graph access because a background service performs the query. Preserve the initiating principal and agent identity, authorize the purpose, and audit protected traversals. When a decision is shown as precedent, disclose enough provenance for the user to assess it while redacting identities or rationale fields that are not needed.

• Authorize traversal and property access before graph context reaches retrieval or a model.
• Evaluate identity, relationship, classification, jurisdiction, purpose, and workflow state together.
• Preserve user delegation and prevent counts, paths, or metadata from leaking hidden relationships.

Hybrid retrieval should compare situations without pretending similarity is authority

A current case can begin with semantic retrieval over its narrative, entity lookup for the relevant customer or product, and graph traversal for decisions with compatible policy, region, segment, conditions, and authority. Reranking can combine textual similarity with structured filters and recency. The result should include the current policy and a small set of precedents whose material similarities and differences are visible.

Similarity must not collapse into a single opaque score. One precedent may match customer segment but use an expired policy; another may match contract terms but involve a different approval authority. Present feature-level comparison and exclude examples that fail hard eligibility conditions. If no sufficiently comparable decision exists, the system should say so instead of retrieving a merely adjacent story to satisfy the interface.

The agent can explain why a precedent is relevant, identify missing facts, and prepare an approval packet. A domain service or authorized person still applies current rules. Record which precedents were shown and whether the reviewer found them useful. That feedback improves retrieval and schema design without turning acceptance of a suggestion into automatic proof that the historic decision was correct.

• Combine narrative retrieval, entity resolution, graph constraints, current policy, and structured reranking.
• Show material similarities and differences instead of presenting one unexplained similarity score.
• Allow a no-comparable-precedent result and keep current authority responsible for the decision.

Precedent should improve judgment without turning yesterday's bias into tomorrow's rule

Historical decisions can contain inconsistent treatment, outdated policy, missing populations, or choices the organization no longer wants to repeat. Context graphs therefore need access control, review, representativeness checks, retention, and product experiences that show why a precedent is similar. High-consequence decisions should remain contestable and should not be automated solely because a graph contains a prior example.

Bizz builds evaluation around the complete decision-support experience. Teams test whether retrieved precedents are relevant, current, authorized, and appropriately weighted; whether the agent identifies important differences; and whether a human can challenge the evidence. The value is institutional memory with provenance, not an automatic permission to repeat history.

Evaluate representativeness, recourse, and outcome quality before automating from history

Audit which populations, regions, product lines, and time periods appear in the graph. Missing history can make the system confidently recommend the pattern of the best-recorded team. Compare approval and outcome distributions across relevant cohorts, accounting for legitimate policy differences. Investigate whether certain groups receive more exceptions, reversals, delays, or missing rationale.

Create a challenge path. Reviewers should be able to mark a precedent irrelevant, identify a material difference, correct an entity link, dispute a rationale, or request that sensitive context be reviewed. Corrections require ownership and resolution; a free-text thumbs-down queue is not enough for consequential decision support. Affected people may also need recourse through the business process even if they never see the graph itself.

Measure downstream results, not agreement with prior decisions. A pricing exception can be approved consistently and still reduce margin without improving retention. A service accommodation can differ from precedent and produce a better customer outcome. Connect decisions to later evidence within an appropriate time window, and use analysis to improve policy rather than training the system to reproduce historical frequency.

• Measure coverage and decision distributions across the populations and periods where the graph will be used.
• Provide owned correction and challenge routes for precedents, identity, rationale, and relevance.
• Judge historical patterns against later business and human outcomes, not consistency alone.

Start with one decision family and prove that lineage changes the outcome

Choose a domain where exceptions recur, authority is identifiable, source records exist, and better precedent can reduce delay or inconsistency. Commercial approvals, service recovery, procurement exceptions, maintenance decisions, fraud review, and care coordination can fit, but consequence and privacy determine the required controls. Avoid beginning with an enterprise-wide graph of everything connected to everything.

In the first phase, define the event and temporal schema, source owners, access policy, quality rules, and a small set of questions. Backfill a reviewed sample, instrument new decisions at the source, and build a read-only reviewer experience. Compare time to evidence, missing-context rate, decision consistency where appropriate, review effort, correction, and outcome quality against the current process.

Expand only after the graph earns trust. Add sources, decision types, and agent assistance separately. Automating an action is a further decision with its own evaluation and authority. A context graph creates value when it shortens the path from current situation to accountable evidence; graph size, edge count, and visualization complexity are not success measures.

• Select one recurring decision family with explicit authority, accessible records, and measurable friction.
• Begin with reviewed lineage and read-only decision support before granting action authority.
• Measure evidence quality, review effort, correction, decision time, and downstream outcome.