Consider a hypothetical revenue agent instructed to follow up with an account that returned to the pricing page three times. The CRM says the deal is active. Product analytics says intent is high. Billing says the customer is current. Support shows an unresolved severity-one escalation. The consent service prohibits marketing outreach. A territory table assigns a different owner.

Each system may be accurate. The danger appears when an agent compresses the claims into one answer: "This is a high-intent account, so send the message."

That is not a hallucination in the usual sense. It is a resolution failure.

Disclosure: I am the founder and CEO of INSIDEA, an Elite HubSpot Partner. This article reflects practical experience and independent research. It is not sponsored by HubSpot or any other company mentioned.

Enterprise teams need a control layer between retrieved context and agent action. I call it the Assertion Conflict Graph.

A field is not a fact

Most CRM architectures expose a record as a collection of current values:

{
  "company_id": "co_4821",
  "deal_stage": "contract_sent",
  "account_status": "active",
  "owner_id": "user_17",
  "contactable": true
}

This representation works for interfaces and reporting. It is incomplete for autonomous action because the final value hides the path that produced it.

HubSpot's object APIs can return selected current and historical property values through propertiesWithHistory. HubSpot also supports custom properties with unique values. Those capabilities provide raw material, but do not decide which assertion should govern an action.

An assertion is more specific than a field value. It is a claim made by a source about an entity at a point in time, under a defined authority and policy context.

{
  "assertion_id": "asrt_01J8Y7M5",
  "entity_id": "company:co_4821",
  "predicate": "outreach_permitted",
  "value": false,
  "source": "consent-service",
  "observed_at": "2026-08-31T14:03:22Z",
  "recorded_at": "2026-08-31T14:03:22Z",
  "effective_from": "2026-08-31T14:03:22Z",
  "authority_tier": 1,
  "confidence": 1.0,
  "policy_basis": "contact-opt-out",
  "derived_from": ["consent-event:evt_9918"]
}

A boolean says no. An assertion explains whose no it is, when it became effective, what policy created it, and which event supports it.

The Assertion Conflict Graph

The graph has two primary elements:

• Assertion nodes represent claims about an entity.
• Typed edges represent relationships between claims.

The minimum useful edge vocabulary is small:

Unlike a general enterprise context graph, the Assertion Conflict Graph has one narrow job: detect incompatible claims for a proposed action and produce a controlled resolution before execution.

The model has a standards foundation. W3C PROV covers entities, attribution, processing, derivation, and provenance validation. SHACL defines shapes and constraints for validating graph data. An implementation need not use RDF, PROV, or SHACL, but should preserve identity, attribution, derivation, constraints, and validation.

Image credit: Original AI-assisted illustration created for this article.

Six conflicts a record-level view will miss

A weak identity join, ambiguous lifecycle, or hidden derivation should never authorize a high-consequence action.

Deterministic resolution before probabilistic reasoning

Do not ask a language model to choose whichever assertion sounds most convincing. Send each conflict set through ordered gates.

An authoritative consent assertion outranks a marketing inference about contactability. A page view may decay in hours while a signed contract remains effective for years. A policy denial is never another signal to average.

Only after these gates should a model rank remaining alternatives:

deterministic constraints
        ↓
eligible assertions
        ↓
probabilistic interpretation
        ↓
consequence-aware action gate

Confidence is evidence about uncertainty. It is not permission, provenance, authority, or truth.

A minimal fail-closed resolver

The resolution layer does not need to begin as a graph database or a model prompt. It can start as a small deterministic service that validates assertions, rejects non-authoritative or stale claims, and refuses to act when critical evidence is missing.

The order matters:

function resolveAction(assertions, proposedAction, now) {
  validateRequiredFields(assertions);
  requireOneResolvedEntity(assertions, 0.95);

  const eligible = assertions
    .filter((claim) => sourceOwnsPredicate(claim.source, claim.predicate))
    .filter((claim) => isFreshForPredicate(claim, now));

  requireCriticalEvidence(eligible, proposedAction);

  if (policyBlocks(eligible, proposedAction)) {
    return stopWithEvidence(eligible);
  }

  if (consequenceRequiresReview(eligible, proposedAction)) {
    return escalateWithDecisionTrace(eligible);
  }

  return actWithinDeclaredAuthority(eligible);
}

This is intentionally not a confidence-weighted vote. A high-confidence page-view inference cannot outvote a current consent denial. A stale authoritative claim is not made current by assigning it more weight. Missing action-critical evidence results in escalation, not optimistic completion.

The resolver above is pseudocode, not a production implementation. A real deployment needs tested identity matching, authority rules, policy semantics, timing, logging, and review paths. Passing isolated fixtures would not establish legal compliance, production safety, or business correctness.

A worked revenue scenario

Assume an agent is deciding whether to send a renewal-expansion message.

A retrieval-only agent may summarize the buying signals and send from the CRM owner. The conflict graph produces a different result:

1. The identity gate confirms that the usage account, billing account, opportunity, and support case belong to the same customer.
2. The authority gate accepts billing for payment status, support for escalation state, consent for contactability, and the territory service for assignment.
3. The freshness gate identifies the territory record as newer than the CRM owner field.
4. The policy gate blocks marketing outreach because of the opt-out.
5. The consequence gate recognizes that an external message can create customer and compliance risk.

The correct output is not "low confidence." It is a structured decision:

{
  "decision": "stop_external_outreach",
  "allowed_actions": [
    "create_private_review_task",
    "notify_current_territory_owner"
  ],
  "blocking_assertions": [
    "contact-opt-out",
    "open-severity-one-case"
  ],
  "owner_conflict": {
    "resolved_to": "user_42",
    "reason": "territory-service-authority-and-freshness"
  },
  "review_required": true
}

The agent prepares the internal task, attaches evidence, and routes it correctly without converting conflicting context into unauthorized outreach.

An implementation path that does not require replacing the CRM

The graph can begin as a control service beside the existing CRM.

1. Ingest and identify. Capture source IDs, property history, timestamps, and events, then map CRM records, billing accounts, product workspaces, and support organizations to durable entity keys.
2. Attach provenance. Record source, authority, observation time, effective time, derivation, and policy basis.
3. Detect conflicts. Apply predicate rules and graph constraints to find contradictions, invalid states, and missing evidence.
4. Resolve or escalate. Run deterministic gates and preserve unresolved conflicts instead of overwriting them.
5. Issue and trace. Return eligible assertions, blocked actions, approvals, and the resolution trace, then store what the agent saw and which rules fired.
6. Learn without erasing disagreement. Update rules from reviewed outcomes while retaining original assertions and decision traces.

NIST's Generative AI Profile includes actions for tracing the origins and modifications of digital content, using provenance and anomaly-analysis tools, documenting how provenance data interacts with privacy and security, testing systems in real-world scenarios, and monitoring human overrides. Applying those controls to CRM business assertions is an architectural inference, not a claim that NIST prescribes this graph.

Metrics that reveal whether resolution is working

Measure the control layer, not only agent task completion.

The last metric separates unforeseeable change from preventable resolution failure.

The source of truth is not enough

"Choose one source of truth" works for a narrow property. It does not solve a decision combining sales, billing, customer health, consent, ownership, and policy.

One source may govern each predicate, but no system owns every meaning. The goal is a governed way to compose authoritative assertions without hiding conflicts.

An agent needs more than context. It needs admissible context, provenance, constraints, and a reasoned path from evidence to action.

Frequently asked questions

What is a CRM assertion conflict?

A CRM assertion conflict occurs when claims about the same entity cannot safely govern one action. It may concern identity, time, authority, policy, lifecycle state, or derivation.

Why is more context not always better for an AI agent?

Additional context can introduce incompatible claims. Without provenance and resolution rules, an agent may blend them instead of recognizing a block or review requirement.

How should an AI agent resolve conflicting CRM data?

Use identity, source authority, predicate-specific freshness, policy or consent, then action consequence. Apply probabilistic reasoning only after removing ineligible assertions.

The control layer agents are missing

Enterprise AI agents act across systems built by different teams, timelines, and definitions of truth.

Do not flatten every system into one oversized record. Preserve claims, provenance, and conflicts long enough to make a governed decision.

When the Assertion Conflict Graph is in place, the agent does not need to pretend that the business has one perfectly clean reality. It can recognize disagreement, apply explicit rules, and choose the safest useful outcome: act, narrow, ask, escalate, or stop.

That is a more credible foundation for enterprise autonomy than a larger context window.

Vested-interest disclosure: INSIDEA is linked because I lead the company and its work includes HubSpot, CRM, RevOps, and AI services. The framework and recommendations in this article are independent analysis, not sponsored content.

Sources

1. HubSpot, Properties API
2. HubSpot, Using Object APIs, including property history
3. W3C, PROV Overview
4. W3C, Shapes Constraint Language (SHACL)
5. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
6. HackerNoon, Context Graphs: Building Production World Models for the Age of AI Agents